]> git.lizzy.rs Git - rust.git/commitdiff
insignificant fix to rust manual and tutorial
authorLiigo Zhuang <com.liigo@gmail.com>
Tue, 18 Feb 2014 07:03:09 +0000 (15:03 +0800)
committerLiigo Zhuang <com.liigo@gmail.com>
Fri, 21 Feb 2014 09:48:36 +0000 (17:48 +0800)
src/doc/rust.md
src/doc/tutorial.md

index c605ed06ffd1f8858bf72dd6ad4c6874dbcef10d..bdf3413e399c01fdd585d3b32a07e6eb0a20ccab 100644 (file)
@@ -752,27 +752,27 @@ mod task {
 #### View items
 
 ~~~~ {.ebnf .gram}
-view_item : extern_mod_decl | use_decl ;
+view_item : extern_crate_decl | use_decl ;
 ~~~~
 
 A view item manages the namespace of a module.
 View items do not define new items, but rather, simply change other items' visibility.
 There are several kinds of view item:
 
- * [`extern crate` declarations](#extern-mod-declarations)
+ * [`extern crate` declarations](#extern-crate-declarations)
  * [`use` declarations](#use-declarations)
 
-##### Extern mod declarations
+##### Extern crate declarations
 
 ~~~~ {.ebnf .gram}
-extern_mod_decl : "extern" "mod" ident [ '(' link_attrs ')' ] ? [ '=' string_lit ] ? ;
+extern_crate_decl : "extern" "crate" ident [ '(' link_attrs ')' ] ? [ '=' string_lit ] ? ;
 link_attrs : link_attr [ ',' link_attrs ] + ;
 link_attr : ident '=' literal ;
 ~~~~
 
 An _`extern crate` declaration_ specifies a dependency on an external crate.
-The external crate is then bound into the declaring scope
-as the `ident` provided in the `extern_mod_decl`.
+The external crate is then bound into the declaring scope as the `ident` provided
+in the `extern_crate_decl`.
 
 The external crate is resolved to a specific `soname` at compile time, and a
 runtime linkage requirement to that `soname` is passed to the linker for
@@ -780,7 +780,7 @@ loading at runtime.  The `soname` is resolved at compile time by scanning the
 compiler's library path and matching the optional `crateid` provided as a string literal
 against the `crateid` attributes that were declared on the external crate when
 it was compiled.  If no `crateid` is provided, a default `name` attribute is
-assumed, equal to the `ident` given in the `extern_mod_decl`.
+assumed, equal to the `ident` given in the `extern_crate_decl`.
 
 Four examples of `extern crate` declarations:
 
@@ -813,7 +813,7 @@ module item. These declarations may appear at the top of [modules](#modules) and
 
 *Note*: Unlike in many languages,
 `use` declarations in Rust do *not* declare linkage dependency with external crates.
-Rather, [`extern crate` declarations](#extern-mod-declarations) declare linkage dependencies.
+Rather, [`extern crate` declarations](#extern-crate-declarations) declare linkage dependencies.
 
 Use declarations support a number of convenient shortcuts:
 
index 6ae8c1d704d6a89f41f3e8e074b71f789d57ef72..6454e22b896a445eb8ab4d11207b728c0c346276 100644 (file)
@@ -495,8 +495,7 @@ reject the previous example if the arm with the wildcard pattern was
 omitted.
 
 A powerful application of pattern matching is *destructuring*:
-matching in order to bind names to the contents of data
-types.
+matching in order to bind names to the contents of data types.
 
 > ***Note:*** The following code makes use of tuples (`(f64, f64)`) which
 > are explained in section 5.3. For now you can think of tuples as a list of
@@ -2726,7 +2725,8 @@ pub mod barn {
 
 In short, `mod foo;` is just syntactic sugar for `mod foo { /* content of <...>/foo.rs or <...>/foo/mod.rs */ }`.
 
-This also means that having two or more identical `mod foo;` declarations somewhere in your crate hierarchy is generally a bad idea,
+This also means that having two or more identical `mod foo;` declarations
+somewhere in your crate hierarchy is generally a bad idea,
 just like copy-and-paste-ing a module into multiple places is a bad idea.
 Both will result in duplicate and mutually incompatible definitions.
 
@@ -3074,11 +3074,6 @@ fn main() {
 It's a bit weird, but it's the result of shadowing rules that have been set that way because
 they model most closely what people expect to shadow.
 
-## Package ids
-
-If you use `extern crate`, per default `rustc` will look for libraries in the library search path (which you can
-extend with the `-L` switch).
-
 ## Crate metadata and settings
 
 For every crate you can define a number of metadata items, such as link name, version or author.
@@ -3096,14 +3091,13 @@ Therefore, if you plan to compile your crate as a library, you should annotate i
 // `lib.rs`
 
 # #[crate_type = "lib"];
-// Package ID
 #[crate_id = "farm#2.5"];
 
 // ...
 # fn farm() {}
 ~~~~
 
-You can also specify package ID information in a `extern crate` statement.  For
+You can also specify crate id information in a `extern crate` statement.  For
 example, these `extern crate` statements would both accept and select the
 crate define above:
 
@@ -3161,7 +3155,7 @@ Now compile and run like this (adjust to your platform if necessary):
 Notice that the library produced contains the version in the file name
 as well as an inscrutable string of alphanumerics. As explained in the previous paragraph,
 these are both part of Rust's library versioning scheme. The alphanumerics are
-a hash representing the crates package ID.
+a hash representing the crates id.
 
 ## The standard library and the prelude
 
@@ -3231,8 +3225,7 @@ library.  You can link to a library such as `extra` with an `extern crate extra;
 [extra library]: extra/index.html
 
 Right now `extra` contains those definitions directly, but in the future it will likely just
-re-export a bunch of 'officially blessed' crates that get managed with a
-package manager.
+re-export a bunch of 'officially blessed' crates that get managed with a package manager.
 
 # What next?