Perform simple scalar replacement of aggregates (SROA) MIR opt
This is a re-open of https://github.com/rust-lang/rust/pull/85796
I copied the debuginfo implementation (first commit) from `@eddyb's` own SROA PR.
This pass replaces plain field accesses by simple locals when possible.
To be eligible, the replaced locals:
- must not be enums or unions;
- must not be used whole;
- must not have their address taken.
The storage and deinit statements are duplicated on each created local.
cc `@tmiasko` who reviewed the former version of this PR.
interpret: support for per-byte provenance
Also factors the provenance map into its own module.
The third commit does the same for the init mask. I can move it in a separate PR if you prefer.
Fixes https://github.com/rust-lang/miri/issues/2181
r? `@oli-obk`
Rollup of 9 pull requests
Successful merges:
- #103439 (Show note where the macro failed to match)
- #103734 (Adjust stabilization version to 1.65.0 for wasi fds)
- #104148 (Visit attributes of trait impl items during AST validation)
- #104241 (Move most of unwind's build script to lib.rs)
- #104258 (Deduce closure signature from a type alias `impl Trait`'s supertraits)
- #104296 (Walk types more carefully in `ProhibitOpaqueTypes` visitor)
- #104309 (Slightly improve error message for invalid identifier)
- #104316 (Simplify suggestions for errors in generators.)
- #104339 (Add `rustc_deny_explicit_impl`)
Failed merges:
- #103484 (Add `rust` to `let_underscore_lock` example)
r? `@ghost`
`@rustbot` modify labels: rollup
Deduce closure signature from a type alias `impl Trait`'s supertraits
r? `@oli-obk`
Basically pass the TAIT's bounds through the same method that we're using to deduce a signature from infer var closure bounds.
Does this need a new FCP? I see it as a logical extension of #101834, but happy to rfcbot a new one if it does.
Add new MIR constant propagation based on dataflow analysis
The current constant propagation in `rustc_mir_transform/src/const_prop.rs` fails to handle many cases that would be expected from a constant propagation optimization. For example:
```rust
let x = if true { 0 } else { 0 };
```
This pull request adds a new constant propagation MIR optimization pass based on the existing dataflow analysis framework. Since most of the analysis is not unique to constant propagation, a generic framework has been extracted. It works on top of the existing framework and could be reused for other optimzations.
Closes#80038. Closes#81605.
## Todo
### Essential
- [x] [Writes to inactive enum variants](https://github.com/rust-lang/rust/pull/101168#pullrequestreview-1089493974). Resolved by rejecting the registration of places with downcast projections for now. Could be improved by flooding other variants if mutable access to a variant is observed.
- [X] Handle [`StatementKind::CopyNonOverlapping`](https://github.com/rust-lang/rust/pull/101168#discussion_r957774914). Resolved by flooding the destination.
- [x] Handle `UnsafeCell` / `!Freeze` correctly.
- [X] Overflow propagation of `CheckedBinaryOp`: Decided to not propagate if overflow flag is `true` (`false` will still be propagated)
- [x] More documentation in general.
- [x] Arguments for correctness, documentation of necessary assumptions.
- [x] Better performance, or alternatively, require `-Zmir-opt-level=3` for now.
### Extra
- [x] Add explicit unreachability, i.e. upgrading the lattice from $\mathbb{P} \to \mathbb{V}$ to $\set{\bot} \cup (\mathbb{P} \to \mathbb{V})$.
- [x] Use storage statements to improve precision.
- [ ] Consider opening issue for duplicate diagnostics: https://github.com/rust-lang/rust/pull/101168#issuecomment-1276609950
- [ ] Flood moved-from places with $\bot$ (requires some changes for places with tracked projections).
- [ ] Add downcast projections back in.
- [ ] [Algebraic simplifications](https://github.com/rust-lang/rust/pull/101168#discussion_r957967878) (possibly with a shared API; done by old const prop).
- [ ] Propagation through slices / arrays.
- [ ] Find other optimizations that are done by old `const_prop.rs`, but not by this one.
Resolve lifetimes independently for each item-like.
Now that the heavy-lifting is done on the AST and during lowering, we do not need to perform HIR lifetime resolution on a full item at once. Instead, we can treat each item-like independently, and look at `generics_of` the parent exceptionally for associated items.
Use `const_error_with_guaranteed` more
Better to pass down an ErrorGuaranteed rather than making a new one out of thin air, for some usages. Also for the ones where we *do* need to delay a bug, that delayed bug will have a more descriptive message.
Add support for custom mir
This implements rust-lang/compiler-team#564 . Details about the design, motivation, etc. can be found in there.
r? ```@oli-obk```
Rollup of 7 pull requests
Successful merges:
- #100508 (avoid making substs of type aliases late bound when used as fn args)
- #101381 (Test that target feature mix up with homogeneous floats is sound)
- #103353 (Fix Access Violation when using lld & ThinLTO on windows-msvc)
- #103521 (Avoid possible infinite loop when next_point reaching the end of file)
- #103559 (first move on a nested span_label)
- #103778 (Update several crates for improved support of the new targets)
- #103827 (Properly remap and check for substs compatibility in `confirm_impl_trait_in_trait_candidate`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Better error for HRTB error from generator interior
cc #100013
This is just a first pass at an error. It could be better, and shouldn't really be emitted in the first place. But this is better than what was being emitted before.
selection failure: recompute applicable impls
The way we currently skip errors for ambiguous trait obligations seems pretty fragile so we get some duplicate errors because of this.
Removing this info from selection errors changes this system to be closer to my image of our new trait solver and is also making it far easier to change overflow errors to be non-fatal ✨
r? types cc `@estebank`
resolve: More detailed effective visibility tracking for imports
Per-`DefId` tracking is not enough, due to glob imports in particular, which have a single `DefId` for the whole glob import item.
We need to track this stuff per every introduced name (`NameBinding`).
Also drop `extern` blocks from the effective visibility table, they are nominally private and it doesn't make sense to keep them there.
Later commits add some debug-only invariant checking and optimiaztions to mitigate regressions in https://github.com/rust-lang/rust/pull/103965#issuecomment-1304256445.
This is a bugfix and continuation of https://github.com/rust-lang/rust/pull/102026.
fix: lint against the functions `LintContext::{lookup_with_diagnostics,lookup,struct_span_lint,lint}`, `TyCtxt::struct_lint_node`, `LintLevelsBuilder::struct_lint`.
Implement `std::marker::Tuple`, use it in `extern "rust-call"` and `Fn`-family traits
Implements rust-lang/compiler-team#537
I made a few opinionated decisions in this implementation, specifically:
1. Enforcing `extern "rust-call"` on fn items during wfcheck,
2. Enforcing this for all functions (not just ones that have bodies),
3. Gating this `Tuple` marker trait behind its own feature, instead of grouping it into (e.g.) `unboxed_closures`.
Still needing to be done:
1. Enforce that `extern "rust-call"` `fn`-ptrs are well-formed only if they have 1/2 args and the second one implements `Tuple`. (Doing this would fix ICE in #66696.)
2. Deny all explicit/user `impl`s of the `Tuple` trait, kinda like `Sized`.
3. Fixing `Tuple` trait built-in impl for chalk, so that chalkification tests are un-broken.
Open questions:
1. Does this need t-lang or t-libs signoff?
Fixes#99820
minor changes to make method lookup diagnostic code easier to read
The end result of around 4 days of trying to understand this 1000+ line long function- a bunch of tiny nitpicks
r? `@compiler-errors`
Rewrite implementation of `#[alloc_error_handler]`
The new implementation doesn't use weak lang items and instead changes `#[alloc_error_handler]` to an attribute macro just like `#[global_allocator]`.
The attribute will generate the `__rg_oom` function which is called by the compiler-generated `__rust_alloc_error_handler`. If no `__rg_oom` function is defined in any crate then the compiler shim will call `__rdl_oom` in the alloc crate which will simply panic.
This also fixes link errors with `-C link-dead-code` with `default_alloc_error_handler`: `__rg_oom` was previously defined in the alloc crate and would attempt to reference the `oom` lang item, even if it didn't exist. This worked as long as `__rg_oom` was excluded from linking since it was not called.
This is a prerequisite for the stabilization of `default_alloc_error_handler` (#102318).
The new implementation doesn't use weak lang items and instead changes
`#[alloc_error_handler]` to an attribute macro just like
`#[global_allocator]`.
The attribute will generate the `__rg_oom` function which is called by
the compiler-generated `__rust_alloc_error_handler`. If no `__rg_oom`
function is defined in any crate then the compiler shim will call
`__rdl_oom` in the alloc crate which will simply panic.
This also fixes link errors with `-C link-dead-code` with
`default_alloc_error_handler`: `__rg_oom` was previously defined in the
alloc crate and would attempt to reference the `oom` lang item, even if
it didn't exist. This worked as long as `__rg_oom` was excluded from
linking since it was not called.
This is a prerequisite for the stabilization of
`default_alloc_error_handler` (#102318).
Rollup of 8 pull requests
Successful merges:
- #97971 (Enable varargs support for calling conventions other than C or cdecl )
- #101428 (Add mir building test directory)
- #101944 (rustdoc: clean up `#toggle-all-docs`)
- #102101 (check lld version to choose correct option to disable multi-threading in tests)
- #102689 (Add a tier 3 target for the Sony PlayStation 1)
- #103746 (rustdoc: add support for incoherent impls on structs and traits)
- #103758 (Add regression test for reexports in search results)
- #103764 (All verbosity checks in `PrettyPrinter` now go through `PrettyPrinter::should_print_verbose`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
All verbosity checks in `PrettyPrinter` now go through `PrettyPrinter::should_print_verbose`
Follow-up to #103428. That pr only partially fixed#94187. In some cases (like closures) `std::any::type_name` was still producing a different output when `-Zverbose` was enabled.
This pr fixes those cases and adds a new function `PrettyPrinter::should_print_verbose`. This function should always be used over `self.tcx().sess.verbose()` inside a `impl PrettyPrinter`.
Maybe closes#94187 now.
r? ``@compiler-errors``
`codegen_switchint_terminator` already uses `br` instead of `switch`
when there is one normal target plus the `otherwise` target. But there's
another common case with two normal targets and an `otherwise` target
that points to an empty unreachable BB. This comes up a lot when
switching on the tags of enums that use niches.
The pattern looks like this:
```
bb1: ; preds = %bb6
%3 = load i8, ptr %_2, align 1, !range !9, !noundef !4
%4 = sub i8 %3, 2
%5 = icmp eq i8 %4, 0
%_6 = select i1 %5, i64 0, i64 1
switch i64 %_6, label %bb3 [
i64 0, label %bb4
i64 1, label %bb2
]
bb3: ; preds = %bb1
unreachable
```
This commit adds code to convert the `switch` to a `br`:
```
bb1: ; preds = %bb6
%3 = load i8, ptr %_2, align 1, !range !9, !noundef !4
%4 = sub i8 %3, 2
%5 = icmp eq i8 %4, 0
%_6 = select i1 %5, i64 0, i64 1
%6 = icmp eq i64 %_6, 0
br i1 %6, label %bb4, label %bb2
bb3: ; No predecessors!
unreachable
```
This has a surprisingly large effect on compile times, with reductions
of 5% on debug builds of some crates. The reduction is all due to LLVM
taking less time. Maybe LLVM is just much better at handling `br` than
`switch`.
The resulting code is still suboptimal.
- The `icmp`, `select`, `icmp` sequence is silly, converting an `i1` to an `i64`
and back to an `i1`. But with the current code structure it's hard to avoid,
and LLVM will easily clean it up, in opt builds at least.
- `bb3` is usually now truly dead code (though not always, so it can't
be removed universally).
Accept `TyCtxt` instead of `TyCtxtAt` in `Ty::is_*` functions
Functions in answer:
- `Ty::is_freeze`
- `Ty::is_sized`
- `Ty::is_unpin`
- `Ty::is_copy_modulo_regions`
This allows to remove a lot of useless `.at(DUMMY_SP)`, making the code a bit nicer :3
r? `@compiler-errors`
Rename some `OwnerId` fields.
`@spastorino` noticed some silly expressions like `item_id.def_id.def_id`.
This commit renames several `def_id: OwnerId` fields as `owner_id`, so those expressions become `item_id.owner_id.def_id`.
`item_id.owner_id.local_def_id` would be even clearer, but the use of `def_id` for values of type `LocalDefId` is *very* widespread, so I left that alone.
r? `@compiler-errors`
spastorino noticed some silly expressions like `item_id.def_id.def_id`.
This commit renames several `def_id: OwnerId` fields as `owner_id`, so
those expressions become `item_id.owner_id.def_id`.
`item_id.owner_id.local_def_id` would be even clearer, but the use of
`def_id` for values of type `LocalDefId` is *very* widespread, so I left
that alone.
Introduce UnordMap, UnordSet, and UnordBag (MCP 533)
This is the start of implementing [MCP 533](https://github.com/rust-lang/compiler-team/issues/533).
I followed `@eddyb's` suggestion of naming the collection types `Unord(Map/Set/Bag)` which is a bit easier to type than `Unordered(Map/Set/Bag)`
r? `@eddyb`
privacy: Rename "accessibility levels" to "effective visibilities"
And a couple of other naming and comment tweaks.
Related to https://github.com/rust-lang/rust/issues/48054
For `enum Level` I initially used naming `enum EffectiveVisibilityLevel`, but it was too long and inconvenient because it's used pretty often.
So I shortened it to just `Level`, if it needs to be used from some context where this name would be ambiguous, then it can be imported with renaming like `use rustc_middle::privacy::Level as EffVisLevel` or something.
Fix line numbers for MIR inlined code
`should_collapse_debuginfo` detects if the specified span is part of a
macro expansion however it does this by checking if the span is anything
other than a normal (non-expanded) kind, then the span sequence is
walked backwards to the root span.
This doesn't work when the MIR inliner inlines code as it creates spans
with expansion information set to `ExprKind::Inlined` and results in the
line number being attributed to the inline callsite rather than the
normal line number of the inlined code.
Fixes#103068
Add eval hack in `super_relate_consts` back
Partially reverts 01adb7e98d.
This extra eval call *still* needs to happen, for example, in `normalize_param_env_or_error` when a param-env predicate has an unnormalized constant, since the param-env candidates never get normalized during candidate assembly (everywhere else we can assume that they are normalized fully).
r? `@lcnr,` though I feel like I've assigned quite a few PRs to you in the last few days, so feel free to reassign to someone else familiar with this code if you're busy!
cc #103243 (fixes the issue, but don't want to auto-close that until a backport is performed).
Split phase change from `MirPass`
The main goal here is to simplify the pass manager logic. `MirPass` no longer contains the `phase_change` method, and `run_passes` instead accepts an `Option<PhaseChange>`. The hope is that this addresses the comments (and maybe perf regression) from #99102 .
r? `@oli-obk` cc `@RalfJung`
Pretty print lifetimes captured by RPIT
This specifically makes the output in #103409 change from:
```diff
error: `impl` item signature doesn't match `trait` item signature
--> $DIR/signature-mismatch.rs:15:5
|
LL | fn async_fn(&self, buff: &[u8]) -> impl Future<Output = Vec<u8>>;
| ----------------------------------------------------------------- expected `fn(&'1 Struct, &'2 [u8]) -> impl Future<Output = Vec<u8>>`
...
LL | fn async_fn<'a>(&self, buff: &'a [u8]) -> impl Future<Output = Vec<u8>> + 'a {
- | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ found `fn(&'1 Struct, &'2 [u8]) -> impl Future<Output = Vec<u8>>`
+ | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ found `fn(&'1 Struct, &'2 [u8]) -> impl Future<Output = Vec<u8>> + '2`
|
= note: expected `fn(&'1 Struct, &'2 [u8]) -> impl Future<Output = Vec<u8>>`
- found `fn(&'1 Struct, &'2 [u8]) -> impl Future<Output = Vec<u8>>`
+ found `fn(&'1 Struct, &'2 [u8]) -> impl Future<Output = Vec<u8>> + '2`
= help: the lifetime requirements from the `impl` do not correspond to the requirements in the `trait`
= help: verify the lifetime relationships in the `trait` and `impl` between the `self` argument, the other inputs and its output
error: aborting due to previous error
```
Along with the UI tests in this PR, which I think are all improvements!
r? `@oli-obk` though feel free to re-roll
Flatten diagnostic slug modules
This makes it easier to grep for the slugs in the code.
See https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Localization.20infra.20interferes.20with.20grepping.20for.20error for more discussion about it.
This was mostly done with a few regexes and a bunch of manual work. This also exposes a pretty annoying inconsistency for the extra labels. Some of the extra labels are defined as additional properties in the fluent message (which makes them not prefixed with the crate name) and some of them are new fluent messages themselves (which makes them prefixed with the crate name). I don't know whether we want to clean this up at some point but it's useful to know.
r? `@davidtwco`
Introduce `subst_iter` and `subst_iter_copied` on `EarlyBinder`
Makes working with bounds lists a bit easier, which I seem to do a lot.
Specifically, means that we don't need to do `.transpose_iter().map(|(pred, _)| *pred)` every time we want to iterate through an `EarlyBinder<&'tcx [(Predicate, Span)]>` (and even then, still have to call `subst` later), which was a very awkward idiom imo.
stop using `ty::UnevaluatedConst` directly
best reviewed commit by commit.
simplifies #99798 because we now don't have to expand `ty::UnevaluatedConst` to `ty::Const`.
I also remember some other places where using `ty::UnevaluatedConst` directly was annoying and caused issues, though I don't quite remember what they were rn '^^
r? `@oli-obk` cc `@JulianKnodt`
Get rid of native_library projection queries
They don't seem particularly useful as I don't expect native libraries to change frequently.
Maybe they do provide significant value of keeping incremental compilation green though, I'm not sure.
Introduce deduced parameter attributes, and use them for deducing `readonly` on indirect immutable freeze by-value function parameters.
Introduce deduced parameter attributes, and use them for deducing `readonly` on
indirect immutable freeze by-value function parameters.
Right now, `rustc` only examines function signatures and the platform ABI when
determining the LLVM attributes to apply to parameters. This results in missed
optimizations, because there are some attributes that can be determined via
analysis of the MIR making up the function body. In particular, `readonly`
could be applied to most indirectly-passed by-value function arguments
(specifically, those that are freeze and are observed not to be mutated), but
it currently is not.
This patch introduces the machinery that allows `rustc` to determine those
attributes. It consists of a query, `deduced_param_attrs`, that, when
evaluated, analyzes the MIR of the function to determine supplementary
attributes. The results of this query for each function are written into the
crate metadata so that the deduced parameter attributes can be applied to
cross-crate functions. In this patch, we simply check the parameter for
mutations to determine whether the `readonly` attribute should be applied to
parameters that are indirect immutable freeze by-value. More attributes could
conceivably be deduced in the future: `nocapture` and `noalias` come to mind.
Adding `readonly` to indirect function parameters where applicable enables some
potential optimizations in LLVM that are discussed in [issue 103103] and [PR
103070] around avoiding stack-to-stack memory copies that appear in functions
like `core::fmt::Write::write_fmt` and `core::panicking::assert_failed`. These
functions pass a large structure unchanged by value to a subfunction that also
doesn't mutate it. Since the structure in this case is passed as an indirect
parameter, it's a pointer from LLVM's perspective. As a result, the
intermediate copy of the structure that our codegen emits could be optimized
away by LLVM's MemCpyOptimizer if it knew that the pointer is `readonly
nocapture noalias` in both the caller and callee. We already pass `nocapture
noalias`, but we're missing `readonly`, as we can't determine whether a
by-value parameter is mutated by examining the signature in Rust. I didn't have
much success with having LLVM infer the `readonly` attribute, even with fat
LTO; it seems that deducing it at the MIR level is necessary.
No large benefits should be expected from this optimization *now*; LLVM needs
some changes (discussed in [PR 103070]) to more aggressively use the `noalias
nocapture readonly` combination in its alias analysis. I have some LLVM patches
for these optimizations and have had them looked over. With all the patches
applied locally, I enabled LLVM to remove all the `memcpy`s from the following
code:
```rust
fn main() {
println!("Hello {}", 3);
}
```
which is a significant codegen improvement over the status quo. I expect that if this optimization kicks in in multiple places even for such a simple program, then it will apply to Rust code all over the place.
[issue 103103]: https://github.com/rust-lang/rust/issues/103103
[PR 103070]: https://github.com/rust-lang/rust/pull/103070
indirect immutable freeze by-value function parameters.
Right now, `rustc` only examines function signatures and the platform ABI when
determining the LLVM attributes to apply to parameters. This results in missed
optimizations, because there are some attributes that can be determined via
analysis of the MIR making up the function body. In particular, `readonly`
could be applied to most indirectly-passed by-value function arguments
(specifically, those that are freeze and are observed not to be mutated), but
it currently is not.
This patch introduces the machinery that allows `rustc` to determine those
attributes. It consists of a query, `deduced_param_attrs`, that, when
evaluated, analyzes the MIR of the function to determine supplementary
attributes. The results of this query for each function are written into the
crate metadata so that the deduced parameter attributes can be applied to
cross-crate functions. In this patch, we simply check the parameter for
mutations to determine whether the `readonly` attribute should be applied to
parameters that are indirect immutable freeze by-value. More attributes could
conceivably be deduced in the future: `nocapture` and `noalias` come to mind.
Adding `readonly` to indirect function parameters where applicable enables some
potential optimizations in LLVM that are discussed in [issue 103103] and [PR
103070] around avoiding stack-to-stack memory copies that appear in functions
like `core::fmt::Write::write_fmt` and `core::panicking::assert_failed`. These
functions pass a large structure unchanged by value to a subfunction that also
doesn't mutate it. Since the structure in this case is passed as an indirect
parameter, it's a pointer from LLVM's perspective. As a result, the
intermediate copy of the structure that our codegen emits could be optimized
away by LLVM's MemCpyOptimizer if it knew that the pointer is `readonly
nocapture noalias` in both the caller and callee. We already pass `nocapture
noalias`, but we're missing `readonly`, as we can't determine whether a
by-value parameter is mutated by examining the signature in Rust. I didn't have
much success with having LLVM infer the `readonly` attribute, even with fat
LTO; it seems that deducing it at the MIR level is necessary.
No large benefits should be expected from this optimization *now*; LLVM needs
some changes (discussed in [PR 103070]) to more aggressively use the `noalias
nocapture readonly` combination in its alias analysis. I have some LLVM patches
for these optimizations and have had them looked over. With all the patches
applied locally, I enabled LLVM to remove all the `memcpy`s from the following
code:
```rust
fn main() {
println!("Hello {}", 3);
}
```
which is a significant codegen improvement over the status quo. I expect that
if this optimization kicks in in multiple places even for such a simple
program, then it will apply to Rust code all over the place.
[issue 103103]: https://github.com/rust-lang/rust/issues/103103
[PR 103070]: https://github.com/rust-lang/rust/pull/103070
Deny hashing ty/re/ct inference variables
cc `@cjgillot` and https://github.com/rust-lang/rust/pull/102695#issuecomment-1275706528
r? `@lcnr`
best reviewed one commit at a time, mostly because the second commit that fixes `ClosureOutlivesRequirement` is mostly noise because of losing its `<'tcx>` lifetime parameter.
Get rid of `rustc_query_description!`
**I am not entirely sure whether this is an improvement and would like to get your feedback on it.**
Helps with #96524.
Queries can provide an arbitrary expression for their description and their caching behavior. Before, these expressions where stored in a `rustc_query_description` macro emitted by the `rustc_queries` macro, and then used in `rustc_query_impl` to fill out the methods for the `QueryDescription` trait.
Instead, we now emit two new modules from `rustc_queries` containing the functions with the expressions. `rustc_query_impl` calls these functions now instead of invoking the macro.
Since we are now defining some of the functions in `rustc_middle::query`, we now need all the imports for the key types mthere as well.
r? `@cjgillot`
Make `dyn*` casts into a coercion, allow `dyn*` upcasting
I know that `dyn*` is likely not going to be a feature exposed to surface Rust, but this makes it slightly more ergonomic to write tests for these types anyways. ... and this was just fun to implement anyways.
1. Make `dyn*` into a coercion instead of a cast
2. Enable `dyn*` upcasting since we basically get it for free
3. Simplify some of the cast checking code since we're using the coercion path now
r? `@eholk` but feel free to reassign
cc `@nikomatsakis` and `@tmandry` who might care about making `dyn*` casts into a coercion
`should_collapse_debuginfo` detects if the specified span is part of a
macro expansion however it does this by checking if the span is anything
other than a normal (non-expanded) kind, then the span sequence is
walked backwards to the root span.
This doesn't work when the MIR inliner inlines code as it creates spans
with expansion information set to `ExprKind::Inlined` and results in the
line number being attributed to the inline callsite rather than the
normal line number of the inlined code.
Queries can provide an arbitrary expression for their description and
their caching behavior. Before, these expressions where stored in a
`rustc_query_description` macro emitted by the `rustc_queries` macro,
and then used in `rustc_query_impl` to fill out the methods for the
`QueryDescription` trait.
Instead, we now emit two new modules from `rustc_queries` containing the
functions with the expressions. `rustc_query_impl` calls these functions
now instead of invoking the macro.
Since we are now defining some of the functions in
`rustc_middle::query`, we now need all the imports for the key types
there as well.
More dupe word typos
I only picked those changes (from the regex search) that I am pretty certain doesn't change meaning and is just a typo fix. Do correct me if any fix is undesirable and I can revert those. Thanks.
Move `IntoDiagnostic` conformance for `TargetDataLayoutErrors` into `rustc_errors`
Addressed this suggestion https://github.com/rust-lang/rust/pull/101558#issuecomment-1243830009.
This way we comply with the Coherence rule given that `IntoDiagnostic` trait is defined in `rustc_errors`, and almost all other crates depend on it.
Support default-body trait functions with return-position `impl Trait` in traits
Introduce a new `Trait` candidate kind for the `ImplTraitInTrait` projection candidate, which just projects an RPITIT down to its opaque type form.
This is a hack until we lower RPITITs to regular associated types, after which we will need to rework how these default bodies are type-checked, so comments are left in a few places for us to clean up later.
Fixes#101665
Check representability in adt_sized_constraint
Now that representability is a query, we can use it to preemptively avoid a cycle in `adt_sized_constraint`.
I moved the representability check into `check_mod_type_wf` to avoid a scenario where rustc quits before checking all the types for representability. This also removes the check from rustdoc, which is alright AFAIK.
r? ``@cjgillot``
Migrate rustc_passes diagnostics
Picks up abandoned work from https://github.com/rust-lang/rust/pull/100870
I would like to do this collaboratively, as there is a lot of work! Here's the process:
- Comment below that you are willing to help and I will add you as a collaborator to my `rust` fork (that gives you write access)
- Indicate which file/task you would like to work on (so we don't duplicate work) from the list below
- Do the work, push up a commit, comment that you're done with that file/task
- Repeat until done 😄
### Files to Migrate (in `compiler/rustc_passes/src/`)
- [x] check_attr.rs ``@CleanCut``
- [x] check_const.rs ``@CleanCut``
- [x] dead.rs ``@CleanCut``
- [x] debugger_visualizer.rs ``@CleanCut``
- [x] diagnostic_items.rs ``@CleanCut``
- [x] entry.rs ``@CleanCut``
- [x] lang_items.rs ``@CleanCut``
- [x] layout_test.rs ``@CleanCut``
- [x] lib_features.rs ``@CleanCut``
- [x] ~liveness.rs~ ``@CleanCut`` Nothing to do
- [x] loops.rs ``@CleanCut``
- [x] naked_functions.rs ``@CleanCut``
- [x] stability.rs ``@CleanCut``
- [x] weak_lang_items.rs ``@CleanCut``
### Tasks
- [x] Rebase on current `master` ``@CleanCut``
- [x] Review work from [the earlier PR](https://github.com/rust-lang/rust/pull/100870) and make sure it all looks good
- [x] compiler/rustc_error_messages/locales/en-US/passes.ftl ``@CleanCut``
- [x] compiler/rustc_passes/src/check_attr.rs ``@CleanCut``
- [x] compiler/rustc_passes/src/errors.rs ``@CleanCut``
- [x] compiler/rustc_passes/src/lang_items.rs ``@CleanCut``
- [x] compiler/rustc_passes/src/lib.rs ``@CleanCut``
- [x] compiler/rustc_passes/src/weak_lang_items.rs ``@CleanCut``
