Fix bad intra-doc-link preprocessing
How did rust-lang/rust#147981 happen?
1. We don't parse intra-doc links as Rust paths or qpaths. Instead they follow a very lenient bespoke grammar. We completely ignore Markdown links if they contain characters that don't match `/[a-zA-Z0-9_:<>, !*&;]/` (we don't even emit lint *broken-intra-doc-links* for these).
2. PR [#132748](https://github.com/rust-lang/rust/pull/132748) made rustdoc intepret more Markdown links as potential intra-doc links. Namely, if the link is surrounded by backticks (and some other conditions apply) then it doesn't matter if the (partially processed) link contains bad characters as defined above (cc `ignore_urllike && should_ignore_link(path_str)`).
3. However, rustdoc's `preprocess_link` must be kept in sync with a simplified counterpart in rustc. More specifically, whenever rustdoc's preprocessor returns a successful result then rustc's must yield the same result. Otherwise, rustc doesn't resolve the necessary links for rustdoc.
4. This uncovered a "dormant bug" / "mistake" in rustc's `preprocess_link`. Namely, when presented with a link like `struct@Type@suffix`, it didn't cut off the disambiguator if present (here: `struct@`). Instead it `rsplit('``@')``` which is incorrect if the "path" contains ```@``` itself (yielding `suffix` instead of `Type@suffix` here). Prior to PR [#132748](https://github.com/rust-lang/rust/pull/132748), a link like ``[`struct@Type@suffix`]`` was not considered a potential intra-doc link / worth querying rustc for. Now it is due to the backticks.
5. Finally, since rustc didn't record a resolution for `Type@suffix` (it only recorded `suffix` (to be `Res::Err`)), we triggered an assertion we have in place to catch cases like this.
Fixesrust-lang/rust#147981.
I didn't and still don't have the time to investigate if rust-lang/rust#132748 led to more rustc/rustdoc mismatches (after all, the PR made rustdoc's `preprocess_link` return `Some(Ok(_))` in more cases). I've at least added another much needed "warning banner" & made the existing one more flashy.
While this fixes a stable-to-beta regression, I don't think it's worth beta backporting, esp. since it's only P-medium and since the final 1.91 release steps commence today / the next days, so it would only be stressful to get it in on time. However, feel free to nominate.
<sub>(I've written such a verbose PR description since I tend to reread my old PR descriptions in the far future to fully freshen my memories when I have to work again in this area)</sub>
r? ``@lolbinarycat``
Add a diagnostic attribute for special casing const bound errors for non-const impls
Somewhat of a follow-up to https://github.com/rust-lang/rust/pull/144194
My plan is to resolve
f4e19c6878/compiler/rustc_hir_typeck/src/callee.rs (L907-913)
but doing so without being able to mark impls the way I do in this PR wrould cause all nice diagnostics about for loops and pointer comparisons to just be a `*const u32 does not implement [const] PartialEq` errors.
There are only two call sites, and three of the arguments are identical
at both call sites. This commit removes those arguments and renames the
method accordingly.
Special case detecting `'static` lifetime requirement coming from `-> Box<dyn Trait>`
```
error[E0310]: the parameter type `R` may not live long enough
--> $DIR/implicit-static-lifetime-in-dyn-trait-return-type.rs:10:5
|
LL | fn bb<R>(r: R) -> Box<dyn Foo> {
| ------- this `dyn Trait` has an implicit `'static` lifetime bound
LL | Box::new(Bar(r))
| ^^^^^^^^^^^^^^^^
| |
| the parameter type `R` must be valid for the static lifetime...
| ...so that the type `R` will meet its required lifetime bounds
|
help: consider adding an explicit lifetime bound
|
LL | fn bb<R: 'static>(r: R) -> Box<dyn Foo> {
| +++++++++
```
Partly address rust-lang/rust#41966 and rust-lang/rust#54753. rust-lang/rust#103849, which shows a case where there's an intermediary binding, is not addressed at all, as aren't cases *other* than `Box<dyn Trait>` return type.
Add note for identifier with attempted hygiene violation
Fixesrust-lang/rust#148580
I changed the original test to make sure we are pointing to the right scope.
mgca: Add ConstArg representation for const items
tracking issue: rust-lang/rust#132980fixesrust-lang/rust#131046fixesrust-lang/rust#134641
As part of implementing `min_generic_const_args`, we need to distinguish const items that can be used in the type system, such as in associated const equality projections, from const items containing arbitrary const code, which must be kept out of the type system. Specifically, all "type consts" must be either concrete (no generics) or generic with a trivial expression like `N` or a path to another type const item.
To syntactically distinguish these cases, we require, for now at least, that users annotate all type consts with the `#[type_const]` attribute. Then, we validate that the const's right-hand side is indeed eligible to be a type const and represent it differently in the HIR.
We accomplish this representation using a new `ConstItemRhs` enum in the HIR, and a similar but simpler enum in the AST. When `#[type_const]` is **not** applied to a const (e.g. on stable), we represent const item right-hand sides (rhs's) as HIR bodies, like before. However, when the attribute is applied, we instead lower to a `hir::ConstArg`. This syntactically distinguishes between trivial const args (paths) and arbitrary expressions, which are represented using `AnonConst`s. Then in `generics_of`, we can take advantage of the existing machinery to bar the `AnonConst` rhs's from using parent generics.
```
error[E0310]: the parameter type `R` may not live long enough
--> $DIR/implicit-static-lifetime-in-dyn-trait-return-type.rs:10:5
|
LL | fn bb<R>(r: R) -> Box<dyn Foo> {
| ------- this `dyn Trait` has an implicit `'static` lifetime bound
LL | Box::new(Bar(r))
| ^^^^^^^^^^^^^^^^
| |
| the parameter type `R` must be valid for the static lifetime...
| ...so that the type `R` will meet its required lifetime bounds
|
help: consider adding an explicit lifetime bound
|
LL | fn bb<R: 'static>(r: R) -> Box<dyn Foo> {
| +++++++++
```
Tweak output of missing lifetime on associated type
Follow up to https://github.com/rust-lang/rust/pull/135602.
Previously we only showed the trait's assoc item if the trait was local, because we were looking for a small span only for the generics, which we don't have for foreign traits. We now use `def_span` for the item, so we at least provide some context, even if its span is too wide.
```
error[E0195]: lifetime parameters or bounds on type `IntoIter` do not match the trait declaration
--> tests/ui/lifetimes/missing-lifetime-in-assoc-type-4.rs:7:18
|
7 | type IntoIter<'a> = std::collections::btree_map::Values<'a, i32, T>;
| ^^^^ lifetimes do not match type in trait
|
::: /home/gh-estebank/rust/library/core/src/iter/traits/collect.rs:292:5
|
292 | type IntoIter: Iterator<Item = Self::Item>;
| ------------------------------------------ lifetimes in impl do not match this type in trait
```
Given an associated item that needs a named lifetime, look at the enclosing `impl` item for one. If there is none, look at the self type and the implemented trait to see if either of those has an anonimous lifetime. If so, suggest adding a named lifetime.
```
error: in the trait associated type is declared without lifetime parameters, so using a borrowed type for them requires that lifetime to come from the implemented type
--> $DIR/missing-lifetime-in-assoc-type-2.rs:5:17
|
LL | type Item = &T;
| ^ this lifetime must come from the implemented type
|
help: add a lifetime to the impl block and use it in the self type and associated type
|
LL ~ impl<'a> IntoIterator for &'a S {
LL ~ type Item = &'a T;
|
```
Move the previous long message to a note and use a shorter primary message:
```
error: missing lifetime in associated type
--> $DIR/missing-lifetime-in-assoc-type-1.rs:9:17
|
LL | impl<'a> IntoIterator for &S {
| ---- there is a named lifetime specified on the impl block you could use
...
LL | type Item = &T;
| ^ this lifetime must come from the implemented type
|
note: in the trait the associated type is declared without lifetime parameters, so using a borrowed type for them requires that lifetime to come from the implemented type
--> $SRC_DIR/core/src/iter/traits/collect.rs:LL:COL
help: consider using the lifetime from the impl block
|
LL | type Item = &'a T;
| ++
```
r? `@Nadrieril`
