| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Refactor the parser to consume token trees
This is groundwork for efficiently parsing attribute proc macro invocations, bang macro invocations, and `TokenStream`-based attributes and fragment matchers.
This improves parsing performance by 8-15% and expansion performance by 0-5% on a sampling of the compiler's crates.
r? @nrc
|
|
Implement `#[proc_macro_attribute]`
This implements `#[proc_macro_attribute]` as described in https://github.com/rust-lang/rfcs/pull/1566
The following major (hopefully non-breaking) changes are included:
* Refactor `proc_macro::TokenStream` to use `syntax::tokenstream::TokenStream`.
* `proc_macro::tokenstream::TokenStream` no longer emits newlines between items, this can be trivially restored if desired
* `proc_macro::TokenStream::from_str` does not try to parse an item anymore, moved to `impl MultiItemModifier for CustomDerive` with more informative error message
* Implement `#[proc_macro_attribute]`, which expects functions of the kind `fn(TokenStream, TokenStream) -> TokenStream`
* Reactivated `#![feature(proc_macro)]` and gated `#[proc_macro_attribute]` under it
* `#![feature(proc_macro)]` and `#![feature(custom_attribute)]` are mutually exclusive
* adding `#![feature(proc_macro)]` makes the expansion pass assume that any attributes that are not built-in, or introduced by existing syntax extensions, are proc-macro attributes
* Fix `feature_gate::find_lang_feature_issue()` to not use `unwrap()`
* This change wasn't necessary for this PR, but it helped debugging a problem where I was using the wrong feature string.
* Move "completed feature gate checking" pass to after "name resolution" pass
* This was necessary for proper feature-gating of `#[proc_macro_attribute]` invocations when the `proc_macro` feature flag isn't set.
Prototype/Litmus Test: [Implementation](https://github.com/abonander/anterofit/blob/proc_macro/service-attr/src/lib.rs#L13) -- [Usage](https://github.com/abonander/anterofit/blob/proc_macro/service-attr/examples/post_service.rs#L35)
|
|
Merge ObjectSum and PolyTraitRef in AST/HIR + some other refactoring
`ObjectSum` and `PolyTraitRef` are the same thing (list of bounds), they exist separately only due to parser quirks. The second commit merges them.
The first commit replaces `Path` with `Ty` in (not yet supported) equality predicates. They are parsed as types anyway and arbitrary types can always be disguised as paths using aliases, so this doesn't add any new functionality.
The third commit uses `Vec` instead of `P<[T]>` in AST. AST is not immutable like HIR and `Vec`s are more convenient for it, unnecessary conversions are also avoided.
The last commit renames `parse_ty_sum` (which is used for parsing types in general) into `parse_ty`, and renames `parse_ty` (which is used restricted contexts where `+` is not permitted due to operator priorities or other reasons) into `parse_ty_no_plus`.
This is the first part of https://github.com/rust-lang/rust/issues/39085#issuecomment-272743755 and https://github.com/rust-lang/rust/issues/39080 focused on data changes and mechanical renaming, I'll submit a PR with parser changes a bit later.
r? @eddyb
|
|
|
|
|
|
|
|
|
|
|
|
* Add support for `#[proc_macro]`
* Reactivate `proc_macro` feature and gate `#[proc_macro_attribute]` under it
* Have `#![feature(proc_macro)]` imply `#![feature(use_extern_macros)]`,
error on legacy import of proc macros via `#[macro_use]`
|
|
Rename ExprKind::Vec to Array in HIR and HAIR.
This is a clearer name since they represent `[a, b, c]` array literals.
r? @eddyb
|
|
|
|
|
|
|
|
This is a clearer name since they represent [a, b, c] array literals.
|
|
This marks the pushpop_unsafe feature as removed inside the feature_gate.
It was added in commit 1829fa5199bae5a192c771807c532badce14be37 and then
removed again in commit d399098fd82e0bf3ed61bbbbcdbb0b6adfa4c808 .
Seems that the second commit forgot to mark it as removed in feature_gate.rs.
This enables us to remove another element from the whitelist of non gate
tested unstable lang features (issue #39059).
|
|
syntax: enable attributes and cfg on struct fields
This enables conditional compilation of field initializers in a struct literal, simplifying construction of structs whose fields are themselves conditionally present. For example, the intializer for the constant in the following becomes legal, and has the intuitive effect:
```rust
struct Foo {
#[cfg(unix)]
bar: (),
}
const FOO: Foo = Foo {
#[cfg(unix)]
bar: (),
};
```
It's not clear to me whether this calls for the full RFC process, but the implementation was simple enough that I figured I'd begin the conversation with code.
|
|
|
|
This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the
compiler to stabilize the "Macros 1.1" feature of the language. Many more
details can be found on the tracking issue, #35900.
Closes #35900
|
|
This commit introduces 128-bit integers. Stage 2 builds and produces a working compiler which
understands and supports 128-bit integers throughout.
The general strategy used is to have rustc_i128 module which provides aliases for iu128, equal to
iu64 in stage9 and iu128 later. Since nowhere in rustc we rely on large numbers being supported,
this strategy is good enough to get past the first bootstrap stages to end up with a fully working
128-bit capable compiler.
In order for this strategy to work, number of locations had to be changed to use associated
max_value/min_value instead of MAX/MIN constants as well as the min_value (or was it max_value?)
had to be changed to use xor instead of shift so both 64-bit and 128-bit based consteval works
(former not necessarily producing the right results in stage1).
This commit includes manual merge conflict resolution changes from a rebase by @est31.
|
|
Allow legacy custom derive authors to disable warnings in downstream crates
This PR allows legacy custom derive authors to use a pre-deprecated method `registry.register_custom_derive()` instead of `registry.register_syntax_extension()` to avoid downstream deprecation warnings.
r? @nrc
|
|
|
|
|
|
Miscellaneous cleanup/refactoring in `resolve` and `syntax::ext`
r? @nrc
|
|
|
|
Don't perform span mangling when building field/tup access nodes
There are no guarantees that the two spans used to create the new one
come from the same place or are even valid.
Fixes #36081.
|
|
|
|
|
|
|
|
remove `export` argument of `resolver.add_macro()`.
|
|
|
|
macros: fix the expected paths for a non-inline module matched by an `item` fragment
Fixes #38190.
r? @nrc
|
|
fragment.
|
|
There are no guarantees that the two spans used to create the new one
come from the same place or are even valid.
Fixes #36081.
|
|
to a Visitor
|
|
|
|
Implement the `loop_break_value` feature.
This implements RFC 1624, tracking issue #37339.
- `FnCtxt` (in typeck) gets a stack of `LoopCtxt`s, which store the
currently deduced type of that loop, the desired type, and a list of
break expressions currently seen. `loop` loops get a fresh type
variable as their initial type (this logic is stolen from that for
arrays). `while` loops get `()`.
- `break {expr}` looks up the broken loop, and unifies the type of
`expr` with the type of the loop.
- `break` with no expr unifies the loop's type with `()`.
- When building MIR, loops no longer construct a `()` value at
termination of the loop; rather, the `break` expression assigns the
result of the loop.
- ~~I have also changed the loop scoping in MIR-building so that the test
of a while loop is not considered to be part of that loop. This makes
the rules consistent with #37360. The new loop scopes in typeck also
follow this rule. That means that `loop { while (break) {} }` now
terminates instead of looping forever. This is technically a breaking
change.~~
- ~~On that note, expressions like `while break {}` and `if break {}` no
longer parse because `{}` is interpreted as an expression argument to
`break`. But no code except compiler test cases should do that anyway
because it makes no sense.~~
- The RFC did not make it clear, but I chose to make `break ()` inside
of a `while` loop illegal, just in case we wanted to do anything with
that design space in the future.
This is my first time dealing with this part of rustc so I'm sure
there's plenty of problems to pick on here ^_^
|
|
This implements RFC 1624, tracking issue #37339.
- `FnCtxt` (in typeck) gets a stack of `LoopCtxt`s, which store the
currently deduced type of that loop, the desired type, and a list of
break expressions currently seen. `loop` loops get a fresh type
variable as their initial type (this logic is stolen from that for
arrays). `while` loops get `()`.
- `break {expr}` looks up the broken loop, and unifies the type of
`expr` with the type of the loop.
- `break` with no expr unifies the loop's type with `()`.
- When building MIR, `loop` loops no longer construct a `()` value at
termination of the loop; rather, the `break` expression assigns the
result of the loop. `while` loops are unchanged.
- `break` respects contexts in which expressions may not end with braced
blocks. That is, `while break { break-value } { while-body }` is
illegal; this preserves backwards compatibility.
- The RFC did not make it clear, but I chose to make `break ()` inside
of a `while` loop illegal, just in case we wanted to do anything with
that design space in the future.
This is my first time dealing with this part of rustc so I'm sure
there's plenty of problems to pick on here ^_^
|
|
|
|
|
|
|
|
places.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
