Normalize each signature input/output in `typeck_with_fallback` with its own span
Applies the same hack as #106582 but to the args in typeck. Greatly improves normalization error spans from a signature.
remove unnecessary `eval_verify_bound`
This does not impact any tests. I feel like any cases where this could useful should instead be fixed by a general improvement to `eval_verify_bound` to avoid having to promote this `TypeTest` in the first place 🤔
r? types cc ``@nikomatsakis``
Avoid naming variables `str`
This renames variables named `str` to other names, to make sure `str`
always refers to a type.
It's confusing to read code where `str` (or another standard type name)
is used as an identifier. It also produces misleading syntax
highlighting.
llvm: Ignore error value that is always false
See llvm/llvm-project#121851
For LLVM 20+, this function (`renameModuleForThinLTO`) has no return value. For prior versions of LLVM, this never failed, but had a signature which allowed an error value people were handling.
`@rustbot` label: +llvm-main
r? `@nikic`
Wait a moment before approving while the llvm-main infrastructure picks it up.
This renames variables named `str` to other names, to make sure `str`
always refers to a type.
It's confusing to read code where `str` (or another standard type name)
is used as an identifier. It also produces misleading syntax
highlighting.
Avoid replacing the definition of `CURRENT_RUSTC_VERSION`
Before this PR, replace-version-placeholder hardcoded the path defining CURRENT_RUSTC_VERSION (to avoid replacing it). After a refactor moved the file defining it without changing the hardcoded path, the tool started replacing the constant itself with the version number.
To avoid this from happening in the future, this changes the definition of the constant to avoid the tool from ever matching it.
r? `@workingjubilee`
mark deprecated option as deprecated in rustc_session to remove copypasta and small refactor
This marks deprecated options as deprecated via flag in options table in rustc_session, which removes copypasted deprecation text from rustc_driver_impl.
This also adds warning for deprecated `-C ar` option, which didn't emitted any warnings before.
Makes `inline_threshold` `[UNTRACKED]`, as it do nothing.
Adds few tests.
See individual commits.
Suggest to replace tuple constructor through projection
See the code example. when `Self::Assoc` normalizes to a struct that has a tuple constructor, you cannot construct the type via `Self::Assoc(field, field)`. Instead, suggest to replace it with the correct named struct.
Fixes#120871
Don't ice on bad transmute in typeck in new solver
Old trait solver ends up getting its infcx tainted because we try to normalize the type, but the new trait solver doesn't. This means we try to compute the stalled transmute obligations, which tries to normalize a type an ICEs. Let's make this a delayed bug.
r? lcnr
Improve diagnostics for `HostEffectPredicate` in the new solver
Adds derived cause for host effect predicates. Some diagnostics regress, but that's connected to the fact that our predicate visitor doesn't play well with aliases just yet.
Add support for wasm exception handling to Emscripten target
This is a draft because we need some additional setting for the Emscripten target to select between the old exception handling and the new exception handling. I don't know how to add a setting like that, would appreciate advice from Rust folks. We could maybe choose to use the new exception handling if `Ctarget-feature=+exception-handling` is passed? I tried this but I get errors from llvm so I'm not doing it right.
See llvm/llvm-project#121851
For LLVM 20+, this function (`renameModuleForThinLTO`) has no return
value. For prior versions of LLVM, this never failed, but had a
signature which allowed an error value people were handling.
Before this commit, replace-version-placeholder hardcoded the path
defining CURRENT_RUSTC_VERSION (to avoid replacing it). After a refactor
moved the file defining it without changing the hardcoded path, the tool
started replacing the constant itself with the version number.
To avoid this from happening in the future, this changes the definition
of the constant to avoid the tool from ever matching it.
Suppress host effect predicates if underlying trait doesn't hold
Don't report two errors for when the (`HostEffectPredicate`) `T: const Trait` isn't implemented because (`TraitPredicate`) `T: Trait` doesn't even hold.
Use `PostBorrowckAnalysis` in `check_coroutine_obligations`
This currently errors with:
```
error: concrete type differs from previous defining opaque type use
--> tests/ui/coroutine/issue-52304.rs:10:21
|
10 | pub fn example() -> impl Coroutine {
| ^^^^^^^^^^^^^^ expected `{example::{closure#0} upvar_tys=() resume_ty=() yield_ty=&'{erased} i32 return_ty=() witness={example::{closure#0}}}`, got `{example::{closure#0} upvar_tys=() resume_ty=() yield_ty=&'static i32 return_ty=() witness={example::{closure#0}}}`
|
= note: previous use here
```
This is because we end up redefining the opaque in `check_coroutine_obligations` but with the `yield_ty = &'erased i32` from hir typeck, which causes the *equality* check for opaques to fail.
The coroutine obligtions in question (when `-Znext-solver` is enabled) are:
```
Binder { value: TraitPredicate(<Opaque(DefId(0:5 ~ issue_52304[4c6d]::example::{opaque#0}), []) as std::marker::Sized>, polarity:Positive), bound_vars: [] }
Binder { value: AliasRelate(Term::Ty(Alias(Opaque, AliasTy { args: [], def_id: DefId(0:5 ~ issue_52304[4c6d]::example::{opaque#0}), .. })), Equate, Term::Ty(Coroutine(DefId(0:6 ~ issue_52304[4c6d]::example::{closure#0}), [(), (), &'{erased} i32, (), CoroutineWitness(DefId(0:6 ~ issue_52304[4c6d]::example::{closure#0}), []), ()]))), bound_vars: [] }
Binder { value: AliasRelate(Term::Ty(Coroutine(DefId(0:6 ~ issue_52304[4c6d]::example::{closure#0}), [(), (), &'{erased} i32, (), CoroutineWitness(DefId(0:6 ~ issue_52304[4c6d]::example::{closure#0}), []), ()])), Subtype, Term::Ty(Alias(Opaque, AliasTy { args: [], def_id: DefId(0:5 ~ issue_52304[4c6d]::example::{opaque#0}), .. }))), bound_vars: [] }
```
Ignoring the fact that we end up stalling some really dumb obligations here (lol), I think it makes more sense for us to be using post borrowck analysis for this check anyways.
r? lcnr
inline_threshold mark deprecated
no-stack-check
print deprecation message for -Car too
inline_threshold deprecated and do nothing: make in untracked
make OptionDesc struct from tuple
A few borrowck tweaks to improve 2024 edition migration lints
See first two commits' changes to test outputs. Test coverage in this area is kinda weak, but I think it affects more cases than this (like the craters that will begin to trigger the `tail_expr_drop_order` tests in #134523).
Third commit is a drive-by change that removes a deref hack from `UseSpans` which doesn't really improve diagnostics much.
Mention `unnameable_types` in `unreachable_pub` documentation.
This link makes sense because someone who wishes to avoid unusable `pub` is likely, but not guaranteed, to be interested in avoiding unnameable types.
Also fixed some grammar problems I noticed in the area.
Fixes#116604.
r? Urgau
add m68k-unknown-none-elf target
r? `@workingjubilee`
The existing `m68k-unknown-linux-gnu` target builds `std` by default, requires atomics, and has a base cpu with an fpu. A smaller/more embedded target is desirable both to have a baseline target for the ISA, as well to make debugging easier for working on the llvm backend. Currently this target is using the `M68010` as the minimum CPU due, but as missing features are merged into the `M68k` llvm backend I am hoping to lower this further.
I have been able to build very small crates using a toolchain built against this target (together with a later version of `object`) using the configuration described in the target platform-support documentation, although getting anything of substantial complexity to build quickly hits errors in the llvm backend
This link makes sense because someone who wishes to avoid unusable `pub`
is likely, but not guaranteed, to be interested in avoiding unnameable
types.
Also fixed some grammar problems I noticed in the area.
Fixes#116604.
cg_llvm: Use constants for DWARF opcodes, instead of FFI calls
Split off from #134009 to incorporate feedback from https://github.com/rust-lang/rust/pull/134009#discussion_r1903133906.
Most of the constant values now come from gimli, which is already a compiler dependency.
I noticed that `DW_OP_LLVM_fragment` is an LLVM detail that is not defined by DWARF and could hypothetically change, so I added a static assertion on the C++ side to detect that if it ever happens.
r? workingjubilee
Add a notion of "some ABIs require certain target features"
I think I finally found the right shape for the data and checks that I recently added in https://github.com/rust-lang/rust/pull/133099, https://github.com/rust-lang/rust/pull/133417, https://github.com/rust-lang/rust/pull/134337: we have a notion of "this ABI requires the following list of target features, and it is incompatible with the following list of target features". Both `-Ctarget-feature` and `#[target_feature]` are updated to ensure we follow the rules of the ABI. This removes all the "toggleability" stuff introduced before, though we do keep the notion of a fully "forbidden" target feature -- this is needed to deal with target features that are actual ABI switches, and hence are needed to even compute the list of required target features.
We always explicitly (un)set all required and in-conflict features, just to avoid potential trouble caused by the default features of whatever the base CPU is. We do this *before* applying `-Ctarget-feature` to maintain backward compatibility; this poses a slight risk of missing some implicit feature dependencies in LLVM but has the advantage of not breaking users that deliberately toggle ABI-relevant target features. They get a warning but the feature does get toggled the way they requested.
For now, our logic supports x86, ARM, and RISC-V (just like the previous logic did). Unsurprisingly, RISC-V is the nicest. ;)
As a side-effect this also (unstably) allows *enabling* `x87` when that is harmless. I used the opportunity to mark SSE2 as required on x86-64, to better match the actual logic in LLVM and because all x86-64 chips do have SSE2. This infrastructure also prepares us for requiring SSE on x86-32 when we want to use that for our ABI (and for float semantics sanity), see https://github.com/rust-lang/rust/issues/133611, but no such change is happening in this PR.
r? `@workingjubilee`
Target: Add mips mti baremetal support
Do the same thing as gcc, which use the vendor `mti` to mark the toolchain as MIPS32r2 default.
We support both big endian and little endian flavor:
mips-mti-none-elf
mipsel-mti-none-elf
[Debuginfo] Force enum `DISCR_*` to `static const u64` to allow for inspection via LLDB
see [here](486614878) for more info.
This change mainly helps `*-msvc` debugged with LLDB. Currently, LLDB cannot inspect `static` struct fields, so the intended visualization for enums is only borderline functional, and niche enums with ranges of discriminant cannot be determined at all .
LLDB *can* inspect `static const` values (though for whatever reason, non-enum/non-u64 consts don't work).
This change adds the `LLVMRustDIBuilderCreateQualifiedType` to the rust FFI layer to wrap the discr type with a `const` modifier, as well as forcing all generated integer enum `DISCR_*` values to be u64's. Those values will only ever be used by debugger visualizers anyway, so it shouldn't be a huge deal, but I left a fixme comment for it just in case.. The `tag` also still properly reflects the discriminant type, so no information is lost.
