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
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.
The const propagator cannot trace references.
Thus we avoid propagation of a local the moment we encounter references to it.
fixes#73609
cc @RalfJung
r? @wesleywiser
Point at the call span when overflow occurs during monomorphization
This improves the output for issue #72577, but there's still more work
to be done.
Currently, an overflow error during monomorphization results in an error
that points at the function we were unable to monomorphize. However, we
don't point at the call that caused the monomorphization to happen. In
the overflow occurs in a large recursive function, it may be difficult
to determine where the issue is.
This commit tracks and `Span` information during collection of
`MonoItem`s, which is used when emitting an overflow error. `MonoItem`
itself is unchanged, so this only affects
`src/librustc_mir/monomorphize/collector.rs`
Move remaining `NodeId` APIs from `Definitions` to `Resolver`
Implements https://github.com/rust-lang/rust/pull/73291#issuecomment-643515557
TL;DR: it moves all fields that are only needed during name resolution passes into the `Resolver` and keep the rest in `Definitions`. This effectively enforces that all references to `NodeId`s are gone once HIR lowering is completed.
After this, the only remaining work for #50928 should be to adjust the dev guide.
r? @petrochenkov
Fix -Z unpretty=everybody_loops
It turns out that this has not been working for who knows how long.
Previously:
```
pub fn h() { 1 + 2; }
```
After this change:
```
pub fn h() { loop { } }
```
This only affected the pass when run with the command line
pretty-printing option, so rustdoc was still replacing bodies with
`loop {}`.
code coverage foundation for hash and num_counters
This PR is the next iteration after PR #73011 (which is still waiting on bors to merge).
@wesleywiser - PTAL
r? @tmandry
(FYI, I'm also working on injecting the coverage maps, in another branch, while waiting for these to merge.)
Thanks!
Check for assignments between non-conflicting generator saved locals
This is to prevent future changes to the generator transform from reintroducing the problem that caused #73137. Namely, a store between two generator saved locals whose storage does not conflict.
My ultimate goal is to introduce a modified version of #71956 that handles this case properly.
r? @tmandry
Mention that BTreeMap::new() doesn't allocate
I think it would be nice to mention this, so you don't have to dig through the src to look at the definition of new().
rustdoc: Fix doc aliases with crate filtering
Fix a crash when searching for an alias contained in the currently selected filter crate.
Also remove alias search results for crates that should be filtered out.
The test suite needed to be fixed to actually take into account the crate filtering and check that there are no results when none are expected.
Needs to be backported to beta to fix the `std` docs.
Fixes#73620
r? @GuillaumeGomez
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.
In the following example, an inaccessible path is suggested via
`use foo::bar::X;` whereas an accessible public exported path can
be suggested instead.
```
mod foo {
mod bar {
pub struct X;
}
pub use self::bar::X;
}
fn main() { X; }
```
This fixes the issue.
Fix a crash when searching for an alias contained in the currently selected filter crate.
Also remove alias search results for crates that should be filtered out.
The test suite needed to be fixed to actually take into account the crate filtering and check that there are no results when none are expected.
bootstrap: no `config.toml` exists regression
Fixes#73574.
This PR fixes a regression introduced in #73317 where an oversight meant that `config.toml` was assumed to exist.
Fix typos in doc comments
Hello 🦀 ,
This commit fixes typos in the doc comments of 'librustc_mir/monomorphize/collector.rs'
Thank you for reviewing this PR 👍
Add second message for LiveDrop errors
This is an attempt to fix https://github.com/rust-lang/rust/issues/72907 by adding a second message to the `LiveDrop` diagnostics. Changing from this
```
error[E0493]: destructors cannot be evaluated at compile-time
--> src/lib.rs:7:9
|
7 | let mut always_returned = None;
| ^^^^^^^^^^^^^^^^^^^ constants cannot evaluate destructors
error: aborting due to previous error
```
to this
```
error[E0493]: destructors cannot be evaluated at compile-time
--> foo.rs:6:9
|
6 | let mut always_returned = None;
| ^^^^^^^^^^^^^^^^^^^ constants cannot evaluate destructors
...
10 | always_returned = never_returned;
| --------------- value is dropped here
error: aborting due to previous error
```
r? @RalfJung @ecstatic-morse
Account for multiple impl/dyn Trait in return type when suggesting `'_`
Make `impl` and `dyn` Trait lifetime suggestions a bit more resilient.
Follow up to #72804.
r? @nikomatsakis
move leak-check to during coherence, candidate eval
Implementation of MCP https://github.com/rust-lang/compiler-team/issues/295.
I'd like to do a crater run on this.
Note to @rust-lang/lang: This PR is a breaking change (bugfix). It causes tests like the following to go from a future-compatibility warning #56105 to a hard error:
```rust
trait Trait {}
impl Trait for for<'a, 'b> fn(&'a u32, &'b u32) {}
impl Trait for for<'c> fn(&'c u32, &'c u32) {} // now rejected, used to warn
```
I am not aware of any instances of this code in the wild, but that is why we are doing a crater run. The reason for this change is that those two types are, in fact, the same type, and hence the two impls are overlapping.
There will still be impls that trigger #56105 after this lands, however -- I hope that we will eventually just accept those impls without warning, for the most part. One example of such an impl is this pattern, which is used by wasm-bindgen and other crates as well:
```rust
trait Trait {}
impl<T> Trait for fn(&T) { }
impl<T> Trait for fn(T) { } // still accepted, but warns
```
Improve compiler error message for wrong generic parameter order
- Added optional "help" parameter that shows a help message on the compiler error if required.
- Added a simple ordered parameter as a sample help.
@varkor will make more changes as required. Let me know if I'm heading in the right direction.
Fixes#68437
r? @varkor
Also added FIXME comments to note the possible need to accommodate
counter increment calls in source-based functions that differ from the
function context of the caller instance (e.g., inline functions).
Rollup of 7 pull requests
Successful merges:
- #71756 (add Windows system error codes that should map to io::ErrorKind::TimedOut)
- #73495 (Converted all platform-specific stdin/stdout/stderr implementations to use io:: traits)
- #73575 (Fix typo in error_codes doc)
- #73578 (Make is_freeze and is_copy_modulo_regions take TyCtxtAt)
- #73586 (switch_ty is redundant)
- #73600 (Fix spurious 'value moved here in previous iteration of loop' messages)
- #73610 (Clean up E0699 explanation)
Failed merges:
r? @ghost
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
