Clean up `ty::Dynamic`
1. As a follow-up to PR rust-lang/rust#143036, remove `DynKind` entirely.
2. Inside HIR ty lowering, consolidate modules `dyn_compatibility` and `lint` into `dyn_trait`
* `dyn_compatibility` wasn't about dyn compatibility itself, it's about lowering trait object types
* `lint` contained dyn-Trait-specific diagnostics+lints only
don't apply temporary lifetime extension rules to non-extended `super let`
Reference PR: rust-lang/reference#1980
This changes the semantics for `super let` (and macros implemented in terms of it, such as `pin!`, `format_args!`, `write!`, and `println!`) as suggested by ````@theemathas```` in https://github.com/rust-lang/rust/issues/145784#issuecomment-3218658335, making `super let` initializers only count as [extending expressions](https://doc.rust-lang.org/nightly/reference/destructors.html#extending-based-on-expressions) when the `super let` itself is within an extending block. Since `super let` initializers aren't temporary drop scopes, their temporaries outside of inner temporary scopes are effectively always extended, even when not in extending positions; this only affects two cases as far as I can tell:
- Block tail expressions in Rust 2024. This PR makes `f(pin!({ &temp() }))` drop `temp()` at the end of the block in Rust 2024, whereas previously it would live until after the call to `f` because syntactically the `temp()` was in an extending position as a result of `super let` in `pin!`'s expansion.
- `super let` nested within a non-extended `super let` is no longer extended. i.e. a normal `let` is required to treat `super let`s as extending (in which case nested `super let`s will also be extending).
Closesrust-lang/rust#145784
This is a breaking change. Both static and dynamic semantics are affected. The most likely breakage is for programs to stop compiling, but it's technically possible for drop order to silently change as well (as in rust-lang/rust#145784). Since this affects stable macros, it probably would need a crater run.
Nominating for discussion alongside rust-lang/rust#145784: ````@rustbot```` label +I-lang-nominated +I-libs-api-nominated
Tracking issue for `super let`: rust-lang/rust#139076
Display ?Sized, const, and lifetime parameters in trait item suggestions across a crate boundary
context: rust-lang/rust#145929
This fixes the MetaSized issue and adds const generics and early bound lifetimes. Late bound lifetimes are harder because they aren't returned by `generics_of`. I'm going to look into it, but there's no guarantee I'll be successful.
Fixes https://github.com/rust-lang/rust/issues/146404.
r? `@BoxyUwu`
Migrate `UnsizedConstParamTy` to unstable impl of `ConstParamTy_`
Now that we have ``#[unstable_feature_bound]``, we can remove ``UnsizedConstParamTy`` that was meant to be an unstable impl of stable type and ``ConstParamTy_`` trait.
r? `@BoxyUwU`
update fixme in compare_method_predicate_entailment resulting from review of EII
r? `@lcnr`
Just the comment update separately from https://github.com/rust-lang/rust/pull/146348/files since it doesn't really belong in that PR. Should be trivial
Skip typeck for items w/o their own typeck context
Skip items which forward typeck to their ancestor.
Should remove some potential but unnecessary typeck query waits, hence might improve performance for the parallel frontend.
Thanks to `@ywxt` for a fix suggestion
Fixesrust-lang/rust#141951
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#145463 (Reject invalid literal suffixes in tuple indexing, tuple struct indexing, and struct field name position)
- rust-lang/rust#145929 (fix APITIT being treated as a normal generic parameter in suggestions)
- rust-lang/rust#146001 (Update getopts to remove unicode-width dependency)
- rust-lang/rust#146365 (triagebot: warn about #[rustc_intrinsic_const_stable_indirect])
- rust-lang/rust#146366 (add approx_delta to all gamma tests)
- rust-lang/rust#146373 (fix comments about trait solver cycle heads)
r? `@ghost`
`@rustbot` modify labels: rollup
rename erase_regions to erase_and_anonymize_regions
I find it consistently confusing that `erase_regions` does more than replacing regions with `'erased`. it also makes some code look real goofy to be writing manual folders to erase regions with a comment saying "we cant use erase regions" :> or code that re-calls erase_regions on types with regions already erased just to anonymize all the bound regions.
r? lcnr
idk how i feel about the name being almost twice as long now
Implement Integer funnel shifts
Tracking issue: rust-lang/rust#145686
ACP: https://github.com/rust-lang/libs-team/issues/642
This implements funnel shifts on primitive integer types. Implements this for cg_llvm, with a fallback impl for everything else
Thanks `@folkertdev` for the fixes and tests
cc `@rust-lang/libs-api`
fix drop scope for `super let` bindings within `if let`
Fixesrust-lang/rust#145328 by making non-lifetime-extended `super let` reuse the logic used to compute drop scopes for non-lifetime-extended temporaries.
Also fixesrust-lang/rust#145374, which regressed due to rust-lang/rust#143376 introducing `if let`-like scopes for match arms with guards.
Tracking issue for `super let`: rust-lang/rust#139076
This is a regression fix / breaking change for macros stably exposing `super let`, including `pin!` and `format_args!`.
Nominating to be discussed alongside rust-lang/rust#145328: ```@rustbot``` label +I-lang-nominated +I-libs-api-nominated
stabilize c-style varargs for sysv64, win64, efiapi, aapcs
This has been split up so the PR now only contains the extended_varargs_abi_support stabilization; "system" has been moved to https://github.com/rust-lang/rust/pull/145954.
**Previous (combined) PR description:**
This stabilizes extern block declarations of variadic functions with the system, sysv64, win64, efiapi, aapcs ABIs. This corresponds to the extended_varargs_abi_support and extern_system_varargs feature gates.
The feature gates were split up since it seemed like there might be further discussion needed for what exactly "system" ABI variadic functions should do, but a [consensus](https://github.com/rust-lang/rust/issues/136946#issuecomment-2967847553) has meanwhile been reached: they shall behave like "C" functions. IOW, the ABI of a "system" function is (bold part is new in this PR):
- "stdcall" for win32 targets **for non-variadic functions**
- "C" for everything else
This had been previously stabilized *without FCP* in https://github.com/rust-lang/rust/pull/116161, which got reverted in https://github.com/rust-lang/rust/pull/136897. There was also a "fun" race condition involved with the system ABI being [added](https://github.com/rust-lang/rust/pull/119587) to the list of variadic-supporting ABIs between the creation and merge of rust-lang/rust#116161.
There was a question raised [here](https://github.com/rust-lang/rust/pull/116161#issuecomment-1983829513) whether t-lang even needs to be involved for a change like this. Not sure if that has meanwhile been clarified? The behavior of the "system" ABI (a Rust-specific ABI) definitely feels like t-lang territory to me.
Fixesrust-lang/rust#100189
Cc `@rust-lang/lang`
# Stabilization report
> ## General design
> ### What is the RFC for this feature and what changes have occurred to the user-facing design since the RFC was finalized?
AFAIK there is no RFC. The tracking issues are
- https://github.com/rust-lang/rust/issues/100189
- https://github.com/rust-lang/rust/issues/136946
> ### What behavior are we committing to that has been controversial? Summarize the major arguments pro/con.
The only controversial point is whether "system" ABI functions should support variadics.
- Pro: This allows crates like windows-rs to consistently use "system", see e.g. https://github.com/microsoft/windows-rs/issues/3626.
- Cons: `@workingjubilee` had some implementation concerns, but I think those have been [resolved](https://github.com/rust-lang/rust/issues/136946#issuecomment-2967847553). EDIT: turns out Jubilee still has concerns (she mentioned that in a DM); I'll let her express those.
Note that "system" is already a magic ABI we introduced to "do the right thing". This just makes it do the right thing in more cases. In particular, it means that on Windows one can almost always just do
```rust
extern "system" {
// put all the things here
}
```
and it'll do the right thing, rather than having to split imports into non-varargs and varargs, with the varargs in a separate `extern "C"` block (and risking accidentally putting a non-vararg there).
(I am saying "almost" always because some Windows API functions actually use cdecl, not stdcall, on x86. Those of course need to go in `extern "C"` blocks.)
> ### Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those?
Actually defining variadic functions in Rust remains unstable, under the [c_variadic feature gate](https://github.com/rust-lang/rust/issues/44930).
> ## Has a Call for Testing period been conducted? If so, what feedback was received?
>
> Does any OSS nightly users use this feature? For instance, a useful indication might be "search <grep.app> for `#![feature(FEATURE_NAME)]` and had `N` results".
There was no call for testing.
A search brings up https://github.com/rust-osdev/uefi-rs/blob/main/uefi-raw/src/table/boot.rs using this for "efiapi". This doesn't seem widely used, but it is an "obvious" gap in our support for c-variadics.
> ## Implementation quality
All rustc does here is forward the ABI to LLVM so there's lot a lot to say here...
> ### Summarize the major parts of the implementation and provide links into the code (or to PRs)
>
> An example for async closures: <https://rustc-dev-guide.rust-lang.org/coroutine-closures.html>.
The check for allowed variadic ABIs is [here](9c870d30e2/compiler/rustc_hir_analysis/src/lib.rs (L109-L126)).
The special handling of "system" is [here](c24914ec83/compiler/rustc_target/src/spec/abi_map.rs (L82-L85)).
> ### Summarize existing test coverage of this feature
>
> Consider what the "edges" of this feature are. We're particularly interested in seeing tests that assure us about exactly what nearby things we're not stabilizing.
>
> Within each test, include a comment at the top describing the purpose of the test and what set of invariants it intends to demonstrate. This is a great help to those reviewing the tests at stabilization time.
>
> - What does the test coverage landscape for this feature look like?
> - Tests for compiler errors when you use the feature wrongly or make mistakes?
> - Tests for the feature itself:
> - Limits of the feature (so failing compilation)
> - Exercises of edge cases of the feature
> - Tests that checks the feature works as expected (where applicable, `//@ run-pass`).
> - Are there any intentional gaps in test coverage?
>
> Link to test folders or individual tests (ui/codegen/assembly/run-make tests, etc.).
Prior PRs add a codegen test for all ABIs and tests actually calling extern variadic functions for sysv64 and win64:
- https://github.com/rust-lang/rust/pull/144359
- https://github.com/rust-lang/rust/pull/144379
We don't have a way of executing uefi target code in the test suite, so it's unclear how to fully test efiapi. aapcs could probably be done? (But note that we have hardly an such actually-calling-functions tests for ABI things, we almost entirely rely on codegen tests.)
The test ensuring that we do *not* stabilize *defining* c-variadic functions is `tests/ui/feature-gates/feature-gate-c_variadic.rs`.
> ### What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking?
None that I am aware of.
> ### What FIXMEs are still in the code for that feature and why is it ok to leave them there?
None that I am aware of.
> ### Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization
`@Soveu` added sysv64, win64, efiapi, aapcs to the list of ABIs that allow variadics, `@beepster4096` added system. `@workingjubilee` recently refactored the ABI handling in the compiler, also affecting this feature.
> ### Which tools need to be adjusted to support this feature. Has this work been done?
>
> Consider rustdoc, clippy, rust-analyzer, rustfmt, rustup, docs.rs.
Maybe RA needs to be taught about the new allowed ABIs? No idea how precisely they mirror what exactly rustc accepts and rejects here.
> ## Type system and execution rules
> ### What compilation-time checks are done that are needed to prevent undefined behavior?
>
> (Be sure to link to tests demonstrating that these tests are being done.)
Nothing new here, this just expands the existing support for calling variadic functions to more ABIs.
> ### Does the feature's implementation need checks to prevent UB or is it sound by default and needs opt in in places to perform the dangerous/unsafe operations? If it is not sound by default, what is the rationale?
Nothing new here, this just expands the existing support for calling variadic functions to more ABIs.
> ### Can users use this feature to introduce undefined behavior, or use this feature to break the abstraction of Rust and expose the underlying assembly-level implementation? (Describe.)
Nothing new here, this just expands the existing support for calling variadic functions to more ABIs.
> ### What updates are needed to the reference/specification? (link to PRs when they exist)
- https://github.com/rust-lang/reference/pull/1936
> ## Common interactions
> ### Does this feature introduce new expressions and can they produce temporaries? What are the lifetimes of those temporaries?
No.
> ### What other unstable features may be exposed by this feature?
None.
This was done in #145740 and #145947. It is causing problems for people
using r-a on anything that uses the rustc-dev rustup package, e.g. Miri,
clippy.
This repository has lots of submodules and subtrees and various
different projects are carved out of pieces of it. It seems like
`[workspace.dependencies]` will just be more trouble than it's worth.
Reject relaxed bounds inside associated type bounds (ATB)
**Reject** relaxed bounds — most notably `?Sized` — inside associated type bounds `TraitRef<AssocTy: …>`.
This was previously accepted without warning despite being incorrect: ATBs are *not* a place where we perform *sized elaboration*, meaning `TraitRef<AssocTy: …>` does *not* elaborate to `TraitRef<AssocTy: Sized + …>` if `…` doesn't contain `?Sized`. Therefore `?Sized` is meaningless. In no other (stable) place do we (intentionally) allow relaxed bounds where we don't also perform sized elab, this is highly inconsistent and confusing! Another point of comparison: For the desugared `$SelfTy: TraitRef, $SelfTy::AssocTy: …` we don't do sized elab either (and thus also don't allow relaxed bounds).
Moreover — as I've alluded to back in https://github.com/rust-lang/rust/pull/135841#pullrequestreview-2619462717 — some later validation steps only happen during sized elaboration during HIR ty lowering[^1]. Namely, rejecting duplicates (e.g., `?Trait + ?Trait`) and ensuring that `Trait` in `?Trait` is equal to `Sized`[^2]. As you can probably guess, on stable/master we don't run these checks for ATBs (so we allow even more nonsensical bounds like `Iterator<Item: ?Copy>` despite T-types's ruling established in the FCP'ed rust-lang/rust#135841).
This PR rectifies all of this. I cratered this back in 2025-01-10 with (allegedly) no regressions found ([report](https://github.com/rust-lang/rust/pull/135331#issuecomment-2585330783), [its analysis](https://github.com/rust-lang/rust/pull/135331#issuecomment-2585356422)). [However a contributor manually found two occurrences](https://github.com/rust-lang/rust/issues/135229#issuecomment-2581832852) of `TraitRef<AssocTy: ?Sized>` in small hobby projects (presumably via GH code search). I immediately sent downstream PRs: https://github.com/Gui-Yom/turbo-metrics/pull/14, https://github.com/ireina7/summon/pull/1 (however, the owners have showed no reaction so far).
I'm leaning towards banning these forms **without a FCW** because a FCW isn't worth the maintenance cost[^3]. Note that associated type bounds were stabilized in 1.79.0 (released 2024-06-13 which is 13 months ago), so the proliferation of ATBs shouldn't be that high yet. If you think we should do another crater run since the last one was 6 months ago, I'm fine with that.
Fixesrust-lang/rust#135229.
[^1]: I consider this a flaw in the implementation and [I've already added a huge FIXME](82a02aefe0/compiler/rustc_hir_analysis/src/hir_ty_lowering/bounds.rs (L195-L207)).
[^2]: To be more precise, if the internal flag `-Zexperimental-default-bounds` is provided other "default traits" (needs internal feature `lang_items`) are permitted as well (cc closely related internal feature: `more_maybe_bounds`).
[^3]: Having to track this and adding an entire lint whose remnants would remain in the code base forever (we never *fully* remove lints).
