| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Add ok-wrapping to catch blocks, per RFC
Updates the `catch{}` lowering to wrap the result in `Try::from_ok`.
r? @nikomatsakis
Fixes #41414
Fixes #43818
|
|
|
|
|
|
This permits easier iteration without having to worry about warnings
being denied.
Fixes #49517
|
|
Bump the bootstrap compiler to 1.26.0 beta
Holy cow that's a lot of `cfg(stage0)` removed and a lot of new stable language
features!
|
|
|
|
|
|
|
|
Merge upstream changes
|
|
|
|
Holy cow that's a lot of `cfg(stage0)` removed and a lot of new stable language
features!
|
|
Closes #22181, #27779
|
|
|
|
Misc changes from my parallel rustc branch
r? @michaelwoerister
|
|
syntax: Make imports in AST closer to the source and cleanup their parsing
This is a continuation of https://github.com/rust-lang/rust/pull/45846 in some sense.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fixes #47311.
r? @nrc
|
|
Remove experimental -Zremap-path-prefix-from/to, and replace it with
the stabilized --remap-path-prefix=from=to variant.
This is an implementation for issue of #41555.
|
|
|
|
|
|
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.
|
