This commit supplies a real fix, which makes retags more complicated, at the benefit of
making accesses more performant.
Co-authored-by: Ralf Jung <post@ralfj.de>
compiletest: explain that UI tests are expected not to compile by default
```
error: ui test compiled successfully!
```
is not a very useful message for someone new to the test suite, so change the wording and add a note to explain
Update wasm-component-ld to 0.5.11
This pulls in an update that supports ``@`-files` used to pass arguments to linkers to fix invocations on Windows that are large.
Closes#133649
improve TagEncoding::Niche docs, sanity check, and UB checks
Turns out the `niche_variants` range can actually contain the `untagged_variant`. We should report this as UB in Miri, so this PR implements that.
Also rename `partially_check_layout` to `layout_sanity_check` for better consistency with how similar functions are called in other parts of the compiler.
Turns out my adjustments to the transmutation logic also fix https://github.com/rust-lang/rust/issues/126267.
Gate async fn trait bound modifier on `async_trait_bounds`
This PR moves `async Fn()` trait bounds into a new feature gate: `feature(async_trait_bounds)`. The general vibe is that we will most likely stabilize the `feature(async_closure)` *without* the `async Fn()` trait bound modifier, so we need to gate that separately.
We're trying to work on the general vision of `async` trait bound modifier general in: https://github.com/rust-lang/rfcs/pull/3710, however that RFC still needs more time for consensus to converge, and we've decided that the value that users get from calling the bound `async Fn()` is *not really* worth blocking landing async closures in general.
Change `AttrArgs::Eq` to a struct variant
Cleanups for simplifying https://github.com/rust-lang/rust/pull/131808
Basically changes `AttrArgs::Eq` to a struct variant and then avoids several matches on `AttrArgsEq` in favor of methods on it. This will make future refactorings simpler, as they can either keep methods or switch to field accesses without having to restructure code
Reducing `target_feature` check-cfg merge conflicts
It was rightfully pointed in https://github.com/rust-lang/rust/pull/133099#discussion_r1862490542 that the expected values for the `target_feature` cfg are regularly updated and unfortunately the check-cfg tests for it are very merge-conflict prone.
This PR aims at drastically reducing the likely-hood of those, by normalizing the "and X more" diagnostic, as well as making the full expected list multi-line instead of being on a single one.
cc `@RalfJung`
r? `@jieyouxu`
Use c"lit" for CStrings without unwrap
I've reviewed uses of `CString::new("lit")`.
Some could be changed to `c"lit"`. Some could be changed to `c"lit".to_owned()`, avoiding an `unwrap()`.
Many `CString` documentation examples could be simplified. I deliberately haven't changed all the examples to use the exact same expression, so that they can demonstrate many ways of creating `CString`s.
I've left UI tests mostly unchanged, because `c""` requires edition 2021, but most UI tests use 2015, and I didn't want to accidentally change what the tests are testing.
remove `Ty::is_copy_modulo_regions`
Using these functions is likely incorrect if an `InferCtxt` is available, I moved this function to `TyCtxt` (and added it to `LateContext`) and added a note to the documentation that one should prefer `Infer::type_is_copy_modulo_regions` instead.
I didn't yet move `is_sized` and `is_freeze`, though I think we should move these as well.
r? `@compiler-errors` cc #132279
Add `needs-target-has-atomic` directive
Before this PR, the test writer has to specify platforms and architectures by hand for targets that have differing atomic width support. `#[cfg(target_has_atomic="...")]` is not quite the same because (1) you may have to specify additional matchers manually which has to be maintained individually, and (2) the `#[cfg]` blocks does not communicate to compiletest that a test would be ignored for a given target.
This PR implements a `//@ needs-target-has-atomic` directive which admits a comma-separated list of required atomic widths that the target must satisfy in order for the test to run.
```
//@ needs-target-has-atomic: 8, 16, ptr
```
See <https://github.com/rust-lang/rust/issues/87377>.
This PR supersedes #133095 and is co-authored by `@kei519,` because it was somewhat subtle, and it turned out easier to implement than to review.
rustc-dev-guide docs PR: https://github.com/rust-lang/rustc-dev-guide/pull/2154
Remove `//@ compare-output-lines-by-subset`
There was only ever one test which used this flag, and it was removed in https://github.com/rust-lang/rust/pull/132244. I think this is a bad flag that should never have been added; comparing by subset makes the test failures extremely hard to debug. Any test that needs complicated output filtering like this should just use run-make instead.
Note that this does not remove the underlying comparison code, because it's still used if `runner` is set. I don't quite understand what's going on there, but since we still test on other platforms and in CI that the full output is accurate, I think it will be easier to debug than a test that uses compare-by-subset unconditionally.
rustc-dev-guide update PR: https://github.com/rust-lang/rustc-dev-guide/pull/2151
Eliminate magic numbers from expression precedence
Context: see https://github.com/rust-lang/rust/pull/133140.
This PR continues on backporting Syn's expression precedence design into rustc. Rustc's design used mysterious integer quantities represented variously as `i8` or `usize` (e.g. `PREC_CLOSURE = -40i8`), a special significance around `0` that is never named, and an extra `PREC_FORCE_PAREN` precedence level that does not correspond to any expression. Syn's design uses a C-like enum with variants that clearly correspond to specific sets of expression kinds.
This PR is a refactoring that has no intended behavior change on its own, but it unblocks other precedence work that rustc's precedence design was poorly suited to accommodate.
- Asymmetrical precedence, so that a pretty-printer can tell `(return 1) + 1` needs parens but `1 + return 1` does not.
- Squashing the `Closure` and `Jump` cases into a single precedence level.
- Numerous remaining false positives and false negatives in rustc pretty-printer's parenthesization of macro metavariables, for example in `$e < rhs` where $e is `lhs as Thing<T>`.
FYI `@fmease` — you don't need to review if rustbot picks someone else, but you mentioned being interested in the followup PRs.
Before this commit, the test writer has to specify platforms and
architectures by hand for targets that have differing atomic width
support. `#[cfg(target_has_atomic)]` is not quite the same because (1)
you may have to specify additional matchers manually which has to be
maintained individually, and (2) the `#[cfg]` blocks does not
communicate to compiletest that a test would be ignored for a given
target.
This commit implements a `//@ needs-target-has-atomic` directive which
admits a comma-separated list of required atomic widths that the target
must satisfy in order for the test to run.
```
//@ needs-target-has-atomic: 8, 16, ptr
```
See <https://github.com/rust-lang/rust/issues/87377>.
Co-authored-by: kei519 <masaki.keigo.q00@kyoto-u.jp>
Remove `hir::ArrayLen`
This refactoring removes `hir::ArrayLen`, replacing it with `hir::ConstArg`. To represent inferred array lengths (previously `hir::ArrayLen::Infer`), a new variant `ConstArgKind::Infer` is added.
r? `@BoxyUwU`
There was only ever one test which used this flag, and it was removed in https://github.com/rust-lang/rust/pull/132244. I think this is a bad flag that should never have been added; comparing by subset makes the test failures extremely hard to debug. Any test that needs complicated output filtering like this should just use run-make instead.
Note that this does not remove the underlying comparison code, because it's still used if `runner` is set. I don't quite understand what's going on there, but since we still test on other platforms and in CI that the full output is accurate, I think it will be easier to debug than a test that uses compare-by-subset unconditionally.
This reverts commit 76f3ff6059, reversing
changes made to 1fc691e6dd.
The new pgo_works test fails when rust is built without profiling
support, including in CI on x86_64-gnu-aux.
Do not call `extern_crate` on current trait on crate mismatch errors
When we encounter an error caused by traits/types of different versions of the same crate, filter out the current crate when collecting spans to add to the context so we don't call `extern_crate` on the `DefId` of the current crate, which is meaningless and ICEs.
Produced output with this filter:
```
error[E0277]: the trait bound `foo::Struct: Trait` is not satisfied
--> y.rs:13:19
|
13 | check_trait::<foo::Struct>();
| ^^^^^^^^^^^ the trait `Trait` is not implemented for `foo::Struct`
|
note: there are multiple different versions of crate `foo` in the dependency graph
--> y.rs:7:1
|
4 | extern crate foo;
| ----------------- one version of crate `foo` is used here, as a direct dependency of the current crate
5 |
6 | pub struct Struct;
| ----------------- this type implements the required trait
7 | pub trait Trait {}
| ^^^^^^^^^^^^^^^ this is the required trait
|
::: x.rs:4:1
|
4 | pub struct Struct;
| ----------------- this type doesn't implement the required trait
5 | pub trait Trait {}
| --------------- this is the found trait
= note: two types coming from two different versions of the same crate are different types even if they look the same
= help: you can use `cargo tree` to explore your dependency tree
note: required by a bound in `check_trait`
--> y.rs:10:19
|
10 | fn check_trait<T: Trait>() {}
| ^^^^^ required by this bound in `check_trait`
```
Fix#133563.
Bump boostrap compiler to new beta
Currently failing due to something about the const stability checks and `panic!`. I'm not sure why though since I wasn't able to see any PRs merged in the past few days that would result in a `cfg(bootstrap)` that shouldn't be removed. cc `@RalfJung` #131349
Remove `HybridBitSet`
`HybridBitSet` was introduced under the name `HybridIdxSetBuf` way back in #53383 where it was a big win for NLL borrow checker performance. In #93984 the more flexible `ChunkedBitSet` was added. Uses of `HybridBitSet` have gradually disappeared (e.g. #116152) and there are now few enough that they can be replaced with `BitSet` or `ChunkedBitSet`, and `HybridBitSet` can be removed, cutting more than 700 lines of code.
r? `@Mark-Simulacrum`
