| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
A scheme for more macro-matcher friendly pre-expansion gating
Pre-expansion gating will now avoid gating macro matchers that did not result in `Success(...)`. That is, the following is now OK despite `box 42` being a valid `expr` and that form being pre-expansion gated:
```rust
macro_rules! m {
($e:expr) => { 0 }; // This fails on the input below due to `, foo`.
(box $e:expr, foo) => { 1 }; // Successful matcher, we should get `2`.
}
fn main() {
assert_eq!(1, m!(box 42, foo));
}
```
Closes https://github.com/rust-lang/rust/issues/65846.
r? @petrochenkov
cc @Mark-Simulacrum
|
|
|
|
|
|
|
|
syntax: Avoid span arithmetic for delimiter tokens
The +/-1 logic is from the time where the whole group had a single span and the delimiter spans had to be calculated from it.
Now the delimiters have their own spans which are constructed by lexer or proc macro API and can be used directly.
If those spans are not perfect, then it should be fixed by tweaking the corresponding lexer logic rather than by trying to add or substract `1` from the span boundaries.
Fixes https://github.com/rust-lang/rust/issues/62524
r? @estebank
|
|
|
|
|
|
When in a file with a non-terminated item, catch the error and consume
the block instead of trying to recover it more granularly in order to
reduce the amount of unrelated errors that would be fixed after adding
the missing closing brace. Also point out the possible location of the
missing closing brace.
|
|
move report_invalid_macro_expansion_item to item.rs
From https://github.com/rust-lang/rust/pull/65324.
r? @Mark-Simulacrum
|
|
|
|
|
|
refactor and move `maybe_append`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Remove `Option` from `TokenStream`
A code simplification.
r? @petrochenkov
|
|
Remove implicit dependencies on syntax::pprust
Part of https://github.com/rust-lang/rust/pull/65324.
The main goal here is to facilitate the eventual move of pprust out from libsyntax and because an AST definition typically should not depend on its pretty printer.
r? @estebank
|
|
|
|
|
|
Instead just use `pprust::path_to_string(..)` where needed.
This has two benefits:
a) The AST definition is now independent of printing it.
(Therefore we get closer to extracting a data-crate.)
b) Debugging should be easier as program flow is clearer.
|
|
|
|
Add support for `const unsafe? extern fn`
This works just as you might expect - an `const extern fn` is a `const fn` that is callable from foreign code.
Currently, panicking is not allowed in `const`s. When https://github.com/rust-lang/rfcs/pull/2345 (https://github.com/rust-lang/rust/issues/51999) is stabilized, then panicking in an `const extern fn` will produce a compile-time error when invoked at compile time, and an abort when invoked at runtime.
Since this is extending the language (we're allowing the `const` keyword in a new context), I believe that this will need an FCP. However, it's a very minor change, so I didn't think that filing an RFC was necessary.
This will allow libc (and other FFI crates) to make many functions `const`, without having to give up on making them `extern` as well.
Tracking issue: https://github.com/rust-lang/rust/issues/64926.
|
|
This commit improves the suggestions provided when function parameters
do not have types:
- A new suggestion is added for arbitrary self types, which suggests
adding `self: ` before the type.
- Existing suggestions are now provided when a `<` is found where a `:`
was expected (previously only `,` and `)` or trait items), this gives
suggestions in the case where the unnamed parameter type is generic
in a free function.
- The suggestion that a type name be provided (e.g. `fn foo(HashMap<u32>)`
-> `fn foo(HashMap: TypeName<u32>)`) will no longer occur when a `<` was
found instead of `:`.
- The ident will not be used for recovery when a `<` was found instead
of `:`.
Signed-off-by: David Wood <david@davidtw.co>
|
|
This works just as you might expect - an 'extern const fn' is a 'const
fn' that is callable from foreign code.
Currently, panicking is not allowed in consts. When RFC 2345 is
stabilized, then panicking in an 'extern const fn' will produce a
compile-time error when invoked at compile time, and an abort when
invoked at runtime.
Since this is extending the language (we're allowing the `const` keyword
in a new context), I believe that this will need an FCP. However, it's a
very minor change, so I didn't think that filing an RFC was necessary.
This will allow libc (and other FFI crates) to make many functions
`const`, without having to give up on making them `extern` as well.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
syntax: fix dropping of attribute on first param of non-method assocated fn
Fixes #64682.
The general idea is that we bake parsing of `self` into `parse_param_general` and then we just use standard list parsing. Overall, this simplifies the parsing and makes it more consistent.
r? @petrochenkov cc @c410-f3r
|
|
Fuse parsing of `self` into `parse_param_general`.
|
