| Age | Commit message (Collapse) | Author | Lines |
|---|
|
It was never used
|
|
|
|
This ensures that we match the order used by proc macro metadata
serialization.
Fixes #64251
|
|
|
|
|
|
|
|
Be accurate on `format!` parse error expectations
Fix https://github.com/rust-lang/rust/issues/57277.
|
|
Arm, Field, FieldPat, GenericParam, Param, StructField and Variant
|
|
Migrate internal diagnostic registration to macro_rules
Review is best done commit-by-commit.
Fixes #64132.
|
|
Move injection of attributes from command line to `libsyntax_ext`
Just a tiny bit of code generation that wasn't moved into `libsyntax_ext` in https://github.com/rust-lang/rust/pull/62771.
|
|
Correct pluralisation of various diagnostic messages
|
|
Use hygiene for AST passes
AST passes are now able to have resolve consider their expansions as if they were opaque macros defined either in some module in the current crate, or a fake empty module with `#[no_implicit_prelude]`.
* Add an ExpnKind for AST passes.
* Remove gensyms in AST passes.
* Remove gensyms in`#[test]`, `#[bench]` and `#[test_case]`.
* Allow opaque macros to define tests.
* Move tests for unit tests to their own directory.
* Remove `Ident::{gensym, is_gensymed}` - `Ident::gensym_if_underscore` still exists.
cc #60869, #61019
r? @petrochenkov
|
|
|
|
|
|
or-patterns: Uniformly use `PatKind::Or` in AST & Fix/Cleanup resolve
Following up on work in https://github.com/rust-lang/rust/pull/63693 and https://github.com/rust-lang/rust/pull/61708, in this PR we:
- Uniformly use `PatKind::Or(...)` in AST:
- Change `ast::Arm.pats: Vec<P<Pat>>` => `ast::Arm.pat: P<Pat>`
- Change `ast::ExprKind::Let.0: Vec<P<Pat>>` => `ast::ExprKind::Let.0: P<Pat>`
- Adjust `librustc_resolve/late.rs` to correctly handle or-patterns at any level of nesting as a result.
In particular, the already-bound check which rejects e.g. `let (a, a);` now accounts for or-patterns. The consistency checking (ensures no missing bindings and binding mode consistency) also now accounts for or-patterns. In the process, a bug was found in the current compiler which allowed:
```rust
enum E<T> { A(T, T), B(T) }
use E::*;
fn foo() {
match A(0, 1) {
B(mut a) | A(mut a, mut a) => {}
}
}
```
The new algorithms took a few iterations to get right. I tried several clever schemes but ultimately a version based on a stack of hashsets and recording product/sum contexts was chosen since it is more clearly correct.
- Clean up `librustc_resolve/late.rs` by, among other things, using a new `with_rib` function to better ensure stack dicipline.
- Do not push the change in AST to HIR for now to avoid doing too much in this PR. To cope with this, we introduce a temporary hack in `rustc::hir::lowering` (clearly marked in the diff).
cc https://github.com/rust-lang/rust/issues/54883
cc @dlrobertson @matthewjasper
r? @petrochenkov
|
|
|
|
|
|
|
|
The global restriction is 100, but since error codes are printed out via
--explain we want to restrict them to just 80 columns.
|
|
Also ensure that we're consistently using the def-site span when
appropriate.
|
|
Use these to create call-site spans for AST passes when needed.
|
|
|
|
use TokenStream rather than &[TokenTree] for built-in macros
That way, we don't loose the jointness info
|
|
|
|
They are only used by rustc_lexer, and are not needed elsewhere.
So we move the relevant definitions into rustc_lexer (while the actual
unicode data comes from the unicode-xid crate) and make the rest of
the compiler use it.
|
|
|
|
That way, we don't loose the jointness info
|
|
|
|
Cleanup: Consistently use `Param` instead of `Arg` #62426
Fixes #62426
|
|
|
|
Previously in was implemented using a special hack in the metadata loader
|
|
Replace them with equivalents of `Span::{def_site,call_site}` from proc macro API.
The new API is much less error prone and doesn't rely on macros having default transparency.
|
|
We now store it in the `Span` of the expression or item.
|
|
Also make them generally more hygienic with name resolution.
|
|
Hygienize use of built-in macros in the standard library
Same as https://github.com/rust-lang/rust/pull/61629, but for built-in macros.
Closes https://github.com/rust-lang/rust/issues/48781
r? @alexcrichton
|
|
Make sure that all file loading happens via SourceMap
That way, callers don't need to repeat "let's add this to sm manually
for tracking dependencies" trick.
It should make it easier to switch to using `FileLoader` for binary
files in the future as well
cc #62948
r? @petrochenkov
|
|
|
|
For naming consistency with everything else in this area
|
|
|
|
`Ident` has had a full span rather than just a `SyntaxContext` for a long time now.
|
|
For consistency with `ExpnId::root`.
Also introduce a helper `Span::with_root_ctxt` for creating spans with `SyntaxContext::root()` context
|
|
|
|
|
|
|
|
That way, callers don't need to repeat "let's add this to sm manually
for tracking dependencies" trick.
It should make it easier to switch to using `FileLoader` for binary
files in the future as well
|
|
Merge Variant and Variant_
Extracted from #63468.
|
|
Add NodeId for Arm, Field and FieldPat
Extracted from #63468
|
|
expand: Unimplement `MutVisitor` on `MacroExpander`
Each call to `fully_expand_fragment` is something unique, interesting, and requiring attention.
It represents a "root" of expansion and its use means that something unusual is happening, like eager expansion or expansion performed outside of the primary expansion pass.
So, it shouldn't hide under a generic visitor call.
Also, from all the implemented visitor methods only two were actually used.
cc https://github.com/rust-lang/rust/pull/63468#discussion_r313504119
|
|
|
|
|
