force-recompile library changes on download-rustc="if-unchanged"
This makes the download-rustc="if-unchanged" option more functional and useful for library developers.
Implements the second item from [this tracking issue](https://github.com/rust-lang/rust/issues/131744).
Rename `rustc_abi::Abi` to `BackendRepr`
Remove the confabulation of `rustc_abi::Abi` with what "ABI" actually means by renaming it to `BackendRepr`, and rename `Abi::Aggregate` to `BackendRepr::Memory`. The type never actually represented how things are passed, as that has to have `PassMode` considered, at minimum, but rather it just is how we represented some things to the backend. This conflation arose because LLVM, the primary backend at the time, would lower certain IR forms using certain ABIs. Even that only somewhat was true, as it broke down when one ventured significantly afield of what is described by the System V AMD64 ABI either by using different architectures, ABI-modifying IR annotations, the same architecture **with different ISA extensions enabled**, or other... unexpected delights.
Unfortunately both names are still somewhat of a misnomer right now, as people have written code for years based on this misunderstanding. Still, their original names are even moreso, and for better or worse, this backend code hasn't received as much maintenance as the rest of the compiler, lately. Actually arriving at a correct end-state will simply require us to disentangle a lot of code in order to fix, much of it pointlessly repeated in several places. Thus this is not an "actual fix", just a way to deflect further misunderstandings.
rustdoc: make doctest span tweak a 2024 edition change
Fixes#132203
This is a compatibility hack, because I think the new behavior is better. When an A `include_str!` B, and B `include_str!` C, the path to C should be resolved relative to B, not A. That's how `include!` itself works, so that's how `include_str!` with should work.
Remap impl-trait lifetimes on HIR instead of AST lowering
Current AST->HIR lowering goes out of its way to remap lifetimes for opaque types. This is complicated and leaks into upstream and downstream code.
This PR stops trying to be clever during lowering, and prefers to do this remapping during the HIR->ty lowering. The remapping computation easily fits into the bound var resolution code. Its result can be used in by `generics_of` and `hir_ty_lowering::new_opaque` to add the proper parameters and arguments.
See an example on the doc for query `opaque_captured_lifetimes`.
Based on https://github.com/rust-lang/rust/pull/129244/
Fixes https://github.com/rust-lang/rust/issues/125249
Fixes https://github.com/rust-lang/rust/issues/126850
cc `@compiler-errors` `@spastorino`
r? `@petrochenkov`
Fix AIX libc call char type from i8 to u8
There was an update to AIX `libc` default char type from `i8 -> u8`, we should reflect that on the call site to satisfy the type checker.
81f0cd3d97/src/unix/aix/mod.rs (L1)
compiletest: improve robustness of LLVM version handling
Previously, `extract_llvm_versions` did some gymnastics for llvm versions by combining `(major, minor, patch)` into a combined version integer, but that is not very robust and made it difficult to add `max-llvm-major-version`. This PR tries to:
- Improve llvm version handling robustness by parsing and representing the version as a semver. We intentionally deviate from strict semver standards by allowing omission of minor and patch versions. They default to `0` when absent. This is for convenience to allow the user to write e.g. `//@ min-llvm-version: 18` instead of having to spell out the full `major.minor.patch` semver string `//@ min-llvm-verison: 18.0.0`.
- Adjust some panic messages to include a bit more context about *why* the version string was rejected.
Prerequisite for #132310.
r? bootstrap (or compiler)
rustdoc: Remove usage of `allow(unused)` attribute on `no_run` merged doctests
Fixes [#130681](https://github.com/rust-lang/rust/issues/130681).
It fixes the behaviour difference with the current doctests.
r? ``@notriddle``
Reject generic self types.
The RFC for arbitrary self types v2 declares that we should reject "generic" self types. This commit does so.
The definition of "generic" was unclear in the RFC, but has been explored in
https://github.com/rust-lang/rust/issues/129147
and the conclusion is that "generic" means any `self` type which is a type parameter defined on the method itself, or references to such a type.
This approach was chosen because other definitions of "generic" don't work. Specifically,
* we can't filter out generic type _arguments_, because that would filter out Rc<Self> and all the other types of smart pointer we want to support;
* we can't filter out all type params, because Self itself is a type param, and because existing Rust code depends on other type params declared on the type (as opposed to the method).
This PR decides to make a new error code for this case, instead of reusing the existing E0307 error. This makes the code a bit more complex, but it seems we have an opportunity to provide specific diagnostics for this case so we should do so.
This PR filters out generic self types whether or not the 'arbitrary self types' feature is enabled. However, it's believed that it can't have any effect on code which uses stable Rust, since there are no stable traits which can be used to indicate a valid generic receiver type, and thus it would have been impossible to write code which could trigger this new error case. It is however possible that this could break existing code which uses either of the unstable `arbitrary_self_types` or `receiver_trait` features. This breakage is intentional; as we move arbitrary self types towards stabilization we don't want to continue to support generic such types.
This PR adds lots of extra tests to arbitrary-self-from-method-substs. Most of these are ways to trigger a "type mismatch" error which 9b82580c73/compiler/rustc_hir_typeck/src/method/confirm.rs (L519) hopes can be minimized by filtering out generics in this way. We remove a FIXME from confirm.rs suggesting that we make this change. It's still possible to cause type mismatch errors, and a subsequent PR may be able to improve diagnostics in this area, but it's harder to cause these errors without contrived uses of the turbofish.
This is a part of the arbitrary self types v2 project, https://github.com/rust-lang/rfcs/pull/3519https://github.com/rust-lang/rust/issues/44874
r? `@wesleywiser`
The RFC for arbitrary self types v2 declares that we should reject
"generic" self types. This commit does so.
The definition of "generic" was unclear in the RFC, but has been
explored in
https://github.com/rust-lang/rust/issues/129147
and the conclusion is that "generic" means any `self` type which
is a type parameter defined on the method itself, or references
to such a type.
This approach was chosen because other definitions of "generic"
don't work. Specifically,
* we can't filter out generic type _arguments_, because that would
filter out Rc<Self> and all the other types of smart pointer
we want to support;
* we can't filter out all type params, because Self itself is a
type param, and because existing Rust code depends on other
type params declared on the type (as opposed to the method).
This PR decides to make a new error code for this case, instead of
reusing the existing E0307 error. This makes the code a
bit more complex, but it seems we have an opportunity to provide
specific diagnostics for this case so we should do so.
This PR filters out generic self types whether or not the
'arbitrary self types' feature is enabled. However, it's believed
that it can't have any effect on code which uses stable Rust, since
there are no stable traits which can be used to indicate a valid
generic receiver type, and thus it would have been impossible to
write code which could trigger this new error case.
It is however possible that this could break existing code which
uses either of the unstable `arbitrary_self_types` or
`receiver_trait` features. This breakage is intentional; as
we move arbitrary self types towards stabilization we don't want
to continue to support generic such types.
This PR adds lots of extra tests to arbitrary-self-from-method-substs.
Most of these are ways to trigger a "type mismatch" error which
9b82580c73/compiler/rustc_hir_typeck/src/method/confirm.rs (L519)
hopes can be minimized by filtering out generics in this way.
We remove a FIXME from confirm.rs suggesting that we make this change.
It's still possible to cause type mismatch errors, and a subsequent
PR may be able to improve diagnostics in this area, but it's harder
to cause these errors without contrived uses of the turbofish.
This is a part of the arbitrary self types v2 project,
https://github.com/rust-lang/rfcs/pull/3519https://github.com/rust-lang/rust/issues/44874
r? @wesleywiser
Fix directives for lint-non-snake-case-crate
This test fails on targets without unwinding or with `--target-rustcflags=-Cpanic=abort` because the proc macro was compiled as the target, not the host. Some targets were explicitly disabled to pass CI, but these directives are more general.
* `needs-dynamic-linking` is self explanatory
* `force-host` for proc macros
* `no-prefer-dynamic` is apparently also used for proc macros
Note that `needs-unwind` can also be useful for situations other than proc macros where unwinding is necessary.
r? `@jieyouxu`
try-job: test-various
cg_llvm: Clean up FFI calls for operand bundles
All of these FFI functions have equivalents in the stable LLVM-C API, though `LLVMBuildCallBr` requires a temporary polyfill on LLVM 18.
This PR also creates a clear split between `OperandBundleOwned` and `OperandBundle`, and updates the internals of the owner to be a little less terrifying.
Use `token_descr` more in error messages
This is the first two commits from #124141, put into their own PR to get things rolling. Commit messages have the details.
r? ``@estebank``
cc ``@petrochenkov``
Point to Fuchsia team in platform support docs
This consolidates our docs into a single source of truth for the current Fuchsia maintainers.
r? ```@tmandry```
powerpc64-ibm-aix: update maintainters
Chaofan (`@ecnelises)` and Kai (`@bzEq)` will be passing over maintainership for the target over to David Tenty (`@daltenty)` and Chris Cambly (`@gilamn5tr)`
TypingMode: merge intercrate, reveal, and defining_opaque_types
This adds `TypingMode` and uses it in most places. We do not yet remove `Reveal` from `param_env`s. This and other future work as tracked in #132279 and via `FIXME`s.
Fetching the `TypingMode` of the `InferCtxt` asserts that the `TypingMode` agrees with `ParamEnv::reveal` to make sure we don't introduce any subtle bugs here. This will be unnecessary once `ParamEnv::reveal` no longer exists.
As the `TypingMode` is now a part of the query input, I've merged the coherence and non-coherence caches for the new solver. I've also enabled the local `infcx` cache during coherence by clearing the cache when forking it with a different `TypingMode`.
#### `TypingMode::from_param_env`
I am using this even in cases where I know that the `param_env` will always be `Reveal::UserFacing`. This is to make it easier to correctly refactor this code in the future, any time we use `Reveal::UserFacing` in a body while not defining its opaque types is incorrect and should use a `TypingMode` which only reveals opaques defined by that body instead, cc #124598
r? ``@compiler-errors``
Don't lint `irrefutable_let_patterns` on leading patterns if `else if` let-chains
fixes#128661
Is there any preference where the test goes? There looks to be several places it could fit.
Use Hacker's Delight impl in `i64::midpoint` instead of wide `i128` impl
This PR switches `i64::midpoint` and (`isize::midpoint` where `isize == i64`) to using our Hacker's Delight impl instead of wide `i128` implementation.
As LLVM seems to be outperformed by the complexity of signed 128-bits number compared to our Hacker's Delight implementation.[^1]
It doesn't seems like it's an improvement for the other sizes[^2], so we let them with the wide implementation.
[^1]: https://rust.godbolt.org/z/ravE75EYj
[^2]: https://rust.godbolt.org/z/fzr171zKh
r? libs
`Formatter` currently has a `RefCell<Option<Results>>` field. This is so
the `Results` can be temporarily taken and put into a `ResultsCursor`
that is used by `BlockFormatter`, and then put back, which is messy.
This commit changes `Formatter` to have a `RefCell<ResultsCursor>` and
`BlockFormatter` to have a `&mut ResultsCursor`, which greatly
simplifies the code at the `Formatter`/`BlockFormatter` interaction
point in `Formatter::node_label`. It also means we construct a
`ResultsCursor` once per `Formatter`, instead of once per `node_label`
call.
The commit also:
- documents the reason for the `RefCell`;
- adds a `Formatter::body` method, replacing the `Formatter::body`
field.
This test fails on targets without unwinding because the proc macro was
compiled as the target, not the host. Some targets were explicitly
disabled to pass CI, but these directives are more general.
Fixes Fuchsia tests.
It's no longer needed. `Engine::iterate_to_fixpoint` can be inlined into
`Analysis::iterate_to_fixpoint` and removed. The commit also renames
`engine.rs` as `results.rs`.
This is a standard pattern:
```
MyAnalysis.into_engine(tcx, body).iterate_to_fixpoint()
```
`into_engine` and `iterate_to_fixpoint` are always called in pairs, but
sometimes with a builder-style `pass_name` call between them. But a
builder-style interface is overkill here. This has been bugging me a for
a while.
This commit:
- Merges `Engine::new` and `Engine::iterate_to_fixpoint`. This removes
the need for `Engine` to have fields, leaving it as a trivial type
that the next commit will remove.
- Renames `Analysis::into_engine` as `Analysis::iterate_to_fixpoint`,
gives it an extra argument for the optional pass name, and makes it
call `Engine::iterate_to_fixpoint` instead of `Engine::new`.
This turns the pattern from above into this:
```
MyAnalysis.iterate_to_fixpoint(tcx, body, None)
```
which is shorter at every call site, and there's less plumbing required
to support it.
