Identify unreachable subpatterns more reliably
In https://github.com/rust-lang/rust/pull/80104 I used `Span`s to identify unreachable sub-patterns in the presence of or-patterns during exhaustiveness checking. In https://github.com/rust-lang/rust/issues/80501 it was revealed that `Span`s are complicated and that this was not a good idea.
Instead, this PR identifies subpatterns logically: as a path in the tree of subpatterns of a given pattern. I made a struct that captures a set of such subpatterns. This is a bit complex, but thankfully self-contained; the rest of the code does not need to know anything about it.
Fixes https://github.com/rust-lang/rust/issues/80501. I think I managed to keep the perf neutral.
r? `@varkor`
Apply workaround from #72003 for #56935 to allow for cross-compilation of `rustc_index` crate
This patch applies the same workaround as #72003 to the `rustc_index` crate. This allows recent versions of rustfmt to compile to wasm again.
Related: #72017.
typeck: Emit structured suggestions for tuple struct syntax
And tuple variant syntax, but that didn't fit in the subject :)
Now the fact that these are suggestions is exposed both to the layout
engine and to IDEs and rustfix for automatic application.
Refactor `PrimitiveTypeTable` for Clippy
I removed `PrimitiveTypeTable` and added `PrimTy::ALL` and `PrimTy::from_name` in its place. This allows Clippy to use `PrimTy::from_name` for the `builtin_type_shadow` lint, and a `const` list of primitive types is deleted from Clippy code (the goal). All changes should be a little faster, if anything.
tidy: Run tidy style against markdown files.
This adds tidy checks for markdown files. I think it is useful to have some style enforcement (for the same reasons the style is enforced on other files). I think it is worthwhile to avoid `ignore` on rust examples since having broken code in documentation is frustrating. Avoiding trailing whitespace is good because it has semantic meaning in markdown, which I think should be avoided.
Rollup of 7 pull requests
Successful merges:
- #80011 (Stabilize `peekable_next_if`)
- #81580 (Document how `MaybeUninit<Struct>` can be initialized.)
- #81610 (BTreeMap: make Ord bound explicit, compile-test its absence)
- #81664 (Avoid a hir access inside get_static)
- #81675 (Make rustdoc respect `--error-format short` in doctests)
- #81753 (Never MIR inline functions with a different instruction set)
- #81795 (Small refactor with Iterator::reduce)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Avoid a hir access inside get_static
Together with #81056 this ensures that the codegen unit DepNode doesn't have a direct dependency on any part of the hir.
Fix rustc sysroot in systems using CAS
Change filesearch::get_or_default_sysroot() to check if sysroot is found using env::args().next() if rustc in argv[0] is a symlink; otherwise, or if it is not found, use env::current_exe() to imply sysroot. This makes the rustc binary able to locate Rust libraries in systems using content-addressable storage (CAS).
Encode MIR metadata by iterating on DefId instead of traversing the HIR tree
Split out of https://github.com/rust-lang/rust/pull/80347.
This part only traverses `mir_keys` and encodes MIR according to the def kind.
r? `@oli-obk`
Revert 78373 ("dont leak return value after panic in drop")
Short term resolution for issue #80949.
Reopen#47949 after this lands.
(We plan to fine-tune PR #78373 to not run into this problem.)
Rollup of 15 pull requests
Successful merges:
- #79554 (Generic associated types in trait paths)
- #80726 (relax adt unsizing requirements)
- #81307 (Handle `Span`s for byte and raw strings and add more detail )
- #81318 (rustdoc-json: Fix has_body)
- #81456 (Make remote-test-server easier to use with new targets)
- #81497 (rustdoc: Move `display_fn` struct inside `display_fn`)
- #81500 (Remove struct_type from union output)
- #81542 (Expose correct symlink API on WASI)
- #81676 (Add more information to the error code for 'crate not found')
- #81682 (Add additional bitset benchmarks)
- #81730 (Make `Allocator` object-safe)
- #81763 (Cleanup rustdoc pass descriptions a bit)
- #81767 (Update LayoutError/LayoutErr stability attributes)
- #81771 (Indicate change in RSS from start to end of pass in time-passes output)
- #81781 (Fix `install-awscli.sh` error in CI)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Indicate change in RSS from start to end of pass in time-passes output
Previously, this was omitted because it could be misleading, but the
functionality seems too useful not to include.
r? ``@oli-obk``
Add additional bitset benchmarks
Add additional benchmarks for operations in bitset, I realize that it was a bit lacking when I intended to optimize it earlier, so I was hoping to put some in so I can verify my work later.
relax adt unsizing requirements
Changes unsizing of structs in case the last struct field shares generic params with other adt fields which do not change.
This change is currently insta stable and changes the language, so it at least requires a lang fcp. I feel like the current state is fairly unintuitive.
An example for what's now allowed would be https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6dd331d23f5c9ffc8c978175aae2e967
```rust
struct A<T, U: ?Sized>(T, B<T, U>); // previously ERR
// struct A<T, U: ?Sized>(T, B<[u32; 1], U>); // ok
struct B<T, U: ?Sized>(T, U);
fn main() {
let x = A([0; 1], B([0; 1], [0; 1]));
let y: &A<[u32; 1], [u32]> = &x;
assert_eq!(y.1.1.len(), 1);
}
```
rustc_codegen_ssa: tune codegen scheduling to reduce memory usage
For better throughput during parallel processing by LLVM, we used to sort
CGUs largest to smallest. This would lead to better thread utilization
by, for example, preventing a large CGU from being processed last and
having only one LLVM thread working while the rest remained idle.
However, this strategy would lead to high memory usage, as it meant the
LLVM-IR for all of the largest CGUs would be resident in memory at once.
Instead, we can compromise by ordering CGUs such that the largest and
smallest are first, second largest and smallest are next, etc. If there
are large size variations, this can reduce memory usage significantly.
Add lint for `panic!(123)` which is not accepted in Rust 2021.
This extends the `panic_fmt` lint to warn for all cases where the first argument cannot be interpreted as a format string, as will happen in Rust 2021.
It suggests to add `"{}",` to format the message as a string. In the case of `std::panic!()`, it also suggests the recently stabilized
`std::panic::panic_any()` function as an alternative.
It renames the lint to `non_fmt_panic` to match the lint naming guidelines.
This is part of #80162.
r? ```@estebank```
introduce future-compatibility warning for forbidden lint groups
We used to ignore `forbid(group)` scenarios completely. This changed in #78864, but that led to a number of regressions (#80988, #81218).
This PR introduces a future compatibility warning for the case where a group is forbidden but then an individual lint within that group is allowed. We now issue a FCW when we see the "allow", but permit it to take effect.
r? ``@Mark-Simulacrum``
And tuple variant syntax, but that didn't fit in the subject :)
Now the fact that these are suggestions is exposed both to the layout
engine and to IDEs and rustfix for automatic application.
For better throughput during parallel processing by LLVM, we used to sort
CGUs largest to smallest. This would lead to better thread utilization
by, for example, preventing a large CGU from being processed last and
having only one LLVM thread working while the rest remained idle.
However, this strategy would lead to high memory usage, as it meant the
LLVM-IR for all of the largest CGUs would be resident in memory at once.
Instead, we can compromise by ordering CGUs such that the largest and
smallest are first, second largest and smallest are next, etc. If there
are large size variations, this can reduce memory usage significantly.
This extends the `panic_fmt` lint to warn for all cases where the first
argument cannot be interpreted as a format string, as will happen in
Rust 2021.
It suggests to add `"{}", ` to format the message as a string. In the
case of `std::panic!()`, it also suggests the recently stabilized
`std::panic::panic_any()` function as an alternative.
It renames the lint to `non_fmt_panic` to match the lint naming
guidelines.
Fix panic when emitting diagnostic for closure mutable binding error
Fixes#81700
The upvar borrow kind may be `ty::BorrowKind::UniqueImmBorrow`, which is
still a mutable borrow for the purposes of this diagnostic code.
Fix non-existent-field ICE for generic fields.
I mentioned this ICE in a chat and it took about 3 milliseconds before `@eddyb` found the problem and said this change would fix it. :)
This also changes one the field types in the related test to one that triggered the ICE.
Fixes#81627.
Fixes#81672.
Fixes#81709.
Cc https://github.com/rust-lang/rust/pull/81480 `@b-naber` `@estebank.`
Reduce tab formatting assertions to debug only
The tab replacement for diagnostics added in #79757 included a few assertions to ensure all tab characters are handled appropriately. We've started getting reports of these assertions firing (#81614). Since it's only a cosmetic issue, this downgrades the assertions to debug only, so we at least continue compiling even if the diagnostics might be a tad wonky.
Minimizes the impact of #81614
Remove incorrect `delay_span_bug`
The following code is supposed to compile
```rust
use std::ops::BitOr;
pub trait IntWrapper {
type InternalStorage;
}
impl<T> BitOr for dyn IntWrapper<InternalStorage = T>
where
Self: Sized,
T: BitOr + BitOr<Output = T>,
{
type Output = Self;
fn bitor(self, _other: Self) -> Self {
todo!()
}
}
```
Before this change it would ICE. In #70998 the removed logic was added
to provide better suggestions, and the `delay_span_bug` guard was added
to protect against a potential logic error when returning traits. As it
happens, there are cases, like the one above, where traits can indeed be
returned, so valid code was being rejected.
Fix (but not close) #80207.
make const_err a future incompat lint
This is the first step for https://github.com/rust-lang/rust/issues/71800: make const_err a future-incompat lint. I also rewrote the const_err lint description as the old one seemed wrong.
This has the unfortunate side-effect of making const-eval error even more verbose by making the const_err message longer without fixing the redundancy caused by additionally emitting an error on each use site of the constant. We cannot fix that redundancy until const_err is a *hard* error (at that point the error-on-use-site can be turned into a `delay_span_bug!` for uses of monomorphic consts, and into a nicely rendered error for [lazily / post-monomorhization evaluated] associated consts).
~~The one annoying effect of this PR is that `let _x = &(1/(1-1));` now also shows the future-incompat warning, even though of course we will *not* make this a hard error. We'll instead (hopefully) stop promoting it -- see https://github.com/rust-lang/rfcs/pull/3027. The only way I see to avoid the future-incompat warning is to use a different lint for "failure to evaluate promoted".~~
Cc `@rust-lang/wg-const-eval`
The tab replacement for diagnostics added in #79757 included a few assertions to
ensure all tab characters are handled appropriately. We've started getting
reports of these assertions firing (#81614). Since it's only a cosmetic issue,
this downgrades the assertions to debug only, so we at least continue compiling
even if the diagnostics might be a tad wonky.
Fixes#81614
The following code is supposed to compile
```rust
use std::ops::BitOr;
pub trait IntWrapper {
type InternalStorage;
}
impl<T> BitOr for dyn IntWrapper<InternalStorage = T>
where
Self: Sized,
T: BitOr + BitOr<Output = T>,
{
type Output = Self;
fn bitor(self, _other: Self) -> Self {
todo!()
}
}
```
Before this change it would ICE. In #70998 the removed logic was added
to provide better suggestions, and the `delay_span_bug` guard was added
to protect against a potential logic error when returning traits. As it
happens, there are cases, like the one above, where traits can indeed be
returned, so valid code was being rejected.
Fix#80207.
Add a new ABI to support cmse_nonsecure_call
This adds support for the `cmse_nonsecure_call` feature to be able to perform non-secure function call.
See the discussion on Zulip [here](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Support.20for.20callsite.20attributes/near/223054928).
This is a followup to #75810 which added `cmse_nonsecure_entry`. As for that PR, I assume that the changes are small enough to not have to go through a RFC but I don't mind doing one if needed 😃
I did not yet create a tracking issue, but if most of it is fine, I can create one and update the various files accordingly (they refer to the other tracking issue now).
On the Zulip chat, I believe `@jonas-schievink` volunteered to be a reviewer 💯
We used to ignore `forbid(group)` scenarios completely. This changed
in #78864, but that led to a number of regressions (#80988, #81218).
This PR introduces a future compatibility warning for the case where
a group is forbidden but then an individual lint within that group
is allowed. We now issue a FCW when we see the "allow", but permit
it to take effect.
Improve wording of suggestion about accessing field
Follow-up to #81504
The compiler at this moment suggests "you might have meant to use field `b` of type `B`", sounding like it's type `B` which has the field `b`.
r? ```@estebank```
Fix bug with assert!() calling the wrong edition of panic!().
The span of `panic!` produced by the `assert` macro did not carry the right edition. This changes `assert` to call the right version.
Also adds tests for the 2021 edition of panic and assert, that would've caught this.
Add better diagnostic for unbounded Abst. Const
~~In the case where a generic abst. const requires a trivial where bound: `where TypeWithConst<const_fn(N)>: ,`,
instead of requiring a where bound, just check that only consts are being substituted in to skip over where check.~~
~~This is pretty sketchy, but I think it works. Presumably, if there is checking for type bounds added later, it can first check nested requirements, and see if they're satisfied by the current `ParamEnv`.~~
Changed the diagnostic to add a better example, which is more practical than what was previously proposed.
r? ```@lcnr```
Add AArch64 big-endian and ILP32 targets
This PR adds 3 new AArch64 targets:
- `aarch64_be-unknown-linux-gnu`
- `aarch64-unknown-linux-gnu_ilp32`
- `aarch64_be-unknown-linux-gnu_ilp32`
It also fixes some ABI issues on big-endian ARM and AArch64.
Upgrade Chalk
~~Blocked on rust-lang/chalk#670~~
~~Now blocked on rust-lang/chalk#680 and release~~
In addition to the straight upgrade, I also tried to fix some tests by properly returning variables and max universes in the solution. Unfortunately, this actually triggers the same perf problem that rustc traits code runs into in `canonicalizer`. Not sure what the root cause of this problem is, or why it's supposed to be solved in chalk.
r? ```@nikomatsakis```
Fix early lints inside an async desugaring
Fixes#81531
When we buffer an early lint for a macro invocation,
we need to determine which NodeId to take the lint level from.
Currently, we use the NodeId of the closest def parent. However, if
the macro invocation is inside the desugared closure from an `async fn`
or async closure, that NodeId does not actually exist in the AST.
This commit uses the parent of a desugared closure when computing
`lint_node_id`, which is something that actually exists in the AST (an
`async fn` or async closure).
Fixes#81531
When we buffer an early lint for a macro invocation,
we need to determine which NodeId to take the lint level from.
Currently, we use the `NodeId` of the closest def parent. However, if
the macro invocation is inside the desugared closure from an `async fn`
or async closure, that `NodeId` does not actually exist in the AST.
This commit explicitly calls `check_lint` for the `NodeId`s of closures
desugared from async expressions, ensuring that we do not miss any
buffered lints.
