For non-incremental builds on Unix, currently all the thread names look
like `opt regex.f10ba03eb5ec7975-cgu.0`. But they are truncated by
`pthread_setname` to `opt regex.f10ba`, hiding the numeric suffix that
distinguishes them. This is really annoying when using a profiler like
Samply.
This commit changes these thread names to a form like `opt cgu.0`, which
is much better.
Currently there are two problems.
First, the CGUS don't end up in size order. The merging loop does sort
by size on each iteration, but we don't sort after the final merge, so
typically there is one CGU out of place. (And sometimes we don't enter
the merging loop at all, in which case they end up in random order.)
Second, we then assign names that differ only by a numeric suffix, and
then we sort them lexicographically by name, giving us an order like
this:
regex.f10ba03eb5ec7975-cgu.1
regex.f10ba03eb5ec7975-cgu.10
regex.f10ba03eb5ec7975-cgu.11
regex.f10ba03eb5ec7975-cgu.12
regex.f10ba03eb5ec7975-cgu.13
regex.f10ba03eb5ec7975-cgu.14
regex.f10ba03eb5ec7975-cgu.15
regex.f10ba03eb5ec7975-cgu.2
regex.f10ba03eb5ec7975-cgu.3
regex.f10ba03eb5ec7975-cgu.4
regex.f10ba03eb5ec7975-cgu.5
regex.f10ba03eb5ec7975-cgu.6
regex.f10ba03eb5ec7975-cgu.7
regex.f10ba03eb5ec7975-cgu.8
regex.f10ba03eb5ec7975-cgu.9
These two problems are really annoying when debugging and profiling the
CGUs.
This commit ensures CGUs are sorted by name *and* reverse sorted by
size. This involves (a) one extra sort by size operation, and (b)
padding the numeric indices with zeroes, e.g.
`regex.f10ba03eb5ec7975-cgu.01`.
(Note that none of this applies for incremental builds, where a
different hash-based CGU naming scheme is used.)
Revert "Structurally resolve correctly in check_pat_lit"
This reverts commit 54fb5a48b9. Also adds a couple of tests, and downgrades the existing `-Ztrait-solver=next` test to a known-bug.
Fixes#112993
Add translatable diagnostic for cannot be reexported error
also added for subdiagnostics
Add translatable diagnostics for resolve_glob_import errors
Add translatable diag for unable to determine import resolution
Add translatable diag for is not directly importable
[-Ztrait-solver=next, mir-typeck] instantiate hidden types in the root universe
Fixes an ICE in the test `member-constraints-in-root-universe`.
Main motivation is to make #112691 pass under the new solver.
r? ``@compiler-errors``
Fix return type notation associated type suggestion when -Zlower-impl-trait-in-trait-to-assoc-ty
This avoid suggesting the associated types generated for RPITITs when the one the code refers to doesn't exist and rustc looks for a suggestion.
r? `@compiler-errors`
Fix return type notation errors with -Zlower-impl-trait-in-trait-to-assoc-ty
This just adjust the way we check for RPITITs and uses the new helper method to do the "old" and "new" check at once.
r? `@compiler-errors`
Don't emit same goal as input during `wf::unnormalized_obligations`
r? `@aliemjay` cc `@lcnr`
I accidentally pruned the logic to handle `WF(?0)` when writing `wf::unnormalized_obligations`.
idk if you wanted to construct a test first, but this is an obvious fix. Copied the comment from above.
Fixesrust-lang/trait-system-refactor-initiative#36
Stop bubbling out hidden types from the eval obligation queries
r? `@compiler-errors`
I don't know why these were added, but they are not needed anymore. The relevant test is unaffected and I didn't see anything interesting in logging that would have justified it.
This PR has no effect on the new solver behaviour of cf2dff2b1e/tests/ui/impl-trait/issue-99642.rs (which is overflow) and cf2dff2b1e/tests/ui/impl-trait/issue-99642-2.rs (which is "unstable certainty ICE")
Various impl trait in assoc tys cleanups
r? `@compiler-errors`
All commits except for the last are pure refactorings. 274dab5bd658c97886a8987340bf50ae57900c39 allows struct fields to participate in deciding whether a function has an opaque in its signature.
best reviewed commit by commit
Stop hiding const eval limit in external macros
fixes#112748
We don't emit a hard error if there was a previous deny lint triggering with the same message. If that lint ends up not being emitted, we ICE and don't emit an error either.
Migrate `item_bounds` to `ty::Clause`
Should be simpler than the next PR that's coming up. Last three commits are the relevant ones.
r? ``@oli-obk`` or ``@lcnr``
Don't ICE on unnormalized struct tail in layout computation
1. We try to compute a `SizeSkeleton` even if a layout error occurs, but we really only need to do this if we get `LayoutError::Unknown`, since that means our type is too polymorphic to actually compute the full layout. If we have other errors, like `LayoutError::NormalizationError` or `LayoutError::Cycle`, then we can't really make any progress, since this represents an actual error.
2. Avoid using `normalize_erasing_regions` and `struct_tail_erasing_lifetimes` since those ICE on normalization errors, and since we may call `layout_of` in HIR typeck, we don't know for certain that we're on the happy path.
Fixes#112736
Always register sized obligation for argument
Removes a "hack" that skips registering sized obligations for parameters that are simple identifiers. This doesn't seem to affect diagnostics because we're probably already being smart enough about deduplicating identical error messages anyways.
Fixes#112608
rustc_session: default to -Z plt=yes on non-x86_64
Per the discussion in #106380 plt=no isn't a great default, and rust-lang/compiler-team#581 decided that the default should be PLT=yes for everything except x86_64. Not everyone agrees about the x86_64 part of this change, but this at least is an improvement in the state of things without changing the x86_64 situation, so I've attempted making this change in the name of not letting the perfect be the enemy of the good.
Please let me know if I've messed this up somehow - I'm not wholly confident I got this right.
r? `@nikic`
Avoid guessing unknown trait implementation in suggestions
When a trait is used without specifying the implementation (e.g. calling a non-member associated function without fully-qualified syntax) and there are multiple implementations available, use a placeholder comment for the implementation type in the suggestion instead of picking a random implementation.
Example:
```
fn main() {
let _ = Default::default();
}
```
Previous output:
```
error[E0790]: cannot call associated function on trait without specifying the corresponding `impl` type
--> test.rs:2:13
|
2 | let _ = Default::default();
| ^^^^^^^^^^^^^^^^ cannot call associated function of trait
|
help: use a fully-qualified path to a specific available implementation (273 found)
|
2 | let _ = <FileTimes as Default>::default();
| +++++++++++++ +
```
New output:
```
error[E0790]: cannot call associated function on trait without specifying the corresponding `impl` type
--> test.rs:2:13
|
2 | let _ = Default::default();
| ^^^^^^^^^^^^^^^^ cannot call associated function of trait
|
help: use a fully-qualified path to a specific available implementation (273 found)
|
2 | let _ = </* self type */ as Default>::default();
| +++++++++++++++++++ +
```
Fixes#112897
Don't structurally resolve during method ambiguity in probe
See comment in UI test for reason for the failure. This is all on the error path anyways, not really sure what the assertion is there to achieve anyways...
Fixes#111739
When a trait is used without specifying the implementation (e.g. calling
a non-member associated function without fully-qualified syntax) and
there are multiple implementations available, use a placeholder comment
for the implementation type in the suggestion instead of picking a
random implementation.
Example:
```
fn main() {
let _ = Default::default();
}
```
Previous output:
```
error[E0790]: cannot call associated function on trait without specifying the corresponding `impl` type
--> test.rs:2:13
|
2 | let _ = Default::default();
| ^^^^^^^^^^^^^^^^ cannot call associated function of trait
|
help: use a fully-qualified path to a specific available implementation (273 found)
|
2 | let _ = <FileTimes as Default>::default();
| +++++++++++++ +
```
New output:
```
error[E0790]: cannot call associated function on trait without specifying the corresponding `impl` type
--> test.rs:2:13
|
2 | let _ = Default::default();
| ^^^^^^^^^^^^^^^^ cannot call associated function of trait
|
help: use a fully-qualified path to a specific available implementation (273 found)
|
2 | let _ = </* self type */ as Default>::default();
| +++++++++++++++++++ +
```
Per the discussion in #106380 plt=no isn't a great default, and
rust-lang/compiler-team#581 decided that the default should be PLT=yes
for everything except x86_64. Not everyone agrees about the x86_64 part
of this change, but this at least is an improvement in the state of
things without changing the x86_64 situation, so I've attempted making
this change in the name of not letting the perfect be the enemy of the
good.
Account for sealed traits in privacy and trait bound errors
On trait bound errors caused by super-traits, identify if the super-trait is publicly accessibly and if not, explain "sealed traits".
```
error[E0277]: the trait bound `S: Hidden` is not satisfied
--> $DIR/sealed-trait-local.rs:17:20
|
LL | impl a::Sealed for S {}
| ^ the trait `Hidden` is not implemented for `S`
|
note: required by a bound in `Sealed`
--> $DIR/sealed-trait-local.rs:3:23
|
LL | pub trait Sealed: self:🅱️:Hidden {
| ^^^^^^^^^^^^^^^ required by this bound in `Sealed`
= note: `Sealed` is a "sealed trait", because to implement it you also need to implelement `a:🅱️:Hidden`, which is not accessible; this is usually done to force you to use one of the provided types that already implement it
```
Deduplicate privacy errors that point to the same path segment even if their deduplication span are different.
When encountering a path that is not reachable due to privacy constraints path segments other than the last, keep metadata for the last path segment's `Res` in order to look for alternative import paths for that item to suggest. If there are none, be explicit that the item is not accessible.
```
error[E0603]: module `b` is private
--> $DIR/re-exported-trait.rs:11:9
|
LL | impl a:🅱️:Trait for S {}
| ^ private module
|
note: the module `b` is defined here
--> $DIR/re-exported-trait.rs:5:5
|
LL | mod b {
| ^^^^^
help: consider importing this trait through its public re-export instead
|
LL | impl a::Trait for S {}
| ~~~~~~~~
```
```
error[E0603]: module `b` is private
--> $DIR/private-trait.rs:8:9
|
LL | impl a:🅱️:Hidden for S {}
| ^ ------ trait `b` is not publicly reachable
| |
| private module
|
note: the module `b` is defined here
--> $DIR/private-trait.rs:2:5
|
LL | mod b {
| ^^^^^
```
Suggest publicly accessible paths for items in private mod:
When encountering a path in non-import situations that are not reachable
due to privacy constraints, search for any public re-exports that the
user could use instead.
Track whether an import suggestion is offering a re-export.
When encountering a path with private segments, mention if the item at
the final path segment is not publicly accessible at all.
Add item visibility metadata to privacy errors from imports:
On unreachable imports, record the item that was being imported in order
to suggest publicly available re-exports or to be explicit that the item
is not available publicly from any path.
In order to allow this, we add a mode to `resolve_path` that will not
add new privacy errors, nor return early if it encounters one. This way
we can get the `Res` corresponding to the final item in the import,
which is used in the privacy error machinery.
When implementing a public trait with a private super-trait, we now emit
a note that the missing bound is not going to be able to be satisfied,
and we explain the concept of a sealed trait.
Avoid `Lrc<Box<dyn CodegenBackend>>`.
Because `Lrc<Box<T>>` is silly. (Clippy warns about `Rc<Box<T>>` and `Arc<Box<T>>`, and it would warn here if (a) we used Clippy with rustc, and (b) Clippy knew about `Lrc`.)
r? `@bjorn3`
Inline before merging cgus
Because CGU merging relies on CGU sizes, but the CGU sizes before inlining aren't accurate.
This change doesn't have much effect on compile perf, but it makes follow-on changes that involve more sophisticated reasoning about CGU sizes much easier.
r? `@wesleywiser`
Rollup of 4 pull requests
Successful merges:
- #112876 (Don't substitute a GAT that has mismatched generics in `OpaqueTypeCollector`)
- #112906 (rustdoc: render the body of associated types before the where-clause)
- #112907 (Update cargo)
- #112908 (Print def_id on EarlyBoundRegion debug)
r? `@ghost`
`@rustbot` modify labels: rollup
Print def_id on EarlyBoundRegion debug
It's not the first time that I can't make sense out of the default debug print on `EarlyBoundRegion`. As I was working on #112682 I needed this.
I was doing some git archeology and found that we used to print everything dfbc9608ce/src/librustc/util/ppaux.rs (L425-L430) but we lost the ability in some refactor midway.
Don't substitute a GAT that has mismatched generics in `OpaqueTypeCollector`
Fixes#111828
I didn't put up minimized UI tests for #112510 or #112873 because they'd minimize to literally the same code, but with different substs on the trait/impl. I don't think that warrants duplicate tests given the nature of the fix.
r? `@oli-obk`
----
Side-note: I checked, and this isn't fixed by #112652 -- I think we discussed whether or not that PR fixed it either intentionally or by accident. The code here isn't really touched by that PR either as far as I can tell?
Also, sorry, did some other drive-bys. Hope it doesn't make rebasing #112652 too difficult 😅
- Rename `create_size_estimate` as `compute_size_estimate`, because that
makes more sense for the second and subsequent calls for each CGU.
- Change `CodegenUnit::size_estimate` from `Option<usize>` to `usize`.
We can still assert that `compute_size_estimate` is called first.
- Move the size estimation for `place_mono_items` inside the function,
for consistency with `merge_codegen_units`.
Because `Lrc<Box<T>>` is silly. (Clippy warns about `Rc<Box<T>>` and
`Arc<Box<T>>`, and it would warn here if (a) we used Clippy with rustc,
and (b) Clippy knew about `Lrc`.)
The codegen main loop has two bools, `codegen_done` and
`codegen_aborted`. There are only three valid combinations: `(false,
false)`, `(true, false)`, `(true, true)`.
This commit replaces them with a single tri-state enum, which makes
things clearer.
Support Apple tvOS in libstd
This target has existed in the compiler for a while, was `no_std`-only previously (even requiring `#![feature(restricted_std)]`). Apple tvOS is essentially the same as iOS, down to using the same version numbering, so there's no reason for this to be a `no_std`-only target the way it is currently.
Not yet tested much (I have an Apple TV, but haven't tested that this can deploy and run programs on it, nor the simulator). Uses the implementation strategy as the watchOS support in https://github.com/rust-lang/rust/pull/98101 and etc. That is, no `std::os::` interfaces aside from those in `std::os::unix`.
Includes an update to libc in order to pull in https://github.com/rust-lang/libc/pull/2958.
Because CGU merging relies on CGU sizes, but the CGU sizes before
inlining aren't accurate.
This requires tweaking how the sizes are updated during merging: if CGU
A and B both have an inlined function F, then `size(A + B)` will be a
little less than `size(A) + size(B)`, because `A + B` will only have one
copy of F. Also, the minimum CGU size is increased because it now has to
account for inlined functions.
This change doesn't have much effect on compile perf, but it makes
follow-on changes that involve more sophisticated reasoning about CGU
sizes much easier.
`Message` is an enum with multiple variants. Four of those variants map
directly onto the four variants of `WorkItemResult`. This commit reduces
those four `Message` variants to a single variant containing a
`WorkItemResult`. This requires increasing `WorkItemResult`'s visibility
to `pub(crate)` visibility, but `WorkItem` and `Message` can also have
their visibility reduced to `pub(crate)`.
This change avoids some boilerplate enum translation code, and makes
`Message` easier to understand.
`Message` is an enum with multiple variants, for messages sent to the
coordinator thread. *Except* for `Message::CodegenItem`, which is
entirely disjoint, being for messages sent from the coordinator thread
to the main thread.
This commit move `Message::CodegenItem` into a separate type,
`CguMessage`, which makes the code much clearer.
resolve: Minor cleanup to `fn resolve_path_with_ribs`
A single-use closure is inlined and one unnecessary enum is removed.
Noticed when reviewing https://github.com/rust-lang/rust/pull/112686.
Removed unnecessary &String -> &str, now that &String implements StableOrd as well
Applied a few nits suggested by lcnr to PR #110040 (nits can be found [here](https://github.com/rust-lang/rust/pull/110040#pullrequestreview-1469452191).)
Making a new PR because the old one was already merged, and given that this just applies changes that were already suggested, reviewing it should be fairly open-and-shut.
Make queries traceable again
This can't be tested without something along the lines of https://github.com/rust-lang/rust/pull/111924 unfortunately.
We could benchmark turning query tracing into an `info` level tracing statement, but let's get this fix landed first so we can actually debug properly again
Add `lazy_type_alias` feature gate
Add the `type_alias_type` to be able to have the weak alias used without restrictions.
Part of #112792.
cc `@compiler-errors`
r? `@oli-obk`
Add retag in MIR transform: `Adt` for `Unique` may contain a reference
Following #112662 , `may_contain_reference` in `rustc_mir_transform::add_retag` underapproximates too much the types that require retagging.
r? ``@RalfJung``
Syntactically accept `become` expressions (explicit tail calls experiment)
This adds `ast::ExprKind::Become`, implements parsing and properly gates the feature.
cc `@scottmcm`
Add a fully fledged `Clause` type, rename old `Clause` to `ClauseKind`
Does two basic things before I put up a more delicate set of PRs (along the lines of #112714, but hopefully much cleaner) that migrate existing usages of `ty::Predicate` to `ty::Clause` (`predicates_of`/`item_bounds`/`ParamEnv::caller_bounds`).
1. Rename `Clause` to `ClauseKind`, so it's parallel with `PredicateKind`.
2. Add a new `Clause` type which is parallel to `Predicate`.
* This type exposes `Clause::kind(self) -> Binder<'tcx, ClauseKind<'tcx>>` which is parallel to `Predicate::kind` 😸
The new `Clause` type essentially acts as a newtype wrapper around `Predicate` that asserts that it is specifically a `PredicateKind::Clause`. Turns out from experimentation[^1] that this is not negative performance-wise, which is wonderful, since this a much simpler design than something that requires encoding the discriminant into the alignment bits of a predicate kind, or something else like that...
r? ``@lcnr`` or ``@oli-obk``
[^1]: https://github.com/rust-lang/rust/pull/112714#issuecomment-1595653910
Merge `BorrowKind::Unique` into `BorrowKind::Mut`
Fixes#112072
Might have conflict with #112070
r? `@lcnr`
I'm not sure what's the suitable change in a couple places.
There's no need to store it in `Queries`. We can just use a local
variable, because it's always used shortly after it's produced.
The commit also removes the `tcx.analysis()` call in `ongoing_codegen`,
because it's easy to ensure that's done beforehand.
All this makes the dataflow within `run_compiler` easier to follow, at
the cost of making one test slightly more verbose, which I think is a
good tradeoff.
The only regression is one ambiguity in the new trait solver, having to
do with two param-env candidates that may apply. I think this is fine,
since the error message already kinda sucks.
Revert #112758 and add test case
Fixes#112831.
Cannot unwrap `update_resolution` for `resolution.single_imports.remove(&Interned::new_unchecked(import));` because there is a relationship between the `Import` and `&NameBinding` in `NameResolution`. This issue caused by my unfamiliarity with the data structure and I apologize for it.
This PR had been reverted, and test case have been added.
r? `@Nilstrieb`
cc `@petrochenkov`
Sort the errors from arguments checking so that suggestions are handled properly
Fixes#112507
The algorithm of `find_issue` does not make sure the index comes out in order, which will make suggesting `remove` or `add` arguments broken in some cases.
Modifying the algorithm to obey order involves much more trivial change, so it's better to order the `errors` after iterations.
Add `implement_via_object` to `rustc_deny_explicit_impl` to control object candidate assembly
Some built-in traits are special, since they are used to prove facts about the program that are important for later phases of compilation such as codegen and CTFE. For example, the `Unsize` trait is used to assert to the compiler that we are able to unsize a type into another type. It doesn't have any methods because it doesn't actually *instruct* the compiler how to do this unsizing, but this is later used (alongside an exhaustive match of combinations of unsizeable types) during codegen to generate unsize coercion code.
Due to this, these built-in traits are incompatible with the type erasure provided by object types. For example, the existence of `dyn Unsize<T>` does not mean that the compiler is able to unsize `Box<dyn Unsize<T>>` into `Box<T>`, since `Unsize` is a *witness* to the fact that a type can be unsized, and it doesn't actually encode that unsizing operation in its vtable as mentioned above.
The old trait solver gets around this fact by having complex control flow that never considers object bounds for certain built-in traits:
2f896da247/compiler/rustc_trait_selection/src/traits/select/candidate_assembly.rs (L61-L132)
However, candidate assembly in the new solver is much more lovely, and I'd hate to add this list of opt-out cases into the new solver. Instead of maintaining this complex and hard-coded control flow, instead we can make this a property of the trait via a built-in attribute. We already have such a build attribute that's applied to every single trait that we care about: `rustc_deny_explicit_impl`. This PR adds `implement_via_object` as a meta-item to that attribute that allows us to opt a trait out of object-bound candidate assembly as well.
r? `@lcnr`
Don't consider TAIT normalizable to hidden ty if it would result in impossible item bounds
See test for example where we shouldn't consider it possible to alias-relate a TAIT and hidden type.
r? `@lcnr`
Don't ICE on bound var in `reject_fn_ptr_impls`
We may try to use an impl like `impl<T: FnPtr> PartialEq {}` to satisfy a predicate like `for<T> T: PartialEq` -- don't ICE in that case.
Fixes#112735
Treat TAIT equation as always ambiguous in coherence
Not sure why we weren't treating all TAIT equality as ambiguous -- this behavior combined with `DefineOpaqueTypes::No` leads to coherence overlap failures, since we incorrectly consider impls as not overlapping because the obligation `T: From<Foo>` doesn't hold.
Fixes#112765
Continue folding in query normalizer on weak aliases
Fixes#112752Fixes#112731 (same root cause, so didn't make a test for it)
fixes#112776
r? ```@oli-obk```
Rewrite various resolve/diagnostics errors as translatable diagnostics
additional question:
For trivial strings is it ever accepted to use `fluent_generated::foo` in a `label` for example? Or is an empty struct `Diagnostic` preferred?
`#[test]` function signature verification improvements
This PR contains two improvements to the expansion of the `#[test]` macro.
The first one fixes https://github.com/rust-lang/rust/issues/112360 by correctly recovering item statements if the signature verification fails.
The second one forbids non-lifetime generics on `#[test]` functions. These were previously allowed if the function returned `()`, but always caused an inference error:
before:
```text
error[E0282]: type annotations needed
--> src/lib.rs:2:1
|
1 | #[test]
| ------- in this procedural macro expansion
2 | fn foo<T>() {}
| ^^^^^^^^^^^^^^ cannot infer type
```
after:
```text
error: functions used as tests can not have any non-lifetime generic parameters
--> src/lib.rs:2:1
|
2 | fn foo<T>() {}
| ^^^^^^^^^^^^^^
```
Also includes some basic tests for test function signature verification, because I couldn't find any (???) in the test suite.
make mir dataflow graphviz dumps opt-in
This should save some MIR traversals and allocations that are not really needed.
Small win but noticeable locally. Let's see what LTO/PGO say.
r? `@ghost`
refactor(resolve): delete update_resolution function
The `{ resolution.single_imports.remove(); }` code block does not modify the `binding` of this `resolution`. Therefore, the result of `resolution.binding()` before and after `let t = f(self, resolution)` will remain the same, and it will always satisfy the result: `_ if old_binding.is_some() => return t` or `None => return t`.
And then we delete the `update_resolution` function because it only called once.
r? ``@petrochenkov``
Don't record adjustments twice in `note_source_of_type_mismatch_constraint`
We call `lookup_method` a few times in `note_source_of_type_mismatch_constraint`, but that function has side-effects to the typeck results. Replace it with a less side-effect-y variant of the function for use in diagnostics.
Specifically the ICE in #112532 happens because we're recording deref adjustments twice for a call receiver, which causes `ExprUseVisitor` to be angry.
Fixes#112532
Don't capture `&[T; N]` when contents isn't read
Fixes the check in #111831Fixes#112607, although I decided to test the root cause rather than including the example in the issue as a test.
cc `@BoxyUwU`
Switch the BB CFG cache from postorder to RPO
The `BasicBlocks` CFG cache is interesting:
- it stores a postorder, but `traversal::postorder` doesn't use it
- `traversal::reverse_postorder` does traverse the postorder cache backwards
- we do more RPO traversals than postorder traversals (around 20x on the perf.rlo benchmarks IIRC) but it's not cached
- a couple places here and there were manually reversing the non-cached postorder traversal
This PR switches the order of the cache, and makes a bit more use of it. This is a tiny win locally, but it's also for consistency and aesthetics.
r? `@ghost`
Make `Bound::predicates` use `Clause`
Part of #107250
`Bound::predicates` returns an iterator over `Binder<_, Clause>` instead of `Predicate`.
I tried updating `explicit_predicates_of` as well, but it seems that it needs a lot more change than I thought. Will do it in a separate PR instead.
