Skipping FileCheck in codegen/assembly tests is normally not very useful, but a
small number of existing tests were using `//@ build-pass` to do so anyway, so
it's clearer for them to explicitly use `//@ skip-filecheck` instead.
we were saying that the type is i32, but would often provide an i64.
That never failed so far, but starts failing (like, crashing LLVM) when
working with 128-bit values that are 16-byte aligned. So, we may as well
use the more robust approach now.
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#155589 (Forbid `check-pass`/`build-pass`/`run-pass` directives in incremental tests)
- rust-lang/rust#155610 (Add missing `dyn` keyword to `trait_alias` page of the Unstable Book)
- rust-lang/rust#155615 (test cleanups for `ui/derives` and `ui/deriving`)
- rust-lang/rust#154874 (Fix ICE for inherited const conditions on const closures)
- rust-lang/rust#155605 (std: Update support for `wasm32-wasip3`)
- rust-lang/rust#155613 (c-variadic: tweak `std` docs)
- rust-lang/rust#155619 (Remove a bunch of unnecessary explicit lifetimes from the ast validator)
Remove a bunch of unnecessary explicit lifetimes from the ast validator
Noticed while fiddling with error reporting. None of the lifetimes were ever used for anything
std: Update support for `wasm32-wasip3`
This commit performs some minor update within the standard library for the `wasm32-wasip3` target. This target is a tier 3 target currently due to the WASIp3 specification not being officially released. This commit adds a dependency from the standard library on the `wasip3` crate in the same manner as the `wasip1` and `wasip2` crates that it already depends on. The use-sites, for randomness and environment variables, are then updated to handle the wasip2/wasip3 multiplexing.
Fix ICE for inherited const conditions on const closures
Synchronize `evaluate_host_effect_for_fn_goal` with the behavior of `extract_fn_def_from_const_callable` in new solver.
Closesrust-lang/rust#153861 .
test cleanups for `ui/derives` and `ui/deriving`
The eventual goal is for `ui/deriving` to be merged into `ui/derives` entirely. This PR focuses on the `issue-*.rs` tests in `deriving` and a few other no-longer-useful tests.
r? @Kivooeo
Add missing `dyn` keyword to `trait_alias` page of the Unstable Book
There seemed to be a small typo in the Rust Unstable Book page for the `trait_alias` feature, where a variable is declared as `&Bar` for a trait `Bar`, rather than `&dyn Bar`.
Forbid `check-pass`/`build-pass`/`run-pass` directives in incremental tests
- Follow-up to https://github.com/rust-lang/rust/pull/155474
---
This PR forbids the use of `//@ check-pass`, `//@ build-pass`, and `//@ run-pass` directives in incremental tests. Tests that would have used those directives should use a revision name beginning with `cpass`/`bpass`/`rpass` instead.
(The `*-fail` directives are already forbidden in incremental tests.)
Existing incremental tests that used the `check-pass` and `build-pass` directives have been migrated. To allow migration of the check-pass tests, this PR also adds support for revision names beginning with `cpass`. No incremental tests were using `run-pass`.
---
Several of the migrated `build-pass` tests have a FIXME indicating that they could potentially be migrated to `check-pass` instead. This PR does not perform that migration.
In the future, I intend to do more cleanup of how compiletest handles pass/fail expectations, but I didn't want to cram too much into one PR.
r? jieyouxu
It's currently an impl for `(CrateMetadataRef, TyCtxt)`, but (a) the
`TyCtxt` is not used, and (b) the `CrateMetadataRef` can be simplified
to a `CrateMetadata` because `CStore` access isn't required. This
require changing `blob` to take `&self`, which is no big deal, and it
simplifies many `get` calls.
`Metadata` has two methods, `blob` and `decoder`, which are not used
together. Splitting the trait in two will allow some cleanups in
subsequent commits.
Incremental tests that would have used the `check-pass`, `build-pass`, or
`run-pass` directives should instead use a revision name starting with
`cpass`/`bpass`/`rpass` as appropriate.
This is the subset of incremental tests that have a FIXME to consider migrating
to check-pass instead.
That migration is beyond the scope of this PR, but might be attempted later.
This is the subset of incremental tests that should continue to use `bpass`
even after `cpass` is supported, because they (presumably) involve codegen.
`cstore.get_crate_data()` creates a `CrateMetadataRef`, which is exactly
what we need. The current code is very confused and does several
unnecessary things: mapping the `FreezeReadGuard` and calling
`CStore::from_tcx` a second time to construct a second
`CrateMetadataRef`.
This is a small perf win.
Use per-parent disambiguators everywhere
This PR addressing the following concerns about per-parent disambiguators (rust-lang/rust#153955):
- DisambiguatorState is removed, PerParentDisambiguatorState is now used everywhere,
- Steals were removed from every per-parent disambiguator in resolver,
- It adds `parent` field in `PerParentDisambiguatorState` in `#[cfg(debug_assertions)]` for asserting that per-parent disambiguator corresponds to the same `LocalDefId` which is passed into `create_def`,
- ~Removes `Disambiguator` trait replacing it with `Disambiguator` enum, with this change we no longer expose `next` method (as trait should be public otherwise the warning will be emitted). It may affect perf in a negative way though.~
~Those changes should not fix perf issues that were [reported](https://github.com/rust-lang/rust/pull/153955#issuecomment-4269223191), perf run that was attempted [before](https://github.com/rust-lang/rust/pull/153955#issuecomment-4214516698) showed much better results. Performance can be probably fixed by removing per-parent disambiguators replacing them with a single one as it was before, then it will be passed to AST -> HIR lowering and modified. For delayed owners we can store ~followup disambiguators as it was in the beginning of the rust-lang/rust#153955~ per-parent disambiguators. This solution should save achievements from rust-lang/rust#153955 (removed `DefPathData` variants).
However, I would prefer to keep per-parent disambiguators as it seems a better architectural solution for me.~
r? @petrochenkov
cc @oli-obk
Remove duplicated `Flags` methods.
The `Flags` trait has two methods: `flags` and `outer_exclusive_binder`. Multiple types impl this trait and then also have duplicate inherent methods with the same names; these are all marked with "Think about removing this" comments. This is left over from things being moved into `rustc_type_ir`.
This commit removes those inherent methods. This requires adding `use Flags` to a number of files.
r? @lcnr
Fix incorrect `let` to `const` suggestion for pattern bindings
When a variable from a pattern binding was referenced inside a `const {}` block, the compiler incorrectly suggested replacing `let` with `const`. This was reported in rust-lang/rust#152831 for `if let`, but also applies to `while let` and `let ... else`.
Improve E0308 error message for `impl Trait` return mismatches
When a function returns `impl Trait`, all branches must return the same concrete type. Previously, the compiler showed:
expected `First` because of return type
This was misleading, as it suggested the return type was `First`, rather than any single type implementing the trait.
Update the diagnostic to:
expected a single type implementing `Value` because of return type
Also highlight the first return expression to make it clearer why subsequent returns do not match.
Every other modification of this variable uses `SeqCst`, which is
justified in the sleep README. This particular choice of `AcqRel` was
not discussed during its addition in rayon-rs/rayon#746, nor
rayon-rs/rfcs#5, so I suspect was simply an oversight from earlier
development. We probably do want this to participate in the same
sequential consistency.
The only other ordering difference is `CoreLatch::probe`'s load with
`Acquire`, which should be fine because this doesn't need consistency
with the sleep counters.
See also rayon-rs/rayon#1297. As I commented there, I think in practice
this would be quite rare to cause any problems, but it *could* be a
source of non-deterministic bugs on targets with weak memory ordering.
Zalathar