| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Fix ICE #103748
Fixes #103748
|
|
Recover wrong-cased keywords that start items
(_this pr was inspired by [this tweet](https://twitter.com/Azumanga/status/1552982326409367561)_)
r? `@estebank`
We've talked a bit about this recovery, but I just wanted to make sure that this is the right approach :)
For now I've only added the case insensitive recovery to `use`s, since most other items like `impl` blocks, modules, functions can start with multiple keywords which complicates the matter.
|
|
r=compiler-errors
Parser: Recover from using colon as path separator in imports
I don't know if this is the right approach, any feedback is welcome.
r? ```@compiler-errors```
Fixes #103269
|
|
|
|
Unescaping cleanups
Some code improvements, and some error message improvements.
Best reviewed one commit at a time.
r? ````@matklad````
|
|
|
|
r=jackh726,wesleywiser
Avoid possible infinite loop when next_point reaching the end of file
Fixes #103451
If we return a span with `lo` = `hi`, `span_to_snippet` will always get `Ok("")`, which may introduce infinite loop if we don't care.
This PR make `find_width_of_character_at_span` return `width` with 1, so that `span_to_snippet` will get an `Err`.
|
|
compiler-errors:oh-no-bad-block-should-not-have-label, r=lcnr
Don't silently eat label before block in block-like expr
Fixes #103983
cc #92823 (where the regression was introduced)
|
|
Make underscore_literal_suffix a hard error.
It's been a warning for 5.5 years. Time to make it a hard error.
Closes #42326.
r? ``@pnkfelix``
|
|
It's been a warning for 5.5 years. Time to make it a hard error.
Closes #42326.
|
|
Implement `std::marker::Tuple`, use it in `extern "rust-call"` and `Fn`-family traits
Implements rust-lang/compiler-team#537
I made a few opinionated decisions in this implementation, specifically:
1. Enforcing `extern "rust-call"` on fn items during wfcheck,
2. Enforcing this for all functions (not just ones that have bodies),
3. Gating this `Tuple` marker trait behind its own feature, instead of grouping it into (e.g.) `unboxed_closures`.
Still needing to be done:
1. Enforce that `extern "rust-call"` `fn`-ptrs are well-formed only if they have 1/2 args and the second one implements `Tuple`. (Doing this would fix ICE in #66696.)
2. Deny all explicit/user `impl`s of the `Tuple` trait, kinda like `Sized`.
3. Fixing `Tuple` trait built-in impl for chalk, so that chalkification tests are un-broken.
Open questions:
1. Does this need t-lang or t-libs signoff?
Fixes #99820
|
|
|
|
|
|
|
|
There are three kinds of "byte" literals: byte literals, byte string
literals, and raw byte string literals. None are allowed to have
non-ASCII chars in them.
Two `EscapeError` variants exist for when that constraint is violated.
- `NonAsciiCharInByte`: used for byte literals and byte string literals.
- `NonAsciiCharInByteString`: used for raw byte string literals.
As a result, the messages for raw byte string literals use different
wording, without good reason. Also, byte string literals are incorrectly
described as "byte constants" in some error messages.
This commit eliminates `NonAsciiCharInByteString` so the three cases are
handled similarly, and described correctly. The `mode` is enough to
distinguish them.
Note: Some existing error messages mention "byte constants" and some
mention "byte literals". I went with the latter here, because it's a
more correct name, as used by the Reference.
|
|
|
|
fee1-dead-contrib:stabilize_arbitrary_enum_discriminant, r=joshtriplett
Stabilize arbitrary_enum_discriminant, take 2
Documentation has been updated in https://github.com/rust-lang/reference/pull/1055. cc #86860 for previous stabilization report.
Not yet marks https://github.com/rust-lang/rust/issues/60553 as done: need documentation in the rust reference.
|
|
Remove extra type error after missing semicolon error
Fixes #103425
|
|
reaching end
|
|
Fix assertion failed for break_last_token and trailing token
Fixes #103143
|
|
|
|
Recover when unclosed char literal is parsed as a lifetime in some positions
Fixes #101278
|
|
macro
|
|
|
|
|
|
|
|
Use the same tense everywhere and prefer display over debug, as these
descriptions are user facing.
|
|
Move some tests to more reasonable directories
r? ``@petrochenkov``
|
|
|
|
|
|
`let`'s not needed in struct field definitions
Fixes #101683
|
|
Co-authored-by: jyn514 <jyn514@gmail.com>
Co-authored-by: Esteban Kuber <estebank@users.noreply.github.com>
|
|
Recover from impl Trait in type param bound
Fixes #102182
r? ``@estebank``
|
|
|
|
|
|
Suggest calling method if fn does not exist
I tried to split this up into two commits, the first where we stash the resolution error until typeck (which causes a bunch of diagnostics changes because the ordering of error messages change), then the second commit is the actual logic that actually implements the suggestion.
I am not in love with the presentation of the suggestion, so I could use some advice for how to format the actual messaging.
r? diagnostics
Fixes #102518
|
|
|
|
|
|
Move lint level source explanation to the bottom
So, uhhhhh
r? `@estebank`
## User-facing change
"note: `#[warn(...)]` on by default" and such are moved to the bottom of the diagnostic:
```diff
- = note: `#[warn(unsupported_calling_conventions)]` on by default
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #87678 <https://github.com/rust-lang/rust/issues/87678>
+ = note: `#[warn(unsupported_calling_conventions)]` on by default
```
Why warning is enabled is the least important thing, so it shouldn't be the first note the user reads, IMO.
## Developer-facing change
`struct_span_lint` and similar methods have a different signature.
Before: `..., impl for<'a> FnOnce(LintDiagnosticBuilder<'a, ()>)`
After: `..., impl Into<DiagnosticMessage>, impl for<'a, 'b> FnOnce(&'b mut DiagnosticBuilder<'a, ()>) -> &'b mut DiagnosticBuilder<'a, ()>`
The reason for this is that `struct_span_lint` needs to edit the diagnostic _after_ `decorate` closure is called. This also makes lint code a little bit nicer in my opinion.
Another option is to use `impl for<'a> FnOnce(LintDiagnosticBuilder<'a, ()>) -> DiagnosticBuilder<'a, ()>` altough I don't _really_ see reasons to do `let lint = lint.build(message)` everywhere.
## Subtle problem
By moving the message outside of the closure (that may not be called if the lint is disabled) `format!(...)` is executed earlier, possibly formatting `Ty` which may call a query that trims paths that crashes the compiler if there were no warnings...
I don't think it's that big of a deal, considering that we move from `format!(...)` to `fluent` (which is lazy by-default) anyway, however this required adding a workaround which is unfortunate.
## P.S.
I'm sorry, I do not how to make this PR smaller/easier to review. Changes to the lint API affect SO MUCH 😢
|
|
|
|
|
|
|
|
r=fee1-dead
Improve errors for incomplete functions in struct definitions
Given the following code:
```rust
fn main() {}
struct Foo {
fn
}
```
[playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=29139f870511f6918324be5ddc26c345)
The current output is:
```
Compiling playground v0.0.1 (/playground)
error: functions are not allowed in struct definitions
--> src/main.rs:4:5
|
4 | fn
| ^^
|
= help: unlike in C++, Java, and C#, functions are declared in `impl` blocks
= help: see https://doc.rust-lang.org/book/ch05-03-method-syntax.html for more information
error: could not compile `playground` due to previous error
```
In this case, rustc should suggest escaping `fn` to use it as an identifier.
|
|
|
|
Migrate more of rustc_parse to SessionDiagnostic
Still far from complete, but I thought I'd add a checkpoint here because rebasing was starting to get annoying.
|
|
Structured suggestion for missing `mut`/`const` in raw pointer
Fixes #102261
|
|
|
|
|
|
|
|
|
