Adds a `ProcMacro` form of syntax extension
This commit adds syntax extension forms matching the types for procedural macros 2.0 (RFC #1566), these still require the usual syntax extension boiler plate, but this is a first step towards proper implementation and should be useful for macros 1.1 stuff too.
Supports both attribute-like and function-like macros.
Note that RFC #1566 has not been accepted yet, but I think there is consensus that we want to head in vaguely that direction and so this PR will be useful in any case. It is also fairly easy to undo and does not break any existing programs.
This is related to #35957 in that I hope it can be used in the implementation of macros 1.1, however, there is no direct overlap and is more of a complement than a competing proposal. There is still a fair bit of work to do before the two can be combined.
r? @jseyfried
cc @alexcrichton, @cgswords, @eddyb, @aturon
Add the ability to merge spans to codemap
This PR adds the ability to merge Spans. To do so, it builds on the Codemap's ability to verify the locations of spans, namely that following can be verified:
* the expn_id of both spans much match
* the lhs span needs to end on the same line the rhs span begins
* the lhs span must start at or before the rhs span
If all of these are met, a new span is returned that is min(lo), max(hi) of the two spans.
This PR also removes an older Span merge, as this new functionality subsumes it.
r? @nrc
This commit adds syntax extension forms matching the types for procedural macros 2.0 (RFC #1566), these still require the usual syntax extension boiler plate, but this is a first step towards proper implementation and should be useful for macros 1.1 stuff too.
Supports both attribute-like and function-like macros.
Optimize the parser's last token handling.
The parser currently makes a heap copy of the last token in four cases:
identifiers, paths, doc comments, and commas. The identifier and
interpolation cases are unused, and for doc comments and commas we only
need to record their presence, not their value.
This commit consolidates the last token handling and avoids the
unnecessary copies by replacing `last_token`, `last_token_eof`, and
`last_token_interpolated` with a new field `last_token_kind`. This
simplifies the parser slightly and speeds up parsing on some files by
3--4%.
Overhaul char_lit()
This commit does the following.
- Removes parsing support for '\X12', '\u123456' and '\U12345678' char
literals. These are no longer valid Rust and rejected by the lexer.
(This strange-sounding situation occurs because the parser rescans
char literals to compute their value.)
- Rearranges the function so that all the escaped values are handled in
a single `match`. The error-handling strategy is based on the one used
by byte_lit().
Avoid loading and parsing unconfigured non-inline modules.
For example, `#[cfg(any())] mod foo;` will always compile after this PR, even if `foo.rs` and `foo/mod.rs` do not exist or do not contain valid Rust.
Fixes#36478 and fixes#27873.
r? @nrc
The parser currently makes a heap copy of the last token in four cases:
identifiers, paths, doc comments, and commas. The identifier and
interpolation cases are unused, and for doc comments and commas we only
need to record their presence, not their value.
This commit consolidates the last token handling and avoids the
unnecessary copies by replacing `last_token`, `last_token_eof`, and
`last_token_interpolated` with a new field `last_token_kind`. This
simplifies the parser slightly and speeds up parsing on some files by
3--4%.
This commit does the following.
- Removes parsing support for '\X12', '\u123456' and '\U12345678' char
literals. These are no longer valid Rust and rejected by the lexer.
(This strange-sounding situation occurs because the parser rescans
char literals to compute their value.)
- Rearranges the function so that all the escaped values are handled in
a single `match`, and changes the error-handling to use vanilla
assert!() and unwrap().
Assign node ids during macro expansion
After this PR,
- The `ExtCtxt` can access `resolve`'s `Resolver` through the trait object `ext::base::Resolver`.
- The `Resolver` trait object can load macros and replaces today's `MacroLoader` trait object.
- The macro expander uses the `Resolver` trait object to resolve macro invocations.
- The macro expander assigns node ids and builds the `Resolver`'s `macros_at_scope` map.
- This is groundwork for merging import resolution and expansion.
- Performance of expansion together with node id assignment improves by ~5%.
**EDIT:** Since Github is reordering the commits, here is `git log`:
- b54e1e3997: Differentiate between monotonic and non-monotonic expansion and only assign node ids during monotonic expansion.
- 78c0039878: Expand generated test harnesses and macro registries.
- f3c2dca353: Remove scope placeholders from the crate root.
- c86c8d41a2: Perform node id assignment and `macros_at_scope` construction during the `InvocationCollector` and `PlaceholderExpander` folds.
- 72a636975f: Move macro resolution into `librustc_resolve`.
- 20b43b2323: Rewrite the unit tests in `ext/expand.rs` as a `compile-fail` test.
- a9821e1658: Refactor `ExtCtxt` to use a `Resolver` instead of a `MacroLoader`.
- 60440b226d: Refactor `noop_fold_stmt_kind` out of `noop_fold_stmt`.
- 50f94f6c95: Avoid needless reexpansions.
r? @nrc
Improve shallow `Clone` deriving
`Copy` unions now support `#[derive(Clone)]`.
Less code is generated for `#[derive(Clone, Copy)]`.
+
Unions now support `#[derive(Eq)]`.
Less code is generated for `#[derive(Eq)]`.
---
Example of code reduction:
```
enum E {
A { a: u8, b: u16 },
B { c: [u8; 100] },
}
```
Before:
```
fn clone(&self) -> E {
match (&*self,) {
(&E::A { a: ref __self_0, b: ref __self_1 },) => {
::std::clone::assert_receiver_is_clone(&(*__self_0));
::std::clone::assert_receiver_is_clone(&(*__self_1));
*self
}
(&E::B { c: ref __self_0 },) => {
::std::clone::assert_receiver_is_clone(&(*__self_0));
*self
}
}
}
```
After:
```
fn clone(&self) -> E {
{
let _: ::std::clone::AssertParamIsClone<u8>;
let _: ::std::clone::AssertParamIsClone<u16>;
let _: ::std::clone::AssertParamIsClone<[u8; 100]>;
*self
}
}
```
All the matches are removed, bound assertions are more lightweight.
`let _: Checker<CheckMe>;`, unlike `checker(&check_me);`, doesn't have to be translated by rustc_trans and then inlined by LLVM, it doesn't even exist in MIR, this means faster compilation.
---
Union impls are generated like this:
```
union U {
a: u8,
b: u16,
c: [u8; 100],
}
```
```
fn clone(&self) -> U {
{
let _: ::std::clone::AssertParamIsCopy<Self>;
*self
}
}
```
Fixes https://github.com/rust-lang/rust/issues/36043
cc @durka
r? @alexcrichton
Documentation of what Default does for each type
Addresses #36265
I haven't changed the following types due to doubts:
1)src/libstd/ffi/c_str.rs
2)src/libcore/iter/sources.rs
3)src/libcore/hash/mod.rs
4)src/libcore/hash/mod.rs
5)src/librustc/middle/privacy.rs
r? @steveklabnik
libcompiler-rt.a is dead, long live libcompiler-builtins.rlib
This commit moves the logic that used to build libcompiler-rt.a into a
compiler-builtins crate on top of the core crate and below the std crate.
This new crate still compiles the compiler-rt instrinsics using gcc-rs
but produces an .rlib instead of a static library.
Also, with this commit rustc no longer passes -lcompiler-rt to the
linker. This effectively makes the "no-compiler-rt" field of target
specifications a no-op. Users of `no_std` will have to explicitly add
the compiler-builtins crate to their crate dependency graph *if* they
need the compiler-rt intrinsics. Users of the `std` have to do nothing
extra as the std crate depends on compiler-builtins.
Finally, this a step towards lazy compilation of std with Cargo as the
compiler-rt intrinsics can now be built by Cargo instead of having to
be supplied by the user by some other method.
closes#34400
Improve char_lit's readability and speed
This is my first contribution to rustc. Please let me know if I've done anything wrong. (I ran `make tidy` before making the pull request.)
This reduces the time taken to run
`rustc -Zparse-only rustc-benchmarks/issue-32278-big-array-of-strings`
from 0.18s to 0.15s on my machine, and reduces the number of
instructions (as measured by Cachegrind) from 1.34B to 1.01B.
With the change applied, the time to fully compile that benchmark is
1.96s, so this is a 1.5% improvement.
bors