Merge unboxed trait object error suggestion into regular dyn incompat error
Another hir-walker removed from the well-formed queries. This error was always a duplicate of another, but it was able to provide more information because it could invoke `is_dyn_compatible` without worrying about cycle errors. That's also the reason we can't put the error directly into hir_ty_lowering when lowering a `dyn Trait` within an associated item signature. So instead I packed it into the error handling of wf obligation checking.
Reduce uses of `hir_crate`.
I tried rebasing my old incremental-HIR branch. This is a by-product, which is required if we want to get rid of `hir_crate` entirely.
The second commit is a drive-by cleanup. It can be pulled into its own PR.
r? ````@oli-obk````
use `#[align]` attribute for `fn_align`
Tracking issue: https://github.com/rust-lang/rust/issues/82232https://github.com/rust-lang/rfcs/pull/3806 decides to add the `#[align]` attribute for alignment of various items. Right now it's used for functions with `fn_align`, in the future it will get more uses (statics, struct fields, etc.)
(the RFC finishes FCP today)
r? `@ghost`
Don't build `ParamEnv` and do trait solving in `ItemCtxt`s when lowering IATs
Fixesrust-lang/rust#108491Fixesrust-lang/rust#125879
This was due to updating inhabited predicate stuff which I had to do to make constructing ADTs with IATs in fields not ICE
Fixesrust-lang/rust#136678 (but no test added, I don't rly care about weird IAT edge cases under GCE)
Fixesrust-lang/rust#138131
Avoids doing "fully correct" candidate selection for IATs during hir ty lowering when in item signatures as it almost always leads to a query cycle from trying to build a `ParamEnv`. I replaced it with a use `DeepRejectCtxt` which should be able to handle this kind of conservative "could these types unify" while in a context where we don't want to do type equality.
This is a relatively simple scheme and should be forwards compatible with doing something more complex/powerful.
I'm not really sure how this interacts with rust-lang/rust#126651, though I'm also not really sure its super important to support projecting IATs from IAT self types given we don't even support `T::Assoc::Other` for trait-associated types so didn't give much thought to how this might fit in with that.
r? `@compiler-errors`
cc `@fmease`
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#135656 (Add `-Z hint-mostly-unused` to tell rustc that most of a crate will go unused)
- rust-lang/rust#138237 (Get rid of `EscapeDebugInner`.)
- rust-lang/rust#141614 (lint direct use of rustc_type_ir )
- rust-lang/rust#142123 (Implement initial support for timing sections (`--json=timings`))
- rust-lang/rust#142377 (Try unremapping compiler sources)
- rust-lang/rust#142674 (remove duplicate crash test)
r? `@ghost`
`@rustbot` modify labels: rollup
This commit adds a lint to prevent the use of rustc_type_ir in random
compiler crates, except for type system internals traits, which are
explicitly allowed. Moreover, this fixes diagnostic_items() to include
the CRATE_OWNER_ID, otherwise rustc_diagnostic_item attribute is ignored
on the crate root.
Sized Hierarchy: Part I
This patch implements the non-const parts of rust-lang/rfcs#3729. It introduces two new traits to the standard library, `MetaSized` and `PointeeSized`. See the RFC for the rationale behind these traits and to discuss whether this change makes sense in the abstract.
These traits are unstable (as is their constness), so users cannot refer to them without opting-in to `feature(sized_hierarchy)`. These traits are not behind `cfg`s as this would make implementation unfeasible, there would simply be too many `cfg`s required to add the necessary bounds everywhere. So, like `Sized`, these traits are automatically implemented by the compiler.
RFC 3729 describes changes which are necessary to preserve backwards compatibility given the introduction of these traits, which are implemented and as follows:
- `?Sized` is rewritten as `MetaSized`
- `MetaSized` is added as a default supertrait for all traits w/out an explicit sizedness supertrait already.
There are no edition migrations implemented in this, as these are primarily required for the constness parts of the RFC and prior to stabilisation of this (and so will come in follow-up PRs alongside the const parts). All diagnostic output should remain the same (showing `?Sized` even if the compiler sees `MetaSized`) unless the `sized_hierarchy` feature is enabled.
Due to the use of unstable extern types in the standard library and rustc, some bounds in both projects have had to be relaxed already - this is unfortunate but unavoidable so that these extern types can continue to be used where they were before. Performing these relaxations in the standard library and rustc are desirable longer-term anyway, but some bounds are not as relaxed as they ideally would be due to the inability to relax `Deref::Target` (this will be investigated separately).
It is hoped that this is implemented such that it could be merged and these traits could exist "under the hood" without that being observable to the user (other than in any performance impact this has on the compiler, etc). Some details might leak through due to the standard library relaxations, but this has not been observed in test output.
**Notes:**
- Any commits starting with "upstream:" can be ignored, as these correspond to other upstream PRs that this is based on which have yet to be merged.
- This best reviewed commit-by-commit. I've attempted to make the implementation easy to follow and keep similar changes and test output updates together.
- Each commit has a short description describing its purpose.
- This patch is large but it's primarily in the test suite.
- I've worked on the performance of this patch and a few optimisations are implemented so that the performance impact is neutral-to-minor.
- `PointeeSized` is a different name from the RFC just to make it more obvious that it is different from `std::ptr::Pointee` but all the names are yet to be bikeshed anyway.
- `@nikomatsakis` has confirmed [that this can proceed as an experiment from the t-lang side](https://rust-lang.zulipchat.com/#narrow/channel/435869-project-goals/topic/SVE.20and.20SME.20on.20AArch64.20.28goals.23270.29/near/506196491)
- FCP in https://github.com/rust-lang/rust/pull/137944#issuecomment-2912207485Fixesrust-lang/rust#79409.
r? `@ghost` (I'll discuss this with relevant teams to find a reviewer)
Opting-out of `Sized` with `?Sized` is now equivalent to adding a
`MetaSized` bound, and adding a `MetaSized` or `PointeeSized` bound
is equivalent to removing the default `Sized` bound - this commit
implements this change in `rustc_hir_analysis::hir_ty_lowering`.
`MetaSized` is also added as a supertrait of all traits, as this is
necessary to preserve backwards compatibility.
Unfortunately, non-global where clauses being preferred over item bounds
(where `PointeeSized` bounds would be proven) - which can result in
errors when a `PointeeSized` supertrait/bound/predicate is added to some
items. Rather than `PointeeSized` being a bound on everything, it can
be the absence of a bound on everything, as `?Sized` was.
As core uses an extern type (`ptr::VTable`), the default `?Sized` to
`MetaSized` migration isn't sufficient, and some code that previously
accepted `VTable` needs relaxed to continue to accept extern types.
Similarly, the compiler uses many extern types in `rustc_codegen_llvm`
and in the `rustc_middle::ty::List` implementation (`OpaqueListContents`)
some bounds must be relaxed to continue to accept these types.
Unfortunately, due to the current inability to relax `Deref::Target`,
some of the bounds in the standard library are forced to be stricter than
they ideally would be.
Expand the automatic implementation of `MetaSized` and `PointeeSized` so
that it is also implemented on non-`Sized` types, just not `ty::Foreign`
(extern type).
Introduce the `MetaSized` and `PointeeSized` traits as supertraits of
`Sized` and initially implement it on everything that currently
implements `Sized` to isolate any changes that simply adding the
traits introduces.
Add documentation on top of `rustc_middle/src/query/mod.rs`
The `rustc-dev-guide` gives a high-level intro, but many details—especially about how the code works and modifiers in `query xxx(){...}`—are only in code comments or the macro implementation. This doc makes it easier for contributors and code readers to understand the workflow and available modifiers without jumping between files and docs.
This PR adds a comprehensive module-level doc comment to `rustc_middle::query::mod.rs` that:
1. Provides an overview of the query system and macro-based query definitions for reading code more easily
2. Centralizes documentation for all query modifiers (previously scattered or only in `rustc_macro` code), closely following the authoritative list in QueryModifiers.
Move metadata object generation for dylibs to the linker code
This deduplicates some code between codegen backends and may in the future allow adding extra metadata that is only known at link time.
Prerequisite of https://github.com/rust-lang/rust/issues/96708.
Unimplement unsized_locals
Implements https://github.com/rust-lang/compiler-team/issues/630
Tracking issue here: https://github.com/rust-lang/rust/issues/111942
Note that this just removes the feature, not the implementation, and does not touch `unsized_fn_params`. This is because it is required to support `Box<dyn FnOnce()>: FnOnce()`.
There may be more that should be removed (possibly in follow up prs)
- the `forget_unsized` function and `forget` intrinsic.
- the `unsized_locals` test directory; I've just fixed up the tests for now
- various codegen support for unsized values and allocas
cc ``@JakobDegen`` ``@oli-obk`` ``@Noratrieb`` ``@programmerjake`` ``@bjorn3``
``@rustbot`` label F-unsized_locals
Fixesrust-lang/rust#79409
Delay replacing escaping bound vars in `FindParamInClause`
By uplifting the `BoundVarReplacer`, which is used by (e.g.) normalization to replace escaping bound vars that are encountered when folding binders, we can use a similar strategy to delay the instantiation of a binder's contents in the `FindParamInClause` used by the new trait solver.
This should alleviate the recently added requirement that `Binder<T>: TypeVisitable` only if `T: TypeFoldable`, which was previously required b/c we were calling `enter_forall` so that we could structurally normalize aliases that we found within the predicates of a param-env clause.
r? lcnr
add `extern "custom"` functions
tracking issue: rust-lang/rust#140829
previous discussion: https://github.com/rust-lang/rust/issues/140566
In short, an `extern "custom"` function is a function with a custom ABI, that rust does not know about. Therefore, such functions can only be defined with `#[unsafe(naked)]` and `naked_asm!`, or via an `extern "C" { /* ... */ }` block. These functions cannot be called using normal rust syntax: calling them can only be done from inline assembly.
The motivation is low-level scenarios where a custom calling convention is used. Currently, we often pick `extern "C"`, but that is a lie because the function does not actually respect the C calling convention.
At the moment `"custom"` seems to be the name with the most support. That name is not final, but we need to pick something to actually implement this.
r? `@traviscross`
cc `@tgross35`
try-job: x86_64-apple-2
Tracking the old name of renamed unstable library features
This PR resolves the first problem of rust-lang/rust#141617 : tracking renamed unstable features. The first commit is to add a ui test, and the second one tracks the changes. I will comment on the code for clarification.
r? `@jdonszelmann`
There have been a lot of PR's reviewed by you lately, thanks for your time!
cc `@jyn514`
