rts: Replace `nat` with `uint32_t`

Summary:
The `nat` type was an alias for `unsigned int` with a comment saying
it was at least 32 bits. We keep the typedef in case client code is
using it but mark it as deprecated.

Test Plan: Validated on Linux, OS X and Windows

Reviewers: simonmar, austin, thomie, hvr, bgamari, hsyl20

Differential Revision: https://phabricator.haskell.org/D2166

1 files changed, 5 insertions, 5 deletions

diff --git a/rts/RaiseAsync.c b/rts/RaiseAsync.c
index f55a4c23de..65bea123d9 100644
--- a/rts/RaiseAsync.c
+++ b/rts/RaiseAsync.c
@@ -93,7 +93,7 @@ suspendComputation (Capability *cap, StgTSO *tso, StgUpdateFrame *stop_here)
    throwTo().
 
    Note [Throw to self when masked]
-   
+
    When a StackOverflow occurs when the thread is masked, we want to
    defer the exception to when the thread becomes unmasked/hits an
    interruptible point.  We already have a mechanism for doing this,
@@ -103,26 +103,26 @@ suspendComputation (Capability *cap, StgTSO *tso, StgUpdateFrame *stop_here)
    multithreaded nonsense). Morally, a stack overflow should be an
    asynchronous exception sent by a thread to itself, and it should
    have the same semantics.  But there are a few key differences:
-   
+
    - If you actually tried to send an asynchronous exception to
      yourself using throwTo, the exception would actually immediately
      be delivered.  This is because throwTo itself is considered an
      interruptible point, so the exception is always deliverable. Thus,
      ordinarily, we never end up with a message to onesself in the
      blocked_exceptions queue.
-   
+
    - In the case of a StackOverflow, we don't actually care about the
      wakeup semantics; when an exception is delivered, the thread that
      originally threw the exception should be woken up, since throwTo
      blocks until the exception is successfully thrown.  Fortunately,
      it is harmless to wakeup a thread that doesn't actually need waking
      up, e.g. ourselves.
-   
+
    - No synchronization is necessary, because we own the TSO and the
      capability.  You can observe this by tracing through the execution
      of throwTo.  We skip synchronizing the message and inter-capability
      communication.
-   
+
    We think this doesn't break any invariants, but do be careful!
    -------------------------------------------------------------------------- */