In the LLVM-C API, boolean values are passed as `typedef int LLVMBool`, but our
Rust-side typedef was using `c_uint` instead.
Signed and unsigned integers have the same ABI on most platforms, but that
isn't universally true, so we should prefer to be consistent with LLVM.
allow `symbol_intern_string_literal` lint in test modules
Since #133545, `x check compiler --stage 1` no longer works because compiler test modules trigger `symbol_intern_string_literal` lint errors. Bootstrap shouldn't control when to ignore or enable this lint in the compiler tree (using `Kind != Test` was ineffective for obvious reasons).
Also, conditionally adding this rustflag invalidates the build cache between `x test` and other commands.
This PR removes the `Kind` check from bootstrap and handles it directly in the compiler tree in a more natural way.
suppress field expr with generics error message if it's a method
Don't emit "field expressions may not have generic arguments" if it's a method call without `()`
r? estebank
Fixes#67680
Is this the best way to go? It's by far the simplest I could come up with.
Simplify `rustc_mir_dataflow::abs_domain`.
`rustc_mir_dataflow` has a typedef `AbstractElem` that is equal to `ProjectionElem<AbstractOperand, AbstractType>`. `AbstractOperand` and `AbstractType` are both unit types. There is also has a trait `Lift` to convert a `PlaceElem` to an `AbstractElem`.
But `rustc_mir_middle` already has a typedef `ProjectionKind` that is equal to `ProjectionElem<(), ()>`, which is equivalent to `AbstractElem`. So this commit reuses `ProjectionKind` in `rustc_mir_dataflow`, removes `AbstractElem`, and simplifies the `Lift` trait.
r? ``@pnkfelix``
Some asm! diagnostic adjustments and a papercut fix
Best reviewed commit by commit.
We forgot a `normalize` call in intrinsic checking, causing us to allow literal integers, but not named constants containing that literal. This can in theory affect stable code, but only if libstd contains a stable SIMD type that has an array length that is a named constant. I'd assume we'd have noticed by now due to asm! rejecting those outright.
The error message left me scratching my head for a bit, so I added some extra information to the diagnostic, too.
Pass end position of span through inline ASM cookie
Before this PR, only the start position of the span was passed though the inline ASM cookie to diagnostics. LLVM 19 has full support for 64-bit inline ASM cookies; this PR uses that to pass the end position of the span in the upper 32 bits, meaning inline ASM diagnostics now point at the entire line the error occurred on, not just the first character of it.
codegen `#[naked]` functions using global asm
tracking issue: https://github.com/rust-lang/rust/issues/90957Fixes#124375
This implements the approach suggested in the tracking issue: use the existing global assembly infrastructure to emit the body of `#[naked]` functions. The main advantage is that we now have full control over what gets generated, and are no longer dependent on LLVM not sneakily messing with our output (inlining, adding extra instructions, etc).
I discussed this approach with `@Amanieu` and while I think the general direction is correct, there is probably a bunch of stuff that needs to change or move around here. I'll leave some inline comments on things that I'm not sure about.
Combined with https://github.com/rust-lang/rust/pull/127853, if both accepted, I think that resolves all steps from the tracking issue.
r? `@Amanieu`
coverage: Rearrange the code for embedding per-function coverage metadata
This is a series of refactorings to the code that prepares and embeds per-function coverage metadata records (“covfun records”) in the `__llvm_covfun` linker section of the final binary. The `llvm-cov` tool reads this metadata from the binary when preparing a coverage report.
Beyond general cleanup, a big motivation behind these changes is to pave the way for re-landing an updated version of #133418.
---
There should be no change in compiler output, as demonstrated by the absence of (meaningful) changes to coverage tests.
The first patch is just moving code around, so I suggest looking at the other patches to see the actual changes.
---
try-job: x86_64-gnu
try-job: x86_64-msvc
try-job: aarch64-apple
A previous commit added a search for certain types of "shadowing"
situation where one method (in an outer smart pointer type, typically)
might hide or shadow the method in the pointee.
Performance investigation showed that the naïve approach is too slow -
this commit speeds it up, while being functionally the same.
This still does not actually cause the deshadowing check to emit any
errors; that comes in a subsequent commit which is where all the tests
live.
This is the first part of a series of commits which impact the
"deshadowing detection" in the arbitrary self types v2 RFC.
This commit should not have any functional changes, but may impact
performance. Subsequent commits add back the performance, and add error
checking to this new code such that it has a functional effect.
Rust prioritizes method candidates in this order:
1. By value;
2. By reference;
3. By mutable reference;
4. By const ptr.
5. By reborrowed pin.
Previously, if a suitable candidate was found in one of these earlier
categories, Rust wouldn't even move onto probing the other categories.
As part of the arbitrary self types work, we're going to need to change
that - even if we choose a method from one of the earlier categories, we
will sometimes need to probe later categories to search for methods that
we may be shadowing.
This commit adds those extra searches for shadowing, but it does not yet
produce an error when such shadowing problems are found. That will come
in a subsequent commit, by filling out the 'check_for_shadowing'
method.
This commit contains a naive approach to detecting these shadowing
problems, which shows what we've functionally looking to do. However,
it's too slow. The performance of this approach was explored in this
PR:
https://github.com/rust-lang/rust/pull/127812#issuecomment-2236911900
Subsequent commits will improve the speed of the search.
This commit makes no (intentional) functional change.
Previously, the picking process maintained two lists of extra
information useful for diagnostics:
* any unstable candidates which might have been picked
* any unsatisfied predicates
Previously, these were dealt with quite differently - the former list
was passed around as a function parameter; the latter lived in a RefCell
in the ProbeCtxt.
With this change we increase consistency by keeping them together in a
new PickDiagHints structure, passed as a parameter, with no need for
interior mutability.
The lifecycle of each of these lists remains fairly complex, so it's
explained with new comments in pick_core.
A further cleanup here would be to package the widely-used tuple
(ty::Predicate<'tcx>,
Option<ty::Predicate<'tcx>>,
Option<ObligationCause<'tcx>>)
into a named struct for UnsatisfiedPredicate. This seems worth doing but
it turns out that this tuple is used in dozens of places, so if we're
going to do this we should do it as a separate PR to avoid constant
rebase trouble.
In this new version of Arbitrary Self Types, we no longer use the Deref trait
exclusively when working out which self types are valid. Instead, we follow a
chain of Receiver traits. This enables methods to be called on smart pointer
types which fundamentally cannot support Deref (for instance because they are
wrappers for pointers that don't follow Rust's aliasing rules).
This includes:
* Changes to tests appropriately
* New tests for:
* The basics of the feature
* Ensuring lifetime elision works properly
* Generic Receivers
* A copy of the method subst test enhanced with Receiver
This is really the heart of the 'arbitrary self types v2' feature, and
is the most critical commit in the current PR.
Subsequent commits are focused on:
* Detecting "shadowing" problems, where a smart pointer type can hide
methods in the pointee.
* Diagnostics and cleanup.
Naming: in this commit, the "Autoderef" type is modified so that it no
longer solely focuses on the "Deref" trait, but can now consider the
"Receiver" trait instead. Should it be renamed, to something like
"TraitFollower"? This was considered, but rejected, because
* even in the Receiver case, it still considers built-in derefs
* the name Autoderef is short and snappy.
LoongArch psABI[^1] specifies that LSX vector types are passed via general-purpose
registers, while LASX vector types are passed indirectly through the stack.
This patch addresses the following warnings:
```
warning: this function call uses a SIMD vector type that is not currently supported with the chosen ABI
--> .../library/core/src/../../stdarch/crates/core_arch/src/loongarch64/lsx/generated.rs:3695:5
|
3695 | __lsx_vreplgr2vr_b(a)
| ^^^^^^^^^^^^^^^^^^^^^ function called here
|
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #116558 <https://github.com/rust-lang/rust/issues/116558>
= note: `#[warn(abi_unsupported_vector_types)]` on by default
```
[^1]: https://github.com/loongson/la-abi-specs/blob/release/lapcs.adoc
Rename `projection_def_id` to `item_def_id`
Renames `projection_def_id` to `item_def_id`, since `item_def_id` is what we call the analogous method for ~~`AliasTerm`/`AliasTy`~~ `PolyExistentialProjection`. I keep forgetting that this one is not called `item_def_id`.
Rudimentary heuristic to insert parentheses when needed for RPIT overcaptures lint
We don't have basically any preexisting machinery to detect when parentheses are needed for *types*. AFAICT, all of the diagnostics we have for opaques just... fail when they suggest `+ 'a` when that's ambiguous.
Fixes#132853
[AIX] keep profile-rt symbol alive
Clang passes `-u __llvm_profile_runtime` on AIX. https://reviews.llvm.org/D136192
We want to preserve the symbol in the case there are no instrumented object files.
Validate self in host predicates correctly
`assert_only_contains_predicates_from` was added to make sure that we are computing predicates for the correct self type for a given `PredicateFilter`. That was not implemented correctly for `PredicateFilter::SelfOnly` when there are const predicates.
Fixes#133526
