Add "dereference boxed value" suggestion.
Contributes to #57741.
This PR adds a `help: consider dereferencing the boxed value` suggestion to discriminants of match statements when the match arms have type `T` and the discriminant has type `Box<T>`.
r? @estebank
Suggest correct cast for struct fields with shorthand syntax
```
error[E0308]: mismatched types
--> $DIR/type-mismatch-struct-field-shorthand.rs:8:19
|
LL | let _ = RGB { r, g, b };
| ^ expected f64, found f32
help: you can cast an `f32` to `f64` in a lossless way
|
LL | let _ = RGB { r: r.into(), g, b };
| ^^^^^^^^^^^
```
Fix#52497.
Continue parsing after parent type args and suggest using angle brackets
```
error[E0214]: parenthesized parameters may only be used with a trait
--> $DIR/E0214.rs:2:15
|
LL | let v: Vec(&str) = vec!["foo"];
| ^^^^^^
| |
| only traits may use parentheses
| help: use angle brackets instead: `<&str>`
```
r? @zackmdavis
Change bounds on `TryFrom` blanket impl to use `Into` instead of `From`
This is from this [comment](https://github.com/rust-lang/rust/issues/33417#issuecomment-447111156) I made.
This will expand the impls available for `TryFrom` and `TryInto`, without losing anything in the process.
This commit adds a `help: consider dereferencing the boxed value`
suggestion to discriminants of match statements when the match arms have
type `T` and the discriminant has type `Box<T>`.
rustdoc: overhaul code block lexing errors
Fixes#53919.
This PR moves the reporting of code block lexing errors from rendering time to an early pass, so we can use the compiler's error reporting mechanisms. This dramatically improves the diagnostics in this situation: we now de-emphasize the lexing errors as a note under a warning that has a span and suggestion instead of just emitting errors at the top level.
Additionally, this PR generalizes the markdown -> source span calculation function, which should allow other rustdoc warnings to use better spans in the future.
Last, the PR makes sure that the code block is always emitted in the docs, even if it fails to highlight correctly.
Of note:
- The new pass unfortunately adds another pass over the docs to gather the doc blocks for syntax-checking. I wonder if this could be combined with the pass that looks for testable blocks? I'm not familiar with that code, so I don't know how feasible that is.
- `pulldown_cmark` doesn't make it easy to find the spans of the code blocks, so the code that calculates the spans is a little nasty. It works for all the test cases I threw at it, but I wouldn't be surprised if an edge case would break it. Should have a thorough review.
- This PR worsens the state of #56885, since those certain fatal lexing errors are now emitted before docs get generated at all.
make trait-aliases work across crates
This is rebase of a small part of @alexreg's PR #55994. It focuses just on the changes that integrate trait aliases properly into crate metadata, excluding the stylistic edits and the trait objects.
The stylistic edits I also rebased and can open a separate PR.
The trait object stuff I found challenging and decided it basically needed to be reimplemented. For now I've excluded it.
Since this is really @alexreg's work (I really just rebased) I am going to make it r=me once it is working.
Fixes#56488.
Fixes#57023.
Generalize `huge-enum.rs` test and expected stderr for more cross platform cases
With this change, I am able to build and test cross-platform `rustc`
In particular, I can use the following in my `config.toml`:
```
[build]
host = ["i686-unknown-linux-gnu", "x86_64-unknown-linux-gnu"]
target = ["i686-unknown-linux-gnu", "x86_64-unknown-linux-gnu"]
```
Before this change, my attempt to run the test suite would fail
because the error output differs depending on what your host and
targets are.
----
To be concrete, here are the actual messages one can observe:
```
% ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc ../src/test/ui/huge-enum.rs -Aunused --target=x86_64-unknown-linux-gnu
error: the type `std::option::Option<[u32; 35184372088831]>` is too big for the current architecture
error: aborting due to previous error
% ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc ../src/test/ui/huge-enum.rs -Aunused --target=i686-unknown-linux-gnu
error: the type `std::option::Option<[u32; 536870911]>` is too big for the current architecture
error: aborting due to previous error
% ./build/i686-unknown-linux-gnu/stage1/bin/rustc ../src/test/ui/huge-enum.rs -Aunused --target=i686-unknown-linux-gnu
error: the type `std::option::Option<[u32; 536870911]>` is too big for the current architecture
error: aborting due to previous error
% ./build/i686-unknown-linux-gnu/stage1/bin/rustc ../src/test/ui/huge-enum.rs -Aunused --target=x86_64-unknown-linux-gnu
error: the type `[u32; 35184372088831]` is too big for the current architecture
error: aborting due to previous error
```
To address these variations, I changed the test to be more aggressive
in its normalization strategy. We cannot (and IMO should not)
guarantee that `Option` will appear in the error output here. So I
normalized both types `Option<[u32; N]>` and `[u32; N]` to just `TYPE`
High priority resolutions for associated variants
In https://github.com/rust-lang/rust/pull/56225 variants were assigned lowest priority during name resolution to avoid crater run and potential breakage.
This PR changes the rules to give variants highest priority instead.
Some motivation:
- If variants (and their constructors) are treated as associated items, then they are obviously *inherent* associated items since they don't come from traits.
- Inherent associated items have higher priority during resolution than associated items from traits.
- The reason is that there is a way to disambiguate in favor of trait items (`<Type as Trait>::Ambiguous`), but there's no way to disambiguate in favor of inherent items, so they became unusable in case of ambiguities if they have low priority.
- It's technically problematic to fallback from associated types to anything until lazy normalization (?) is implemented.
Crater found some regressions from this change, but they are all in type positions, e.g.
```rust
fn f() -> Self::Ambiguos { ... } // Variant `Ambiguous` or associated type `Ambiguous`?
```
, so variants are not usable there right now, but they may become usable in the future if https://github.com/rust-lang/rfcs/pull/2593 is accepted.
This PR keeps code like this successfully resolving, but introduces a future-compatibility lint `ambiguous_associated_items` that recommends rewriting it as `<Self as Trait>::Ambiguous`.
Fix stack overflow when finding blanket impls
Currently, SelectionContext tries to prevent stack overflow by keeping
track of the current recursion depth. However, this depth tracking is
only used when performing normal section (which includes confirmation).
No such tracking is performed for evaluate_obligation_recursively, which
can allow a stack overflow to occur.
To fix this, this commit tracks the current predicate evaluation depth.
This is done separately from the existing obligation depth tracking:
an obligation overflow can occur across multiple calls to 'select' (e.g.
when fulfilling a trait), while a predicate evaluation overflow can only
happen as a result of a deep recursive call stack.
Fixes#56701
I've re-used `tcx.sess.recursion_limit` when checking for predication evaluation overflows. This is such a weird corner case that I don't believe it's necessary to have a separate setting controlling the maximum depth.
Fix suggestions given mulitple bad lifetimes
When given multiple lifetimes prior to type parameters in generic
parameters, do not ICE and print the correct suggestion.
r? @estebank
CC @pnkfelix
Fixes: #57521
librustc_metadata: Pass a default value when unwrapping a span
Fixes#57323.
When compiling with `static-nobundle` a-la
`rustc -l static-nobundle=nonexistent main.rs`
we now get a neat output in the form of:
```
error[E0658]: kind="static-nobundle" is feature gated (see issue #37403)
|
= help: add #![feature(static_nobundle)] to the crate attributes to enable
error: aborting due to previous error
For more information about this error, try `rustc --explain E0658`.
```
The build and tests completed successfully on my machine. Should I be adding a new test?
Better error note on unimplemented Index trait for string
fixes#56740
I've tried to compile suggestion from comments in the issue #56740, but unsure of it. So I'm open to advice :)
Current output will be like this:
```rust
error[E0277]: the type `str` cannot be indexed by `{integer}`
--> $DIR/str-idx.rs:3:17
|
LL | let c: u8 = s[4]; //~ ERROR the type `str` cannot be indexed by `{integer}`
| ^^^^ `str` cannot be indexed by `{integer}`
|
= help: the trait `std::ops::Index<{integer}>` is not implemented for `str`
= note: you can use `.chars().nth()` or `.bytes().nth()`
see chapter in The Book <https://doc.rust-lang.org/book/ch08-02-strings.html#indexing-into-strings>
error: aborting due to previous error
For more information about this error, try `rustc --explain E0277`.
```
`x.py test src/test/ui` succeeded and I've also tested output manually by compiling the following code:
```rust
fn _f() {
let s = std::string::String::from("hello");
let _c = s[0];
let s = std::string::String::from("hello");
let mut _c = s[0];
let s = "hello";
let _c = s[0];
let s = "hello";
let mut _c = &s[0];
}
```
Not sure if some docs should be changed too. I will also fix error message in the [Book :: Indexing into Strings](db53e2e3cd/src/ch08-02-strings.md (indexing-into-strings)) if that PR will get approved :)
