| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
stabilize outlives requirements
https://github.com/rust-lang/rust/issues/44493
r? @nikomatsakis
|
|
Co-authored-by: nikomatsakis
|
|
|
|
|
|
|
|
|
|
Invocation/expansion ID (aka `Mark`) is not really necessary for resolving a macro path.
What is really necessary is its parent module, parent expansion and parent legacy scope.
This is required for validation resolutions of built-in attributes, which don't get their own `Mark`s
|
|
rustc_resolve: inject `uniform_paths` canaries regardless of the feature-gate, on Rust 2018.
This PR is an attempt at future-proofing "anchored paths" by emitting the same ambiguity errors that `#![feature(uniform_paths)]` would, with slightly changed phrasing (see added UI tests).
Also, on top of #54005, this PR allows this as well:
```rust
use crate_name;
use crate_name::foo;
```
In that any ambiguity between an extern crate and an import *of that same crate* is ignored.
r? @petrochenkov cc @aturon @Centril @joshtriplett
|
|
the same crate.
|
|
feature-gate, on Rust 2018.
|
|
#53359: putting multiple unresolved import on single line
r? @estebank
Here is WIP implementation of #53359
this PR have clubbed multiple unresolved imports into a single line.
I think still two things need to improve like giving specific `label message` for each span of multi_span(how we can do this?) and second we are getting a warning while compiling, stating something like `E0432` have been passed before.
|
|
|
|
|
|
resolve: Relax shadowing restrictions on macro-expanded macros
Previously any macro-expanded macros weren't allowed to shadow macros from outer scopes.
Now only "more macro-expanded" macros cannot shadow "less macro-expanded" macros.
See comments to `fn may_appear_after` and added tests for more details and examples.
The functional changes are a21f6f588fc28c97533130ae44a6957b579ab58c and 46dd365ce9ca0a6b8653849b80267763c542842a, other commits are refactorings.
|
|
proc_macro::Group::span_open and span_close
Before this addition, every delimited group like `(`...`)` `[`...`]` `{`...`}` has only a single Span that covers the full source location from opening delimiter to closing delimiter. This makes it impossible for a procedural macro to trigger an error pointing to just the opening or closing delimiter. The Rust compiler does not seem to have the same limitation:
```rust
mod m {
type T =
}
```
```console
error: expected type, found `}`
--> src/main.rs:3:1
|
3 | }
| ^
```
On that same input, a procedural macro would be forced to trigger the error on the last token inside the block, on the entire block, or on the next token after the block, none of which is really what you want for an error like above.
This commit adds `group.span_open()` and `group.span_close()` which access the Span associated with just the opening delimiter and just the closing delimiter of the group. Relevant to Syn as we implement real error messages for when parsing fails in a procedural macro: https://github.com/dtolnay/syn/issues/476.
```diff
impl Group {
fn span(&self) -> Span;
+ fn span_open(&self) -> Span;
+ fn span_close(&self) -> Span;
}
```
Fixes #48187
r? @alexcrichton
|
|
rustc_resolve: only prepend CrateRoot to a non-keyword segment.
Fixes #53770 by treating `use` paths as absolute in a finer-grained manner, specifically:
```rust
use {a, crate::b, self::c, super::d};
```
Used to be interpreted as if it were (when `uniform_paths` is not enabled):
```rust
use ::{a, crate::b, self::c, super::d};
```
With this PR, the `CrateRoot` pseudo-keyword indicating an absolute path is only inserted when the first path segment is found (if it's not a keyword), i.e. the example behaves like:
```rust
use {::a, crate::b, self::c, super::d};
```
This should (finally) make `use {path};` fully equivalent to `use path;`.
r? @petrochenkov cc @cramertj @joshtriplett @nikomatsakis
|
|
Fix incorrect outer function type parameter message
Fix #51303.
|
|
|
|
diagnostic
Addressed estebank's comments for 53359
|
|
Add labels to ambiguous resolution errors
|
|
|
|
|
|
|
|
... for both legacy and modern macros.
Fix previously introduced regressions, add tests.
|
|
|
|
|
|
This is a regression for legacy macros that will be fixed in the next commit
|
|
|
|
|
|
rustc_resolve: don't record uniform_paths canaries as reexports.
Fixes #53691, fixes #53484.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
refactor match guard
This is the first step to implement RFC 2294: if-let-guard. Tracking issue: https://github.com/rust-lang/rust/issues/51114
The second step should be introducing another variant `IfLet` in the Guard enum. I separated them into 2 PRs for the convenience of reviewers.
r? @petrochenkov
|
|
set applicability
Update a few more calls as described in #50723
r? @estebank
|
|
|
|
resolve suggestions should use `crate::` when enabled
I couldn't find a way to add a specific assertion for the ui test, so the expected output is living under the `crates-in-path.stderr` ui test.
- is this the right place for the test?
fixes #51212
|
|
fix for late-bound regions
Fix for https://github.com/rust-lang/rust/issues/53419
r? @nikomatsakis
|
|
|
|
|
