| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
This is the first small step towards testing auto-fixable compiler
suggestions using compiletest. Currently, it only checks if next to a
UI test there also happens to a `*.rs.fixed` file, and then uses rustfix
(added as external crate) on the original file, and asserts that it
produces the fixed version.
To show that this works, I've included one such test. I picked this test
case at random (and because it was simple) -- It is not relevant to the
2018 edition. Indeed, in the near future, we want to be able to restrict
rustfix to edition-lints, so this test cast might go away soon.
In case you still think this is somewhat feature-complete, here's a
quick list of things currently missing that I want to add before telling
people they can use this:
- [ ] Make this an actual compiletest mode, with `test [fix] …` output
and everything
- [ ] Assert that fixed files still compile
- [ ] Assert that fixed files produce no (or a known set of) diagnostics
output
- [ ] Update `update-references.sh` to support rustfix
- [ ] Use a published version of rustfix (i.e.: publish a new version
rustfix that exposes a useful API for this)
|
|
Affected methods are `abs`, `signum`, and `powi`.
CC https://github.com/rust-lang/rust/issues/32110#issuecomment-379503183
|
|
|
|
Explicitly mention `Option` in `?` error message.
Save users the time/effort of having to lookup what types implement
the `Try` trait.
|
|
Save users the time/effort of having to lookup what types implement
the `Try` trait.
|
|
This includes a submodule update to rustfmt
in order to allow a stable feature declaration.
|
|
|
|
|
|
|
|
|
|
When finding:
```rust
match &Some(3) {
&None => 1
&Some(2) => { 3 }
_ => 2
}
```
provide the following diagnostic:
```
error: expected one of `,`, `.`, `?`, `}`, or an operator, found `=>`
--> $DIR/missing-comma-in-match.rs:15:18
|
X | &None => 1
| -- - help: missing comma
| |
| while parsing the match arm starting here
X | &Some(2) => { 3 }
| ^^ expected one of `,`, `.`, `?`, `}`, or an operator here
```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- filter error on the evaluated value of `Self`
- filter error on the evaluated value of the type arguments
- add argument to include custom note in diagnostic
- allow the parser to parse `Self` when processing attributes
- add custom message to binops
|
|
If the original name is uppercase, use camel case. Otherwise, use snake
case.
|
|
Correctly format `extern crate` conflict resolution help
Closes #45799. Follow up to @Cldfire's #45820.
If the `extern` statement that will have a suggestion ends on a `;`, synthesize a new span that doesn't include it.
|
|
For E0277 on `for` loops, point at the "head" expression
When E0277's span points at a `for` loop, the actual issue is in the
element being iterated. Instead of pointing at the entire loop, point
only at the first line (when possible) so that the span ends in the
element for which E0277 was triggered.
|
|
|
|
|
|
Modify the spans used for `for`-loop expression expansion, instead of
creating a new span during error creation.
|
|
|
|
Fix into() cast paren check precedence
As discussed in #47699 the logic for determining if an expression needs parenthesis when suggesting an `.into()` cast is incorrect. Two broken examples from nightly are:
```
error[E0308]: mismatched types
--> main.rs:4:10
|
4 | test(foo as i8);
| ^^^^^^^^^ expected i32, found i8
help: you can cast an `i8` to `i32`, which will sign-extend the source value
|
4 | test(foo as i8.into());
|
```
```
error[E0308]: mismatched types
--> main.rs:4:10
|
4 | test(*foo);
| ^^^^ expected i32, found i8
help: you can cast an `i8` to `i32`, which will sign-extend the source value
|
4 | test(*foo.into());
|
```
As suggested by @petrochenkov switch the precedence check to `PREC_POSTFIX`. This catches both `as` and unary operators. Fixes #47699.
r? @petrochenkov
|
|
As discussed in #47699 the logic for determining if an expression needs
parenthesis when suggesting an `.into()` cast is incorrect. Two broken
examples from nightly are:
```
error[E0308]: mismatched types
--> main.rs:4:10
|
4 | test(foo as i8);
| ^^^^^^^^^ expected i32, found i8
help: you can cast an `i8` to `i32`, which will sign-extend the source value
|
4 | test(foo as i8.into());
|
```
```
error[E0308]: mismatched types
--> main.rs:4:10
|
4 | test(*foo);
| ^^^^ expected i32, found i8
help: you can cast an `i8` to `i32`, which will sign-extend the source value
|
4 | test(*foo.into());
|
```
As suggested by @petrochenkov switch the precedence check to
PREC_POSTFIX. This catches both `as` and unary operators. Fixes #47699.
|
|
When E0277's span points at a `for` loop, the actual issue is in the
element being iterated. Instead of pointing at the entire loop, point
only at the first line (when possible) so that the span ends in the
element for which E0277 was triggered.
|
|
When encountering a method call for an ADT that doesn't have any
implementation of it, we search for traits that could be implemented
that do have that method. Filter out private non-local traits that would
not be able to be implemented.
This doesn't account for public traits that are in a private scope, but
works as a first approximation and is a more correct behavior than the
current one.
|
|
Suggest casting on numeric type error
Re #47168.
|
|
On E0283, point at method with the requirements
On required type annotation diagnostic error, point at method with the
requirements if the span is available.
CC #45453.
|
|
Do not suggest to make `mut` binding external to `Fn` closure
Re #46834.
|
|
On required type annotation diagnostic error, point at method with the
requirements if the span is available.
|
|
|
|
|
|
- Use `syntax::util::parser::expr_precedence` to determine wether
parenthesis are needed around the casting target.
- Update message to not incorrectly mention rounding on `.into()`
suggestions, as those types that do have that implemented will never
round.
|
|
|
|
|
|
|
|
r=estebank
type error method suggestions use whitelisted identity-like conversions
Previously, on a type mismatch (and if this wasn't preëmpted by a
higher-priority suggestion), we would look for argumentless methods
returning the expected type, and list them in a `help` note. This had two
major shortcomings: firstly, a lot of the suggestions didn't really make
sense (if you used a &str where a String was expected,
`.to_ascii_uppercase()` is probably not the solution you were hoping
for). Secondly, we weren't generating suggestions from the most useful
traits! We address the first problem with an internal
`#[rustc_conversion_suggestion]` attribute meant to mark methods that keep
the "same value" in the relevant sense, just converting the type. We
address the second problem by making `FnCtxt.probe_for_return_type` pass
the `ProbeScope::AllTraits` to `probe_op`: this would seem to be safe
because grep reveals no other callers of `probe_for_return_type`.
Also, structured suggestions are pretty and good for RLS and friends.
Unfortunately, the trait probing is still not all one would hope for: at a
minimum, we don't know how to rule out `into()` in cases where it wouldn't
actually work, and we don't know how to rule in `.to_owned()` where it
would. Issues #46459 and #46460 have been filed and are ref'd in a FIXME.
This is hoped to resolve #42929, #44672, and #45777.
|
|
Account for `pub` in `const` -> `static` suggestion
Fix #45562.
|
|
|
|
Provide suggestion when trying to use method on numeric literal
New output:
```
error[E0688]: can't call method `powi` on ambiguous numeric type `{float}`
--> $DIR/method-on-ambiguous-numeric-type.rs:12:17
|
12 | let x = 2.0.powi(2);
| ^^^^
help: you must specify a concrete type for this numeric value, like `f32`
|
12 | let x = 2.0_f32.powi(2);
| ^^^^^^^
```
Previous output:
```
error[E0599]: no method named `powi` found for type `{float}` in the current scope
--> src/main.rs:12:17
|
12 | let x = 2.0.powi(2);
| ^^^^
|
= help: items from traits can only be used if the trait is in scope
help: the following trait is implemented but not in scope, perhaps add a `use` for it:
|
11 | use core::num::Float;
|
```
Fix #40985.
|
|
Previously, on a type mismatch (and if this wasn't preëmpted by a
higher-priority suggestion), we would look for argumentless methods
returning the expected type, and list them in a `help` note.
This had two major shortcomings. Firstly, a lot of the suggestions didn't
really make sense (if you used a &str where a String was expected,
`.to_ascii_uppercase()` is probably not the solution you were hoping
for). Secondly, we weren't generating suggestions from the most useful
traits!
We address the first problem with an internal
`#[rustc_conversion_suggestion]` attribute meant to mark methods that keep
the "same value" in the relevant sense, just converting the type. We
address the second problem by making `FnCtxt.probe_for_return_type` pass
the `ProbeScope::AllTraits` to `probe_op`: this would seem to be safe
because grep reveals no other callers of `probe_for_return_type`.
Also, structured suggestions are preferred (because they're pretty, but
also for RLS and friends).
Also also, we make the E0055 autoderef recursion limit error use the
one-time-diagnostics set, because we can potentially hit the limit a lot
during probing. (Without this,
test/ui/did_you_mean/recursion_limit_deref.rs would report "aborting due to
51 errors").
Unfortunately, the trait probing is still not all one would hope for: at a
minimum, we don't know how to rule out `into()` in cases where it wouldn't
actually work, and we don't know how to rule in `.to_owned()` where it
would. Issues #46459 and #46460 have been filed and are ref'd in a FIXME.
This is hoped to resolve #42929, #44672, and #45777.
|
|
|
|
|
|
Due to the disable-cloudabi tags being added to the source files, the
expected output of the compiler is altered slightly.
|
|
It looks like many of these tests are already disabled on emscripten,
which also doesn't seem to support environment variables and subprocess
spawning. Just add a similar tag for CloudABI. While there, sort some of
the lists of operating systems alphabetically.
|
|
This simple patch resolves #46756 (which was specifically about the case of
casts, but it would be poor form indeed to fix a reported issue without at
least a cursory attempt at answering the immortal question, "How does this bug
generalize?").
|
