Privacy: move macros handling to early stage
The patch moves effective visibility computation for macros from `rustc_privacy` to `rustc_resolve`. It will enable this optimization: https://github.com/rust-lang/rust/pull/156228.
However, I found some problems with macro handling while I was doing this. The current implementation was written ~6 years ago and checks the reachability of a definition from a macro by nominal visibility. In general this is incorrect.
For example, in the current implementation modules are not traversed if their nominal visibility is less then the nominal visibility of a module defining macro: https://github.com/rust-lang/rust/blob/29b7590130c83542a095cdf1323ed0f78eec2bb8/compiler/rustc_privacy/src/lib.rs#L618-L626
As a result, in order to compile code like `tests/ui/definition-reachable/auxiliary/field-method-macro.rs`. we have to additionally traverse types of adt fields: https://github.com/rust-lang/rust/blob/29b7590130c83542a095cdf1323ed0f78eec2bb8/compiler/rustc_privacy/src/lib.rs#L628-L638
This is a hack and the proper solution would be to check definitions with `EffectiveVisibilities::is_reachable`. I haven’t done this yet, as it would start to trigger many lints as more items become reachable. I think it’s better to leave the change to another commit.
r? @petrochenkov
Do not index past end of buffer when checking heuristic in error index syntax highlighter
When checking whether the current token is a function indentifier by inspecting the syntax, do not attempt to access past the end of the code buffer.
Fixrust-lang/rust#156326.
Split the node_id_to_def_id table into a per-owner table
*[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/138995)*
My goal is to split all the resolver tables that get passed to act lowering into per-owner tables, so that all information that ast lowering needs from the resolver is separated by owners. This should allow us to fully split ast lowering to have one query invocation per owner that steal the individual resolver results for each owner.
part of https://github.com/rust-lang/rust-project-goals/issues/620
Fix unused assignments in diverging branches
Fixesrust-lang/rust#156416
Add `location` and use `is_predecessor_of` to check in the control flow graph.
r? @ghost
I'd like to see whether there is performence regression.
Add Swift function call ABI
Adds an unstable `extern "Swift"` ABI behind the `abi_swift` feature gate, mapping to LLVM's `swiftcc` calling convention. This is only allowed (a) for `is_darwin_like` targets, since the [ABI is only stable for those platforms](https://www.swift.org/blog/abi-stability-and-more/) and (b) with the LLVM backend, since the other backends don't support it.
Current approaches to interoperability with Swift lower to Objective-C (or require a Swift stub exposing a C ABI), but that is an optional mapping on the Swift side that some newer Apple frameworks omit. It would be great to be able to more directly/natively be able to call into Swift code directly via its stable API (on Apple platforms at least).
Reimplements rust-lang/rust#64582 on top of current main. The main objection to the previous PR seemed to be that it needed an RFC, but there was pushback (which seems sensible to me) that an RFC could be deferred until stabilization.
I think this needs a tracking issue? Would be happy to write one up if/when there is a consensus that this will be merged.
It's currrently `(Option<(Level, Option<LintExpectationId>)>,
LintLevelSource)`. But when the first element of the pair is `None` the
second element is always `LintLevelSource::Default`. So this commit
moves the `LintLevelSource` within the `Option`, which simplifies
things a bit.
It currently returns a triple: `(Level, Option<LintExpectationId>,
LintLevelSource)`. That's structurally identical to `LevelAndSource`, so
this commit changes it accordingly.
`reveal_actual_level` has two call sites, which look like this:
```
let (level, mut src) = self.raw_lint_id_level(lint, idx, aux);
let (level, lint_id) = reveal_actual_level(level, &mut src, sess, lint, |id| {
self.raw_lint_id_level(id, idx, aux)
});
```
and:
```
let (level, mut src) = self.probe_for_lint_level(tcx, lint, cur);
let (level, lint_id) = reveal_actual_level(level, &mut src, tcx.sess, lint, |lint| {
self.probe_for_lint_level(tcx, lint, cur)
});
```
They both have the same pattern: there's a prior call expression that is then
repeated within a closure passed to `reveal_actual_level`.
This commit moves that prior call inside `reveal_actual_level`, making things
simpler.
Remove the dummy `PreCodegen` mir-opt pass, and use `runtime-optimized` instead
- Alternative to https://github.com/rust-lang/rust/pull/156358.
The `PreCodegen` pass doesn't do anything on its own; it was only serving as a marker to allow `-Zdump-mir` and mir-opt tests to easily dump the final MIR just before codegen.
However, https://github.com/rust-lang/rust/pull/156358#issuecomment-4422445297 pointed out that the `runtime-optimized` phase transition should dump the same MIR, so there shouldn't be any need for a separate *PreCodegen* pass.
---
r? oli-obk (or compiler)
Add support for Zprint-codegen-stats-json
Add a flag `-Zprint-codegen-stats-json=<file>` to collect and write LLVM statistics in JSON format. It makes use of the function `llvm::PrintStatisticsJSON` in LLVM.
The flag currently only obtains LLVM statistics for now, but could be used to collect more front-end statistics in the future.
This function doesn't have an obvious home, but there's little reason for it to
be in mir-transform, and having it in `rustc_driver_impl::pretty` at least puts
it near other callers of `write_mir_pretty`.
Unnormalized migration: assert_fully_normalized, struct_tail, and `field.ty`
tracking issue: https://github.com/rust-lang/rust/issues/155345 (first checkbox, and partial second checkbox, of that issue)
I'm going a bit slower than expected (less free time than I'd hope, lots of GCA work that I'm doing instead), and figured I'd just submit what I have now rather than building up a big batch of changes. Slow and steady!
r? @lcnr
Adds an unstable `extern "Swift"` ABI behind the `abi_swift` feature
gate, mapping to LLVM's `swiftcc` calling convention. Cranelift and
GCC backends fall back to the platform default since they have no
equivalent.
enable more f16/f128 tests in Miri
See the individual commit messages for details.
The last commit is a drive-by comment fix that was not worth its own PR.
r? @tgross35
-Zassumptions-on-binders
r? lcnr
cc https://rust-lang.github.io/rust-project-goals/2026/assumptions_on_binders.html I would cc a tracking issue but the project goals haven't been finalized yet ^^'
Implements `-Zassumptions-on-binders`. This has a few main components:
1. We introduce a new form of region constraints for use by the trait solver which supports ORs
2. When entering binders universally inside of the trait solver we walk the bound thing and compute a list of region assumptions. We then track in the `InferCtxt` all the region outlives and type outlives mentioning a placeholder from the binder for use when handling constraints involving placeholders
3. Ideally when exiting a binder, but currently actually when computing a response inside the solver, we look through all of region constraints involving placeholders and eagerly handle these region constraints instead of returning them to the caller
This is very much a first-draft impl (though it is vaguely functional), there's a lot we need to change going forwards:
- We should really be using this new form of region constraint everywhere/more generally we shouldnt have two kinds of region constraints
- We shouldn't be computing implied bounds when entering binders, instead they should be explicit everywhere and actually checked when instantiating binders. As-is `-Zassumptions-on-binders` probably widens existing soundness holes around implied bounds due to having significantly more implied bounds
- We should be eagerly handling placeholders *everywhere* not just inside of the trait solver. Right now there will still be missing assumptions for placeholders when we do higher ranked type relations during type checking outside of the trait solver.
- I'm not normalizing our assumptions or our constraints and we should be doing both ✨
- Handling of alias outlives' involving placeholders is incomplete in a number of ways
- We should handle placeholders when leaving binders not when computing responses IMO
- Actually support OR region constraints in borrow checking and region checking ✨ right now all our OR constraints are converted into normal ANDed region constraints in root contexts.
- Right now diagnostics just point to the whole item which the unsatisfied constraints came from. this is suboptimal! fix this!
- Move universe information into InferCtxtInner so it can be rolled back by probes
- we should make some kind of test suite helper so we can directly write universal/existential quantifiers and assumptions rather than having to go through rust syntax :')
How do we actually eagerly handle constraints?
The general idea is that we have some function (`eagerly_handle_placeholders_in_universe`) which takes:
- A set of region constraints
- The universe which we want to eagerly handle constraints in
- A set of outlives assumptions associated with that universe/binder
This function will rewrite all of the region constraints which involve placeholders from the passed in universe to be in terms of variables from smaller universes (or drop the constraints if we know them to be satisfied). For example:
```rust
for<'a> where('a: 'b) {
prove ('a: 'c)
}
```
when exiting `for<'a>` we want to handle the `'!a: 'c` constraint *somehow* and we can do that by requiring that *any* of the lifetimes which `'!a` outlives, themselves outlive `'c`. In this case we can require `Or('b: 'c)` and instead of `'!a: 'c` which gives us a constraint that makes sense after exiting the forall.
some more examples:
```rust
for<'a> where('a: 'b, 'a: 'c) {
prove('a: 'd)
}
// rewritten to Or('b: 'd, 'c: 'd)
for<'a> where('b: 'a) {
prove(T: 'a)
}
// rewritten to Or(T: 'b)
```
The tricky thing here is that we want/need to avoid the trait solver knowing about *all* type outlives/region outlives assumptions. So this algorithm is implemented with only knowing about the assumptions coming from the binder that is being exited.
We want to avoid passing all outlives assumptions through the trait solver for two main reasons. The first is just perf, augmenting the `ParamEnv` with significant amounts of outlives assumptions could easily mess up caching.
The second is that it's Not Possible™️ to implement. Type checking requires trait solving inside of a closure which still has an uninferred signature, this means that there are some set of implied bounds that we just don't know about yet because we only know some inference variable is well formed and nothing else.
---
Long term we should be able to wholly rip out placeholder handling from borrow checking and we won't ever encounter placeholders outside of the binders they were produced from.
Refactor `CheckAttrVisitor` so rustfmt can format it.
I don’t have any need for this myself, but [I heard it was annoying people](https://rust-lang.zulipchat.com/#narrow/channel/147480-t-compiler.2Fdiagnostics/topic/.60.23.5Bdiagnostic.3A.3Aon_unimplemented.5D.60.20on.20trait.20methods.3F/near/594113991) and I like fixing formatting and structure problems.
The key change is that the do-nothing cases are now individual match arms instead of an enormous or-pattern. In order to achieve this cleanly, I moved the code handling `Attribute::Parsed` into a separate function matching `AttributeKind`s rather than `Attribute`s.
This also fixes `RustcAllowIncoherentImpl` being non-alphabetical because it was spelled without a leading “|” (though that by itself could be achieved by adding the optional leading “|”).
LLVM 23: Specify `returnaddress` intrinsic return type
https://github.com/llvm/llvm-project/pull/188464 made the return type of the intrinsic generic to support different pointer address spaces.
@rustbot label llvm-main
Have arrays' `drop_glue` just unsize and call the slice version
It's silly to emit two loops (because of the drop ladder -- just one in panic=abort) for every array length that's dropped when we can just polymorphize to the slice version.
Built atop rust-lang/rust#154327 to avoid conflicts later, so draft for now.
r? @WaffleLapkin
Simplify `intrinsic::raw_eq` in MIR when possible
After https://github.com/rust-lang/rust/pull/150945 things can inline enough to have this end up specific enough that we can remove it, for example changing `raw_eq::<[u8; 4]>(a, b)` → `Transmute(a) == Transmute(b)`.
The LLVM backend can also do this (and in more cases too) but we might as well do it in MIR instead when we can so it applies to all backends and other MIR optimizations can apply afterwards.
Jonathan Brouwer