| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
This approach lives exclusively in the parser, so struct expr bodies
that are syntactically correct on their own but are otherwise incorrect
will still emit confusing errors, like in the following case:
```rust
fn foo() -> Foo {
bar: Vec::new()
}
```
```
error[E0425]: cannot find value `bar` in this scope
--> src/file.rs:5:5
|
5 | bar: Vec::new()
| ^^^ expecting a type here because of type ascription
error[E0214]: parenthesized type parameters may only be used with a `Fn` trait
--> src/file.rs:5:15
|
5 | bar: Vec::new()
| ^^^^^ only `Fn` traits may use parentheses
error[E0107]: wrong number of type arguments: expected 1, found 0
--> src/file.rs:5:10
|
5 | bar: Vec::new()
| ^^^^^^^^^^ expected 1 type argument
```
If that field had a trailing comma, that would be a parse error and it
would trigger the new, more targetted, error:
```
error: struct literal body without path
--> file.rs:4:17
|
4 | fn foo() -> Foo {
| _________________^
5 | | bar: Vec::new(),
6 | | }
| |_^
|
help: you might have forgotten to add the struct literal inside the block
|
4 | fn foo() -> Foo { Path {
5 | bar: Vec::new(),
6 | } }
|
```
Partially address last part of #34255.
|
|
|
|
|
|
|
|
|
|
This was a big hack, and built-in macros should be able to deal with `NtIdents` in the input by themselves like any other parser code.
|
|
|
|
Detect overflow in proc_macro_server subspan
* Detect overflow in proc_macro_server subspan
* Add tests for overflow in Vec::drain
* Add tests for overflow in String / VecDeque operations using ranges
|
|
We currently only attach tokens when parsing a `:stmt` matcher for a
`macro_rules!` macro. Proc-macro attributes on statements are still
unstable, and need additional work.
|
|
A `Visibility` does not have outer attributes, so we only capture tokens
when parsing a `macro_rules!` matcher
|
|
|
|
An `AttrItem` does not have outer attributes, so we only capture tokens
when parsing a `macro_rules!` matcher
|
|
A `Ty` does not have outer attributes, so we only capture tokens
when parsing a `macro_rules!` matcher
|
|
A `Block` does not have outer attributes, so we only capture tokens when
parsing a `macro_rules!` matcher
|
|
|
|
Rename IsJoint -> Spacing
Builds on #76286 and might conflict with #76285
r? `@petrochenkov`
|
|
This reverts commit 85cee57fd791d670d92dc61e0ad71594128dd45a, reversing
changes made to b4d387302416c90a3f70211770292d8d8ab5e07d.
|
|
Create E0774
|
|
r=nikomatsakis
remove public visibility previously needed for rustfmt
`submod_path_from_attr` in rustc_expand::module was previously public because it was also consumed by rustfmt. However, we've done a bit of refactoring in rustfmt and no longer need to use this function.
This changes the visibility to the parent mod as was originally going to be done before the rustfmt dependency was realized (https://github.com/rust-lang/rust/commit/c189565edc5c9fc516170885b3a3061b936205fb#diff-cd1b379893bae95f7991d5a3f3c6d337R201)
|
|
|
|
|
|
|
|
Cloning a tt is cheap, but not free (there's Arc inside).
|
|
To match better naming from proc-macro
|
|
Proc-macro API currently exposes jointness in `Punct` tokens. That is,
`+` in `+one` is **non** joint.
Our lexer produces jointness info for all tokens, so we need to censor
it *somewhere*
Previously we did this in a lexer, but it makes more sense to do this
in a proc-macro server.
|
|
Remove trivia tokens
r? @ghost
|
|
Factor out StmtKind::MacCall fields into `MacCallStmt` struct
In PR #76130, I add a fourth field, which makes using a tuple variant
somewhat unwieldy.
|
|
Run cfg-stripping on generic parameters before invoking derive macros
Fixes #75930
This changes the tokens seen by a proc-macro. However, ising a `#[cfg]` attribute
on a generic paramter is unusual, and combining it with a proc-macro
derive is probably even more unusual. I don't expect this to cause any
breakage.
|
|
|
|
Remove unused function
|
|
Fixes #75050
Previously, we would unconditionally suppress the panic hook during
proc-macro execution. This commit adds a new flag
-Z proc-macro-backtrace, which allows running the panic hook for
easier debugging.
|
|
In PR #76130, I add a fourth field, which makes using a tuple variant
somewhat unwieldy.
|
|
StringReader is an intornal abstraction which at the moment changes a
lot, so these unit tests cause quite a bit of friction.
Moving them to rustc_lexer and more ingerated-testing style should
make them much less annoying, hopefully without decreasing their
usefulness much.
Note that coloncolon tests are removed (it's unclear what those are
testing).
\r\n tests are removed as well, as we normalize line endings even
before lexing.
|
|
Fixes #75930
This changes the tokens seen by a proc-macro. However, ising a `#[cfg]` attribute
on a generic paramter is unusual, and combining it with a proc-macro
derive is probably even more unusual. I don't expect this to cause any
breakage.
|
|
|
