diff --git a/src/doc/style/style/comments.md b/src/doc/style/style/comments.md index b2d2d9ab6b4d6..3851187b52034 100644 --- a/src/doc/style/style/comments.md +++ b/src/doc/style/style/comments.md @@ -85,3 +85,20 @@ Use inner doc comments _only_ to document crates and file-level modules: //! //! The core library is a something something... ``` + +### Explain context. + +Rust doesn't have special constructors, only functions that return new +instances. These aren't visible in the automatically generated documentation +for a type, so you should specifically link to them: + +``` rust +/// An iterator that yields `None` forever after the underlying iterator +/// yields `None` once. +/// +/// These can be created through +/// [`iter.fuse()`](trait.Iterator.html#method.fuse). +pub struct Fuse { + // ... +} +``` diff --git a/src/doc/trpl/advanced-linking.md b/src/doc/trpl/advanced-linking.md index 921f27336f2dd..9ef6d5c2bffbb 100644 --- a/src/doc/trpl/advanced-linking.md +++ b/src/doc/trpl/advanced-linking.md @@ -26,7 +26,7 @@ shells out to the system linker (`gcc` on most systems, `link.exe` on MSVC), so it makes sense to provide extra command line arguments, but this will not always be the case. In the future `rustc` may use LLVM directly to link native libraries, in which case `link_args` will have no -meaning. You can achieve the same effect as the `link-args` attribute with the +meaning. You can achieve the same effect as the `link_args` attribute with the `-C link-args` argument to `rustc`. It is highly recommended to *not* use this attribute, and rather use the more @@ -71,7 +71,7 @@ Dynamic linking on Linux can be undesirable if you wish to use new library features on old systems or target systems which do not have the required dependencies for your program to run. -Static linking is supported via an alternative `libc`, `musl`. You can compile +Static linking is supported via an alternative `libc`, [`musl`](http://www.musl-libc.org). You can compile your own version of Rust with `musl` enabled and install it into a custom directory with the instructions below: diff --git a/src/doc/trpl/closures.md b/src/doc/trpl/closures.md index 983af4a0efe7f..7d4452a4c8470 100644 --- a/src/doc/trpl/closures.md +++ b/src/doc/trpl/closures.md @@ -1,9 +1,10 @@ % Closures -Rust not only has named functions, but anonymous functions as well. Anonymous -functions that have an associated environment are called ‘closures’, because they -close over an environment. Rust has a really great implementation of them, as -we’ll see. +Sometimes it is useful to wrap up a function and _free variables_ for better +clarity and reuse. The free variables that can be used come from the +enclosing scope and are ‘closed over’ when used in the function. From this, we +get the name ‘closures’ and Rust provides a really great implementation of +them, as we’ll see. # Syntax @@ -34,7 +35,7 @@ assert_eq!(4, plus_two(2)); ``` You’ll notice a few things about closures that are a bit different from regular -functions defined with `fn`. The first is that we did not need to +named functions defined with `fn`. The first is that we did not need to annotate the types of arguments the closure takes or the values it returns. We can: @@ -44,14 +45,15 @@ let plus_one = |x: i32| -> i32 { x + 1 }; assert_eq!(2, plus_one(1)); ``` -But we don’t have to. Why is this? Basically, it was chosen for ergonomic reasons. -While specifying the full type for named functions is helpful with things like -documentation and type inference, the types of closures are rarely documented -since they’re anonymous, and they don’t cause the kinds of error-at-a-distance -problems that inferring named function types can. +But we don’t have to. Why is this? Basically, it was chosen for ergonomic +reasons. While specifying the full type for named functions is helpful with +things like documentation and type inference, the full type signatures of +closures are rarely documented since they’re anonymous, and they don’t cause +the kinds of error-at-a-distance problems that inferring named function types +can. -The second is that the syntax is similar, but a bit different. I’ve added spaces -here for easier comparison: +The second is that the syntax is similar, but a bit different. I’ve added +spaces here for easier comparison: ```rust fn plus_one_v1 (x: i32) -> i32 { x + 1 } @@ -63,8 +65,8 @@ Small differences, but they’re similar. # Closures and their environment -Closures are called such because they ‘close over their environment’. It -looks like this: +The environment for a closure can include bindings from its enclosing scope in +addition to parameters and local bindings. It looks like this: ```rust let num = 5; @@ -197,9 +199,10 @@ frame. Without `move`, a closure may be tied to the stack frame that created it, while a `move` closure is self-contained. This means that you cannot generally return a non-`move` closure from a function, for example. -But before we talk about taking and returning closures, we should talk some more -about the way that closures are implemented. As a systems language, Rust gives -you tons of control over what your code does, and closures are no different. +But before we talk about taking and returning closures, we should talk some +more about the way that closures are implemented. As a systems language, Rust +gives you tons of control over what your code does, and closures are no +different. # Closure implementation @@ -288,9 +291,9 @@ isn’t interesting. The next part is: # some_closure(1) } ``` -Because `Fn` is a trait, we can bound our generic with it. In this case, our closure -takes a `i32` as an argument and returns an `i32`, and so the generic bound we use -is `Fn(i32) -> i32`. +Because `Fn` is a trait, we can bound our generic with it. In this case, our +closure takes a `i32` as an argument and returns an `i32`, and so the generic +bound we use is `Fn(i32) -> i32`. There’s one other key point here: because we’re bounding a generic with a trait, this will get monomorphized, and therefore, we’ll be doing static @@ -452,7 +455,7 @@ autogenerated name. The error also points out that the return type is expected to be a reference, but what we are trying to return is not. Further, we cannot directly assign a `'static` lifetime to an object. So we'll take a different approach and return -a "trait object" by `Box`ing up the `Fn`. This _almost_ works: +a ‘trait object’ by `Box`ing up the `Fn`. This _almost_ works: ```rust,ignore fn factory() -> Box i32> { diff --git a/src/doc/trpl/crates-and-modules.md b/src/doc/trpl/crates-and-modules.md index 63eccc12b0f65..4a4648c7b563f 100644 --- a/src/doc/trpl/crates-and-modules.md +++ b/src/doc/trpl/crates-and-modules.md @@ -563,8 +563,8 @@ What's going on here? First, both `extern crate` and `use` allow renaming the thing that is being imported. So the crate is still called "phrases", but here we will refer to it as "sayings". Similarly, the first `use` statement pulls in the -`japanese::farewells` module from the crate, but makes it available as -`jp_farewells` as opposed to simply `farewells`. This can help to avoid +`japanese::greetings` module from the crate, but makes it available as +`ja_greetings` as opposed to simply `greetings`. This can help to avoid ambiguity when importing similarly-named items from different places. The second `use` statement uses a star glob to bring in _all_ symbols from the diff --git a/src/doc/trpl/iterators.md b/src/doc/trpl/iterators.md index 6d1e66b67334f..3350df4ff7f18 100644 --- a/src/doc/trpl/iterators.md +++ b/src/doc/trpl/iterators.md @@ -42,12 +42,12 @@ loop is just a handy way to write this `loop`/`match`/`break` construct. `for` loops aren't the only thing that uses iterators, however. Writing your own iterator involves implementing the `Iterator` trait. While doing that is outside of the scope of this guide, Rust provides a number of useful iterators -to accomplish various tasks. Before we talk about those, we should talk about a -Rust anti-pattern. And that's using ranges like this. +to accomplish various tasks. But first, a few notes about limitations of ranges. -Yes, we just talked about how ranges are cool. But ranges are also very -primitive. For example, if you needed to iterate over the contents of a vector, -you may be tempted to write this: +Ranges are very primitive, and we often can use better alternatives. Consider +following Rust anti-pattern: using ranges to emulate a C-style `for` loop. Let’s +suppose you needed to iterate over the contents of a vector. You may be tempted +to write this: ```rust let nums = vec![1, 2, 3]; @@ -281,8 +281,8 @@ If you are trying to execute a closure on an iterator for its side effects, just use `for` instead. There are tons of interesting iterator adapters. `take(n)` will return an -iterator over the next `n` elements of the original iterator. Let's try it out with our infinite -iterator from before: +iterator over the next `n` elements of the original iterator. Let's try it out +with an infinite iterator: ```rust for i in (1..).take(5) { diff --git a/src/doc/trpl/lifetimes.md b/src/doc/trpl/lifetimes.md index 4896be714bb89..23569dd1b917e 100644 --- a/src/doc/trpl/lifetimes.md +++ b/src/doc/trpl/lifetimes.md @@ -43,11 +43,11 @@ With that in mind, let’s learn about lifetimes. Lending out a reference to a resource that someone else owns can be complicated. For example, imagine this set of operations: -- I acquire a handle to some kind of resource. -- I lend you a reference to the resource. -- I decide I’m done with the resource, and deallocate it, while you still have +1. I acquire a handle to some kind of resource. +2. I lend you a reference to the resource. +3. I decide I’m done with the resource, and deallocate it, while you still have your reference. -- You decide to use the resource. +4. You decide to use the resource. Uh oh! Your reference is pointing to an invalid resource. This is called a dangling pointer or ‘use after free’, when the resource is memory. diff --git a/src/doc/trpl/patterns.md b/src/doc/trpl/patterns.md index a365732fe9bd1..3d22066c72574 100644 --- a/src/doc/trpl/patterns.md +++ b/src/doc/trpl/patterns.md @@ -299,7 +299,7 @@ match x { ``` This prints `no`, because the `if` applies to the whole of `4 | 5`, and not to -just the `5`, In other words, the the precedence of `if` behaves like this: +just the `5`. In other words, the precedence of `if` behaves like this: ```text (4 | 5) if y => ... diff --git a/src/libcore/option.rs b/src/libcore/option.rs index d1bb65d22904a..0e4c6d1676e63 100644 --- a/src/libcore/option.rs +++ b/src/libcore/option.rs @@ -706,7 +706,8 @@ impl Option { } impl<'a, T: Clone> Option<&'a T> { - /// Maps an Option<&T> to an Option by cloning the contents of the Option. + /// Maps an `Option<&T>` to an `Option` by cloning the contents of the + /// option. #[stable(feature = "rust1", since = "1.0.0")] pub fn cloned(self) -> Option { self.map(|t| t.clone()) diff --git a/src/librustc_trans/diagnostics.rs b/src/librustc_trans/diagnostics.rs index dd7c3834e564a..05236a7a6fb28 100644 --- a/src/librustc_trans/diagnostics.rs +++ b/src/librustc_trans/diagnostics.rs @@ -12,6 +12,21 @@ register_long_diagnostics! { +E0515: r##" +A constant index expression was out of bounds. Erroneous code example: + +``` +let x = &[0, 1, 2][7]; // error: const index-expr is out of bounds +``` + +Please specify a valid index (not inferior to 0 or superior to array length). +Example: + +``` +let x = &[0, 1, 2][2]; // ok! +``` +"##, + } register_diagnostics! { diff --git a/src/librustc_trans/trans/consts.rs b/src/librustc_trans/trans/consts.rs index 8e63f2788ed26..0cae0ae59ba57 100644 --- a/src/librustc_trans/trans/consts.rs +++ b/src/librustc_trans/trans/consts.rs @@ -628,8 +628,8 @@ fn const_expr_unadjusted<'a, 'tcx>(cx: &CrateContext<'a, 'tcx>, if iv >= len { // FIXME #3170: report this earlier on in the const-eval // pass. Reporting here is a bit late. - cx.sess().span_err(e.span, - "const index-expr is out of bounds"); + span_err!(cx.sess(), e.span, E0515, + "const index-expr is out of bounds"); C_undef(val_ty(arr).element_type()) } else { const_get_elt(cx, arr, &[iv as c_uint]) diff --git a/src/test/run-pass/lexer-crlf-line-endings-string-literal-doc-comment.rs b/src/test/run-pass/lexer-crlf-line-endings-string-literal-doc-comment.rs index 10bf096dae7f7..5c8db524cc2ed 100644 --- a/src/test/run-pass/lexer-crlf-line-endings-string-literal-doc-comment.rs +++ b/src/test/run-pass/lexer-crlf-line-endings-string-literal-doc-comment.rs @@ -1,7 +1,7 @@ // ignore-tidy-cr ignore-license // ignore-tidy-cr (repeated again because of tidy bug) // license is ignored because tidy can't handle the CRLF here properly. - + // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. @@ -11,33 +11,33 @@ // , at your // option. This file may not be copied, modified, or distributed // except according to those terms. - + // NB: this file needs CRLF line endings. The .gitattributes file in // this directory should enforce it. - + // ignore-pretty - + /// Doc comment that ends in CRLF pub fn foo() {} - + /** Block doc comment that * contains CRLF characters */ pub fn bar() {} - + fn main() { let s = "string literal"; assert_eq!(s, "string\nliteral"); - + let s = "literal with \ escaped newline"; assert_eq!(s, "literal with escaped newline"); - + let s = r"string literal"; assert_eq!(s, "string\nliteral"); - + // validate that our source file has CRLF endings let source = include_str!("lexer-crlf-line-endings-string-literal-doc-comment.rs"); assert!(source.contains("string\r\nliteral"));