| Age | Commit message (Collapse) | Author | Lines |
|---|
|
mbe stands for macro-by-example
|
|
|
|
|
|
|
|
|
|
fully remove AstBuilder
The mentioned Cargo test is fixed in https://github.com/rust-lang/cargo/pull/7210
I think this can be removed now?
|
|
It was never used
|
|
The mentioned Cargo test is fixed in https://github.com/rust-lang/cargo/pull/7210
|
|
|
|
|
|
|
|
r=petrochenkov
Use `Symbol` in two more functions.
r? @petrochenkov
|
|
|
|
Cleanup handling of hygiene for built-in macros
This makes most identifiers generated by built-in macros use def-site hygiene, not only the ones that previously used gensyms.
* `ExtCtxt::ident_of` now takes a `Span` and is preferred to `Ident::{from_str, from_str_and_span}`
* Remove `Span::with_legacy_ctxt`
* `assert` now uses call-site hygiene because it needs to resolve `panic` unhygienically.
* `concat_idents` now uses call-site hygiene because it wouldn't be very useful with def-site hygiene.
* everything else is moved to def-site hygiene
r? @petrochenkov
|
|
|
|
|
|
|
|
|
|
Arm, Field, FieldPat, GenericParam, Param, StructField and Variant
|
|
|
|
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
|
|
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
|
|
|
|
On the call site, `rustc_lexer::is_whitespace` reads much better than
`character_properties::is_whitespace`.
|
|
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
|
|
resolve: Block expansion of a derive container until all its derives are resolved
So, it turns out there's one more reason to block expansion of a `#[derive]` container until all the derives inside it are resolved, beside `Copy` (https://github.com/rust-lang/rust/pull/63248).
The set of derive helper attributes registered by derives in the container also has to be known before the derives themselves are expanded, otherwise it may be too late (see https://github.com/rust-lang/rust/pull/63468#issuecomment-524550872 and the `#[stable_hasher]`-related test failures in https://github.com/rust-lang/rust/pull/63468).
So, we stop our attempts to unblock the container earlier, as soon as the `Copy` status is known, and just block until all its derives are resolved.
After all the derives are resolved we immediately go and process their helper attributes in the item, without delaying it until expansion of the individual derives.
Unblocks https://github.com/rust-lang/rust/pull/63468
r? @matthewjasper (as a reviewer of https://github.com/rust-lang/rust/pull/63248)
cc @c410-f3r
|
|
Cleanup: Consistently use `Param` instead of `Arg` #62426
Fixes #62426
|
|
|
|
Which is no longer dummy and is available from metadata now.
|
|
|
|
resolved
Also mark derive helpers as known as a part of the derive container's expansion instead of expansion of the derives themselves which may happen too late.
|
|
Modifies how Arg, Arm, Field, FieldPattern and Variant are visited
Part of the necessary work to accomplish #63468.
|
|
Part of the necessary work to accomplish #63468.
|
|
All transparancies are passed explicitly now.
Also remove `#[rustc_macro_transparency]` annotations from built-in macros, they are no longer used.
`#[rustc_macro_transparency]` only makes sense for declarative macros now.
|
|
|
|
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.
|
|
|
|
expression
Maybe it made sense when it was introduced, but now it's doing something incorrect.
|
|
Solve the problem of `ParentScope` entries for eager expansions not exising in the resolver map by creating them on demand.
|
|
|
|
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
|
|
|
