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
syntax: Remove `DummyResult::expr_only`
The effect is that if a built-in macro both returns an erroneous AST fragment and is used in unexpected position, then the incorrect position error won't be reported.
This combination of two errors should be rare and isn't worth an extra field that makes people ask questions in comments.
(There wasn't even a test making sure it worked.)
Addresses https://github.com/rust-lang/rust/pull/63468#discussion_r313504644
r? @estebank
syntax: account for CVarArgs being in the argument list.
Fixes#63430 by testing for `1` argument (the `CVarArgs` itself) instead of `0`.
Note that the error has basically been impossible to trigger since the change that caused #63430, so perhaps we need an audit of untested errors.
Also, this check probably belongs in AST validation/HIR lowering, but I'd rather fix it in place for now.
r? @petrochenkov cc @dlrobertson
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.
resolve: Remove remaining special cases from built-in macros
Edition and definition sites of the macros are now also taken from the `#[rustc_builtin_macro]` definitions in `libcore`.
---
The edition switch may be a breaking change for `Rustc{Encodable,Decodable}` derives if they are used in combination with the unstable crate `serialize` from sysroot like this
```rust
extern crate serialize;
use serialize as rustc_serialize;
#[derive(RustcEncodable)]
struct S;
```
(see the updated `ui-fulldeps` tests).
More explicit diagnostic when using a `vec![]` in a pattern
```
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)
```
Fix#61933.
```
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)
```
