jyapayne/Nim
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Change wording in some parts. Fix some typos.

Browse source
This commit is contained in:
Oscar Campbell 2015-05-25 05:24:47 +02:00
commit feff2bae68
11 changed files with 71 additions and 60 deletions
Download patch file Download diff file Expand all files Collapse all files

19
doc/manual/pragmas.txt
View file

@ -18,9 +18,7 @@ The deprecated pragma is used to mark a symbol as deprecated:
proc p() {.deprecated.}
var x {.deprecated.}: char
It can also be used as a statement. Then it takes a list of *renamings*. The
upcoming ``nimfix`` tool can automatically update the code and perform these
renamings:
It can also be used as a statement, in that case it takes a list of *renamings*.
.. code-block:: nim
type
@ -28,6 +26,8 @@ renamings:
Stream = ref object
{.deprecated: [TFile: File, PStream: Stream].}
The ``nimfix`` tool can be used to, without effort, automatically update your code and refactor it by performing these renamings.
noSideEffect pragma
-------------------
@ -54,9 +54,7 @@ destructor pragma
-----------------
The ``destructor`` pragma is used to mark a proc to act as a type destructor.
Its usage is deprecated, use the ``override`` pragma instead.
See `type bound operations`_.
Its usage is deprecated, See `type bound operations`_ instead.
override pragma
---------------
@ -371,7 +369,7 @@ The ``register`` pragma is for variables only. It declares the variable as
in a hardware register for faster access. C compilers usually ignore this
though and for good reasons: Often they do a better job without it anyway.
In highly specific cases (a dispatch loop of an bytecode interpreter for
In highly specific cases (a dispatch loop of a bytecode interpreter for
example) it may provide benefits, though.
@ -429,13 +427,10 @@ Example:
2. When a top level call is encountered (usually at the very end of the module),
the compiler will try to determine the actual types of all of the symbols in the
matching overload set. This is a potentially recursive process as the signatures
of the symbols may include other call expressions, whoose types will be resolved
of the symbols may include other call expressions, whose types will be resolved
at this point too.
3. Finally, after the best overload is picked, the compiler will start compiling
the body of the respective symbol. This in turn will lead the compiler to discover
more call expresions that need to be resolved and steps 2 and 3 will be repeated
as necessary.
3. Finally, after the best overload is picked, the compiler will start compiling the body of the respective symbol. This in turn will lead the compiler to discover more call expressions that need to be resolved and steps 2 and 3 will be repeated as necessary.
Please note that if a callable symbol is never used in this scenario, its body
will never be compiled. This is the default behavior leading to best compilation