| Age | Commit message (Collapse) | Author | Lines |
|
`TokenStream`-based attributes, paths in attribute and derive macro invocations
This PR
- refactors `Attribute` to use `Path` and `TokenStream` instead of `MetaItem`.
- supports macro invocation paths for attribute procedural macros.
- e.g. `#[::foo::attr_macro] struct S;`, `#[cfg_attr(all(), foo::attr_macro)] struct S;`
- supports macro invocation paths for derive procedural macros.
- e.g. `#[derive(foo::Bar, super::Baz)] struct S;`
- supports arbitrary tokens as arguments to attribute procedural macros.
- e.g. `#[foo::attr_macro arbitrary + tokens] struct S;`
- supports using arbitrary tokens in "inert attributes" with derive procedural macros.
- e.g. `#[derive(Foo)] struct S(#[inert arbitrary + tokens] i32);`
where `#[proc_macro_derive(Foo, attributes(inert))]`
r? @nrc
|
|
Fixes issue #40408.
|
|
|
|
|
|
Whenever we parse a chain of binary operations, as long as the first
operation is `<` and the subsequent operations are either `>` or `<`,
present the following diagnostic help:
use `::<...>` instead of `<...>` if you meant to specify type arguments
This will lead to spurious recommendations on situations like
`2 < 3 < 4` but should be clear from context that the help doesn't apply
in that case.
|
|
See https://github.com/rust-lang/rfcs/pull/1414.
Updates #38865.
|
|
Add catch {} to AST
Part of #39849. Builds on #39864.
|
|
|
|
|
|
|
|
Give spans to individual path segments in AST
And use these spans in path resolution diagnostics.
The spans are spans of identifiers in segments, not whole segments. I'm not sure what spans are more useful in general, but identifier spans are a better fit for resolve errors.
HIR still doesn't have spans.
Fixes https://github.com/rust-lang/rust/pull/38927#discussion_r95336667 https://github.com/rust-lang/rust/pull/38890#issuecomment-271731008
r? @nrc @eddyb
|
|
Update syntax for `pub(restricted)`
Update the syntax before stabilization.
cc https://github.com/rust-lang/rust/issues/32409
r? @nikomatsakis
|
|
|
|
|
|
syntax: add `ast::ItemKind::MacroDef`, simplify hygiene info
This PR
- adds a new variant `MacroDef` to `ast::ItemKind` for `macro_rules!` and eventually `macro` items,
- [breaking-change] forbids macro defs without a name (`macro_rules! { () => {} }` compiles today),
- removes `ast::MacroDef`, and
- no longer uses `Mark` and `Invocation` to identify and characterize macro definitions.
- We used to apply (at least) two `Mark`s to an expanded identifier's `SyntaxContext` -- the definition mark(s) and the expansion mark(s). We now only apply the latter.
r? @nrc
|
|
|
|
|
|
macros
|
|
|
|
|
|
|
|
Fix description of closure coercion feature
Thanks to @whitequark for pointing this out.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rollup of 7 pull requests
- Successful merges: #39832, #40104, #40110, #40117, #40129, #40139, #40166
- Failed merges:
|
|
Implement function-like procedural macros ( `#[proc_macro]`)
Adds the `#[proc_macro]` attribute, which expects bare functions of the kind `fn(TokenStream) -> TokenStream`, which can be invoked like `my_macro!()`.
cc rust-lang/rfcs#1913, #38356
r? @jseyfried
cc @nrc
|
|
Made no_stack_check a stable_removed attribute
r? @brson
|
|
Tracking issue: https://github.com/rust-lang/rust/issues/40180
This calling convention can be used for definining interrupt handlers on
32-bit and 64-bit x86 targets. The compiler then uses `iret` instead of
`ret` for returning and ensures that all registers are restored to their
original values.
Usage:
```
extern "x86-interrupt" fn handler(stack_frame: &ExceptionStackFrame) {…}
```
for interrupts and exceptions without error code and
```
extern "x86-interrupt" fn page_fault_handler(stack_frame: &ExceptionStackFrame,
error_code: u64) {…}
```
for exceptions that push an error code (e.g., page faults or general
protection faults). The programmer must ensure that the correct version
is used for each interrupt.
For more details see the [LLVM PR][1] and the corresponding [proposal][2].
[1]: https://reviews.llvm.org/D15567
[2]: http://lists.llvm.org/pipermail/cfe-dev/2015-September/045171.html
|
|
suggest doubling recursion limit in more situations
Fixes #38852.
r? @bluss
|
|
|
|
|
|
|
|
|
|
|
|
|
|
`tokenstream::TokenTree::Sequence`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
fixes #34915
|
|
|