Some cleanups in our normalization logic
Changed a match to be exhaustive and deduplicated some code.
r? ```@compiler-errors```
this pulls out the uncontroversial part of https://github.com/rust-lang/rust/pull/108860
make `define_opaque_types` fully explicit
based on the idea of #108389. Moved `define_opaque_types` into the actual operations, e.g. `eq`, instead of `infcx.at` because normalization doesn't use `define_opaque_types` and even creates it's own `At` with a different `define_opaque_types` internally.
Somewhat surprisingly, coherence actually relies on `DefineOpaqueTypes::Yes` for soundness which was revealed because I've incorrectly used `DefineOpaqueTypes::No` in `equate_impl_headers`. It feels concerning that even though this is the case, we still sometimes use `DefineOpaqueTypes::No` in coherence. I did not look into this as part of this PR as it is purely changing the structure of the code without changing behavior in any way.
r? ```@oli-obk```
rustdoc: DocFS: Replace rayon with threadpool and enable it for all targets
Fixes https://github.com/rust-lang/rust/issues/109060.
Switching to `threadpool` makes it a bit simpler for us to wait for all tasks in `DocFS` directly in the `Drop` implementation. I'm also curious if making all the writes into a thread pool could improve run time for rustdoc on all other platforms than Windows as well.
I'll run a perf check to see.
cc ```@ehuss```
r? ```@notriddle```
error-msg: impl better suggestion for `E0532`
Fixes#106862
No test as there is already a test which is nearly identical to the example in the linked issue.
Revert #107376 to fix potential `bincode` breakage and `rustc-perf` benchmark.
#107376 caused `rustc-perf`'s `webrender` benchmark to break, by regressing on the `bincode-1.3.3` crate.
~~This PR is a draft revert in case we can't land a fix soon enough, and we'd like to land the revert instead~~
(Though I myself think it'd be safer to do the revert, and run crater when relanding #107376.)
cc `@aliemjay`
Implement checked Shl/Shr at MIR building.
This does not require any special handling by codegen backends,
as the overflow behaviour is entirely determined by the rhs (shift amount).
This allows MIR ConstProp to remove the overflow check for constant shifts.
~There is an existing different behaviour between cg_llvm and cg_clif (cc `@bjorn3).`
I took cg_llvm's one as reference: overflow if `rhs < 0 || rhs > number_of_bits_in_lhs_ty`.~
EDIT: `cg_llvm` and `cg_clif` implement the overflow check differently. This PR uses `cg_llvm`'s implementation based on a `BitAnd` instead of `cg_clif`'s one based on an unsigned comparison.
Sync rustc_codegen_cranelift
Bunch of bug fixes this time. Also an update to Cranelift 0.93 which adds a brand new optimization pass which cg_clif exposes when using `--release`. And various improvements to cg_clif's test suite, making it faster to run. And finally two small perf improvements.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
Rollup of 7 pull requests
Successful merges:
- #108991 (add `enable-warnings` flag for llvm, and disable it by default.)
- #109109 (Use `unused_generic_params` from crate metadata)
- #109111 (Create dirs for build_triple)
- #109136 (Simplify proc macro signature validity check)
- #109150 (Update cargo)
- #109154 (Fix MappingToUnit to support no span of arg_ty)
- #109157 (Remove mw from review rotation for a while)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
This patched has been necessary for subtree syncs from the start, but
previously it was necessary to locally install tqc's patched git
version, which hasn't been updated for quite a while. I made a small
change to allow downloading it as script without requiring an entire git
installation for the patched version.
This removes a dependency on ntapi 0.3.x which failed to compiled with
latest beta.
rust-lang/rustc-perf@93dc60d995 removed
that dependency in the upstream rustc-perf.
Install binaries to the miri toolchain's sysroot
The default install produces this behavior:
```
$ cargo +miri miri --version
miri 0.1.0 (0ba1f4a0 2023-03-05)
$ cargo +nightly miri --version
miri 0.1.0 (0ba1f4a0 2023-03-05)
```
Which is not good. We've effectively erased the toolchain selection, and users may reasonably conclude that their rustup install is broken.
After this change, we now get this:
```
$ cargo +miri miri --version
miri 0.1.0 (0ba1f4a0 2023-03-05)
$ cargo +nightly miri --version
miri 0.1.0 (f63ccaf 2023-03-06)
```
Thanks `@jyn514` who all but wrote this for me.
