Add test cases for issue #26186Closes#26186
It seems that issue #26186 has been solved at some point since the issue has been last updated. I've merged together the examples that were supplied by `@Osspial,` `@Mark-Simulacrum,` `@Diggsey,` `@eefriedman` and `@shepmaster,` so that we can add this to the testing suite and prevent these issues from re-occurring.
Relax priv-in-pub lint on generic bounds and where clauses of trait impls.
The priv-in-pub lint is a legacy mechanism of the compiler, supplanted by a reachability-based [type privacy](https://github.com/rust-lang/rfcs/blob/master/text/2145-type-privacy.md) analysis. This PR does **not** relax type privacy; it only relaxes the lint (as proposed by the type privacy RFC) in the case of trait impls.
## Current Behavior
On public trait impls, it's currently an **error** to have a `where` bound constraining a private type with a trait:
```rust
pub trait Trait {}
pub struct Type {}
struct Priv {}
impl Trait for Priv {}
impl Trait for Type
where
Priv: Trait // ERROR
{}
```
...and it's a **warning** to have have a public type constrained by a private trait:
```rust
pub trait Trait {}
pub struct Type {}
pub struct Pub {}
trait Priv {}
impl Priv for Pub {}
impl Trait for Type
where
Pub: Priv // WARNING
{}
```
This lint applies to `where` clauses in other contexts, too; e.g. on free functions:
```rust
struct Priv<T>(T);
pub trait Pub {}
impl<T: Pub> Pub for Priv<T> {}
pub fn function<T>()
where
Priv<T>: Pub // WARNING
{}
```
**These constraints could be relaxed without issue.**
## New Behavior
This lint is relaxed for `where` clauses on trait impls, such that it's okay to have a `where` bound constraining a private type with a trait:
```rust
pub trait Trait {}
pub struct Type {}
struct Priv {}
impl Trait for Priv {}
impl Trait for Type
where
Priv: Trait // OK
{}
```
...and it's okay to have a public type constrained by a private trait:
```rust
pub trait Trait {}
pub struct Type {}
pub struct Pub {}
trait Priv {}
impl Priv for Pub {}
impl Trait for Type
where
Pub: Priv // OK
{}
```
## Rationale
While the priv-in-pub lint is not essential for soundness, it *can* help programmers avoid pitfalls that would make their libraries difficult to use by others. For instance, such a lint *is* useful for free functions; e.g. if a downstream crate tries to call the `function` in the previous snippet in a generic context:
```rust
fn callsite<T>()
where
Priv<T>: Pub // ERROR: omitting this bound is a compile error, but including it is too
{
function::<T>()
}
```
...it cannot do so without repeating `function`'s `where` bound, which we cannot do because `Priv` is out-of-scope. A lint for this case is arguably helpful.
However, this same reasoning **doesn't** hold for trait impls. To call an unconstrained method on a public trait impl with private bounds, you don't need to forward those private bounds, you can forward the public trait:
```rust
mod upstream {
pub trait Trait {
fn method(&self) {}
}
pub struct Type<T>(T);
pub struct Pub<T>(T);
trait Priv {}
impl<T: Priv> Priv for Pub<T> {}
impl<T> Trait for Type<T>
where
Pub<T>: Priv // WARNING
{}
}
mod downstream {
use super::upstream::*;
fn function<T>(value: Type<T>)
where
Type<T>: Trait // <- no private deets!
{
value.method();
}
}
```
**This PR only eliminates the lint on trait impls.** It leaves it intact for all other contexts, including trait definitions, inherent impls, and function definitions. It doesn't need to exist in those cases either, but I figured I'd first target a case where it's mostly pointless.
## Other Notes
- See discussion [on zulip](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/relax.20priv-in-pub.20lint.20for.20trait.20impl.20.60where.60.20bounds/near/222458397).
- This PR effectively reverts #79291.
Rustdoc: use `is_doc_hidden` method on more places
While profiling `rustdoc`, I noticed that finding out if some item is marked with `#[doc(hidden)]` is relatively hot, so I tried to optimize it.
I noticed that there is already a method called `is_doc_hidden` on `TyCtxt`, but it wasn't used much, so I replaced the manual calls to `attrs(...).has_word(...)` with this method. Just by doing that, perf. was improved locally, although I'm not sure if the semantics of the previous calls and this method are the same?
As another step, I tried to querify `is_doc_hidden`, but I didn't include that here until we see the perf. results from the first commit and until I find whether this change is OK at all :)
Can I ask for a perf. run? Thanks.
r? `@jyn514`
Do not display `~const Drop` in rustdoc
Although `T: ~const Drop` is still at an experimental stage, we have already begun inserting these bounds in libstd. This change hides them from rustdoc because 1. `~const` should not be documented in general as it is not yet official syntax; 2. users are not expected to know what `~const Drop` means yet.
All other 'containers' (e.g. `impl` blocks) hashed their contents
in the normal, order-dependent way. However, `Mod` was hashing
its contents in a (sort-of) order-independent way. However, the
exact order is exposed to consumers through `Mod.item_ids`,
and through query results like `hir_module_items`. Therefore,
stable hashing needs to take the order of items into account,
to avoid fingerprint ICEs.
Unforuntately, I was unable to directly build a reproducer
for the ICE, due to the behavior of `Fingerprint::combine_commutative`.
This operation swaps the upper and lower `u64` when constructing the
result, which makes the function non-associative. Since we start
the hashing of module items by combining `Fingerprint::ZERO` with
the first item, it's difficult to actually build an example where
changing the order of module items leaves the final hash unchanged.
However, this appears to have been hit in practice in #92218
While we're not able to reproduce it, the fact that proc-macros
are involved (which can give an entire module the same span, preventing
any span-related invalidations) makes me confident that the root
cause of that issue is our method of hashing module items.
This PR removes all of the special handling for `Mod`, instead deriving
a `HashStable` implementation. This makes `Mod` consistent with other
'contains' like `Impl`, which hash their contents through the typical
derive of `HashStable`.
CTFE eval_fn_call: use FnAbi to determine argument skipping and compatibility
This makes use of the `FnAbi` type in CTFE/Miri, which `@eddyb` has been saying for years is what we should do.^^ `FnAbi` is used to
- determine which arguments to skip (rather than the previous heuristic of skipping ZST arguments with the Rust ABI)
- impose further restrictions on whether caller and callee are consistent in how a given argument is passed
I was hoping it would also simplify the code, but that is not the case -- the previous type compatibility checks are still required (AFAIK), only the ZST skipping is gone and that took barely any code. We also need some hacks because `FnAbi` assumes a certain way of implementing `caller_location` (by passing extra arguments), but Miri can just read the caller location from the call stack so it doesn't need those arguments. (The fact that every backend has to separately implement support for these arguments seems suboptimal -- looks like this might have been better implemented on the MIR level.) To avoid having to implement those unnecessary arguments in Miri, we just compute *whether* the argument is present on the caller/callee side, but don't actually pass that argument around.
I have no idea if this looks the way `@eddyb` thinks it should look... but it makes Miri's test suite pass. ;)
One of rustc's tests fails unfortunately (`ui/const-generics/issues/issue-67739.rs`), some const generic code that is evaluated too early -- I think that should raise `TooGeneric` but instead it ICEs. My assumption is this is some FnAbi code that has not been properly tested on polymorphic code, but it might also be me calling that FnAbi code the wrong way.
r? `@oli-obk` `@eddyb`
Fixes https://github.com/rust-lang/rust/issues/56166
Miri PR at https://github.com/rust-lang/miri/pull/1928
Remove useless `#[global_allocator]` from rustc and rustdoc.
This was added in #83152, which has several errors in its comments.
This commit also fix up the comments, which are quite wrong and
misleading.
r? `@alexcrichton`
Rollup of 5 pull requests
Successful merges:
- #90625 (Add `UnwindSafe` to `Once`)
- #92121 (disable test with self-referential generator on Miri)
- #92166 (Fixed a small typo in ui test comments)
- #92203 (Store a `DefId` instead of an `AdtDef` in `AggregateKind::Adt`)
- #92231 (Update books)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Fixes#92163Fixes#92014
When writing to the incremental cache, we encode all `Span`s
we encounter, regardless of whether or not their `SourceFile`
comes from the local crate, or from a foreign crate.
When we decode a `Span`, we use the `StableSourceFileId` we encoded
to locate the matching `SourceFile` in the current session. If this
id corresponds to a `SourceFile` from another crate, then we need to
have already imported that `SourceFile` into our current session.
This usually happens automatically during resolution / macro expansion,
when we try to resolve definitions from other crates. In certain cases,
however, we may try to load a `Span` from a transitive dependency
without having ever imported the `SourceFile`s from that crate, leading
to an ICE.
This PR fixes the issue by calling `imported_source_files()`
when we encounter a `SourceFile` with a foreign `CrateNum`.
This ensures that all `SourceFile`s from that crate are imported
into the current session.
Update books
## nomicon
1 commits in 49681ea4a9fa81173dbe9ffed74b4d4a35eae9e3..c05c452b36358821bf4122f9c418674edd1d713d
2021-11-24 16:27:28 +0900 to 2021-12-13 15:23:48 +0900
- Update the guidance on uninitialized data with ptr::addr_of_mut (rust-lang/nomicon#325)
## reference
3 commits in 954f3d441ad880737a13e241108f791a4d2a38cd..06f9e61931bcf58b91dfe6c924057e42ce273ee1
2021-11-29 11:11:30 -0800 to 2021-12-17 07:31:40 -0800
- keep consistent for primitive types (rust-lang/reference#1118)
- README.md: link to mdbook docs (rust-lang/reference#1117)
- Say that `...` range patterns are rejected in the 2021 edition (rust-lang/reference#1114)
## book
4 commits in 5f9358faeb1f46e19b8a23a21e79fd7fe150491e..8a0bb3c96e71927b80fa2286d7a5a5f2547c6aa4
2021-12-05 21:33:16 -0500 to 2021-12-22 20:54:27 -0500
- Propagate edits back
- Fix number disagreement. Fixesrust-lang/book#2858.
- Wrap some code in main to make scopes clearer. Fixesrust-lang/book#2830.
- Respond to ch5 nostarch edits
## rustc-dev-guide
9 commits in a374e7d8bb6b79de45b92295d06b4ac0ef35bc09..9bf0028b557798ddd07a6f652e4d0c635d3d6620
2021-12-03 09:26:47 -0800 to 2021-12-20 21:53:57 +0900
- remove rustfix item in test intro (rust-lang/rustc-dev-guide#1277)
- Move date-check comment to fix Markdown syntax
- Update humor docs for special-casing ferris emoji
- Fix some broken links (rust-lang/rustc-dev-guide#1274)
- Update rustdoc internals
- Update HIR chapter to use `HirId` instead of `NodeId`
- Fix some broken links
- Update src/getting-started.md
- Improve documentation on r?
Backport LLVM changes to disable deferred inlining
Fixes#91128
I was thinking of how to best add the test case from the issue, and I think rust perf infrastructure would probably be the best place for something like it.
Update chalk to 0.75.0
- Compute flags in `intern_ty`
- Remove `tracing-serde` from `PERMITTED_DEPENDENCIES`
- Bump `tracing-tree` to 0.2.0
- Bump `tracing-subscriber` to 0.3.3
David Tolnay