| Age | Commit message (Collapse) | Author | Lines |
|---|
|
vincenzopalazzo:macros/wrong_sugg_with_positional_arg, r=TaKO8Ki
sugg: take into count the debug formatting
Closes https://github.com/rust-lang/rust/issues/100648
This PR will fix a suggestion error by taking into consideration also the `:?` symbol and act in a different way
``@rustbot`` r? ``@compiler-errors``
N.B: I did not find a full way to test the change, any idea?
|
|
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
|
|
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
TaKO8Ki:suggest-adding-reference-to-trait-assoc-item, r=cjgillot
Suggest adding a reference to a trait assoc item
fixes #100289
|
|
Reenable disabled early syntax gates as future-incompatibility lints
- MCP: https://github.com/rust-lang/compiler-team/issues/535
The approach taken by this PR is
- Introduce a new lint, `unstable_syntax_pre_expansion`, and reenable the early syntax gates to emit it
- Use the diagnostic stashing mechanism to stash warnings the early warnings
- When the hard error occurs post expansion, steal and cancel the early warning
- Don't display any stashed warnings if errors are present to avoid the same noise problem that hiding type ascription errors is avoiding
Commits are working commits, but in a coherent steps-to-implement manner. Can be squashed if desired.
The preexisting `soft_unstable` lint seems like it would've been a good fit, but it is deny-by-default (appropriate for `#[bench]`) and these gates should be introduced as warn-by-default.
It may be desirable to change the stash mechanism's behavior to not flush lint errors in the presence of other errors either (like is done for warnings here), but upgrading a stash-using lint from warn to error perhaps is enough of a request to see the lint that they shouldn't be hidden; additionally, fixing the last error to get new errors thrown at you always feels bad, so if we know the lint errors are present, we should show them.
Using a new flag/mechanism for a "weak diagnostic" which is suppressed by other errors may also be desirable over assuming any stashed warnings are "weak," but this is the first user of stashing warnings and seems an appropriate use of stashing (it follows the "know more later to refine the diagnostic" pattern; here we learn that it's in a compiled position) so we get to define what it means to stash a non-hard-error diagnostic.
cc `````@petrochenkov````` (seconded MCP)
|
|
Mention `as_mut` alongside `as_ref` in borrowck error message
Kinda fixes #99426 but I guess that really might be better staying open to see if we could make it suggest `as_mut` in a structured way. Not sure how to change borrowck to know that info tho.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Adjust span of fn argument declaration
Span of a fn argument declaration goes from:
```
fn foo(i : i32 , ...)
^^^^^^^^
```
to:
```
fn foo(i : i32 , ...)
^^^^^^^
```
That is, we don't include the extra spacing up to the trailing comma, which I think is more correct.
cc https://github.com/rust-lang/rust/pull/99646#discussion_r944568074
r? ``@estebank``
---
The two tests that had dramatic changes in their rendering I think actually are improved, though they are kinda poor spans both before and after the changes. :shrug: Thoughts?
|
|
improve "try ignoring the field" diagnostic
Closes #95795
|
|
|
|
r=lcnr
Argument type error improvements
Motivated by this interesting code snippet:
```rust
#[derive(Copy, Clone)]
struct Wrapper<T>(T);
fn foo(_: fn(i32), _: Wrapper<i32>) {}
fn f(_: u32) {}
fn main() {
let w = Wrapper::<isize>(1isize);
foo(f, w);
}
```
Which currently errors like:
```
error[E0308]: arguments to this function are incorrect
--> src/main.rs:10:5
|
10 | foo(f, w);
| ^^^ - - expected `i32`, found `isize`
| |
| expected `i32`, found `u32`
|
= note: expected fn pointer `fn(i32)`
found fn item `fn(u32) {f}`
= note: expected struct `Wrapper<i32>`
found struct `Wrapper<isize>`
note: function defined here
--> src/main.rs:4:4
|
4 | fn foo(_: fn(i32), _: Wrapper<i32>) {}
| ^^^ ---------- ---------------
```
Specifically, that double `expected .. found ..` which is very difficult to correlate to the types in the arguments. Also, the fact that "expected `i32`, found `isize`" and the other argument mismatch label don't even really explain what's going on here.
After this PR:
```
error[E0308]: arguments to this function are incorrect
--> $DIR/two-mismatch-notes.rs:10:5
|
LL | foo(f, w);
| ^^^
|
note: expected fn pointer, found fn item
--> $DIR/two-mismatch-notes.rs:10:9
|
LL | foo(f, w);
| ^
= note: expected fn pointer `fn(i32)`
found fn item `fn(u32) {f}`
note: expected struct `Wrapper`, found a different struct `Wrapper`
--> $DIR/two-mismatch-notes.rs:10:12
|
LL | foo(f, w);
| ^
= note: expected struct `Wrapper<i32>`
found struct `Wrapper<isize>`
note: function defined here
--> $DIR/two-mismatch-notes.rs:4:4
|
LL | fn foo(_: fn(i32), _: Wrapper<i32>) {}
| ^^^ ---------- ---------------
error: aborting due to previous error
For more information about this error, try `rustc --explain E0308`.
```
Yeah, it's a bit verbose, but much clearer IMO.
---
Open to discussions about how this could be further improved. Motivated by `@jyn514's` [tweet](https://mobile.twitter.com/joshuayn514/status/1558042020601634816) here.
|
|
|
|
|
|
Closes #95795
|
|
|
|
Refactor: remove a type string comparison
|
|
|
|
Some "this expression has a field"-related fixes
Each commit does something different and is worth reviewing, but the final diff from `master..HEAD` contains the sum of the changes to the UI tests, since some commits added UI tests "regressions" which were later removed in other commits.
The only change I could see adding on top of this is suppressing `Clone::clone` from the "this expression has a field that has this method" suggestion, since it's so commonly implemented by types that it's not worthwhile suggesting in general.
|
|
WaffleLapkin:improve_diagnostics_for_missing_type_in_a_const_item, r=compiler-errors
Improve diagnostics for `const a: = expr;`
Adds a suggestion to write a type when there is a colon, but the type is not present.
I've also shrunk spans a little, so the suggestions are a little nicer.
Resolves #100146
r? `@compiler-errors`
|
|
|
|
|
|
|
|
|
|
|
|
TaKO8Ki:suggest-removing-semicolon-and-boxing-the-expressions, r=compiler-errors
Suggest removing a semicolon and boxing the expressions for if-else
`InferCtxt::suggest_remove_semi_or_return_binding` was not working well, so I fixed it and added a ui test.
|
|
Use `impl`'s generics when suggesting fix on bad `impl Copy`
See the UI test for a more complicated example, but we weren't correctly suggesting to add bounds given a manual `impl` whose generics didn't match the struct generics.
```rust
#[derive(Clone)]
struct Wrapper<T>(T);
impl<S> Copy for Wrapper<S> {}
```
Coincidentally this fix didn't cause any regressions for `derive(Copy)` impls, I think because those use the same spans in the impl generics as the struct generics, so the machinery still applies the same change.
|
|
well for if-else
|
|
Adjust an expr span to account for macros
Fix this erroneous suggestion:
```
error[E0529]: expected an array or slice, found `Vec<{integer}>`
--> /home/gh-compiler-errors/test.rs:2:9
|
2 | let [..] = vec![1, 2, 3];
| ^^^^ pattern cannot match with input type `Vec<{integer}>`
|
help: consider slicing here
--> /home/gh-compiler-errors/rust2/library/alloc/src/macros.rs:50:36
|
50~ $crate::__rust_force_expr!(<[_]>::into_vec(
51+ #[rustc_box]
52+ $crate::boxed::Box::new([$($x),+])
53~ )[..])
```
|
|
Suggest dereferencing index when trying to use a reference of usize as index
fixes #96678
|
|
|
|
fix msg
|
|
Prefer visibility map parents that are not `doc(hidden)` first
Far simpler approach to #98876.
This only fixes the case where the parent is `doc(hidden)`, not where the child is `doc(hidden)` since I don't know how to get the attrs on the import statement given a `ModChild`... I'll try to follow up with that, but this is a good first step.
|
|
|
|
|
|
Resolve function lifetime elision on the AST
~Based on https://github.com/rust-lang/rust/pull/97720~
Lifetime elision for functions is purely syntactic in nature, so can be resolved on the AST.
This PR replicates the elision logic and diagnostics on the AST, and replaces HIR-based resolution by a `delay_span_bug`.
This refactor allows for more consistent diagnostics, which don't have to guess the original code from HIR.
r? `@petrochenkov`
|
|
|
|
|
|
|
|
|
