Update books
## reference
5 commits in 5d40ba5c2515caffa7790cda621239dc21ef5a72..04d5d5d7ba624b6f5016298451f3a63d557f3260
2020-06-06 20:25:36 -0700 to 2020-06-16 15:08:05 -0700
- Mention `feature="foo"` is a Cargo convention. (rust-lang-nursery/reference#833)
- fix out of date info on type aliases (rust-lang-nursery/reference#831)
- Fix an invalid variable name in the loop example (rust-lang-nursery/reference#832)
- Fix note about using proc_macro with Cargo. (rust-lang-nursery/reference#815)
- Add a link to the definition of Pattern_White_Space. (rust-lang-nursery/reference#824)
## book
7 commits in 30cd9dfe71c446de63826bb4472627af45acc9db..4e7c00bece1544d409312ec93467beb62b5bd0cb
2020-06-07 23:07:19 -0500 to 2020-06-19 09:39:12 -0400
- Link to the reference file that exists
- Link to the reference
- Clean up discussion around advanced lifetime stuff (rust-lang/book#2351)
- Reword Chapter 6 page 2, match (rust-lang/book#2374)
- Clarify some package/crate distinctions in chapter 14 (rust-lang/book#2373)
- Not mandatory with cargo 1.41.0-nightly (rust-lang/book#2368)
- Use same naming for Rhs as libcore/ops (rust-lang/book#2371)
## rust-by-example
4 commits in 7aa82129aa23e7e181efbeb8da03a2a897ef6afc..6f94ccb48da6fa4ed0031290f21411cf789f7d5e
2020-05-25 14:54:26 -0300 to 2020-06-20 17:51:30 -0300
- Update to mdbook 0.3.7 (rust-lang/rust-by-example#1352)
- Update fn.md (rust-lang/rust-by-example#1351)
- Fixed typo in formatted print (rust-lang/rust-by-example#1350)
- This explanation incorrectly inverts the meaning of SuperTrait (rust-lang/rust-by-example#1349)
## embedded-book
5 commits in 5555a97f04ad7974ac6fb8fb47c267c4274adf4a..616962ad0dd80f34d8b802da038d0aed9dd691bb
2020-05-25 18:00:51 +0000 to 2020-06-23 16:03:45 +0000
- Update RTFM name to RTIC, fixed links, updated singletons.md example. (rust-embedded/book#254)
- Note on how to rebuild if memory.x is changed (rust-embedded/book#253)
- Ease the readers into the Discovery book (rust-embedded/book#250)
- Provide a note on 'extern crate' usage in edition 2018 syntax of Rust (rust-embedded/book#248)
- Fix Typos and Improve Readability (rust-embedded/book#245)
Add re-exports to use suggestions
In the following example, an inaccessible path is suggested via `use foo::bar::X;` whereas an accessible public exported path can be suggested instead.
```rust
mod foo {
mod bar {
pub struct X;
}
pub use self::bar::X;
}
fn main() { X; }
```
This fixes the issue.
Change heuristic for determining range literal
Currently, rustc uses a heuristic to determine if a range expression is
not a literal based on whether the expression looks like a function call
or struct initialization. This fails for range literals whose
lower/upper bounds are the results of function calls. A possibly-better
heuristic is to check if the expression contains `..`, required in range
literals.
Of course, this is also not perfect; for example, if the range
expression is a struct which includes some text with `..` this will
fail, but in general I believe it is a better heuristic.
A better alternative altogether is to add the `QPath::LangItem` enum
variant suggested in #60607. I would be happy to do this as a precursor
to this patch if someone is able to provide general suggestions on how
usages of `QPath` need to be changed later in the compiler with the
`LangItem` variant.
Closes#73553
This commit adjusts the behaviour introduced in a previous commit so
that generic parameters and projections are only allowed in the
definitions mode - and are otherwise a bug. Generic parameters in
declarations are prohibited earlier in the compiler, so if that branch
were reached, it would be a bug.
Signed-off-by: David Wood <david@davidtw.co>
This commit changes the improper ctypes lint (when operating on
definitions) to consider raw pointers or references to sized types as
FFI-safe.
Signed-off-by: David Wood <david@davidtw.co>
This commit adds a new lint - `improper_ctypes_definitions` - which
functions identically to `improper_ctypes`, but on `extern "C" fn`
definitions (as opposed to `improper_ctypes`'s `extern "C" {}`
declarations).
Signed-off-by: David Wood <david@davidtw.co>
I know very little about rust, so I saw this example and tried to generalize it by writing,
```
let layout = Layout:🆕:<T>();
let new_obj = unsafe {
let ptr = alloc(layout) as *mut T;
*ptr = obj;
Box::from_raw(ptr)
};
```
for some more complicated `T`, which ended up crashing with SIGSEGV,
because it tried to `drop_in_place` the previous object in `ptr` which is
of course garbage. I also added a comment that explains why `.write`
is used, but I think adding that comment is optional and may be too verbose
here. I do however think that changing this example is a good idea to
suggest the correct generalization. `.write` is also used in most of the rest
of the documentation here, even if the example is `i32`, so it would additionally
be more consistent.
Always capture tokens for `macro_rules!` arguments
When we invoke a proc-macro, the `TokenStream` we pass to it may contain 'interpolated' AST fragments, represented by `rustc_ast::token::Nonterminal`. In order to correctly, pass a `Nonterminal` to a proc-macro, we need to have 'captured' its `TokenStream` at the time the AST was parsed.
Currently, we perform this capturing when attributes are present on items and expressions, since we will end up using a `Nonterminal` to pass the item/expr to any proc-macro attributes it is annotated with. However, `Nonterminal`s are also introduced by the expansion of metavariables in `macro_rules!` macros. Since these metavariables may be passed to proc-macros, we need to have tokens available to avoid the need to pretty-print and reparse (see https://github.com/rust-lang/rust/issues/43081).
This PR unconditionally performs token capturing for AST items and expressions that are passed to a `macro_rules!` invocation. We cannot know in advance if captured item/expr will be passed to proc-macro, so this is needed to ensure that tokens will always be available when they are needed.
This ensures that proc-macros will receive tokens with proper `Spans` (both location and hygiene) in more cases. Like all work on https://github.com/rust-lang/rust/issues/43081, this will cause regressions in proc-macros that were relying on receiving tokens with dummy spans.
In this case, Crater revealed only one regression: the [Pear](https://github.com/SergioBenitez/Pear) crate (a helper for [rocket](https://github.com/SergioBenitez/Rocket)), which was previously [fixed](https://github.com/SergioBenitez/Pear/pull/25) as part of https://github.com/rust-lang/rust/pull/73084.
This regression manifests itself as the following error:
```
[INFO] [stdout] error: proc macro panicked
[INFO] [stdout] --> /opt/rustwide/cargo-home/registry/src/github.com-1ecc6299db9ec823/rocket_http-0.4.5/src/parse/uri/parser.rs:119:34
[INFO] [stdout] |
[INFO] [stdout] 119 | let path_and_query = pear_try!(path_and_query(is_pchar));
[INFO] [stdout] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[INFO] [stdout] |
[INFO] [stdout] = help: message: called `Option::unwrap()` on a `None` value
[INFO] [stdout] = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)
```
It can be fixed by running `cargo update -p pear`, which updates your `Cargo.lock` to use the latest version of Pear (which includes a bugfix for the regression).
Split out from https://github.com/rust-lang/rust/pull/73084/
rustc: Modernize wasm checks for atomics
This commit modernizes how rustc checks for whether the `atomics`
feature is enabled for the wasm target. The `sess.target_features` set
is consulted instead of fiddling around with dealing with various
aspects of LLVM and that syntax.
