| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
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
|
|
|
|
The expansion info is not optional and should always exist
|
|
`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
|
|
|
|
|
|
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 be hide under a generic visitor call.
Also, from all the implemented visitor methods only two were actually used.
|
|
|
|
|
|
|
|
|
|
```
error: unexpected `(` after qualified path
--> $DIR/vec-macro-in-pattern.rs:3:14
|
LL | Some(vec![x]) => (),
| ^^^^^^^
| |
| unexpected `(` after qualified path
| in this macro invocation
| use a slice pattern here instead
|
= help: for more information, see https://doc.rust-lang.org/edition-guide/rust-2018/slice-patterns.html
= note: this warning originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)
```
|
|
Some more libsyntax::attr cleanup
Much smaller patch than the last one, mostly just finishing up by removing some Span arguments.
r? @petrochenkov
|
|
|
|
|
|
|
|
Move special treatment of `derive(Copy, PartialEq, Eq)` from expansion infrastructure to elsewhere
As described in https://github.com/rust-lang/rust/pull/62086#issuecomment-515195477.
Reminder:
- `derive(PartialEq, Eq)` makes the type it applied to a "structural match" type, so constants of this type can be used in patterns (and const generics in the future).
- `derive(Copy)` notifies other derives that the type it applied to implements `Copy`, so `derive(Clone)` can generate optimized code and other derives can generate code working with `packed` types and types with `rustc_layout_scalar_valid_range` attributes.
First, the special behavior is now enabled after properly resolving the derives, rather than after textually comparing them with `"Copy"`, `"PartialEq"` and `"Eq"` in `fn add_derived_markers`.
The markers are no longer kept as attributes in AST since derives cannot modify items and previously did it through hacks in the expansion infra.
Instead, the markers are now kept in a "global context" available from all the necessary places, namely - resolver.
For `derive(PartialEq, Eq)` the markers are created by the derive macros themselves and then consumed during HIR lowering to add the `#[structural_match]` attribute in HIR.
This is still a hack, but now it's a hack local to two specific macros rather than affecting the whole expansion infra.
Ideally we should find the way to put `#[structural_match]` on the impls rather than on the original item, and then consume it in `rustc_mir`, then no hacks in expansion and lowering will be required.
(I'll make an issue about this for someone else to solve, after this PR lands.)
The marker for `derive(Copy)` cannot be emitted by the `Copy` macro itself because we need to know it *before* the `Copy` macro is expanded for expanding other macros.
So we have to do it in resolve and block expansion of any derives in a `derive(...)` container until we know for sure whether this container has `Copy` in it or not.
Nasty stuff.
r? @eddyb or @matthewjasper
|
|
Rename `ItemKind::Ty` to `ItemKind::TyAlias`
The current name is not entirely clear without context and `TyAlias` is consistent with `ItemKind::TraitAlias`.
|
|
|
|
Point at type ascription before macro invocation on expansion parse error
Fix https://github.com/rust-lang/rust/issues/47666. Follow up to https://github.com/rust-lang/rust/pull/62791.
r? @petrochenkov
|
|
infrastructure to elsewhere
|
|
Cleanup syntax::attr
Mostly removing needless arguments to constructors
r? @petrochenkov
|
|
Fix typo in Delimited::open_tt
|
|
|
|
|
|
|
|
Always the same as the passed MetaItem
|
|
MetaItem.span was always equivalent
|
|
|
|
There is no difference in the code/arguments, so go with the shorter
name throughout the code.
|
|
|
|
Lint attributes on function arguments
Fixes #61238.
cc #60406
|
|
Implement RFC 2707 + Parser recovery for range patterns
Implement https://github.com/rust-lang/rfcs/pull/2707.
- Add a new basic syntactic pattern form `ast::PatKind::Rest` (parsed as `..` or `DOTDOT`) and simplify `ast::PatKind::{Slice, Tuple, TupleStruct}` as a result.
- Lower `ast::PatKind::Rest` in combination with the aforementioned `PatKind` variants as well as `PatKind::Ident`. The HIR remains unchanged for now (may be advisable to make slight adjustments later).
- Refactor `parser.rs` wrt. parsing sequences and lists of things in the process.
- Add parser recovery for range patterns of form `X..`, `X..=`, `X...`, `..Y`, `..=Y`, and `...Y`.
This should make it easy to actually support these patterns semantically later if we so desire.
cc https://github.com/rust-lang/rust/issues/62254
r? @petrochenkov
|
|
|
|
Break dependencies between `syntax_ext` and other crates
Move `source_util` macros into `syntax_ext`.
Move other early code generation facilities like standard library injection into `syntax_ext`.
The only crate that depends on `syntax_ext` now is `rustc_interface` which is one of the "final" crates that depend on everything.
Minor: Cleanup dependencies of `rustc_driver`, many of them are no longer used after introduction of `rustc_interface`.
r? @eddyb
|
|
|
|
Few other minor renamings for consistency.
Remove one unused dependency from `rustc_passes`.
Fix libsyntax tests.
Fix rebase.
|
|
|
|
Move `source_uitil` macros into `syntax_ext`
Cleanup dependencies of `rustc_driver`
|
|
|
