compiletest: Rename `//@ ignore-pass` to `//@ no-pass-override`
By convention, compiletest directives starting with `ignore-*` normally cause the test itself to be skipped under certain conditions.
The `//@ ignore-pass` directive was the only exception to that convention. The new name should hopefully do a better job of communicating its effect, which is to cause the `--pass` flag to not override the test's `build-pass` or `run-pass` directive.
The `//@ no-pass-override` directive is mainly useful for tests that expect warnings produced during codegen.
---
r? jieyouxu
compiletest: Enforce that directives are consistently used with or without a colon
With the notable exception of `//@ pp-exact`, all directives expect to either always be used *with* a colon, or always be used *without* a colon. For example:
- `//@ uses-colon: value`
- `//@ no-colon` or `//@ no-colon (remark)`
Currently we just silently discard directives that use the wrong syntax, which is not great.
This PR therefore makes `parse_name_directive` and `parse_name_value_directive` panic if the wrong syntax is encountered.
The parser for `pp-exact` has been adjusted to check for the colon before deciding which parse method to call.
r? jieyouxu
test: suppress deprecation warning
The newer mac os ld linker emits a deprecation warning:
```
warning: linker stderr: ld: -ld_classic is deprecated and will be removed in a future release
|
= note: `#[warn(linker_messages)]` on by default
```
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.
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.
By convention, compiletest directives starting with `ignore-*` normally cause
the test itself to be skipped under certain conditions.
The `//@ ignore-pass` directive was the only exception to that convention. The
new name should hopefully do a better job of communicating its effect, which is
to cause the `--pass` flag to not override the test's `build-pass` or
`run-pass` directive.
The `//@ no-pass-override` directive is mainly useful for tests that expect
warnings produced during codegen.
The compiletest `--pass` flag only affects tests with a `*-pass` directive,
i.e. `check-pass`, `build-pass`, or `run-pass`.
It has no effect in `*-fail` tests, or in auxiliary crates.
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.
-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.
Add `Drop::pin_drop` for pinned drops
This PR is part of the `pin_ergonomics` experiment (the tracking issue is rust-lang/rust#130494). It allows implementing `Drop` with a pinned `self` receiver, which is required for safe pin-projection.
Implementations:
- [x] At least and at most one of `drop` and `pin_drop` should be implemented.
- [x] No direct call of `drop` or `pin_drop`. They should only be called by the drop glue.
- [x] `pin_drop` must and must only be used with types that support pin-projection (i.e. types with `#[pin_v2]`).
- [ ] Allows writing `fn drop(&pin mut self)` and desugars to `fn pin_drop(&pin mut self)`. (Will be in the next PRs)
error on empty `export_name`
fixes https://github.com/rust-lang/rust/issues/155495
Using an empty string as the name makes LLVM make up a name. However this name can be inconsistent between compilation units, which is UB and can cause linking errors, and some parts of LLVM just crash on the empty name (see the linked issue).
As far as we know there is only one valid pattern that could use this, a `#[used]` static that is not referenced by the program at all. That is not UB, but the `export_name` is not required for that to work, just normal rust name mangling would do fine.
Technically this is a breaking change, but it seems unlikely that this actually breaks code in the wild that wasn't already broken. I'll leave it up to T-lang to determine what is required here (crater run, FCW, ...), but my gut feeling is that we could just merge this and nobody would notice.
Consider `Result<T, Uninhabited>` and `ControlFlow<Uninhabited, T>` to be equivalent to `T` for must use lint
This is an extension to rust-lang/rust#147382.
With this PR `Result<T, Uninhabited>` and `ControlFlow<Uninhabited, T>` considered as must use iif `T` must be used.
For such cases the lint will mention that `T` is wrapped in a `Result`/`ControlFlow` with an uninhabited error/break.
The reasoning here is that `Result<T, Uninhabited>` is equivalent to `T` in which values can be represented and thus the must-used-ness should also be equivalent.
Fixes https://github.com/rust-lang/rust/issues/65861
fix: Guard SizeSkeleton::compute against stack overflow
Fixesrust-lang/rust#156137
Fix: extract the recursion into a private `compute_inner` that carries a depth counter. When depth exceeds the crate's recursion limit, return `LayoutError::Unknown` and let the existing transmute size-check produce a normal error instead of crashing.
A regression test is included in `tests/ui/transmute/`.
Avoid invalid spans in dotdotdot rest pattern suggestions
Fixesrust-lang/rust#156316
The parser recovers Unicode confusables such as `···` as `...`, while keeping the original source span over the multibyte characters.
`recover_dotdotdot_rest_pat` built its suggestion by subtracting `BytePos(1)` from the end of that recovered token span. For multibyte characters, that can create a span boundary inside a UTF-8, causing diagnostic emission to ICE.
This changes the suggestion to replace the whole recovered token span with `..` instead of slicing off one byte.
fix incorrect suggestions in private import diagnostic
Resolvesrust-lang/rust#156060.
1. In nested imports like `use two::{One, ...}`, the diagnostic suggested replacing the `One` with a multi-segment path of a different module, producing invalid code like `use crate::two::{one::One, Two}`. Skip it when `single_nested == true`.
2. Stop unconditionally skipping the first segment of `import.module_path`, which can produce incorrect paths in edition 2018 and later.
3. Mark the suggestion as "directly" instead of "through the re-export" when the import's source is the definition itself.
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#156246 (Introduce a `RerunNonErased` error type mirroring `NoSolution`, to better track when we're bailing)
- rust-lang/rust#156038 (turn `compute_goal_fast_path` into a single match)
- rust-lang/rust#156291 (Treat MSVC "performing full link" message as informational)
- rust-lang/rust#156301 (Avoid ICE when suggesting as_ref for ill-typed closure receivers)
Avoid ICE when suggesting as_ref for ill-typed closure receivers
Fixesrust-lang/rust#156299
When building mismatch suggestions, `can_use_as_ref` may inspect the receiver of a method call that is itself an ill-typed closure expression. In that recovery path, the receiver may not have a recorded type in `TypeckResults`.
Use `expr_ty_opt` instead of `expr_ty` so the optional `as_ref()` suggestion is skipped when the receiver type is unavailable.
许杰友 Jieyou Xu (Joe)