@@ -208,7 +208,7 @@ The keywords are the following strings:
208208~~~~ {.notrust .keyword}
209209as
210210box break
211- crate
211+ continue crate
212212else enum extern
213213false fn for
214214if impl in
@@ -2924,18 +2924,16 @@ while i < 10 {
29242924
29252925### Infinite loops
29262926
2927- The keyword ` loop ` in Rust appears both in _ loop expressions_ and in _ continue expressions_ .
2928- A loop expression denotes an infinite loop;
2929- see [ Continue expressions] ( #continue-expressions ) for continue expressions.
2927+ A ` loop ` expression denotes an infinite loop.
29302928
29312929~~~~ {.notrust .ebnf .gram}
29322930loop_expr : [ lifetime ':' ] "loop" '{' block '}';
29332931~~~~
29342932
29352933A ` loop ` expression may optionally have a _ label_ .
29362934If a label is present,
2937- then labeled ` break ` and ` loop ` expressions nested within this loop may exit out of this loop or return control to its head.
2938- See [ Break expressions] ( #break-expressions ) .
2935+ then labeled ` break ` and ` continue ` expressions nested within this loop may exit out of this loop or return control to its head.
2936+ See [ Break expressions] ( #break-expressions ) and [ Continue expressions ] ( #continue-expressions ) .
29392937
29402938### Break expressions
29412939
@@ -2953,21 +2951,21 @@ but must enclose it.
29532951### Continue expressions
29542952
29552953~~~~ {.notrust .ebnf .gram}
2956- continue_expr : "loop " [ lifetime ];
2954+ continue_expr : "continue " [ lifetime ];
29572955~~~~
29582956
2959- A continue expression, written ` loop ` , also has an optional ` label ` .
2957+ A ` continue ` expression has an optional ` label ` .
29602958If the label is absent,
2961- then executing a ` loop ` expression immediately terminates the current iteration of the innermost loop enclosing it,
2959+ then executing a ` continue ` expression immediately terminates the current iteration of the innermost loop enclosing it,
29622960returning control to the loop * head* .
29632961In the case of a ` while ` loop,
29642962the head is the conditional expression controlling the loop.
29652963In the case of a ` for ` loop, the head is the call-expression controlling the loop.
2966- If the label is present, then ` loop foo` returns control to the head of the loop with label ` foo ` ,
2964+ If the label is present, then ` continue foo` returns control to the head of the loop with label ` foo ` ,
29672965which need not be the innermost label enclosing the ` break ` expression,
29682966but must enclose it.
29692967
2970- A ` loop ` expression is only permitted in the body of a loop.
2968+ A ` continue ` expression is only permitted in the body of a loop.
29712969
29722970### For expressions
29732971
@@ -4008,45 +4006,45 @@ compiler must at some point make a choice between these two formats. With this
40084006in mind, the compiler follows these rules when determining what format of
40094007dependencies will be used:
40104008
4011- 1 . If a dynamic library is being produced, then it is required for all upstream
4012- Rust dependencies to also be dynamic. This is a limitation of the current
4013- implementation of the linkage model. The reason behind this limitation is to
4014- prevent multiple copies of the same upstream library from showing up, and in
4015- the future it is planned to support a mixture of dynamic and static linking.
4016-
4017- When producing a dynamic library, the compiler will generate an error if an
4018- upstream dependency could not be found, and also if an upstream dependency
4019- could only be found in an ` rlib ` format. Remember that ` staticlib ` formats
4020- are always ignored by ` rustc ` for crate-linking purposes.
4021-
4022- 2 . If a static library is being produced, all upstream dependencies are
4009+ 1 . If a static library is being produced, all upstream dependencies are
40234010 required to be available in ` rlib ` formats. This requirement stems from the
4024- same reasons that a dynamic library must have all dynamic dependencies .
4011+ reason that a dynamic library cannot be converted into a static format .
40254012
40264013 Note that it is impossible to link in native dynamic dependencies to a static
40274014 library, and in this case warnings will be printed about all unlinked native
40284015 dynamic dependencies.
40294016
4030- 3 . If an ` rlib ` file is being produced, then there are no restrictions on what
4017+ 2 . If an ` rlib ` file is being produced, then there are no restrictions on what
40314018 format the upstream dependencies are available in. It is simply required that
40324019 all upstream dependencies be available for reading metadata from.
40334020
40344021 The reason for this is that ` rlib ` files do not contain any of their upstream
40354022 dependencies. It wouldn't be very efficient for all ` rlib ` files to contain a
40364023 copy of ` libstd.rlib ` !
40374024
4038- 4 . If an executable is being produced, then things get a little interesting. As
4039- with the above limitations in dynamic and static libraries, it is required
4040- for all upstream dependencies to be in the same format. The next question is
4041- whether to prefer a dynamic or a static format. The compiler currently favors
4042- static linking over dynamic linking, but this can be inverted with the `-C
4043- prefer-dynamic` flag to the compiler.
4044-
4045- What this means is that first the compiler will attempt to find all upstream
4046- dependencies as ` rlib ` files, and if successful, it will create a statically
4047- linked executable. If an upstream dependency is missing as an ` rlib ` file,
4048- then the compiler will force all dependencies to be dynamic and will generate
4049- errors if dynamic versions could not be found.
4025+ 3 . If an executable is being produced and the ` -C prefer-dynamic ` flag is not
4026+ specified, then dependencies are first attempted to be found in the ` rlib `
4027+ format. If some dependencies are not available in an rlib format, then
4028+ dynamic linking is attempted (see below).
4029+
4030+ 4 . If a dynamic library or an executable that is being dynamically linked is
4031+ being produced, then the compiler will attempt to reconcile the available
4032+ dependencies in either the rlib or dylib format to create a final product.
4033+
4034+ A major goal of the compiler is to ensure that a library never appears more
4035+ than once in any artifact. For example, if dynamic libraries B and C were
4036+ each statically linked to library A, then a crate could not link to B and C
4037+ together because there would be two copies of A. The compiler allows mixing
4038+ the rlib and dylib formats, but this restriction must be satisfied.
4039+
4040+ The compiler currently implements no method of hinting what format a library
4041+ should be linked with. When dynamically linking, the compiler will attempt to
4042+ maximize dynamic dependencies while still allowing some dependencies to be
4043+ linked in via an rlib.
4044+
4045+ For most situations, having all libraries available as a dylib is recommended
4046+ if dynamically linking. For other situations, the compiler will emit a
4047+ warning if it is unable to determine which formats to link each library with.
40504048
40514049In general, ` --crate-type=bin ` or ` --crate-type=lib ` should be sufficient for
40524050all compilation needs, and the other options are just available if more
0 commit comments