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`.)
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.
Fix union fields display
![Screenshot from 2023-06-21 16-47-24](https://github.com/rust-lang/rust/assets/3050060/833b0fe6-7fb6-4371-86c3-d82fa0c3fe49)
So two bugs in this screenshot: no whitespace between field name and type name, both fields are on the same line. Both problems come from issues in the templates because all whitespace are removed if a askama "command" follows.
r? `@notriddle`
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.
Warn on unused `offset_of!()` result
The usage of `core::hint::must_use()` means that we don't get a specialized message. I figured out that since there are plenty of other methods that just have `#[must_use]` with no message it'll be fine, but it is a bit unfortunate that the error mentions `must_use` and not `offset_of!`.
Fixes#111669.