mir-opt: Make SimplifyCfg collapse goto chains starting from bb0
`SimplifyCfg` pass was not able to collapse goto chains starting from bb0, leaving MIR like this:
```
bb0: {
goto -> bb1;
}
```
Bump minimum required LLVM version to 6.0
Based on the discussion in #55842, while the overall position of Rust wrt LLVM continues to be contentious, there does seem to be a consensus that there is no need for continued support of LLVM 5. This PR bumps our version requirement to LLVM 6.0 and makes Travis run against that.
I hope that this is going to unblock #52694. If I understand correctly, while this issue still exists in LLVM 6, Ubuntu has backported the relevant patch.
r? @alexcrichton
rustdoc: look for comments when scraping attributes/crates from doctests
Fixes https://github.com/rust-lang/rust/issues/56727
When scraping out crate-level attributes and `extern crate` statements, we wouldn't look for comments, so any presence of comments would shunt it and everything after it into "everything else". This could cause parsing issues when looking for `fn main` and `extern crate my_crate` later on, which would in turn cause rustdoc to incorrectly wrap a test with `fn main` when it already had one declared.
I took the opportunity to clean up the logic a little bit, but it would still benefit from a libsyntax-based loop like the `fn main` detection.
Make RValue::Discriminant a normal Shallow read
Enum layout optimizations mean that the discriminant of an enum may not be stored in a tag disjoint from the rest of the fields of the enum. Stop borrow checking as though they are.
Run with MIRI to see why this is needed: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=09a3236685a06b6096e2e2e3968b852c.
This issue exists with the lexical borrow checker as well (see #45045) so migrate mode should prevent this from being immediately breaking.
r? @nikomatsakis
Fixes#56797
rustc: Add an unstable `simd_select_bitmask` intrinsic
This is going to be required for binding a number of AVX-512 intrinsics
in the `stdsimd` repository, and this intrinsic is the same as
`simd_select` except that it takes a bitmask as the first argument
instead of a SIMD vector. This bitmask is then transmuted into a `<NN x
i8>` argument, depending on how many bits it is.
cc rust-lang-nursery/stdsimd#310
Clearer error message for dead assign
I'm not that this is the right place for this (if it needs an RFC or not).
I had the problem where I misunderstood the compiler lint message https://github.com/rust-lang/rust/issues/56436 and other people seem to have had the same problem https://www.reddit.com/r/rust/comments/8cy9p4/value_assigned_to_is_never_read/.
I think this new wording might be slightly clearer (and help out beginners like me). I'm very new though, so there might be some nuance I'm missing that would make this more confusing or a bad idea for other reasons.
I thought I would create a PR to make it easy to change the code if the consensus was that it would make sense to make a change.
If this is the wrong place for this sort of thing I'll happily delete/move it.
overhaul external doc attribute diagnostics
This PR improves the error handling and spans for the external doc attribute. Many cases that silently failed before now emit errors, spans are tightened, and the errors have help and suggestions.
I tried to address all the cases that users ran into in the tracking issue.
cc #44732
r? @QuietMisdreavus
#[must_use] on traits in stdlib
Based on #55506.
Adds `#[must_use]` attribute to traits in the stdlib:
- `Iterator`
- `Future`
- `FnOnce`
- `Fn`
- `FnMut`
There may be other traits that should have the attribute, but I couldn't find/think of any.
Add test of current behavior (infer free region within closure body)
This behavior was previously not encoded in our test suite.
it is pretty important that we test this behavior. In particular, in #56537 I had proposed expanding the lifetime elision rules so that they would apply to some of the cases encoded in this test, which would cause them to start failing to compile successfully (because the lifetime attached to the return type would start being treated as connected to the lifetime on the input parameter to the lambda expression, which is explicitly *not* what the code wants in this particular case).
In other words, I am trying to ensure that anyone who tries such experiments with lifetime elision in the future quickly finds out why we don't support lifetime elision on lambda expressions (at least not in the naive manner described on #56537).
Fix private_no_mangle_fns message grammar
Simply changes "an warning" to "a warning" in the `private_no_mangle_fns` warning. I started getting this in some code after upgrading to 1.31.0.
2018 edition - confusing error message when declaring unnamed parameters
Fixes#53990.
This PR adds a note providing context for the change to argument
names being required in the 2018 edition for trait methods and a
suggestion for the fix.
Contexually dependent error message for E0424 when value is assigned to "self"
This is an improvement for pull request #54495 referencing issue #54369. If the "self" keyword is assigned a value as though it were a valid identifier, it will now report:
```
let self = "self";
^^^^ `self` value is a keyword and may not be bound to variables or shadowed
```
instead of
```
let self = "self";
^^^^ `self` value is a keyword only available in methods with `self` parameter
```
If anyone has a better idea for what the error should be I'd be happy to modify it appropriately.
This is going to be required for binding a number of AVX-512 intrinsics
in the `stdsimd` repository, and this intrinsic is the same as
`simd_select` except that it takes a bitmask as the first argument
instead of a SIMD vector. This bitmask is then transmuted into a `<NN x
i8>` argument, depending on how many bits it is.
cc rust-lang-nursery/stdsimd#310
rustc: Add an unstable `simd_select_bitmask` intrinsic
This is going to be required for binding a number of AVX-512 intrinsics
in the `stdsimd` repository, and this intrinsic is the same as
`simd_select` except that it takes a bitmask as the first argument
instead of a SIMD vector. This bitmask is then transmuted into a `<NN x
i8>` argument, depending on how many bits it is.
cc rust-lang-nursery/stdsimd#310
Disable btree pretty-printers on older gdbs
gdb versions before 8.1 have a bug that prevents the BTreeSet and
BTreeMap pretty-printers from working. This patch disables the test
on those versions, and also disables the pretty-printers there as
well.
Closes#56730
Update panic message to be clearer about env-vars
Esteban Kuber requested that the panic message make it clear
that `RUST_BACKTRACE=1` is an environment variable. This change
makes that clear.
I understand that this may simply be closed if the concept isn't accepted, and I'd be fine with that :-)
Fixes#56734
rustdoc: Fix local reexports of proc macros
Filter out `ProcMacroStub`s to avoid an ICE during cleaning.
Also add proc macros to `cache().paths` so it can generate links.
r? @QuietMisdreavus
Stabilize `linker-flavor` flag.
Part of #55396.
This commit moves the linker-flavor flag from a debugging option to a
codegen option, thus stabilizing it. There are no feature flags
associated with this flag.
r? @nagisa
Esteban Kuber requested that the panic message make it clear
that `RUST_BACKTRACE=1` is an environment variable. This change
makes that clear. Wording provided in part by David Tolnay.
This is going to be required for binding a number of AVX-512 intrinsics
in the `stdsimd` repository, and this intrinsic is the same as
`simd_select` except that it takes a bitmask as the first argument
instead of a SIMD vector. This bitmask is then transmuted into a `<NN x
i8>` argument, depending on how many bits it is.
cc rust-lang-nursery/stdsimd#310
Enum layout optimizations mean that the discriminant of an enum may not
be stored in a tag disjoint from the rest of the fields of the enum.
Stop borrow checking as though they are.
This commit moves the linker-flavor flag from a debugging option to a
codegen option, thus stabilizing it. There are no feature flags
associated with this flag.
gdb versions before 8.1 have a bug that prevents the BTreeSet and
BTreeMap pretty-printers from working. This patch disables the test
on those versions, and also disables the pretty-printers there as
well.
Closes#56730
This was intended to land way back in 1.24, but it was backed out due to
breakage which has long since been fixed. An unstable `#[unwind]`
attribute can be used to tweak the behavior here, but this is currently
simply switching rustc's internal default to abort-by-default if an
`extern` function panics, making our codegen sound primarily (as
currently you can produce UB with safe code)
Closes#52652
std: Depend directly on crates.io crates
Ever since we added a Cargo-based build system for the compiler the
standard library has always been a little special, it's never been able
to depend on crates.io crates for runtime dependencies. This has been a
result of various limitations, namely that Cargo doesn't understand that
crates from crates.io depend on libcore, so Cargo tries to build crates
before libcore is finished.
I had an idea this afternoon, however, which lifts the strategy
from #52919 to directly depend on crates.io crates from the standard
library. After all is said and done this removes a whopping three
submodules that we need to manage!
The basic idea here is that for any crate `std` depends on it adds an
*optional* dependency on an empty crate on crates.io, in this case named
`rustc-std-workspace-core`. This crate is overridden via `[patch]` in
this repository to point to a local crate we write, and *that* has a
`path` dependency on libcore.
Note that all `no_std` crates also depend on `compiler_builtins`, but if
we're not using submodules we can publish `compiler_builtins` to
crates.io and all crates can depend on it anyway! The basic strategy
then looks like:
* The standard library (or some transitive dep) decides to depend on a
crate `foo`.
* The standard library adds
```toml
[dependencies]
foo = { version = "0.1", features = ['rustc-dep-of-std'] }
```
* The crate `foo` has an optional dependency on `rustc-std-workspace-core`
* The crate `foo` has an optional dependency on `compiler_builtins`
* The crate `foo` has a feature `rustc-dep-of-std` which activates these
crates and any other necessary infrastructure in the crate.
A sample commit for `dlmalloc` [turns out to be quite simple][commit].
After that all `no_std` crates should largely build "as is" and still be
publishable on crates.io! Notably they should be able to continue to use
stable Rust if necessary, since the `rename-dependency` feature of Cargo
is soon stabilizing.
As a proof of concept, this commit removes the `dlmalloc`,
`libcompiler_builtins`, and `libc` submodules from this repository. Long
thorns in our side these are now gone for good and we can directly
depend on crates.io! It's hoped that in the long term we can bring in
other crates as necessary, but for now this is largely intended to
simply make it easier to manage these crates and remove submodules.
This should be a transparent non-breaking change for all users, but one
possible stickler is that this almost for sure breaks out-of-tree
`std`-building tools like `xargo` and `cargo-xbuild`. I think it should
be relatively easy to get them working, however, as all that's needed is
an entry in the `[patch]` section used to build the standard library.
Hopefully we can work with these tools to solve this problem!
[commit]: 28ee12db81
fix intra-link resolution spans in block comments
This commit improves the calculation of code spans for intra-doc
resolution failures. All sugared doc comments should now have the
correct spans, including those where the comment is longer than the
docs.
It also fixes an issue where the spans were calculated incorrectly for
certain unsugared doc comments. The diagnostic will now always use the
span of the attributes, as originally intended.
Fixes#55964.
r? @QuietMisdreavus
