Peephole optimize `x == false` and `x != true`
This adds peephole optimizations to make `x == false`, `false == x`, `x != true`, and `true != x` get optimized to `!x` in the `instcombine` MIR pass. That pass currently handles `x == true` -> `x` already.
Update books
## reference
4 commits in 9c68af3ce6ccca2395e1868addef26a0542e9ddd..8f598e2af6c25b4a7ee88ef6a8196d9b8ea50ca8
2021-05-24 09:53:32 -0700 to 2021-06-01 19:00:46 +0100
- Add crate and module to glossary. (rust-lang-nursery/reference#1016)
- Fix type_length_limit example. (rust-lang-nursery/reference#1026)
- Rearrange HRTB grammar. (rust-lang-nursery/reference#1011)
- Revert "Temporarily remove pat_param." (rust-lang-nursery/reference#1010)
## rustc-dev-guide
6 commits in 50de7f0682adc5d95ce858fe6318d19b4b951553..c8da5bfd1c7c71d90ef1646f5e0a9f6609d5c78a
2021-05-20 15:02:20 +0200 to 2021-06-04 09:08:56 +0200
- Fix some links (rust-lang/rustc-dev-guide#1137)
- explain Miri engine vs Miri-the-tool
- Add more information about no_hash query modifier. (rust-lang/rustc-dev-guide#1133)
- improve section introduction
- not all tools require waiting for a nightly release before they can be fixed
- Describe the difference of rustc_lint vs rustc_lint_defs.
Refactor: Extract render_summary from render_impl.
This allows for a more readable straight-through logic in render_impl without need for a closure.
I think this will make #85970 a bit more of a straightforward change.
This is a pure refactoring. I've verified that the output of `x.py doc library/std` is byte-for-byte identical.
r? `@GuillaumeGomez`
Include macro name in 'local ambiguity' error
Currently, we only point at the span of the macro argument. When the
macro call is itself generated by another macro, this can make it
difficult or impossible to determine which macro is responsible for
producing the error.
Enable rustdoc to document safe wasm intrinsics
This commit fixes an issue not found during #84988 where rustdoc is used
to document cross-platform intrinsics but it was requiring that
functions which use `#[target_feature]` are `unsafe` erroneously, even
if they're WebAssembly specific. Rustdoc today, for example, already has
a special case where it enables annotations like
`#[target_feature(enable = "simd128")]` on platforms other than
WebAssembly. The purpose of this commit is to relax the "require all
`#[target_feature]` functions are `unsafe`" requirement for all targets
whenever rustdoc is running, enabling all targets to fully document
other targets, such as WebAssembly, where intrinsics functions aren't
always `unsafe`.
Comment out unused error codes and add description for E0316
I have added an extended description of `E0316` and commented out a bunch of unused error codes to make clear the fact that they are no longer in use. You can check for yourself with
```shell
for ec in \
E0314 E0315 E0473 E0474 E0475 E0479 E0480 E0481 \
E0483 E0484 E0485 E0486 E0487 E0488 E0489
do
if [ ! -z "`grep -r $ec compiler/* --exclude-dir=rustc_error_codes`" ]
then
echo $ec
false
fi
done
```
i.e. these error codes appear nowhere in the compiler code and thus cannot be emitted.
r? ```@GuillaumeGomez```
Default panic message should print Box<dyn Any>
Closes#86039
Prior to this patch, the panic message from running the following code would be `thread 'main' panicked at 'Box<Any>'...`
```rust
use std::panic::panic_any;
fn main() {
panic_any(42);
}
```
This patch updates the phrasing to be more consistent. It now instead shows the following panic message:
```
thread 'main' panicked at 'Box<dyn Any>', ...
```
It's a very small fix 😄
Update the documentation of `-C force-unwind-tables` for #83482
`panic=unwind` does not require `force-unwind-tables` to be "yes" anymore.
I forgot to update this in #83482.
Currently, we only point at the span of the macro argument. When the
macro call is itself generated by another macro, this can make it
difficult or impossible to determine which macro is responsible for
producing the error.
This commit fixes an issue not found during #84988 where rustdoc is used
to document cross-platform intrinsics but it was requiring that
functions which use `#[target_feature]` are `unsafe` erroneously, even
if they're WebAssembly specific. Rustdoc today, for example, already has
a special case where it enables annotations like
`#[target_feature(enable = "simd128")]` on platforms other than
WebAssembly. The purpose of this commit is to relax the "require all
`#[target_feature]` functions are `unsafe`" requirement for all targets
whenever rustdoc is running, enabling all targets to fully document
other targets, such as WebAssembly, where intrinsics functions aren't
always `unsafe`.
Remove the install prefix from the rpath set when using -Crpath
It was broken anyway for rustup installs and nobody seems to have noticed.
Fixes https://github.com/rust-lang/rust/issues/82392
rustbuild: take changes to the standard library into account for `download-rustc`
Previously, changing the standard library with `download-rustc =
"if-unchanged"` would incorrectly reuse the cached compiler and standard
library from CI, which was confusing and led to incorrect test failures
or successes.
r? `@Mark-Simulacrum`
Fix ICE during type layout when there's a `[type error]`
Fixes#84108.
Based on estebank's [comment], except I used `delay_span_bug` because it
should work in more cases, and I think it expresses its intent more
clearly.
r? `@estebank`
[comment]: https://github.com/rust-lang/rust/issues/84108#issuecomment-818916848
Driver improvements
This PR contains a couple of cleanups for the driver and a few small improvements for the custom codegen backend interface. It also implements `--version` and `-Cpasses=list` support for custom codegen backends.
This patch fixes tests from failing that were matching on `Box<Any>`,
which was the old panic message. Since the new panic message is `Box<dyn
Any>`, the tests have been updated to match against this instead.
Fix two ICEs in the parser
This pull request fixes#84104 and fixes#84148. The latter is caused by an invalid `assert_ne!()` in the parser, which I have simply removed because the error is then caught in another part of the parser.
#84104 is somewhat more subtle and has to do with a suggestion to remove extraneous `<` characters; for instance:
```rust
fn main() {
foo::<Ty<<<i32>();
}
```
currently leads to
```
error: unmatched angle brackets
--> unmatched-langle.rs:2:10
|
2 | foo::<Ty<<<i32>();
| ^^^ help: remove extra angle brackets
```
which is obviously wrong and stems from the fact that the code for issuing the above suggestion does not consider the possibility that there might be other tokens in between the opening angle brackets. In #84104, this has led to a span being generated that ends in the middle of a multi-byte character (because the code issuing the suggestion thought that it was only skipping over `<`, which are single-byte), causing an ICE.
Don't run sanity checks for `x.py setup`
These requirements change as soon as the command finishes running, and
`setup` doesn't build anything, so the check doesn't make sense.
Previously, `x.py setup` would give hard errors if `ninja` and `cmake`
were not installed, even if the new profile didn't require them.
Fixes https://github.com/rust-lang/rust/issues/84938.
Pass --cfg=bootstrap for proc macros built by stage0
Cargo has a bug where it ignores RUSTFLAGS when building proc macro
crates (https://github.com/rust-lang/cargo/issues/4423).
However, sometimes rustc_macro needs to have conditional
compilation when there are breaking changes to the `libproc_macro` API
(see for example #83363). Previously, this wasn't possible, because the
crate couldn't tell the difference between stage 0 and stage 1.
Another alternative is to unconditionally build rustc_macros with the
master libstd instead of the beta one (i.e. use `--sysroot
stage0-sysroot`), but that led to strange and maddening errors:
```
error[E0460]: found possibly newer version of crate `std` which `synstructure` depends on
--> compiler/rustc_macros/src/lib.rs:5:5
|
5 | use synstructure::decl_derive;
| ^^^^^^^^^^^^
|
= note: perhaps that crate needs to be recompiled?
= note: the following crate versions were found:
crate `std`: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/stage0-sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-b3602c301b71cc3d.rmeta
crate `synstructure`: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/stage0-rustc/release/deps/libsynstructure-74ee66863479e972.rmeta
error[E0460]: found possibly newer version of crate `std` which `proc_macro2` depends on
--> /home/joshua/.local/lib/cargo/registry/src/github.com-1ecc6299db9ec823/tracing-attributes-0.1.13/src/lib.rs:90:5
|
90 | use proc_macro2::TokenStream;
| ^^^^^^^^^^^
|
= note: perhaps that crate needs to be recompiled?
= note: the following crate versions were found:
crate `std`: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/stage0-sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-b3602c301b71cc3d.rmeta
crate `proc_macro2`: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/stage0-rustc/release/deps/libproc_macro2-a83c1f01610c129e.rlib
```
r? `@Mark-Simulacrum` cc `@jhpratt`
parser: Ensure that all nonterminals have tokens after parsing
`parse_nonterminal` should always result in something with tokens.
This requirement wasn't satisfied in two cases:
- `stmt` nonterminal with expression statements (e.g. `0`, or `{}`, or `path + 1`) because `fn parse_stmt_without_recovery` forgot to propagate `force_collect` in some cases.
- `expr` nonterminal with expressions with built-in attributes (e.g. `#[allow(warnings)] 0`) due to an incorrect optimization in `fn parse_expr_force_collect`, it assumed that all expressions starting with `#` have their tokens collected during parsing, but that's not true if all the attributes on that expression are built-in and inert.
(Discovered when trying to implement eager `cfg` expansion for all attributes https://github.com/rust-lang/rust/pull/83824#issuecomment-817317170.)
r? `@Aaron1011`
