remove FIXME block from `has_significant_drop`, it never encounters inference variables
The `FIXME` block in `Ty::has_significant_drop` is outdated as related queries can now handle type inference.
321a89bec5/compiler/rustc_middle/src/ty/util.rs (L1378-L1389)Closesrust-lang/rust#86868 (other places mentioned in the issue have been resolved, or moved to other issues)
r? types
interpret: fix overlapping aggregate initialization
This fixes the problem pointed out by ````@saethlin```` in https://github.com/rust-lang/rust/issues/146383#issuecomment-3273224645.
Also clarify when exactly current de-facto MIR semantics allow overlap of the LHS and RHS in an assignment.
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
but a C-variadic method makes a trait dyn-incompatible. That is because
methods from dyn traits, when cast to a function pointer, create a shim.
That shim can't really forward the c-variadic arguments.
Trim paths less in MIR dumping
With this PR, the paths MIR dump filters and that are printed at the start of a dump file are no longer trimmed. They don't include the crate that is being compiled, however.
Implement `#[rustc_align_static(N)]` on `static`s
Tracking issue: https://github.com/rust-lang/rust/issues/146177
```rust
#![feature(static_align)]
#[rustc_align_static(64)]
static SO_ALIGNED: u64 = 0;
```
We need a different attribute than `rustc_align` because unstable attributes are tied to their feature (we can't have two unstable features use the same unstable attribute). Otherwise this uses all of the same infrastructure as `#[rustc_align]`.
r? `@traviscross`
We need a different attribute than `rustc_align` because unstable attributes are
tied to their feature (we can't have two unstable features use the same
unstable attribute). Otherwise this uses all of the same infrastructure
as `#[rustc_align]`.
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
const-eval: disable pointer fragment support
This fixes https://github.com/rust-lang/rust/issues/146291 by disabling pointer fragment support for const-eval. I want to properly fix this eventually, but won't get to it in the next few weeks, so this is an emergency patch to prevent the buggy implementation from landing on stable. The beta cutoff is on Sep 12th so if this PR lands after that, we'll need a backport.
Port limit attributes to the new attribute parsing infrastructure
Doesn't pass tests, to be rebased on https://github.com/rust-lang/rust/pull/145792 which will solve that
r? `@fmease`
eagerly compute `sub_unification_table` again
Previously called `sub_relations`. We still only using them for diagnostics right now. This mostly reverts rust-lang/rust#119989. Necessary for type inference guidance due to not-yet defined opaque types, cc https://github.com/rust-lang/trait-system-refactor-initiative/issues/182.
We could use them for cycle detection in generalization and it seems desirable to do so in the future. However, this is unsound with the old trait solver as its cache does not track these `sub_unification_table` in any way.
We now properly track the `sub_unification_table` when canonicalizing so using them in the new solver is totally sound and the performance impact is far more manageable than I thought back in rust-lang/rust#119989.
r? `@compiler-errors`
Migrate more things in the new solver to specific `DefId`s
Continuation of https://github.com/rust-lang/rust/pull/145377. I migrated the rest of the types, except aliases.
Aliases are problematic because opaques and associated types share the same type in the new solver. `@jackh726,` `@lcnr,` `@ShoyuVanilla` I'd like to hear ideas here. Anyway, even if we do nothing with them we already got a substantial improvement.
r? types
Don't require next-solver `ProbeRef` to be `Copy`
rust-analyzer would like to use a non-interned `Probe` there.
Also rename it to `Probe` for this reason.
We can make it `Copy` (although then `Probe` will need to be `Clone` for rust-analyzer) but it seems just non-needed.
r? types
Allow `inline(always)` with a target feature behind a unstable feature `target_feature_inline_always`.
Rather than adding the inline always attribute to the function definition, we add it to the callsite. We can then check that the target features match and that the call would be safe to inline. If the function isn't inlined due to a mismatch, we emit a warning informing the user that the function can't be inlined due to the target feature mismatch.
See tracking issue rust-lang/rust#145574
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
