To test behaviour that depends on the extern options of intermediate
crates, compiletest auxiliaries must have their own auxiliaries.
Auxiliary compilation previously did not trigger compilation of any
auxiliaries in the auxiliary's headers. In addition, those auxiliaries
would need to be in an `auxiliary/auxiliary` directory, which is
unnecessary and makes some crate graphs harder to write tests for,
such as when A depends on B and C, and B depends on C.
For a test `tests/ui/$path/root.rs`, with the following crate graph:
```
root
|-- grandparent
`-- parent
`-- grandparent
```
then the intermediate outputs from compiletest will be:
```
build/$target/test/ui/$path/
|-- auxiliary
| |-- libgrandparent.dylib
| |-- libparent.dylib
| |-- grandparent
| | |-- grandparent.err
| | `-- grandparent.out
| `-- parent
| |-- parent.err
| `-- parent.out
|-- libroot.rmeta
|-- root.err
`-- root.out
```
Signed-off-by: David Wood <david@davidtw.co>
As bonus this makes the errors when failing to load a proc macro more
informative to match the backend loading errors. In addition it makes it
slightly easier to patch rustc to work on platforms that don't support
dynamic linking like wasm.
Compiletest code sometimes refers to a test's revision as its `cfg`. This
results in two different names for the same thing, one of which is ambiguous
with other kinds of configuration (such as compiletest's own config).
This patch replaces those occurrences of `cfg` with `revision`.
Add "algebraic" fast-math intrinsics, based on fast-math ops that cannot return poison
Setting all of LLVM's fast-math flags makes our fast-math intrinsics very dangerous, because some inputs are UB. This set of flags permits common algebraic transformations, but according to the [LangRef](https://llvm.org/docs/LangRef.html#fastmath), only the flags `nnan` (no nans) and `ninf` (no infs) can produce poison.
And this uses the algebraic float ops to fix https://github.com/rust-lang/rust/issues/120720
cc `@orlp`
Print proper relative path for descriptive name check
The `stripped_path` starts with `ui/...`, while we are mostly working in `rust` directory.
print a relative path starting with `tests/ui/...` so that we can copy and use the path when renaming.
Hardcoding the `tests` maybe not good style, but seems we have a lot of hardcoded `tests/..` paths in tidy check :(.
Downgrade ambiguous_wide_pointer_comparisons suggestions to MaybeIncorrect
In certain cases like #121330, it is possible to have more than one suggestion from the `ambiguous_wide_pointer_comparisons` lint (which before this PR are `MachineApplicable`). When this gets passed to rustfix, rustfix makes *multiple* changes according to the suggestions which result in incorrect code.
This is a temporary workaround. The real long term solution to problems like these is to address <https://github.com/rust-lang/rust/issues/53934>.
This PR also includes a drive-by edit to the panic message emitted by compiletest because "ui" test suite now uses `//`@`` directives.
Fixes#121330.
Make --verbose imply -Z write-long-types-to-disk=no
When shortening the type it is necessary to take into account the `--verbose` flag, if it is activated, we must always show the entire type and not write it in a file.
Fixes: https://github.com/rust-lang/rust/issues/119130
Convert `delayed_bug`s to `bug`s.
I have a suspicion that quite a few delayed bug paths are impossible to reach, so I did an experiment.
I converted every `delayed_bug` to a `bug`, ran the full test suite, then converted back every `bug` that was hit. A surprising number were never hit.
This is too dangerous to merge. Increased coverage (fuzzing or a crater run) would likely hit more cases. But it might be useful for people to look at and think about which paths are genuinely unreachable.
r? `@ghost`
wasm: Store rlib metadata in wasm object files
The goal of this commit is to remove warnings using LLVM tip-of-tree `wasm-ld`. In llvm/llvm-project#78658 the `wasm-ld` LLD driver no longer looks at archive indices and instead looks at all the objects in archives. Previously `lib.rmeta` files were simply raw rustc metadata bytes, not wasm objects, meaning that `wasm-ld` would emit a warning indicating so.
WebAssembly targets previously passed `--fatal-warnings` to `wasm-ld` by default which meant that if Rust were to update to LLVM 18 then all wasm targets would not work. This immediate blocker was resolved in rust-lang/rust#120278 which removed `--fatal-warnings` which enabled a theoretical update to LLVM 18 for wasm targets. This current state is ok-enough for now because rustc squashes all linker output by default if it doesn't fail. This means, for example, that rustc squashes all the linker warnings coming out of `wasm-ld` about `lib.rmeta` files with LLVM 18. This again isn't a pressing issue because the information is all hidden, but it runs the risk of being annoying if another linker error were to happen and then the output would have all these unrelated warnings that couldn't be fixed.
Thus, this PR comes into the picture. The goal of this PR is to resolve these warnings by using the WebAssembly object file format on wasm targets instead of using raw rustc metadata. When I first implemented the rlib-in-objects scheme in #84449 I remember either concluding that `wasm-ld` would either include the metadata in the output or I thought we didn't have to do anything there at all. I think I was wrong on both counts as `wasm-ld` does not include the metadata in the final output unless the object is referenced and we do actually need to do something to resolve these warnings.
This PR updates the object file format containing rustc metadata on WebAssembly targets to be an actual WebAssembly file. To avoid bringing in any new dependencies I've opted to hand-code this encoding at this time. If the object gets more complicated though it'd probably be best to pull in `wasmparser` and `wasm-encoder`. For now though there's two adjacent functions reading/writing wasm.
The only caveat I know of with this is that if `wasm-ld` does indeed look at the object file then the metadata will be included in the final output. I believe the only thing that could cause that at this time is `--whole-archive` which I don't think is passed for rlibs. I would clarify that I'm not 100% certain about this, however.
If we abort immediately after complaining about the obsolete `impl Trait
for ..` syntax, then we avoid reaching HIR lowering. This means we can
use `TyKind::Dummy` instead of `TyKind::Err`.
match lowering: simplify empty candidate selection
In match lowering, `match_simplified_candidates` is tasked with removing candidates that are fully matched and linking them up properly. The code that does that was needlessly complicated; this PR simplifies it.
The overall change isn't big but I split it up into tiny commits to convince myself that I was correctly preserving behavior. The test changes are all due to the first commit. Let me know if you'd prefer me to split up the PR to make reviewing easier.
r? `@matthewjasper`
match lowering: eagerly simplify match pairs
This removes one important complication from match lowering. Before this, match pair simplification (which includes collecting bindings and type ascriptions) was intertwined with the whole match lowering algorithm.
I'm avoiding this by storing in each `MatchPair` the sub-`MatchPair`s that correspond to its subfields. This makes it possible to simplify everything (except or-patterns) in `Candidate::new()`.
This should open up further simplifications. It will also give us proper control over the order of bindings.
r? `@matthewjasper`
Because:
- `diagnostic_builder.rs` is small (282 lines),
- `Diagnostic` and `DiagnosticBuilder` are closely related types, and
- there's already an `impl DiagnosticBuilder` block in `diagnostic.rs`.
At the same time, reorder a few of things already in `diagnostic.rs`,
e.g. move `struct Diagnostic` just before `impl Diagnostic`.
This commit only moves code around. There are no functional changes.
I have a suspicion that quite a few delayed bug paths are impossible to
reach, so I did an experiment.
I converted every `delayed_bug` to a `bug`, ran the full test suite,
then converted back every `bug` that was hit. A surprising number were
never hit.
The next commit will convert some more back, based on human judgment.
Rollup of 7 pull requests
Successful merges:
- #119203 (Correct the simd_masked_{load,store} intrinsic docs)
- #121277 (Refactor trait implementations in `core::convert::num`.)
- #121322 (Don't ICE when hitting overflow limit in fulfillment loop in next solver)
- #121323 (Don't use raw parameter types in `find_builder_fn`)
- #121344 (Expand weak alias types before collecting constrained/referenced late bound regions + refactorings)
- #121350 (Fix stray trait mismatch in `resolve_associated_item` for `AsyncFn`)
- #121352 (docs: add missing "the" to `str::strip_prefix` doc)
Failed merges:
- #121340 (bootstrap: apply most of clippy's suggestions)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix stray trait mismatch in `resolve_associated_item` for `AsyncFn`
Copy-paste error meant that we were calling `fn_trait_kind_from_def_id` instead of `async_fn_trait_kind_from_def_id`. But turns out we don't even need to do that, since we already matched the trait def id above.
Fixes#121306
r? oli-obk
Don't use raw parameter types in `find_builder_fn`
We shouldn't really ever be using `EarlyBinder::skip_binder` then performing type equality, since param types will never be equal to other types. When checking compatibility with the signature, we instead create some fresh args.
Fixes#121314
Don't ICE when hitting overflow limit in fulfillment loop in next solver
As the title says, let's not ICE when hitting the overflow limit in fulfill. On the other hand, we don't want to treat these as true errors, since it means that whether something is considered a true error or an ambiguity is dependent on overflow handling in the solver, which seems not worth it.
Now that we use the presence of true errors in fulfillment for implicit negative coherence, we especially don't want to tie together coherence and overflow.
I guess I could also drain these errors out of fulfillment and put them into some `ambiguities` storage so we could return them in `select_all_or_error` without having to re-process them every time we call `select_where_possible`. Let me know if that's desired.
r? lcnr
Refactor trait implementations in `core::convert::num`.
Tracking issue: https://github.com/rust-lang/rust/issues/120257
Implement conversion traits using generic `NonZero` type, and refactor all macros to use a consistent format/order of parameters.
r? `@dtolnay`
Correct the simd_masked_{load,store} intrinsic docs
Explains the uniform pointer being used for these two operations and how elements are offset from it.
The goal of this commit is to remove warnings using LLVM tip-of-tree
`wasm-ld`. In llvm/llvm-project#78658 the `wasm-ld` LLD driver no longer
looks at archive indices and instead looks at all the objects in
archives. Previously `lib.rmeta` files were simply raw rustc metadata
bytes, not wasm objects, meaning that `wasm-ld` would emit a warning
indicating so.
WebAssembly targets previously passed `--fatal-warnings` to `wasm-ld` by
default which meant that if Rust were to update to LLVM 18 then all wasm
targets would not work. This immediate blocker was resolved in
rust-lang/rust#120278 which removed `--fatal-warnings` which enabled a
theoretical update to LLVM 18 for wasm targets. This current state is
ok-enough for now because rustc squashes all linker output by default if
it doesn't fail. This means, for example, that rustc squashes all the
linker warnings coming out of `wasm-ld` about `lib.rmeta` files with
LLVM 18. This again isn't a pressing issue because the information is
all hidden, but it runs the risk of being annoying if another linker
error were to happen and then the output would have all these unrelated
warnings that couldn't be fixed.
Thus, this PR comes into the picture. The goal of this PR is to resolve
these warnings by using the WebAssembly object file format on wasm
targets instead of using raw rustc metadata. When I first implemented
the rlib-in-objects scheme in #84449 I remember either concluding that
`wasm-ld` would either include the metadata in the output or I thought
we didn't have to do anything there at all. I think I was wrong on both
counts as `wasm-ld` does not include the metadata in the final output
unless the object is referenced and we do actually need to do something
to resolve these warnings.
This PR updates the object file format containing rustc metadata on
WebAssembly targets to be an actual WebAssembly file. This enables the
`wasm` feature of the `object` crate to be able to read the custom
section in the same manner as other platforms, but currently `object`
doesn't support writing wasm object files so a handwritten encoder is
used instead.
The only caveat I know of with this is that if `wasm-ld` does indeed
look at the object file then the metadata will be included in the final
output. I believe the only thing that could cause that at this time is
`--whole-archive` which I don't think is passed for rlibs. I would
clarify that I'm not 100% certain about this, however.
It is possible to have more than one valid suggestion, which when
applied together via rustfix causes the code to no longer compile.
This is a temporary workaround; the real long term solution to these
issues is to solve <https://github.com/rust-lang/rust/issues/53934>.
