| Age | Commit message (Collapse) | Author | Lines |
|---|
|
spans involving macro context Sometimes the parser attempts to synthesize spans from within a macro context with the span for the captured argument, leading to non-sensical spans with very bad output. Given that an incorrect span is worse than a partially incomplete span, when detecting this situation return only one of the spans without merging them. Fix #32072, #47778. CC #23480.
|
|
Sometimes the parser attempts to synthesize spans from within a macro
context with the span for the captured argument, leading to non-sensical
spans with very bad output. Given that an incorrect span is worse than
a partially incomplete span, when detecting this situation return only
one of the spans without mergin them.
|
|
|
|
|
|
macros: improve 1.0/2.0 interaction
This PR supports using unhygienic macros from hygienic macros without breaking the latter's hygiene.
```rust
// crate A:
#[macro_export]
macro_rules! m1 { () => {
f(); // unhygienic: this macro needs `f` in its environment
fn g() {} // (1) unhygienic: `g` is usable outside the macro definition
} }
// crate B:
#![feature(decl_macro)]
extern crate A;
use A::m1;
macro m2() {
fn f() {} // (2)
m1!(); // After this PR, `f()` in the expansion resolves to (2), not (3)
g(); // After this PR, this resolves to `fn g() {}` from the above expansion.
// Today, it is a resolution error.
}
fn test() {
fn f() {} // (3)
m2!(); // Today, `m2!()` can see (3) even though it should be hygienic.
fn g() {} // Today, this conflicts with `fn g() {}` from the expansion, even though it should be hygienic.
}
```
Once this PR lands, you can make an existing unhygienic macro hygienic by wrapping it in a hygienic macro. There is an [example](https://github.com/rust-lang/rust/pull/46551/commits/b766fa887dc0e4b923a38751fe4d570e35a75710) of this in the tests.
r? @nrc
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Modify message for keyword as identifier name
This is a temporary solution to #46311.
The message is generic enough to cover both cases and is probably a fine enough solution to the specific problem described in the task. However, the underlying reason for this to be wrong is that `next_token_inner` returns `Lifetime` even if the token is a label. That's not simple, as the syntax for both can be quite similar and it may need to take a look to the next token to make a decision. I'm not sure I have enough knowledge about the project to be able to solve that (yet!), so I thought I'll fix the immediate problem first.
|
|
It's just not useful. It also makes it hard to have tests that probe
internal state, since the interning number is very sensitive.
Dumping the number in the case of gensym is not ideal but will do for
now.
|
|
|
|
|
|
|
|
Display `\t` in diagnostics code as four spaces
Follow up to #44386 using the unicode variable width machinery from #45711 to replace tabs in the source code when displaying a diagnostic error with four spaces (instead of only one), while properly accounting for this when calculating underlines.
Partly addresses #44618.
|
|
|
|
The previous method ran into problems because ICH would treat Spans
as (file,line,col) but the cache contained byte offsets and its
possible for the latter to change while the former stayed stable.
|
|
|
|
|
|
|
|
Add comment explaining the ctxt field in Span
As discussed in #45747.
r? @petrochenkov
|
|
|
|
Display spans correctly when there are zero-width or wide characters
Hopefully...
* fixes #45211
* fixes #8706
---
Before:
```
error: invalid width `7` for integer literal
--> unicode_2.rs:12:25
|
12 | let _ = ("a̐éö̲", 0u7);
| ^^^
|
= help: valid widths are 8, 16, 32, 64 and 128
error: invalid width `42` for integer literal
--> unicode_2.rs:13:20
|
13 | let _ = ("아あ", 1i42);
| ^^^^
|
= help: valid widths are 8, 16, 32, 64 and 128
error: aborting due to 2 previous errors
```
After:
```
error: invalid width `7` for integer literal
--> unicode_2.rs:12:25
|
12 | let _ = ("a̐éö̲", 0u7);
| ^^^
|
= help: valid widths are 8, 16, 32, 64 and 128
error: invalid width `42` for integer literal
--> unicode_2.rs:13:20
|
13 | let _ = ("아あ", 1i42);
| ^^^^
|
= help: valid widths are 8, 16, 32, 64 and 128
error: aborting due to 2 previous errors
```
Spans might display incorrectly on the browser.
r? @estebank
|
|
|
|
Adds an `IsAuto` field to `ItemTrait` which flags if the trait was
declared as an `auto trait`.
Auto traits cannot have generics nor super traits.
|
|
|
|
Decode span data only once
|
|
|
|
Refactor to use `debug_struct` in several Debug impls
Also use `pad` and derive `Debug` for `Edge`.
Fixes #44771.
|
|
Fixes #44771.
|
|
|
|
|
|
|
|
|
|
Maybe I should allow error messages to check the *specific* desugaring?
Thanks @huntiep for the idea!
|
|
|
|
This helps to avoid landing changes to rustc and rustfmt in one step
|
|
|
|
|
|
Fixes #41701.
|
|
Implement CompilerDesugaringKind enum
This is the first step outlined in #35946. I think that the variants of `CompilerDesugaringKind` should be changed, I didn't know what the official names for `...` and `<-` are.
I'm not to sure how tests for the compiler work, but I would imagine that tests should be added such that
`Symbol::intern(s) == CompilerDesugaringKind::from(s).as_symbol()` for valid `s`.
|
|
|
|
Like #43008 (f668999), but _much more aggressive_.
|
|
|
|
|
|
Fix quadratic performance with lots of use statements
This fixes 2 problems that caused quadratic performance when lots of use-statements were present. After this patch, performance is linear (and very fast) even with 1M uses.
Fixes #43572.
Fixes #43573.
r? @eddyb
|
