| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Canonicalize input ty/ct infer/placeholder in the root universe
We shouldn't care what universe the inputs are, since we only ever do the leak check on the universes instantiated after entering the canonical binder.
|
|
|
|
|
|
|
|
Rollup of 11 pull requests
Successful merges:
- rust-lang/rust#142440 (`tests/ui`: A New Order [14/N])
- rust-lang/rust#143040 (Add `const Rem`)
- rust-lang/rust#143086 (Update poison.rs to fix the typo (sys->sync))
- rust-lang/rust#143202 (`tests/ui`: A New Order [18/N])
- rust-lang/rust#143296 (`tests/ui`: A New Order [21/N])
- rust-lang/rust#143297 (`tests/ui`: A New Order [22/N])
- rust-lang/rust#143299 (`tests/ui`: A New Order [24/N])
- rust-lang/rust#143300 (`tests/ui`: A New Order [25/N])
- rust-lang/rust#143397 (test passing a `VaList` from rust to C)
- rust-lang/rust#143410 (Block SIMD in transmute_immediate; delete `OperandValueKind`)
- rust-lang/rust#143452 (Fix CLI completion check in `tidy`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Remove `Symbol` from `Named` variant of `BoundRegionKind`/`LateParamRegionKind`
The `Symbol` is redundant, since we already store a `DefId` in the region variant. Instead, load the name via `item_name` when needed (which is almost always on the diagnostic path).
This introduces a `BoundRegionKind::NamedAnon` which is used for giving anonymous bound regions names, but which should only be used during pretty printing and error reporting.
|
|
r=RalfJung,workingjubilee
Block SIMD in transmute_immediate; delete `OperandValueKind`
Vectors have been causing me problems for years in this code, for example https://github.com/rust-lang/rust/pull/110021#discussion_r1160975086 and https://github.com/rust-lang/rust/pull/143194
See conversation in <https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Is.20transmuting.20a.20.60T.60.20to.20.60Tx1.60.20.28one-element.20SIMD.20vector.29.20UB.3F/near/526262799>.
By blocking SIMD in `transmute_immediate` it can be simplified to just take the `Scalar`s involved -- the backend types can be gotten from those `Scalar`s, rather than needing to be passed. And there's an assert added to ICE it if it does get hit.
Accordingly, this changes `rvalue_creates_operand` to not send SIMD transmutes through the operand path, but to always go through memory instead, like they did back before rust-lang/rust#108442.
And thanks to those changes, I could also remove the `OperandValueKind` type that I added back then which `@RalfJung` rightly considers pretty sketchy.
cc `@folkertdev` `@workingjubilee` from the zulip conversation too
|
|
Allow `enum` and `union` literals to also create SSA values
Today, `Some(x)` always goes through an `alloca`, even in trivial cases where the niching means the constructor doesn't even change the value.
For example, <https://rust.godbolt.org/z/6KG6PqoYz>
```rust
pub fn demo(r: &i32) -> Option<&i32> {
Some(r)
}
```
currently emits the IR
```llvm
define align 4 ptr `@demo(ptr` align 4 %r) unnamed_addr {
start:
%_0 = alloca [8 x i8], align 8
store ptr %r, ptr %_0, align 8
%0 = load ptr, ptr %_0, align 8
ret ptr %0
}
```
but with this PR it becomes just
```llvm
define align 4 ptr `@demo(ptr` align 4 %r) unnamed_addr {
start:
ret ptr %r
}
```
(Of course the optimizer can clean that up, but it'd be nice if it didn't have to -- especially in debug where it doesn't run. This is like rust-lang/rust#123886, but that only handled non-simd `struct`s -- this PR generalizes it to all non-simd ADTs.)
Doing this means handing variants other than `FIRST_VARIANT`, handling the active field for unions, refactoring the discriminant code so the Place and Operand parts can share the calculation, etc.
Other PRs that led up to this one:
- https://github.com/rust-lang/rust/pull/142005
- https://github.com/rust-lang/rust/pull/142103
- https://github.com/rust-lang/rust/pull/142324
- https://github.com/rust-lang/rust/pull/142383
---
try-job: aarch64-gnu
|
|
remove special-casing of boxes from match exhaustiveness/usefulness analysis
As a first step in replacing `box_patterns` with `deref_patterns`, this treats box patterns as deref patterns in the THIR and exhaustiveness analysis. This allows a bunch of special-casing to be removed. The emitted MIR is unchanged.
Incidentally, this fixes a bug caused by box patterns being treated like structs rather than pointers, where enabling `exhaustive_patterns` (rust-lang/rust#51085) could give rise to spurious `unreachable_patterns` lints on arms required for exhaustiveness. Following the lint's advice to remove the match arm would result in an error. I'm not sure what the current state of `exhaustive_patterns` is with regard to reference/box opsem, or whether there's any intention to have `unreachable_patterns` be more granular than the whole arm, but regardless this should hopefully make them easier to handle consistently.
Tracking issue for deref patterns: rust-lang/rust#87121
r? `@Nadrieril`
|
|
mbe: Gracefully handle macro rules that end after `=>`
Add a test for various cases of invalid macro definitions.
Closes: https://github.com/rust-lang/rust/issues/143351
|
|
Remove some unnecessary `unsafe` in VecCache
I'm pretty sure, but until perf confirms,
r? ghost
|
|
Remove names_imported_by_glob_use query.
Based on https://github.com/rust-lang/rust/pull/143247
r? ``@ghost`` for perf
|
|
Port `#[non_exhaustive]` to the new attribute parsing infrastructure
Ports `non_exhaustive` to the new attribute parsing infrastructure for https://github.com/rust-lang/rust/issues/131229#issuecomment-2971353197
r? ``@jdonszelmann``
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Make metadata a workproduct and reuse it
This PR aims to skip the generation of metadata by reusing the infrastructure that already exists for compiled codegen-units, namely "workproducts".
This can yield substantial gains (~10%) when we can demonstrate that metadata does not change between an incremental session and the next. This is the case if the crate is unchanged, or if all the changes are in upstream crates and have no effect on it. This latter case is most interesting, as it arises regularly for users with several crates in their workspace.
TODO:
- [x] Materialize the fact that metadata encoding relies on the relative order of definitions;
- [x] Refactor the handling of doc links.
|
|
|
|
bump termize dep
Bumps termize to drop one more winapi dep. Only change is really moving from winapi: https://github.com/JohnTitor/termize/releases/tag/v0.2.0
Clippy depends on termize 0.1.1, https://github.com/rust-lang/rust-clippy/pull/15207
|
|
Port `#[rustc_pass_by_value]` to the new attribute system
Part of rust-lang/rust#131229
r? `@oli-obk`
|
|
Make __rust_alloc_error_handler_should_panic a function
Fixes rust-lang/rust#143253
`__rust_alloc_error_handler_should_panic` is a static but was being exported as a function.
For most targets this doesn't matter, but Arm64EC Windows uses different decorations for exported variables vs functions, hence it fails to link when `-Z oom=abort` is enabled.
We've had issues in the past with statics like this (see rust-lang/rust#141061) but the tldr; is that Arm64EC needs symbols correctly exported as either a function or data, and data MUST and MUST ONLY be marked `dllimport` when the symbol is being imported from another binary, which is non-trivial to calculate for these compiler-generated statics.
So, instead, the easiest thing to do is to make `__rust_alloc_error_handler_should_panic` a function instead.
Since `__rust_alloc_error_handler_should_panic` isn't involved in any linking shenanigans, I've marked it as `AlwaysInline` with the hopes that the various backends will see that it is just returning a constant and perform the same optimizations as the previous implementation.
r? `@bjorn3`
|
|
Remove `PointerLike` trait
r? oli-obk
|
|
Make -Ztrack-diagnostics emit like a note
[#t-compiler/diagnostics > Rendering -Ztrack-diagnostics like a note](https://rust-lang.zulipchat.com/#narrow/channel/147480-t-compiler.2Fdiagnostics/topic/Rendering.20-Ztrack-diagnostics.20like.20a.20note/with/526608647)
As discussed on the Zulip thread above, I want to make `-Ztrack-diagnostics` emit like a `note`. This is because I find its current output jarring, and the fact that it gets rendered completely left-aligned, [even in the middle of a snippet](https://github.com/rust-lang/rust/blob/86e05cd300fac9e83e812c4d46582b48db780d8f/tests/ui/track-diagnostics/track6.stderr), seems like something that should be changed. Turning it into a `note` seems like the best choice, as it would align it with the rest of the output, and `note` is already used for somewhat similar things, like seeing why a lint was fired.
---
Note: turning `-Ztrack-diagnostics` into a `note` will also make `annotate-snippets` API a bit cleaner
|
|
Refactor StableMIR
This PR refactors stable-mir according to the guidance in [this doc](https://hackmd.io/jBRkZLqAQL2EVgwIIeNMHg). It reverses the dependency between `rustc_smir` and `stable_mir`, making `rustc_smir` completely agnostic of `stable_mir`.
Under the new architecture, the `rustc_smir` crate would retain direct access to rustc queries, while `stable_mir` should proxy all such requests through `rustc_smir` instead of accessing rustc's internals directly. `stable_mir` would only be responsible for the conversion between internal and stable constructs.
This PR mainly introduces these changes:
- **Bridge / Tables<'tcx, B: Bridge>**
```rust
/// A trait defining types that are used to emulate StableMIR components, which is really
/// useful when programming in stable_mir-agnostic settings.
pub trait Bridge {
type DefId: Copy + Debug + PartialEq + IndexedVal;
type AllocId: Copy + Debug + PartialEq + IndexedVal;
type Span: Copy + Debug + PartialEq + IndexedVal;
type Ty: Copy + Debug + PartialEq + IndexedVal;
type InstanceDef: Copy + Debug + PartialEq + IndexedVal;
type TyConstId: Copy + Debug + PartialEq + IndexedVal;
type MirConstId: Copy + Debug + PartialEq + IndexedVal;
type Layout: Copy + Debug + PartialEq + IndexedVal;
type Error: SmirError;
}
pub struct Tables<'tcx, B: Bridge> {
tcx: TyCtxt<'tcx>,
pub(crate) def_ids: IndexMap<DefId, B::DefId>,
pub(crate) alloc_ids: IndexMap<AllocId, B::AllocId>,
pub(crate) spans: IndexMap<rustc_span::Span, B::Span>,
pub(crate) types: IndexMap<Ty<'tcx>, B::Ty>,
pub(crate) instances: IndexMap<ty::Instance<'tcx>, B::InstanceDef>,
pub(crate) ty_consts: IndexMap<ty::Const<'tcx>, B::TyConstId>,
pub(crate) mir_consts: IndexMap<mir::Const<'tcx>, B::MirConstId>,
pub(crate) layouts: IndexMap<rustc_abi::Layout<'tcx>, B::Layout>,
}
```
Since `rustc_smir` needs these stable types somewhere, using associated types is a good approach.
- **SmirContainer / SmirInterface**
```rust
/// A container which is used for TLS.
pub struct SmirContainer<'tcx, B: Bridge> {
pub tables: RefCell<Tables<'tcx, B>>,
pub cx: RefCell<SmirCtxt<'tcx, B>>,
}
impl<'tcx> SmirInterface for SmirContainer<'tcx, BridgeTys> {
// ...
}
/// Provides direct access to rustc's internal queries.
///
/// The [`crate::stable_mir::compiler_interface::SmirInterface`] must go through
/// this context to obtain rustc-level information.
pub struct SmirCtxt<'tcx, B: Bridge> {
tcx: TyCtxt<'tcx>,
_marker: PhantomData<B>,
}
```
This PR moves `Tables` from `SmirCtxt` to a new `SmirContainer` struct, since mutable borrows of `tables` should only be managed by `SmirInterface`. This change prevents `SmirCtxt` from holding separate borrows and requires passing `tables` explicitly when needed:
```rust
impl<'tcx, B: Bridge> SmirCtxt<'tcx, B> {
// ...
/// Get the body of an Instance which is already monomorphized.
pub fn instance_body(
&self,
instance: ty::Instance<'tcx>,
tables: &mut Tables<'tcx, B>,
) -> Option<Body<'tcx>> {
tables
.instance_has_body(instance)
.then(|| BodyBuilder::new(self.tcx, instance).build(tables))
}
// ...
}
```
This PR introduces `SmirContainer` as a separate struct rather than bundling it into a `SmirInterface` struct. This separation makes the architecture more modular and easier to reason about.
- **context/traits.rs**
We use this file to define traits that are used for encapsulating the associated functions in the rustc's internals. This is much easier to use and maintain than directly cramming everything into `SmirCtxt`. Here is a real-world use case:
```rust
impl RustcInternal for ExistentialTraitRef {
type T<'tcx> = rustc_ty::ExistentialTraitRef<'tcx>;
fn internal<'tcx>(
&self,
tables: &mut Tables<'_, BridgeTys>,
cx: &SmirCtxt<'tcx, BridgeTys>,
) -> Self::T<'tcx> {
use rustc_smir::context::SmirExistentialTraitRef;
cx.new_from_args(self.def_id.0.internal(tables, cx), self.generic_args.internal(tables, cx))
}
}
```
- **Separation of `rustc_smir::alloc`**
The previous `rustc_smir::alloc` had many direct calls to rustc queries. This PR splits it into two parts: `rustc_smir::alloc` and `stable_mir::alloc`. Following the same pattern as `SmirCtxt` and `SmirInterface`, the `rustc_smir::alloc` handles all direct interactions with rustc queries and performs the actual memory allocations, while the `stable_mir::alloc` is responsible for constructing stable components.
- **Removal of `convert/error.rs`**
We use `SmirError::from_internal` instead, since implementing `Stable` for these internal errors would be redundant—`tables` is not actually used. If we later need to add something like `LayoutError` to `stable_mir`, we could implement it as follows:
```rust
impl SmirError for stable_mir::LayoutError {
fn from_internal<T: Debug>(err: T) -> Self {
// ...
}
}
```
**Unresolved questions:**
- There are still a few direct calls to rustc's internals scattered across `impl Stable`s, but most of them appear to be relatively stable, e.g., `mir::interpret::ConstAllocation::inner(self)` and `mir::syntax::SwitchTargets::otherwise(self)`.
r? `@celinval`
|
|
|
|
|
|
|
|
|
|
|
|
Avoid depending on forever-red DepNode when encoding metadata.
Split from https://github.com/rust-lang/rust/pull/114669 for perf
r? `@petrochenkov`
|
|
|
|
This removes special-casing of boxes from `rustc_pattern_analysis`, as a
first step in replacing `box_patterns` with `deref_patterns`.
Incidentally, it fixes a bug caused by box patterns being represented as
structs rather than pointers, where `exhaustive_patterns` could generate
spurious `unreachable_patterns` lints on arms required for
exhaustiveness; following the lint's advice would result in an error.
|
|
r=jdonszelmann,oli-obk
Port `#[no_implicit_prelude]` to the new attribute parsing infrastructure
Ports no_implicit_prelude to the new attribute parsing infrastructure for https://github.com/rust-lang/rust/issues/131229#issuecomment-2971353197
r? `@oli-obk`
cc `@jdonszelmann`
|
|
|
|
See conversation in <https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Is.20transmuting.20a.20.60T.60.20to.20.60Tx1.60.20.28one-element.20SIMD.20vector.29.20UB.3F/near/526262799>.
|
|
Add a test for various cases of invalid macro definitions.
Closes: https://github.com/rust-lang/rust/issues/143351
|
|
Always use the pure Rust fallback instead of `llvm.{maximum,minimum}`
While https://github.com/llvm/llvm-project/pull/142170 was merged, it was reverted and next attempt (https://github.com/llvm/llvm-project/pull/140193) at fixing the LLVM implementation seems to have stall, so let's reverted back to pure Rust with the LLVM codegen.
cc [#t-compiler/llvm > `llvm.minimum`/`llvm.maximum` issues @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/187780-t-compiler.2Fllvm/topic/.60llvm.2Eminimum.60.2F.60llvm.2Emaximum.60.20issues/near/527044712)
Fixes https://github.com/rust-lang/rust/issues/141087
r? `@tgross35`
|
|
r=compiler-errors
compiler: Document and reduce `fn provide`s in hir crates
I found it hard to follow all these tiny micro-indirections. Much like you shouldn't pass around `&u32` if you can help it, you probably shouldn't use an indirection if the indirection overhead itself is literally bigger than the amount of data you are organizing. Generally a new `fn provide` amounts to around 3 LOC:
- the signature with opening brace
- the `rustc_middle::query::Providers` import
- an end brace
I am not even counting the cost in time and thought to go find the other `provide`, read it, understand, "Ah, yes, these functions", and then go to those. Thus I say we should collapse indirections of `provide` for modules that only export 1~2 queries. For higher-count indirections, I left them as-is, as I don't understand the crate well enough to judge their worth.
Then I dropped a pointer to the actual module of interest for all these instances of the same function. I think documenting them is important because the comment that it relates to the query system makes it obvious that they have **nothing** to do with the rest of the module's logic and I can carry on ignoring them. Actively doing so is another cognitive cost, but much more minimal.
There is also a small correctness issue in that all of these functions are technically mutating state. It's not a huge deal, but it's still easier to check all these mutations do not overlap if we have less instances of `fn provide` to check.
|
|
Replace kw_span by full span for generic const parameters.
Small simplification extracted from https://github.com/rust-lang/rust/pull/127241
|
|
Fast path nitpicks
Miscellaneous commits that I didn't really want to fold into anything else.
Fixes one theoretical bug with the fast path not considering polarity for `T: !Sized` bounds.
|
|
|
|
`coroutine_discr_for_variant()`
|
|
|
|
`explicit_predicates_of()`
|
|
We want to keep StableMIR definitions and logic separate from any sort of conversion and usage of internal rustc code. So we bundle all unstable items that have no stability guarantees into `stable_mir::unstable`.
|
|
add a new trait `InternalCx`, which defines the methods that are fine to call from `RustcInternal`. `RustcInternal::internal()` then takes a `impl InternalCx<'tcx>` instead of `TyCtxt<'tcx>`.
make `tcx` in `SmirCtxt` public, since we need to pass it to `RustcInternal::internal()` in `SmirInterface`.
|
