2021-07-18 14:53:06 -05:00
|
|
|
use crate::base::ExtCtxt;
|
Remove `TokenStreamBuilder`.
`TokenStreamBuilder` exists to concatenate multiple `TokenStream`s
together. This commit removes it, and moves the concatenation
functionality directly into `TokenStream`, via two new methods
`push_tree` and `push_stream`. This makes things both simpler and
faster.
`push_tree` is particularly important. `TokenStreamBuilder` only had a
single `push` method, which pushed a stream. But in practice most of the
time we push a single token tree rather than a stream, and `push_tree`
avoids the need to build a token stream with a single entry (which
requires two allocations, one for the `Lrc` and one for the `Vec`).
The main `push_tree` use arises from a change to one of the `ToInternal`
impls in `proc_macro_server.rs`. It now returns a `SmallVec` instead of
a `TokenStream`. This return value is then iterated over by
`concat_trees`, which does `push_tree` on each element. Furthermore, the
use of `SmallVec` avoids more allocations, because there is always only
one or two token trees.
Note: the removed `TokenStreamBuilder::push` method had some code to
deal with a quadratic blowup case from #57735. This commit removes the
code. I tried and failed to reproduce the blowup from that PR, before
and after this change. Various other changes have happened to
`TokenStreamBuilder` in the meantime, so I suspect the original problem
is no longer relevant, though I don't have proof of this. Generally
speaking, repeatedly extending a `Vec` without pre-determining its
capacity is *not* quadratic. It's also incredibly common, within rustc
and many other Rust programs, so if there were performance problems
there you'd think it would show up in other places, too.
2022-10-04 18:38:15 -05:00
|
|
|
use pm::bridge::{
|
|
|
|
server, DelimSpan, Diagnostic, ExpnGlobals, Group, Ident, LitKind, Literal, Punct, TokenTree,
|
|
|
|
};
|
|
|
|
use pm::{Delimiter, Level, LineColumn};
|
2020-04-27 12:56:11 -05:00
|
|
|
use rustc_ast as ast;
|
2022-01-01 03:15:47 -06:00
|
|
|
use rustc_ast::token;
|
2021-07-01 16:36:38 -05:00
|
|
|
use rustc_ast::tokenstream::{self, Spacing::*, TokenStream};
|
2020-01-11 10:02:46 -06:00
|
|
|
use rustc_ast_pretty::pprust;
|
Implement span quoting for proc-macros
This PR implements span quoting, allowing proc-macros to produce spans
pointing *into their own crate*. This is used by the unstable
`proc_macro::quote!` macro, allowing us to get error messages like this:
```
error[E0412]: cannot find type `MissingType` in this scope
--> $DIR/auxiliary/span-from-proc-macro.rs:37:20
|
LL | pub fn error_from_attribute(_args: TokenStream, _input: TokenStream) -> TokenStream {
| ----------------------------------------------------------------------------------- in this expansion of procedural macro `#[error_from_attribute]`
...
LL | field: MissingType
| ^^^^^^^^^^^ not found in this scope
|
::: $DIR/span-from-proc-macro.rs:8:1
|
LL | #[error_from_attribute]
| ----------------------- in this macro invocation
```
Here, `MissingType` occurs inside the implementation of the proc-macro
`#[error_from_attribute]`. Previosuly, this would always result in a
span pointing at `#[error_from_attribute]`
This will make many proc-macro-related error message much more useful -
when a proc-macro generates code containing an error, users will get an
error message pointing directly at that code (within the macro
definition), instead of always getting a span pointing at the macro
invocation site.
This is implemented as follows:
* When a proc-macro crate is being *compiled*, it causes the `quote!`
macro to get run. This saves all of the sapns in the input to `quote!`
into the metadata of *the proc-macro-crate* (which we are currently
compiling). The `quote!` macro then expands to a call to
`proc_macro::Span::recover_proc_macro_span(id)`, where `id` is an
opaque identifier for the span in the crate metadata.
* When the same proc-macro crate is *run* (e.g. it is loaded from disk
and invoked by some consumer crate), the call to
`proc_macro::Span::recover_proc_macro_span` causes us to load the span
from the proc-macro crate's metadata. The proc-macro then produces a
`TokenStream` containing a `Span` pointing into the proc-macro crate
itself.
The recursive nature of 'quote!' can be difficult to understand at
first. The file `src/test/ui/proc-macro/quote-debug.stdout` shows
the output of the `quote!` macro, which should make this eaier to
understand.
This PR also supports custom quoting spans in custom quote macros (e.g.
the `quote` crate). All span quoting goes through the
`proc_macro::quote_span` method, which can be called by a custom quote
macro to perform span quoting. An example of this usage is provided in
`src/test/ui/proc-macro/auxiliary/custom-quote.rs`
Custom quoting currently has a few limitations:
In order to quote a span, we need to generate a call to
`proc_macro::Span::recover_proc_macro_span`. However, proc-macros
support renaming the `proc_macro` crate, so we can't simply hardcode
this path. Previously, the `quote_span` method used the path
`crate::Span` - however, this only works when it is called by the
builtin `quote!` macro in the same crate. To support being called from
arbitrary crates, we need access to the name of the `proc_macro` crate
to generate a path. This PR adds an additional argument to `quote_span`
to specify the name of the `proc_macro` crate. Howver, this feels kind
of hacky, and we may want to change this before stabilizing anything
quote-related.
Additionally, using `quote_span` currently requires enabling the
`proc_macro_internals` feature. The builtin `quote!` macro
has an `#[allow_internal_unstable]` attribute, but this won't work for
custom quote implementations. This will likely require some additional
tricks to apply `allow_internal_unstable` to the span of
`proc_macro::Span::recover_proc_macro_span`.
2020-08-02 18:52:16 -05:00
|
|
|
use rustc_data_structures::fx::FxHashMap;
|
2020-01-09 04:18:47 -06:00
|
|
|
use rustc_data_structures::sync::Lrc;
|
2022-07-24 23:43:33 -05:00
|
|
|
use rustc_errors::{MultiSpan, PResult};
|
2019-12-29 05:50:43 -06:00
|
|
|
use rustc_parse::lexer::nfc_normalize;
|
2022-05-21 07:50:39 -05:00
|
|
|
use rustc_parse::parse_stream_from_source_str;
|
2020-01-11 08:03:15 -06:00
|
|
|
use rustc_session::parse::ParseSess;
|
Implement span quoting for proc-macros
This PR implements span quoting, allowing proc-macros to produce spans
pointing *into their own crate*. This is used by the unstable
`proc_macro::quote!` macro, allowing us to get error messages like this:
```
error[E0412]: cannot find type `MissingType` in this scope
--> $DIR/auxiliary/span-from-proc-macro.rs:37:20
|
LL | pub fn error_from_attribute(_args: TokenStream, _input: TokenStream) -> TokenStream {
| ----------------------------------------------------------------------------------- in this expansion of procedural macro `#[error_from_attribute]`
...
LL | field: MissingType
| ^^^^^^^^^^^ not found in this scope
|
::: $DIR/span-from-proc-macro.rs:8:1
|
LL | #[error_from_attribute]
| ----------------------- in this macro invocation
```
Here, `MissingType` occurs inside the implementation of the proc-macro
`#[error_from_attribute]`. Previosuly, this would always result in a
span pointing at `#[error_from_attribute]`
This will make many proc-macro-related error message much more useful -
when a proc-macro generates code containing an error, users will get an
error message pointing directly at that code (within the macro
definition), instead of always getting a span pointing at the macro
invocation site.
This is implemented as follows:
* When a proc-macro crate is being *compiled*, it causes the `quote!`
macro to get run. This saves all of the sapns in the input to `quote!`
into the metadata of *the proc-macro-crate* (which we are currently
compiling). The `quote!` macro then expands to a call to
`proc_macro::Span::recover_proc_macro_span(id)`, where `id` is an
opaque identifier for the span in the crate metadata.
* When the same proc-macro crate is *run* (e.g. it is loaded from disk
and invoked by some consumer crate), the call to
`proc_macro::Span::recover_proc_macro_span` causes us to load the span
from the proc-macro crate's metadata. The proc-macro then produces a
`TokenStream` containing a `Span` pointing into the proc-macro crate
itself.
The recursive nature of 'quote!' can be difficult to understand at
first. The file `src/test/ui/proc-macro/quote-debug.stdout` shows
the output of the `quote!` macro, which should make this eaier to
understand.
This PR also supports custom quoting spans in custom quote macros (e.g.
the `quote` crate). All span quoting goes through the
`proc_macro::quote_span` method, which can be called by a custom quote
macro to perform span quoting. An example of this usage is provided in
`src/test/ui/proc-macro/auxiliary/custom-quote.rs`
Custom quoting currently has a few limitations:
In order to quote a span, we need to generate a call to
`proc_macro::Span::recover_proc_macro_span`. However, proc-macros
support renaming the `proc_macro` crate, so we can't simply hardcode
this path. Previously, the `quote_span` method used the path
`crate::Span` - however, this only works when it is called by the
builtin `quote!` macro in the same crate. To support being called from
arbitrary crates, we need access to the name of the `proc_macro` crate
to generate a path. This PR adds an additional argument to `quote_span`
to specify the name of the `proc_macro` crate. Howver, this feels kind
of hacky, and we may want to change this before stabilizing anything
quote-related.
Additionally, using `quote_span` currently requires enabling the
`proc_macro_internals` feature. The builtin `quote!` macro
has an `#[allow_internal_unstable]` attribute, but this won't work for
custom quote implementations. This will likely require some additional
tricks to apply `allow_internal_unstable` to the span of
`proc_macro::Span::recover_proc_macro_span`.
2020-08-02 18:52:16 -05:00
|
|
|
use rustc_span::def_id::CrateNum;
|
2022-06-30 20:05:46 -05:00
|
|
|
use rustc_span::symbol::{self, sym, Symbol};
|
2022-03-23 21:03:04 -05:00
|
|
|
use rustc_span::{BytePos, FileName, Pos, SourceFile, Span};
|
Remove `TokenStreamBuilder`.
`TokenStreamBuilder` exists to concatenate multiple `TokenStream`s
together. This commit removes it, and moves the concatenation
functionality directly into `TokenStream`, via two new methods
`push_tree` and `push_stream`. This makes things both simpler and
faster.
`push_tree` is particularly important. `TokenStreamBuilder` only had a
single `push` method, which pushed a stream. But in practice most of the
time we push a single token tree rather than a stream, and `push_tree`
avoids the need to build a token stream with a single entry (which
requires two allocations, one for the `Lrc` and one for the `Vec`).
The main `push_tree` use arises from a change to one of the `ToInternal`
impls in `proc_macro_server.rs`. It now returns a `SmallVec` instead of
a `TokenStream`. This return value is then iterated over by
`concat_trees`, which does `push_tree` on each element. Furthermore, the
use of `SmallVec` avoids more allocations, because there is always only
one or two token trees.
Note: the removed `TokenStreamBuilder::push` method had some code to
deal with a quadratic blowup case from #57735. This commit removes the
code. I tried and failed to reproduce the blowup from that PR, before
and after this change. Various other changes have happened to
`TokenStreamBuilder` in the meantime, so I suspect the original problem
is no longer relevant, though I don't have proof of this. Generally
speaking, repeatedly extending a `Vec` without pre-determining its
capacity is *not* quadratic. It's also incredibly common, within rustc
and many other Rust programs, so if there were performance problems
there you'd think it would show up in other places, too.
2022-10-04 18:38:15 -05:00
|
|
|
use smallvec::{smallvec, SmallVec};
|
2019-07-18 13:02:34 -05:00
|
|
|
use std::ops::Bound;
|
2018-07-19 07:59:08 -05:00
|
|
|
|
2018-03-20 09:41:14 -05:00
|
|
|
trait FromInternal<T> {
|
|
|
|
fn from_internal(x: T) -> Self;
|
|
|
|
}
|
|
|
|
|
|
|
|
trait ToInternal<T> {
|
|
|
|
fn to_internal(self) -> T;
|
|
|
|
}
|
|
|
|
|
2022-04-26 07:40:14 -05:00
|
|
|
impl FromInternal<token::Delimiter> for Delimiter {
|
|
|
|
fn from_internal(delim: token::Delimiter) -> Delimiter {
|
2018-07-19 07:59:08 -05:00
|
|
|
match delim {
|
2022-04-26 07:40:14 -05:00
|
|
|
token::Delimiter::Parenthesis => Delimiter::Parenthesis,
|
|
|
|
token::Delimiter::Brace => Delimiter::Brace,
|
|
|
|
token::Delimiter::Bracket => Delimiter::Bracket,
|
|
|
|
token::Delimiter::Invisible => Delimiter::None,
|
2018-07-19 07:59:08 -05:00
|
|
|
}
|
|
|
|
}
|
2018-03-20 09:41:14 -05:00
|
|
|
}
|
2018-07-19 07:59:08 -05:00
|
|
|
|
2022-04-26 07:40:14 -05:00
|
|
|
impl ToInternal<token::Delimiter> for Delimiter {
|
|
|
|
fn to_internal(self) -> token::Delimiter {
|
2018-07-19 07:59:08 -05:00
|
|
|
match self {
|
2022-04-26 07:40:14 -05:00
|
|
|
Delimiter::Parenthesis => token::Delimiter::Parenthesis,
|
|
|
|
Delimiter::Brace => token::Delimiter::Brace,
|
|
|
|
Delimiter::Bracket => token::Delimiter::Bracket,
|
|
|
|
Delimiter::None => token::Delimiter::Invisible,
|
2018-07-19 07:59:08 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-07-03 00:04:31 -05:00
|
|
|
impl FromInternal<token::LitKind> for LitKind {
|
|
|
|
fn from_internal(kind: token::LitKind) -> Self {
|
|
|
|
match kind {
|
|
|
|
token::Byte => LitKind::Byte,
|
|
|
|
token::Char => LitKind::Char,
|
|
|
|
token::Integer => LitKind::Integer,
|
|
|
|
token::Float => LitKind::Float,
|
|
|
|
token::Str => LitKind::Str,
|
|
|
|
token::StrRaw(n) => LitKind::StrRaw(n),
|
|
|
|
token::ByteStr => LitKind::ByteStr,
|
|
|
|
token::ByteStrRaw(n) => LitKind::ByteStrRaw(n),
|
|
|
|
token::Err => LitKind::Err,
|
|
|
|
token::Bool => unreachable!(),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl ToInternal<token::LitKind> for LitKind {
|
|
|
|
fn to_internal(self) -> token::LitKind {
|
|
|
|
match self {
|
|
|
|
LitKind::Byte => token::Byte,
|
|
|
|
LitKind::Char => token::Char,
|
|
|
|
LitKind::Integer => token::Integer,
|
|
|
|
LitKind::Float => token::Float,
|
|
|
|
LitKind::Str => token::Str,
|
|
|
|
LitKind::StrRaw(n) => token::StrRaw(n),
|
|
|
|
LitKind::ByteStr => token::ByteStr,
|
|
|
|
LitKind::ByteStrRaw(n) => token::ByteStrRaw(n),
|
|
|
|
LitKind::Err => token::Err,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl FromInternal<(TokenStream, &mut Rustc<'_, '_>)> for Vec<TokenTree<TokenStream, Span, Symbol>> {
|
2021-07-01 16:36:38 -05:00
|
|
|
fn from_internal((stream, rustc): (TokenStream, &mut Rustc<'_, '_>)) -> Self {
|
2020-02-29 11:37:32 -06:00
|
|
|
use rustc_ast::token::*;
|
2018-07-19 07:59:08 -05:00
|
|
|
|
2022-06-27 19:03:56 -05:00
|
|
|
// Estimate the capacity as `stream.len()` rounded up to the next power
|
|
|
|
// of two to limit the number of required reallocations.
|
|
|
|
let mut trees = Vec::with_capacity(stream.len().next_power_of_two());
|
2021-07-01 16:36:38 -05:00
|
|
|
let mut cursor = stream.into_trees();
|
|
|
|
|
Remove `TreeAndSpacing`.
A `TokenStream` contains a `Lrc<Vec<(TokenTree, Spacing)>>`. But this is
not quite right. `Spacing` makes sense for `TokenTree::Token`, but does
not make sense for `TokenTree::Delimited`, because a
`TokenTree::Delimited` cannot be joined with another `TokenTree`.
This commit fixes this problem, by adding `Spacing` to `TokenTree::Token`,
changing `TokenStream` to contain a `Lrc<Vec<TokenTree>>`, and removing the
`TreeAndSpacing` typedef.
The commit removes these two impls:
- `impl From<TokenTree> for TokenStream`
- `impl From<TokenTree> for TreeAndSpacing`
These were useful, but also resulted in code with many `.into()` calls
that was hard to read, particularly for anyone not highly familiar with
the relevant types. This commit makes some other changes to compensate:
- `TokenTree::token()` becomes `TokenTree::token_{alone,joint}()`.
- `TokenStream::token_{alone,joint}()` are added.
- `TokenStream::delimited` is added.
This results in things like this:
```rust
TokenTree::token(token::Semi, stmt.span).into()
```
changing to this:
```rust
TokenStream::token_alone(token::Semi, stmt.span)
```
This makes the type of the result, and its spacing, clearer.
These changes also simplifies `Cursor` and `CursorRef`, because they no longer
need to distinguish between `next` and `next_with_spacing`.
2022-07-27 19:31:04 -05:00
|
|
|
while let Some(tree) = cursor.next() {
|
|
|
|
let (Token { kind, span }, joint) = match tree {
|
2021-07-01 16:36:38 -05:00
|
|
|
tokenstream::TokenTree::Delimited(span, delim, tts) => {
|
|
|
|
let delimiter = pm::Delimiter::from_internal(delim);
|
|
|
|
trees.push(TokenTree::Group(Group {
|
|
|
|
delimiter,
|
|
|
|
stream: Some(tts),
|
|
|
|
span: DelimSpan {
|
|
|
|
open: span.open,
|
|
|
|
close: span.close,
|
|
|
|
entire: span.entire(),
|
|
|
|
},
|
|
|
|
}));
|
|
|
|
continue;
|
|
|
|
}
|
Remove `TreeAndSpacing`.
A `TokenStream` contains a `Lrc<Vec<(TokenTree, Spacing)>>`. But this is
not quite right. `Spacing` makes sense for `TokenTree::Token`, but does
not make sense for `TokenTree::Delimited`, because a
`TokenTree::Delimited` cannot be joined with another `TokenTree`.
This commit fixes this problem, by adding `Spacing` to `TokenTree::Token`,
changing `TokenStream` to contain a `Lrc<Vec<TokenTree>>`, and removing the
`TreeAndSpacing` typedef.
The commit removes these two impls:
- `impl From<TokenTree> for TokenStream`
- `impl From<TokenTree> for TreeAndSpacing`
These were useful, but also resulted in code with many `.into()` calls
that was hard to read, particularly for anyone not highly familiar with
the relevant types. This commit makes some other changes to compensate:
- `TokenTree::token()` becomes `TokenTree::token_{alone,joint}()`.
- `TokenStream::token_{alone,joint}()` are added.
- `TokenStream::delimited` is added.
This results in things like this:
```rust
TokenTree::token(token::Semi, stmt.span).into()
```
changing to this:
```rust
TokenStream::token_alone(token::Semi, stmt.span)
```
This makes the type of the result, and its spacing, clearer.
These changes also simplifies `Cursor` and `CursorRef`, because they no longer
need to distinguish between `next` and `next_with_spacing`.
2022-07-27 19:31:04 -05:00
|
|
|
tokenstream::TokenTree::Token(token, spacing) => (token, spacing == Joint),
|
2018-07-19 07:59:08 -05:00
|
|
|
};
|
|
|
|
|
2022-09-27 19:07:01 -05:00
|
|
|
// Split the operator into one or more `Punct`s, one per character.
|
|
|
|
// The final one inherits the jointness of the original token. Any
|
|
|
|
// before that get `joint = true`.
|
2022-06-27 19:03:56 -05:00
|
|
|
let mut op = |s: &str| {
|
|
|
|
assert!(s.is_ascii());
|
2022-10-02 21:57:47 -05:00
|
|
|
trees.extend(s.bytes().enumerate().map(|(i, ch)| {
|
|
|
|
let is_final = i == s.len() - 1;
|
|
|
|
// Split the token span into single chars. Unless the span
|
|
|
|
// is an unusual one, e.g. due to proc macro expansion. We
|
|
|
|
// determine this by assuming any span with a length that
|
|
|
|
// matches the operator length is a normal one, and any
|
|
|
|
// span with a different length is an unusual one.
|
|
|
|
let span = if (span.hi() - span.lo()).to_usize() == s.len() {
|
|
|
|
let lo = span.lo() + BytePos::from_usize(i);
|
|
|
|
let hi = lo + BytePos::from_usize(1);
|
|
|
|
span.with_lo(lo).with_hi(hi)
|
|
|
|
} else {
|
|
|
|
span
|
|
|
|
};
|
2022-09-27 19:07:01 -05:00
|
|
|
TokenTree::Punct(Punct { ch, joint: if is_final { joint } else { true }, span })
|
2022-06-27 19:03:56 -05:00
|
|
|
}));
|
|
|
|
};
|
2021-07-01 16:36:38 -05:00
|
|
|
|
|
|
|
match kind {
|
2022-06-27 19:03:56 -05:00
|
|
|
Eq => op("="),
|
|
|
|
Lt => op("<"),
|
|
|
|
Le => op("<="),
|
|
|
|
EqEq => op("=="),
|
|
|
|
Ne => op("!="),
|
|
|
|
Ge => op(">="),
|
|
|
|
Gt => op(">"),
|
|
|
|
AndAnd => op("&&"),
|
|
|
|
OrOr => op("||"),
|
|
|
|
Not => op("!"),
|
|
|
|
Tilde => op("~"),
|
|
|
|
BinOp(Plus) => op("+"),
|
|
|
|
BinOp(Minus) => op("-"),
|
|
|
|
BinOp(Star) => op("*"),
|
|
|
|
BinOp(Slash) => op("/"),
|
|
|
|
BinOp(Percent) => op("%"),
|
|
|
|
BinOp(Caret) => op("^"),
|
|
|
|
BinOp(And) => op("&"),
|
|
|
|
BinOp(Or) => op("|"),
|
|
|
|
BinOp(Shl) => op("<<"),
|
|
|
|
BinOp(Shr) => op(">>"),
|
|
|
|
BinOpEq(Plus) => op("+="),
|
|
|
|
BinOpEq(Minus) => op("-="),
|
|
|
|
BinOpEq(Star) => op("*="),
|
|
|
|
BinOpEq(Slash) => op("/="),
|
|
|
|
BinOpEq(Percent) => op("%="),
|
|
|
|
BinOpEq(Caret) => op("^="),
|
|
|
|
BinOpEq(And) => op("&="),
|
|
|
|
BinOpEq(Or) => op("|="),
|
|
|
|
BinOpEq(Shl) => op("<<="),
|
|
|
|
BinOpEq(Shr) => op(">>="),
|
|
|
|
At => op("@"),
|
|
|
|
Dot => op("."),
|
|
|
|
DotDot => op(".."),
|
|
|
|
DotDotDot => op("..."),
|
|
|
|
DotDotEq => op("..="),
|
|
|
|
Comma => op(","),
|
|
|
|
Semi => op(";"),
|
|
|
|
Colon => op(":"),
|
|
|
|
ModSep => op("::"),
|
|
|
|
RArrow => op("->"),
|
|
|
|
LArrow => op("<-"),
|
|
|
|
FatArrow => op("=>"),
|
|
|
|
Pound => op("#"),
|
|
|
|
Dollar => op("$"),
|
|
|
|
Question => op("?"),
|
|
|
|
SingleQuote => op("'"),
|
2021-07-01 16:36:38 -05:00
|
|
|
|
2022-06-30 20:05:46 -05:00
|
|
|
Ident(sym, is_raw) => trees.push(TokenTree::Ident(Ident { sym, is_raw, span })),
|
2021-07-01 16:36:38 -05:00
|
|
|
Lifetime(name) => {
|
|
|
|
let ident = symbol::Ident::new(name, span).without_first_quote();
|
2022-06-27 19:03:56 -05:00
|
|
|
trees.extend([
|
|
|
|
TokenTree::Punct(Punct { ch: b'\'', joint: true, span }),
|
2022-06-30 20:05:46 -05:00
|
|
|
TokenTree::Ident(Ident { sym: ident.name, is_raw: false, span }),
|
2022-06-27 19:03:56 -05:00
|
|
|
]);
|
2018-03-15 18:09:22 -05:00
|
|
|
}
|
2022-07-03 00:04:31 -05:00
|
|
|
Literal(token::Lit { kind, symbol, suffix }) => {
|
|
|
|
trees.push(TokenTree::Literal(self::Literal {
|
|
|
|
kind: FromInternal::from_internal(kind),
|
|
|
|
symbol,
|
|
|
|
suffix,
|
|
|
|
span,
|
|
|
|
}));
|
|
|
|
}
|
2021-07-01 16:36:38 -05:00
|
|
|
DocComment(_, attr_style, data) => {
|
|
|
|
let mut escaped = String::new();
|
|
|
|
for ch in data.as_str().chars() {
|
|
|
|
escaped.extend(ch.escape_debug());
|
|
|
|
}
|
2022-06-27 19:03:56 -05:00
|
|
|
let stream = [
|
2021-07-01 16:36:38 -05:00
|
|
|
Ident(sym::doc, false),
|
|
|
|
Eq,
|
|
|
|
TokenKind::lit(token::Str, Symbol::intern(&escaped), None),
|
|
|
|
]
|
|
|
|
.into_iter()
|
Remove `TreeAndSpacing`.
A `TokenStream` contains a `Lrc<Vec<(TokenTree, Spacing)>>`. But this is
not quite right. `Spacing` makes sense for `TokenTree::Token`, but does
not make sense for `TokenTree::Delimited`, because a
`TokenTree::Delimited` cannot be joined with another `TokenTree`.
This commit fixes this problem, by adding `Spacing` to `TokenTree::Token`,
changing `TokenStream` to contain a `Lrc<Vec<TokenTree>>`, and removing the
`TreeAndSpacing` typedef.
The commit removes these two impls:
- `impl From<TokenTree> for TokenStream`
- `impl From<TokenTree> for TreeAndSpacing`
These were useful, but also resulted in code with many `.into()` calls
that was hard to read, particularly for anyone not highly familiar with
the relevant types. This commit makes some other changes to compensate:
- `TokenTree::token()` becomes `TokenTree::token_{alone,joint}()`.
- `TokenStream::token_{alone,joint}()` are added.
- `TokenStream::delimited` is added.
This results in things like this:
```rust
TokenTree::token(token::Semi, stmt.span).into()
```
changing to this:
```rust
TokenStream::token_alone(token::Semi, stmt.span)
```
This makes the type of the result, and its spacing, clearer.
These changes also simplifies `Cursor` and `CursorRef`, because they no longer
need to distinguish between `next` and `next_with_spacing`.
2022-07-27 19:31:04 -05:00
|
|
|
.map(|kind| tokenstream::TokenTree::token_alone(kind, span))
|
2021-07-01 16:36:38 -05:00
|
|
|
.collect();
|
2022-06-27 19:03:56 -05:00
|
|
|
trees.push(TokenTree::Punct(Punct { ch: b'#', joint: false, span }));
|
2021-07-01 16:36:38 -05:00
|
|
|
if attr_style == ast::AttrStyle::Inner {
|
2022-06-27 19:03:56 -05:00
|
|
|
trees.push(TokenTree::Punct(Punct { ch: b'!', joint: false, span }));
|
2021-07-01 16:36:38 -05:00
|
|
|
}
|
|
|
|
trees.push(TokenTree::Group(Group {
|
|
|
|
delimiter: pm::Delimiter::Bracket,
|
|
|
|
stream: Some(stream),
|
|
|
|
span: DelimSpan::from_single(span),
|
|
|
|
}));
|
2018-07-19 07:59:08 -05:00
|
|
|
}
|
|
|
|
|
2021-07-01 16:36:38 -05:00
|
|
|
Interpolated(nt) if let NtIdent(ident, is_raw) = *nt => {
|
2022-06-30 20:05:46 -05:00
|
|
|
trees.push(TokenTree::Ident(Ident { sym: ident.name, is_raw, span: ident.span }))
|
2021-07-01 16:36:38 -05:00
|
|
|
}
|
2018-07-19 07:59:08 -05:00
|
|
|
|
2021-07-01 16:36:38 -05:00
|
|
|
Interpolated(nt) => {
|
|
|
|
let stream = TokenStream::from_nonterminal_ast(&nt);
|
2022-06-27 19:03:56 -05:00
|
|
|
// A hack used to pass AST fragments to attribute and derive
|
|
|
|
// macros as a single nonterminal token instead of a token
|
|
|
|
// stream. Such token needs to be "unwrapped" and not
|
|
|
|
// represented as a delimited group.
|
|
|
|
// FIXME: It needs to be removed, but there are some
|
|
|
|
// compatibility issues (see #73345).
|
2021-07-01 16:36:38 -05:00
|
|
|
if crate::base::nt_pretty_printing_compatibility_hack(&nt, rustc.sess()) {
|
|
|
|
trees.extend(Self::from_internal((stream, rustc)));
|
|
|
|
} else {
|
|
|
|
trees.push(TokenTree::Group(Group {
|
|
|
|
delimiter: pm::Delimiter::None,
|
|
|
|
stream: Some(stream),
|
|
|
|
span: DelimSpan::from_single(span),
|
|
|
|
}))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
OpenDelim(..) | CloseDelim(..) => unreachable!(),
|
|
|
|
Eof => unreachable!(),
|
|
|
|
}
|
2018-07-19 07:59:08 -05:00
|
|
|
}
|
2021-07-01 16:36:38 -05:00
|
|
|
trees
|
2018-07-19 07:59:08 -05:00
|
|
|
}
|
2018-03-20 09:41:14 -05:00
|
|
|
}
|
2018-07-19 07:59:08 -05:00
|
|
|
|
Remove `TokenStreamBuilder`.
`TokenStreamBuilder` exists to concatenate multiple `TokenStream`s
together. This commit removes it, and moves the concatenation
functionality directly into `TokenStream`, via two new methods
`push_tree` and `push_stream`. This makes things both simpler and
faster.
`push_tree` is particularly important. `TokenStreamBuilder` only had a
single `push` method, which pushed a stream. But in practice most of the
time we push a single token tree rather than a stream, and `push_tree`
avoids the need to build a token stream with a single entry (which
requires two allocations, one for the `Lrc` and one for the `Vec`).
The main `push_tree` use arises from a change to one of the `ToInternal`
impls in `proc_macro_server.rs`. It now returns a `SmallVec` instead of
a `TokenStream`. This return value is then iterated over by
`concat_trees`, which does `push_tree` on each element. Furthermore, the
use of `SmallVec` avoids more allocations, because there is always only
one or two token trees.
Note: the removed `TokenStreamBuilder::push` method had some code to
deal with a quadratic blowup case from #57735. This commit removes the
code. I tried and failed to reproduce the blowup from that PR, before
and after this change. Various other changes have happened to
`TokenStreamBuilder` in the meantime, so I suspect the original problem
is no longer relevant, though I don't have proof of this. Generally
speaking, repeatedly extending a `Vec` without pre-determining its
capacity is *not* quadratic. It's also incredibly common, within rustc
and many other Rust programs, so if there were performance problems
there you'd think it would show up in other places, too.
2022-10-04 18:38:15 -05:00
|
|
|
// We use a `SmallVec` because the output size is always one or two `TokenTree`s.
|
|
|
|
impl ToInternal<SmallVec<[tokenstream::TokenTree; 2]>>
|
|
|
|
for (TokenTree<TokenStream, Span, Symbol>, &mut Rustc<'_, '_>)
|
|
|
|
{
|
|
|
|
fn to_internal(self) -> SmallVec<[tokenstream::TokenTree; 2]> {
|
2020-02-29 11:37:32 -06:00
|
|
|
use rustc_ast::token::*;
|
2018-03-15 18:09:22 -05:00
|
|
|
|
2022-06-30 20:05:46 -05:00
|
|
|
let (tree, rustc) = self;
|
2022-10-04 18:33:49 -05:00
|
|
|
match tree {
|
|
|
|
TokenTree::Punct(Punct { ch, joint, span }) => {
|
|
|
|
let kind = match ch {
|
|
|
|
b'=' => Eq,
|
|
|
|
b'<' => Lt,
|
|
|
|
b'>' => Gt,
|
|
|
|
b'!' => Not,
|
|
|
|
b'~' => Tilde,
|
|
|
|
b'+' => BinOp(Plus),
|
|
|
|
b'-' => BinOp(Minus),
|
|
|
|
b'*' => BinOp(Star),
|
|
|
|
b'/' => BinOp(Slash),
|
|
|
|
b'%' => BinOp(Percent),
|
|
|
|
b'^' => BinOp(Caret),
|
|
|
|
b'&' => BinOp(And),
|
|
|
|
b'|' => BinOp(Or),
|
|
|
|
b'@' => At,
|
|
|
|
b'.' => Dot,
|
|
|
|
b',' => Comma,
|
|
|
|
b';' => Semi,
|
|
|
|
b':' => Colon,
|
|
|
|
b'#' => Pound,
|
|
|
|
b'$' => Dollar,
|
|
|
|
b'?' => Question,
|
|
|
|
b'\'' => SingleQuote,
|
|
|
|
_ => unreachable!(),
|
|
|
|
};
|
Remove `TokenStreamBuilder`.
`TokenStreamBuilder` exists to concatenate multiple `TokenStream`s
together. This commit removes it, and moves the concatenation
functionality directly into `TokenStream`, via two new methods
`push_tree` and `push_stream`. This makes things both simpler and
faster.
`push_tree` is particularly important. `TokenStreamBuilder` only had a
single `push` method, which pushed a stream. But in practice most of the
time we push a single token tree rather than a stream, and `push_tree`
avoids the need to build a token stream with a single entry (which
requires two allocations, one for the `Lrc` and one for the `Vec`).
The main `push_tree` use arises from a change to one of the `ToInternal`
impls in `proc_macro_server.rs`. It now returns a `SmallVec` instead of
a `TokenStream`. This return value is then iterated over by
`concat_trees`, which does `push_tree` on each element. Furthermore, the
use of `SmallVec` avoids more allocations, because there is always only
one or two token trees.
Note: the removed `TokenStreamBuilder::push` method had some code to
deal with a quadratic blowup case from #57735. This commit removes the
code. I tried and failed to reproduce the blowup from that PR, before
and after this change. Various other changes have happened to
`TokenStreamBuilder` in the meantime, so I suspect the original problem
is no longer relevant, though I don't have proof of this. Generally
speaking, repeatedly extending a `Vec` without pre-determining its
capacity is *not* quadratic. It's also incredibly common, within rustc
and many other Rust programs, so if there were performance problems
there you'd think it would show up in other places, too.
2022-10-04 18:38:15 -05:00
|
|
|
smallvec![if joint {
|
|
|
|
tokenstream::TokenTree::token_joint(kind, span)
|
2022-10-04 18:33:49 -05:00
|
|
|
} else {
|
Remove `TokenStreamBuilder`.
`TokenStreamBuilder` exists to concatenate multiple `TokenStream`s
together. This commit removes it, and moves the concatenation
functionality directly into `TokenStream`, via two new methods
`push_tree` and `push_stream`. This makes things both simpler and
faster.
`push_tree` is particularly important. `TokenStreamBuilder` only had a
single `push` method, which pushed a stream. But in practice most of the
time we push a single token tree rather than a stream, and `push_tree`
avoids the need to build a token stream with a single entry (which
requires two allocations, one for the `Lrc` and one for the `Vec`).
The main `push_tree` use arises from a change to one of the `ToInternal`
impls in `proc_macro_server.rs`. It now returns a `SmallVec` instead of
a `TokenStream`. This return value is then iterated over by
`concat_trees`, which does `push_tree` on each element. Furthermore, the
use of `SmallVec` avoids more allocations, because there is always only
one or two token trees.
Note: the removed `TokenStreamBuilder::push` method had some code to
deal with a quadratic blowup case from #57735. This commit removes the
code. I tried and failed to reproduce the blowup from that PR, before
and after this change. Various other changes have happened to
`TokenStreamBuilder` in the meantime, so I suspect the original problem
is no longer relevant, though I don't have proof of this. Generally
speaking, repeatedly extending a `Vec` without pre-determining its
capacity is *not* quadratic. It's also incredibly common, within rustc
and many other Rust programs, so if there were performance problems
there you'd think it would show up in other places, too.
2022-10-04 18:38:15 -05:00
|
|
|
tokenstream::TokenTree::token_alone(kind, span)
|
|
|
|
}]
|
2022-10-04 18:33:49 -05:00
|
|
|
}
|
2021-07-01 16:36:38 -05:00
|
|
|
TokenTree::Group(Group { delimiter, stream, span: DelimSpan { open, close, .. } }) => {
|
Remove `TokenStreamBuilder`.
`TokenStreamBuilder` exists to concatenate multiple `TokenStream`s
together. This commit removes it, and moves the concatenation
functionality directly into `TokenStream`, via two new methods
`push_tree` and `push_stream`. This makes things both simpler and
faster.
`push_tree` is particularly important. `TokenStreamBuilder` only had a
single `push` method, which pushed a stream. But in practice most of the
time we push a single token tree rather than a stream, and `push_tree`
avoids the need to build a token stream with a single entry (which
requires two allocations, one for the `Lrc` and one for the `Vec`).
The main `push_tree` use arises from a change to one of the `ToInternal`
impls in `proc_macro_server.rs`. It now returns a `SmallVec` instead of
a `TokenStream`. This return value is then iterated over by
`concat_trees`, which does `push_tree` on each element. Furthermore, the
use of `SmallVec` avoids more allocations, because there is always only
one or two token trees.
Note: the removed `TokenStreamBuilder::push` method had some code to
deal with a quadratic blowup case from #57735. This commit removes the
code. I tried and failed to reproduce the blowup from that PR, before
and after this change. Various other changes have happened to
`TokenStreamBuilder` in the meantime, so I suspect the original problem
is no longer relevant, though I don't have proof of this. Generally
speaking, repeatedly extending a `Vec` without pre-determining its
capacity is *not* quadratic. It's also incredibly common, within rustc
and many other Rust programs, so if there were performance problems
there you'd think it would show up in other places, too.
2022-10-04 18:38:15 -05:00
|
|
|
smallvec![tokenstream::TokenTree::Delimited(
|
2021-07-01 16:36:38 -05:00
|
|
|
tokenstream::DelimSpan { open, close },
|
|
|
|
delimiter.to_internal(),
|
|
|
|
stream.unwrap_or_default(),
|
Remove `TokenStreamBuilder`.
`TokenStreamBuilder` exists to concatenate multiple `TokenStream`s
together. This commit removes it, and moves the concatenation
functionality directly into `TokenStream`, via two new methods
`push_tree` and `push_stream`. This makes things both simpler and
faster.
`push_tree` is particularly important. `TokenStreamBuilder` only had a
single `push` method, which pushed a stream. But in practice most of the
time we push a single token tree rather than a stream, and `push_tree`
avoids the need to build a token stream with a single entry (which
requires two allocations, one for the `Lrc` and one for the `Vec`).
The main `push_tree` use arises from a change to one of the `ToInternal`
impls in `proc_macro_server.rs`. It now returns a `SmallVec` instead of
a `TokenStream`. This return value is then iterated over by
`concat_trees`, which does `push_tree` on each element. Furthermore, the
use of `SmallVec` avoids more allocations, because there is always only
one or two token trees.
Note: the removed `TokenStreamBuilder::push` method had some code to
deal with a quadratic blowup case from #57735. This commit removes the
code. I tried and failed to reproduce the blowup from that PR, before
and after this change. Various other changes have happened to
`TokenStreamBuilder` in the meantime, so I suspect the original problem
is no longer relevant, though I don't have proof of this. Generally
speaking, repeatedly extending a `Vec` without pre-determining its
capacity is *not* quadratic. It's also incredibly common, within rustc
and many other Rust programs, so if there were performance problems
there you'd think it would show up in other places, too.
2022-10-04 18:38:15 -05:00
|
|
|
)]
|
2018-07-19 07:59:08 -05:00
|
|
|
}
|
2018-12-08 12:00:39 -06:00
|
|
|
TokenTree::Ident(self::Ident { sym, is_raw, span }) => {
|
2022-06-30 20:05:46 -05:00
|
|
|
rustc.sess().symbol_gallery.insert(sym, span);
|
Remove `TokenStreamBuilder`.
`TokenStreamBuilder` exists to concatenate multiple `TokenStream`s
together. This commit removes it, and moves the concatenation
functionality directly into `TokenStream`, via two new methods
`push_tree` and `push_stream`. This makes things both simpler and
faster.
`push_tree` is particularly important. `TokenStreamBuilder` only had a
single `push` method, which pushed a stream. But in practice most of the
time we push a single token tree rather than a stream, and `push_tree`
avoids the need to build a token stream with a single entry (which
requires two allocations, one for the `Lrc` and one for the `Vec`).
The main `push_tree` use arises from a change to one of the `ToInternal`
impls in `proc_macro_server.rs`. It now returns a `SmallVec` instead of
a `TokenStream`. This return value is then iterated over by
`concat_trees`, which does `push_tree` on each element. Furthermore, the
use of `SmallVec` avoids more allocations, because there is always only
one or two token trees.
Note: the removed `TokenStreamBuilder::push` method had some code to
deal with a quadratic blowup case from #57735. This commit removes the
code. I tried and failed to reproduce the blowup from that PR, before
and after this change. Various other changes have happened to
`TokenStreamBuilder` in the meantime, so I suspect the original problem
is no longer relevant, though I don't have proof of this. Generally
speaking, repeatedly extending a `Vec` without pre-determining its
capacity is *not* quadratic. It's also incredibly common, within rustc
and many other Rust programs, so if there were performance problems
there you'd think it would show up in other places, too.
2022-10-04 18:38:15 -05:00
|
|
|
smallvec![tokenstream::TokenTree::token_alone(Ident(sym, is_raw), span)]
|
2018-07-19 07:59:08 -05:00
|
|
|
}
|
2018-03-15 18:09:22 -05:00
|
|
|
TokenTree::Literal(self::Literal {
|
2022-07-03 00:04:31 -05:00
|
|
|
kind: self::LitKind::Integer,
|
|
|
|
symbol,
|
|
|
|
suffix,
|
2018-07-19 07:59:08 -05:00
|
|
|
span,
|
2020-02-26 06:03:46 -06:00
|
|
|
}) if symbol.as_str().starts_with('-') => {
|
2018-07-19 07:59:08 -05:00
|
|
|
let minus = BinOp(BinOpToken::Minus);
|
2019-05-18 17:04:26 -05:00
|
|
|
let symbol = Symbol::intern(&symbol.as_str()[1..]);
|
2019-06-04 09:55:23 -05:00
|
|
|
let integer = TokenKind::lit(token::Integer, symbol, suffix);
|
Remove `TreeAndSpacing`.
A `TokenStream` contains a `Lrc<Vec<(TokenTree, Spacing)>>`. But this is
not quite right. `Spacing` makes sense for `TokenTree::Token`, but does
not make sense for `TokenTree::Delimited`, because a
`TokenTree::Delimited` cannot be joined with another `TokenTree`.
This commit fixes this problem, by adding `Spacing` to `TokenTree::Token`,
changing `TokenStream` to contain a `Lrc<Vec<TokenTree>>`, and removing the
`TreeAndSpacing` typedef.
The commit removes these two impls:
- `impl From<TokenTree> for TokenStream`
- `impl From<TokenTree> for TreeAndSpacing`
These were useful, but also resulted in code with many `.into()` calls
that was hard to read, particularly for anyone not highly familiar with
the relevant types. This commit makes some other changes to compensate:
- `TokenTree::token()` becomes `TokenTree::token_{alone,joint}()`.
- `TokenStream::token_{alone,joint}()` are added.
- `TokenStream::delimited` is added.
This results in things like this:
```rust
TokenTree::token(token::Semi, stmt.span).into()
```
changing to this:
```rust
TokenStream::token_alone(token::Semi, stmt.span)
```
This makes the type of the result, and its spacing, clearer.
These changes also simplifies `Cursor` and `CursorRef`, because they no longer
need to distinguish between `next` and `next_with_spacing`.
2022-07-27 19:31:04 -05:00
|
|
|
let a = tokenstream::TokenTree::token_alone(minus, span);
|
|
|
|
let b = tokenstream::TokenTree::token_alone(integer, span);
|
Remove `TokenStreamBuilder`.
`TokenStreamBuilder` exists to concatenate multiple `TokenStream`s
together. This commit removes it, and moves the concatenation
functionality directly into `TokenStream`, via two new methods
`push_tree` and `push_stream`. This makes things both simpler and
faster.
`push_tree` is particularly important. `TokenStreamBuilder` only had a
single `push` method, which pushed a stream. But in practice most of the
time we push a single token tree rather than a stream, and `push_tree`
avoids the need to build a token stream with a single entry (which
requires two allocations, one for the `Lrc` and one for the `Vec`).
The main `push_tree` use arises from a change to one of the `ToInternal`
impls in `proc_macro_server.rs`. It now returns a `SmallVec` instead of
a `TokenStream`. This return value is then iterated over by
`concat_trees`, which does `push_tree` on each element. Furthermore, the
use of `SmallVec` avoids more allocations, because there is always only
one or two token trees.
Note: the removed `TokenStreamBuilder::push` method had some code to
deal with a quadratic blowup case from #57735. This commit removes the
code. I tried and failed to reproduce the blowup from that PR, before
and after this change. Various other changes have happened to
`TokenStreamBuilder` in the meantime, so I suspect the original problem
is no longer relevant, though I don't have proof of this. Generally
speaking, repeatedly extending a `Vec` without pre-determining its
capacity is *not* quadratic. It's also incredibly common, within rustc
and many other Rust programs, so if there were performance problems
there you'd think it would show up in other places, too.
2022-10-04 18:38:15 -05:00
|
|
|
smallvec![a, b]
|
2018-07-19 07:59:08 -05:00
|
|
|
}
|
2018-03-15 18:09:22 -05:00
|
|
|
TokenTree::Literal(self::Literal {
|
2022-07-03 00:04:31 -05:00
|
|
|
kind: self::LitKind::Float,
|
|
|
|
symbol,
|
|
|
|
suffix,
|
2018-07-19 07:59:08 -05:00
|
|
|
span,
|
2020-02-26 06:03:46 -06:00
|
|
|
}) if symbol.as_str().starts_with('-') => {
|
2018-07-19 07:59:08 -05:00
|
|
|
let minus = BinOp(BinOpToken::Minus);
|
2019-05-18 17:04:26 -05:00
|
|
|
let symbol = Symbol::intern(&symbol.as_str()[1..]);
|
2019-06-04 09:55:23 -05:00
|
|
|
let float = TokenKind::lit(token::Float, symbol, suffix);
|
Remove `TreeAndSpacing`.
A `TokenStream` contains a `Lrc<Vec<(TokenTree, Spacing)>>`. But this is
not quite right. `Spacing` makes sense for `TokenTree::Token`, but does
not make sense for `TokenTree::Delimited`, because a
`TokenTree::Delimited` cannot be joined with another `TokenTree`.
This commit fixes this problem, by adding `Spacing` to `TokenTree::Token`,
changing `TokenStream` to contain a `Lrc<Vec<TokenTree>>`, and removing the
`TreeAndSpacing` typedef.
The commit removes these two impls:
- `impl From<TokenTree> for TokenStream`
- `impl From<TokenTree> for TreeAndSpacing`
These were useful, but also resulted in code with many `.into()` calls
that was hard to read, particularly for anyone not highly familiar with
the relevant types. This commit makes some other changes to compensate:
- `TokenTree::token()` becomes `TokenTree::token_{alone,joint}()`.
- `TokenStream::token_{alone,joint}()` are added.
- `TokenStream::delimited` is added.
This results in things like this:
```rust
TokenTree::token(token::Semi, stmt.span).into()
```
changing to this:
```rust
TokenStream::token_alone(token::Semi, stmt.span)
```
This makes the type of the result, and its spacing, clearer.
These changes also simplifies `Cursor` and `CursorRef`, because they no longer
need to distinguish between `next` and `next_with_spacing`.
2022-07-27 19:31:04 -05:00
|
|
|
let a = tokenstream::TokenTree::token_alone(minus, span);
|
|
|
|
let b = tokenstream::TokenTree::token_alone(float, span);
|
Remove `TokenStreamBuilder`.
`TokenStreamBuilder` exists to concatenate multiple `TokenStream`s
together. This commit removes it, and moves the concatenation
functionality directly into `TokenStream`, via two new methods
`push_tree` and `push_stream`. This makes things both simpler and
faster.
`push_tree` is particularly important. `TokenStreamBuilder` only had a
single `push` method, which pushed a stream. But in practice most of the
time we push a single token tree rather than a stream, and `push_tree`
avoids the need to build a token stream with a single entry (which
requires two allocations, one for the `Lrc` and one for the `Vec`).
The main `push_tree` use arises from a change to one of the `ToInternal`
impls in `proc_macro_server.rs`. It now returns a `SmallVec` instead of
a `TokenStream`. This return value is then iterated over by
`concat_trees`, which does `push_tree` on each element. Furthermore, the
use of `SmallVec` avoids more allocations, because there is always only
one or two token trees.
Note: the removed `TokenStreamBuilder::push` method had some code to
deal with a quadratic blowup case from #57735. This commit removes the
code. I tried and failed to reproduce the blowup from that PR, before
and after this change. Various other changes have happened to
`TokenStreamBuilder` in the meantime, so I suspect the original problem
is no longer relevant, though I don't have proof of this. Generally
speaking, repeatedly extending a `Vec` without pre-determining its
capacity is *not* quadratic. It's also incredibly common, within rustc
and many other Rust programs, so if there were performance problems
there you'd think it would show up in other places, too.
2022-10-04 18:38:15 -05:00
|
|
|
smallvec![a, b]
|
2018-07-19 07:59:08 -05:00
|
|
|
}
|
2022-07-03 00:04:31 -05:00
|
|
|
TokenTree::Literal(self::Literal { kind, symbol, suffix, span }) => {
|
Remove `TokenStreamBuilder`.
`TokenStreamBuilder` exists to concatenate multiple `TokenStream`s
together. This commit removes it, and moves the concatenation
functionality directly into `TokenStream`, via two new methods
`push_tree` and `push_stream`. This makes things both simpler and
faster.
`push_tree` is particularly important. `TokenStreamBuilder` only had a
single `push` method, which pushed a stream. But in practice most of the
time we push a single token tree rather than a stream, and `push_tree`
avoids the need to build a token stream with a single entry (which
requires two allocations, one for the `Lrc` and one for the `Vec`).
The main `push_tree` use arises from a change to one of the `ToInternal`
impls in `proc_macro_server.rs`. It now returns a `SmallVec` instead of
a `TokenStream`. This return value is then iterated over by
`concat_trees`, which does `push_tree` on each element. Furthermore, the
use of `SmallVec` avoids more allocations, because there is always only
one or two token trees.
Note: the removed `TokenStreamBuilder::push` method had some code to
deal with a quadratic blowup case from #57735. This commit removes the
code. I tried and failed to reproduce the blowup from that PR, before
and after this change. Various other changes have happened to
`TokenStreamBuilder` in the meantime, so I suspect the original problem
is no longer relevant, though I don't have proof of this. Generally
speaking, repeatedly extending a `Vec` without pre-determining its
capacity is *not* quadratic. It's also incredibly common, within rustc
and many other Rust programs, so if there were performance problems
there you'd think it would show up in other places, too.
2022-10-04 18:38:15 -05:00
|
|
|
smallvec![tokenstream::TokenTree::token_alone(
|
2022-07-03 00:04:31 -05:00
|
|
|
TokenKind::lit(kind.to_internal(), symbol, suffix),
|
|
|
|
span,
|
Remove `TokenStreamBuilder`.
`TokenStreamBuilder` exists to concatenate multiple `TokenStream`s
together. This commit removes it, and moves the concatenation
functionality directly into `TokenStream`, via two new methods
`push_tree` and `push_stream`. This makes things both simpler and
faster.
`push_tree` is particularly important. `TokenStreamBuilder` only had a
single `push` method, which pushed a stream. But in practice most of the
time we push a single token tree rather than a stream, and `push_tree`
avoids the need to build a token stream with a single entry (which
requires two allocations, one for the `Lrc` and one for the `Vec`).
The main `push_tree` use arises from a change to one of the `ToInternal`
impls in `proc_macro_server.rs`. It now returns a `SmallVec` instead of
a `TokenStream`. This return value is then iterated over by
`concat_trees`, which does `push_tree` on each element. Furthermore, the
use of `SmallVec` avoids more allocations, because there is always only
one or two token trees.
Note: the removed `TokenStreamBuilder::push` method had some code to
deal with a quadratic blowup case from #57735. This commit removes the
code. I tried and failed to reproduce the blowup from that PR, before
and after this change. Various other changes have happened to
`TokenStreamBuilder` in the meantime, so I suspect the original problem
is no longer relevant, though I don't have proof of this. Generally
speaking, repeatedly extending a `Vec` without pre-determining its
capacity is *not* quadratic. It's also incredibly common, within rustc
and many other Rust programs, so if there were performance problems
there you'd think it would show up in other places, too.
2022-10-04 18:38:15 -05:00
|
|
|
)]
|
2018-07-19 07:59:08 -05:00
|
|
|
}
|
Remove `TreeAndSpacing`.
A `TokenStream` contains a `Lrc<Vec<(TokenTree, Spacing)>>`. But this is
not quite right. `Spacing` makes sense for `TokenTree::Token`, but does
not make sense for `TokenTree::Delimited`, because a
`TokenTree::Delimited` cannot be joined with another `TokenTree`.
This commit fixes this problem, by adding `Spacing` to `TokenTree::Token`,
changing `TokenStream` to contain a `Lrc<Vec<TokenTree>>`, and removing the
`TreeAndSpacing` typedef.
The commit removes these two impls:
- `impl From<TokenTree> for TokenStream`
- `impl From<TokenTree> for TreeAndSpacing`
These were useful, but also resulted in code with many `.into()` calls
that was hard to read, particularly for anyone not highly familiar with
the relevant types. This commit makes some other changes to compensate:
- `TokenTree::token()` becomes `TokenTree::token_{alone,joint}()`.
- `TokenStream::token_{alone,joint}()` are added.
- `TokenStream::delimited` is added.
This results in things like this:
```rust
TokenTree::token(token::Semi, stmt.span).into()
```
changing to this:
```rust
TokenStream::token_alone(token::Semi, stmt.span)
```
This makes the type of the result, and its spacing, clearer.
These changes also simplifies `Cursor` and `CursorRef`, because they no longer
need to distinguish between `next` and `next_with_spacing`.
2022-07-27 19:31:04 -05:00
|
|
|
}
|
2018-07-19 07:59:08 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-01-09 04:18:47 -06:00
|
|
|
impl ToInternal<rustc_errors::Level> for Level {
|
|
|
|
fn to_internal(self) -> rustc_errors::Level {
|
2018-07-19 07:59:08 -05:00
|
|
|
match self {
|
2021-07-20 22:23:22 -05:00
|
|
|
Level::Error => rustc_errors::Level::Error { lint: false },
|
2022-06-05 05:33:45 -05:00
|
|
|
Level::Warning => rustc_errors::Level::Warning(None),
|
2020-01-09 04:18:47 -06:00
|
|
|
Level::Note => rustc_errors::Level::Note,
|
|
|
|
Level::Help => rustc_errors::Level::Help,
|
2018-03-20 09:41:14 -05:00
|
|
|
_ => unreachable!("unknown proc_macro::Level variant: {:?}", self),
|
2018-07-19 07:59:08 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2018-03-15 18:09:22 -05:00
|
|
|
|
2020-07-22 13:08:01 -05:00
|
|
|
pub struct FreeFunctions;
|
|
|
|
|
2021-07-18 14:53:06 -05:00
|
|
|
pub(crate) struct Rustc<'a, 'b> {
|
|
|
|
ecx: &'a mut ExtCtxt<'b>,
|
2018-03-19 15:44:24 -05:00
|
|
|
def_site: Span,
|
|
|
|
call_site: Span,
|
2019-09-22 10:38:02 -05:00
|
|
|
mixed_site: Span,
|
Implement span quoting for proc-macros
This PR implements span quoting, allowing proc-macros to produce spans
pointing *into their own crate*. This is used by the unstable
`proc_macro::quote!` macro, allowing us to get error messages like this:
```
error[E0412]: cannot find type `MissingType` in this scope
--> $DIR/auxiliary/span-from-proc-macro.rs:37:20
|
LL | pub fn error_from_attribute(_args: TokenStream, _input: TokenStream) -> TokenStream {
| ----------------------------------------------------------------------------------- in this expansion of procedural macro `#[error_from_attribute]`
...
LL | field: MissingType
| ^^^^^^^^^^^ not found in this scope
|
::: $DIR/span-from-proc-macro.rs:8:1
|
LL | #[error_from_attribute]
| ----------------------- in this macro invocation
```
Here, `MissingType` occurs inside the implementation of the proc-macro
`#[error_from_attribute]`. Previosuly, this would always result in a
span pointing at `#[error_from_attribute]`
This will make many proc-macro-related error message much more useful -
when a proc-macro generates code containing an error, users will get an
error message pointing directly at that code (within the macro
definition), instead of always getting a span pointing at the macro
invocation site.
This is implemented as follows:
* When a proc-macro crate is being *compiled*, it causes the `quote!`
macro to get run. This saves all of the sapns in the input to `quote!`
into the metadata of *the proc-macro-crate* (which we are currently
compiling). The `quote!` macro then expands to a call to
`proc_macro::Span::recover_proc_macro_span(id)`, where `id` is an
opaque identifier for the span in the crate metadata.
* When the same proc-macro crate is *run* (e.g. it is loaded from disk
and invoked by some consumer crate), the call to
`proc_macro::Span::recover_proc_macro_span` causes us to load the span
from the proc-macro crate's metadata. The proc-macro then produces a
`TokenStream` containing a `Span` pointing into the proc-macro crate
itself.
The recursive nature of 'quote!' can be difficult to understand at
first. The file `src/test/ui/proc-macro/quote-debug.stdout` shows
the output of the `quote!` macro, which should make this eaier to
understand.
This PR also supports custom quoting spans in custom quote macros (e.g.
the `quote` crate). All span quoting goes through the
`proc_macro::quote_span` method, which can be called by a custom quote
macro to perform span quoting. An example of this usage is provided in
`src/test/ui/proc-macro/auxiliary/custom-quote.rs`
Custom quoting currently has a few limitations:
In order to quote a span, we need to generate a call to
`proc_macro::Span::recover_proc_macro_span`. However, proc-macros
support renaming the `proc_macro` crate, so we can't simply hardcode
this path. Previously, the `quote_span` method used the path
`crate::Span` - however, this only works when it is called by the
builtin `quote!` macro in the same crate. To support being called from
arbitrary crates, we need access to the name of the `proc_macro` crate
to generate a path. This PR adds an additional argument to `quote_span`
to specify the name of the `proc_macro` crate. Howver, this feels kind
of hacky, and we may want to change this before stabilizing anything
quote-related.
Additionally, using `quote_span` currently requires enabling the
`proc_macro_internals` feature. The builtin `quote!` macro
has an `#[allow_internal_unstable]` attribute, but this won't work for
custom quote implementations. This will likely require some additional
tricks to apply `allow_internal_unstable` to the span of
`proc_macro::Span::recover_proc_macro_span`.
2020-08-02 18:52:16 -05:00
|
|
|
krate: CrateNum,
|
|
|
|
rebased_spans: FxHashMap<usize, Span>,
|
2018-03-19 15:44:24 -05:00
|
|
|
}
|
|
|
|
|
2021-07-18 14:53:06 -05:00
|
|
|
impl<'a, 'b> Rustc<'a, 'b> {
|
|
|
|
pub fn new(ecx: &'a mut ExtCtxt<'b>) -> Self {
|
|
|
|
let expn_data = ecx.current_expansion.id.expn_data();
|
2018-03-19 15:44:24 -05:00
|
|
|
Rustc {
|
2021-07-18 14:53:06 -05:00
|
|
|
def_site: ecx.with_def_site_ctxt(expn_data.def_site),
|
|
|
|
call_site: ecx.with_call_site_ctxt(expn_data.call_site),
|
|
|
|
mixed_site: ecx.with_mixed_site_ctxt(expn_data.call_site),
|
2021-07-10 15:15:30 -05:00
|
|
|
krate: expn_data.macro_def_id.unwrap().krate,
|
Implement span quoting for proc-macros
This PR implements span quoting, allowing proc-macros to produce spans
pointing *into their own crate*. This is used by the unstable
`proc_macro::quote!` macro, allowing us to get error messages like this:
```
error[E0412]: cannot find type `MissingType` in this scope
--> $DIR/auxiliary/span-from-proc-macro.rs:37:20
|
LL | pub fn error_from_attribute(_args: TokenStream, _input: TokenStream) -> TokenStream {
| ----------------------------------------------------------------------------------- in this expansion of procedural macro `#[error_from_attribute]`
...
LL | field: MissingType
| ^^^^^^^^^^^ not found in this scope
|
::: $DIR/span-from-proc-macro.rs:8:1
|
LL | #[error_from_attribute]
| ----------------------- in this macro invocation
```
Here, `MissingType` occurs inside the implementation of the proc-macro
`#[error_from_attribute]`. Previosuly, this would always result in a
span pointing at `#[error_from_attribute]`
This will make many proc-macro-related error message much more useful -
when a proc-macro generates code containing an error, users will get an
error message pointing directly at that code (within the macro
definition), instead of always getting a span pointing at the macro
invocation site.
This is implemented as follows:
* When a proc-macro crate is being *compiled*, it causes the `quote!`
macro to get run. This saves all of the sapns in the input to `quote!`
into the metadata of *the proc-macro-crate* (which we are currently
compiling). The `quote!` macro then expands to a call to
`proc_macro::Span::recover_proc_macro_span(id)`, where `id` is an
opaque identifier for the span in the crate metadata.
* When the same proc-macro crate is *run* (e.g. it is loaded from disk
and invoked by some consumer crate), the call to
`proc_macro::Span::recover_proc_macro_span` causes us to load the span
from the proc-macro crate's metadata. The proc-macro then produces a
`TokenStream` containing a `Span` pointing into the proc-macro crate
itself.
The recursive nature of 'quote!' can be difficult to understand at
first. The file `src/test/ui/proc-macro/quote-debug.stdout` shows
the output of the `quote!` macro, which should make this eaier to
understand.
This PR also supports custom quoting spans in custom quote macros (e.g.
the `quote` crate). All span quoting goes through the
`proc_macro::quote_span` method, which can be called by a custom quote
macro to perform span quoting. An example of this usage is provided in
`src/test/ui/proc-macro/auxiliary/custom-quote.rs`
Custom quoting currently has a few limitations:
In order to quote a span, we need to generate a call to
`proc_macro::Span::recover_proc_macro_span`. However, proc-macros
support renaming the `proc_macro` crate, so we can't simply hardcode
this path. Previously, the `quote_span` method used the path
`crate::Span` - however, this only works when it is called by the
builtin `quote!` macro in the same crate. To support being called from
arbitrary crates, we need access to the name of the `proc_macro` crate
to generate a path. This PR adds an additional argument to `quote_span`
to specify the name of the `proc_macro` crate. Howver, this feels kind
of hacky, and we may want to change this before stabilizing anything
quote-related.
Additionally, using `quote_span` currently requires enabling the
`proc_macro_internals` feature. The builtin `quote!` macro
has an `#[allow_internal_unstable]` attribute, but this won't work for
custom quote implementations. This will likely require some additional
tricks to apply `allow_internal_unstable` to the span of
`proc_macro::Span::recover_proc_macro_span`.
2020-08-02 18:52:16 -05:00
|
|
|
rebased_spans: FxHashMap::default(),
|
2021-07-18 14:53:06 -05:00
|
|
|
ecx,
|
2018-03-19 15:44:24 -05:00
|
|
|
}
|
|
|
|
}
|
2019-05-18 17:04:26 -05:00
|
|
|
|
2021-07-18 14:53:06 -05:00
|
|
|
fn sess(&self) -> &ParseSess {
|
|
|
|
self.ecx.parse_sess()
|
|
|
|
}
|
2018-03-19 15:44:24 -05:00
|
|
|
}
|
2018-03-15 18:09:22 -05:00
|
|
|
|
2021-07-18 14:53:06 -05:00
|
|
|
impl server::Types for Rustc<'_, '_> {
|
2020-07-22 13:08:01 -05:00
|
|
|
type FreeFunctions = FreeFunctions;
|
2018-03-15 18:09:22 -05:00
|
|
|
type TokenStream = TokenStream;
|
|
|
|
type SourceFile = Lrc<SourceFile>;
|
|
|
|
type Span = Span;
|
2022-06-30 20:05:46 -05:00
|
|
|
type Symbol = Symbol;
|
2018-03-15 18:09:22 -05:00
|
|
|
}
|
|
|
|
|
2021-07-18 14:53:06 -05:00
|
|
|
impl server::FreeFunctions for Rustc<'_, '_> {
|
2020-07-22 13:08:01 -05:00
|
|
|
fn track_env_var(&mut self, var: &str, value: Option<&str>) {
|
2021-07-18 14:53:06 -05:00
|
|
|
self.sess()
|
|
|
|
.env_depinfo
|
|
|
|
.borrow_mut()
|
|
|
|
.insert((Symbol::intern(var), value.map(Symbol::intern)));
|
2020-07-22 13:08:01 -05:00
|
|
|
}
|
2021-04-09 09:35:40 -05:00
|
|
|
|
|
|
|
fn track_path(&mut self, path: &str) {
|
2021-07-18 14:53:06 -05:00
|
|
|
self.sess().file_depinfo.borrow_mut().insert(Symbol::intern(path));
|
2021-04-09 09:35:40 -05:00
|
|
|
}
|
2022-07-03 00:04:31 -05:00
|
|
|
|
|
|
|
fn literal_from_str(&mut self, s: &str) -> Result<Literal<Self::Span, Self::Symbol>, ()> {
|
|
|
|
let name = FileName::proc_macro_source_code(s);
|
|
|
|
let mut parser = rustc_parse::new_parser_from_source_str(self.sess(), name, s.to_owned());
|
|
|
|
|
|
|
|
let first_span = parser.token.span.data();
|
|
|
|
let minus_present = parser.eat(&token::BinOp(token::Minus));
|
|
|
|
|
|
|
|
let lit_span = parser.token.span.data();
|
|
|
|
let token::Literal(mut lit) = parser.token.kind else {
|
|
|
|
return Err(());
|
|
|
|
};
|
|
|
|
|
|
|
|
// Check no comment or whitespace surrounding the (possibly negative)
|
|
|
|
// literal, or more tokens after it.
|
|
|
|
if (lit_span.hi.0 - first_span.lo.0) as usize != s.len() {
|
|
|
|
return Err(());
|
|
|
|
}
|
|
|
|
|
|
|
|
if minus_present {
|
|
|
|
// If minus is present, check no comment or whitespace in between it
|
|
|
|
// and the literal token.
|
|
|
|
if first_span.hi.0 != lit_span.lo.0 {
|
|
|
|
return Err(());
|
|
|
|
}
|
|
|
|
|
|
|
|
// Check literal is a kind we allow to be negated in a proc macro token.
|
|
|
|
match lit.kind {
|
|
|
|
token::LitKind::Bool
|
|
|
|
| token::LitKind::Byte
|
|
|
|
| token::LitKind::Char
|
|
|
|
| token::LitKind::Str
|
|
|
|
| token::LitKind::StrRaw(_)
|
|
|
|
| token::LitKind::ByteStr
|
|
|
|
| token::LitKind::ByteStrRaw(_)
|
|
|
|
| token::LitKind::Err => return Err(()),
|
|
|
|
token::LitKind::Integer | token::LitKind::Float => {}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Synthesize a new symbol that includes the minus sign.
|
|
|
|
let symbol = Symbol::intern(&s[..1 + lit.symbol.as_str().len()]);
|
|
|
|
lit = token::Lit::new(lit.kind, symbol, lit.suffix);
|
|
|
|
}
|
|
|
|
let token::Lit { kind, symbol, suffix } = lit;
|
|
|
|
Ok(Literal {
|
|
|
|
kind: FromInternal::from_internal(kind),
|
|
|
|
symbol,
|
|
|
|
suffix,
|
|
|
|
span: self.call_site,
|
|
|
|
})
|
|
|
|
}
|
2022-07-24 23:43:33 -05:00
|
|
|
|
|
|
|
fn emit_diagnostic(&mut self, diagnostic: Diagnostic<Self::Span>) {
|
|
|
|
let mut diag =
|
|
|
|
rustc_errors::Diagnostic::new(diagnostic.level.to_internal(), diagnostic.message);
|
|
|
|
diag.set_span(MultiSpan::from_spans(diagnostic.spans));
|
|
|
|
for child in diagnostic.children {
|
|
|
|
diag.sub(
|
|
|
|
child.level.to_internal(),
|
|
|
|
child.message,
|
|
|
|
MultiSpan::from_spans(child.spans),
|
|
|
|
None,
|
|
|
|
);
|
|
|
|
}
|
|
|
|
self.sess().span_diagnostic.emit_diagnostic(&mut diag);
|
|
|
|
}
|
2020-07-22 13:08:01 -05:00
|
|
|
}
|
|
|
|
|
2021-07-18 14:53:06 -05:00
|
|
|
impl server::TokenStream for Rustc<'_, '_> {
|
2018-03-15 18:09:22 -05:00
|
|
|
fn is_empty(&mut self, stream: &Self::TokenStream) -> bool {
|
|
|
|
stream.is_empty()
|
|
|
|
}
|
2022-06-19 22:52:48 -05:00
|
|
|
|
2018-03-15 18:09:22 -05:00
|
|
|
fn from_str(&mut self, src: &str) -> Self::TokenStream {
|
2019-10-15 15:48:13 -05:00
|
|
|
parse_stream_from_source_str(
|
2019-06-08 05:06:58 -05:00
|
|
|
FileName::proc_macro_source_code(src),
|
2018-03-19 15:44:24 -05:00
|
|
|
src.to_string(),
|
2021-07-18 14:53:06 -05:00
|
|
|
self.sess(),
|
2018-03-19 15:44:24 -05:00
|
|
|
Some(self.call_site),
|
2019-03-04 14:59:43 -06:00
|
|
|
)
|
2018-03-15 18:09:22 -05:00
|
|
|
}
|
2022-06-19 22:52:48 -05:00
|
|
|
|
2018-03-15 18:09:22 -05:00
|
|
|
fn to_string(&mut self, stream: &Self::TokenStream) -> String {
|
2020-06-24 09:45:08 -05:00
|
|
|
pprust::tts_to_string(stream)
|
2018-03-15 18:09:22 -05:00
|
|
|
}
|
2022-06-19 22:52:48 -05:00
|
|
|
|
2021-07-18 14:53:06 -05:00
|
|
|
fn expand_expr(&mut self, stream: &Self::TokenStream) -> Result<Self::TokenStream, ()> {
|
|
|
|
// Parse the expression from our tokenstream.
|
|
|
|
let expr: PResult<'_, _> = try {
|
|
|
|
let mut p = rustc_parse::stream_to_parser(
|
|
|
|
self.sess(),
|
|
|
|
stream.clone(),
|
|
|
|
Some("proc_macro expand expr"),
|
|
|
|
);
|
|
|
|
let expr = p.parse_expr()?;
|
|
|
|
if p.token != token::Eof {
|
|
|
|
p.unexpected()?;
|
|
|
|
}
|
|
|
|
expr
|
|
|
|
};
|
2022-01-27 03:44:25 -06:00
|
|
|
let expr = expr.map_err(|mut err| {
|
|
|
|
err.emit();
|
|
|
|
})?;
|
2021-07-18 14:53:06 -05:00
|
|
|
|
|
|
|
// Perform eager expansion on the expression.
|
|
|
|
let expr = self
|
|
|
|
.ecx
|
|
|
|
.expander()
|
|
|
|
.fully_expand_fragment(crate::expand::AstFragment::Expr(expr))
|
|
|
|
.make_expr();
|
|
|
|
|
|
|
|
// NOTE: For now, limit `expand_expr` to exclusively expand to literals.
|
|
|
|
// This may be relaxed in the future.
|
2022-05-21 07:50:39 -05:00
|
|
|
// We don't use `TokenStream::from_ast` as the tokenstream currently cannot
|
2021-07-18 14:53:06 -05:00
|
|
|
// be recovered in the general case.
|
|
|
|
match &expr.kind {
|
2022-08-01 01:46:08 -05:00
|
|
|
ast::ExprKind::Lit(l) if l.token_lit.kind == token::Bool => {
|
|
|
|
Ok(tokenstream::TokenStream::token_alone(
|
|
|
|
token::Ident(l.token_lit.symbol, false),
|
|
|
|
l.span,
|
|
|
|
))
|
|
|
|
}
|
2021-07-18 14:53:06 -05:00
|
|
|
ast::ExprKind::Lit(l) => {
|
2022-08-01 01:46:08 -05:00
|
|
|
Ok(tokenstream::TokenStream::token_alone(token::Literal(l.token_lit), l.span))
|
2021-07-18 14:53:06 -05:00
|
|
|
}
|
|
|
|
ast::ExprKind::Unary(ast::UnOp::Neg, e) => match &e.kind {
|
2022-08-01 01:46:08 -05:00
|
|
|
ast::ExprKind::Lit(l) => match l.token_lit {
|
2021-07-18 14:53:06 -05:00
|
|
|
token::Lit { kind: token::Integer | token::Float, .. } => {
|
2021-09-03 05:36:33 -05:00
|
|
|
Ok(Self::TokenStream::from_iter([
|
2021-07-18 14:53:06 -05:00
|
|
|
// FIXME: The span of the `-` token is lost when
|
|
|
|
// parsing, so we cannot faithfully recover it here.
|
Remove `TreeAndSpacing`.
A `TokenStream` contains a `Lrc<Vec<(TokenTree, Spacing)>>`. But this is
not quite right. `Spacing` makes sense for `TokenTree::Token`, but does
not make sense for `TokenTree::Delimited`, because a
`TokenTree::Delimited` cannot be joined with another `TokenTree`.
This commit fixes this problem, by adding `Spacing` to `TokenTree::Token`,
changing `TokenStream` to contain a `Lrc<Vec<TokenTree>>`, and removing the
`TreeAndSpacing` typedef.
The commit removes these two impls:
- `impl From<TokenTree> for TokenStream`
- `impl From<TokenTree> for TreeAndSpacing`
These were useful, but also resulted in code with many `.into()` calls
that was hard to read, particularly for anyone not highly familiar with
the relevant types. This commit makes some other changes to compensate:
- `TokenTree::token()` becomes `TokenTree::token_{alone,joint}()`.
- `TokenStream::token_{alone,joint}()` are added.
- `TokenStream::delimited` is added.
This results in things like this:
```rust
TokenTree::token(token::Semi, stmt.span).into()
```
changing to this:
```rust
TokenStream::token_alone(token::Semi, stmt.span)
```
This makes the type of the result, and its spacing, clearer.
These changes also simplifies `Cursor` and `CursorRef`, because they no longer
need to distinguish between `next` and `next_with_spacing`.
2022-07-27 19:31:04 -05:00
|
|
|
tokenstream::TokenTree::token_alone(token::BinOp(token::Minus), e.span),
|
2022-08-01 01:46:08 -05:00
|
|
|
tokenstream::TokenTree::token_alone(
|
|
|
|
token::Literal(l.token_lit),
|
|
|
|
l.span,
|
|
|
|
),
|
2021-09-03 05:36:33 -05:00
|
|
|
]))
|
2021-07-18 14:53:06 -05:00
|
|
|
}
|
|
|
|
_ => Err(()),
|
|
|
|
},
|
|
|
|
_ => Err(()),
|
|
|
|
},
|
|
|
|
_ => Err(()),
|
|
|
|
}
|
|
|
|
}
|
2022-06-19 22:52:48 -05:00
|
|
|
|
2018-03-15 18:09:22 -05:00
|
|
|
fn from_token_tree(
|
|
|
|
&mut self,
|
2022-07-03 00:04:31 -05:00
|
|
|
tree: TokenTree<Self::TokenStream, Self::Span, Self::Symbol>,
|
2018-03-15 18:09:22 -05:00
|
|
|
) -> Self::TokenStream {
|
Remove `TokenStreamBuilder`.
`TokenStreamBuilder` exists to concatenate multiple `TokenStream`s
together. This commit removes it, and moves the concatenation
functionality directly into `TokenStream`, via two new methods
`push_tree` and `push_stream`. This makes things both simpler and
faster.
`push_tree` is particularly important. `TokenStreamBuilder` only had a
single `push` method, which pushed a stream. But in practice most of the
time we push a single token tree rather than a stream, and `push_tree`
avoids the need to build a token stream with a single entry (which
requires two allocations, one for the `Lrc` and one for the `Vec`).
The main `push_tree` use arises from a change to one of the `ToInternal`
impls in `proc_macro_server.rs`. It now returns a `SmallVec` instead of
a `TokenStream`. This return value is then iterated over by
`concat_trees`, which does `push_tree` on each element. Furthermore, the
use of `SmallVec` avoids more allocations, because there is always only
one or two token trees.
Note: the removed `TokenStreamBuilder::push` method had some code to
deal with a quadratic blowup case from #57735. This commit removes the
code. I tried and failed to reproduce the blowup from that PR, before
and after this change. Various other changes have happened to
`TokenStreamBuilder` in the meantime, so I suspect the original problem
is no longer relevant, though I don't have proof of this. Generally
speaking, repeatedly extending a `Vec` without pre-determining its
capacity is *not* quadratic. It's also incredibly common, within rustc
and many other Rust programs, so if there were performance problems
there you'd think it would show up in other places, too.
2022-10-04 18:38:15 -05:00
|
|
|
Self::TokenStream::new((tree, &mut *self).to_internal().into_iter().collect::<Vec<_>>())
|
2018-03-15 18:09:22 -05:00
|
|
|
}
|
2022-06-19 22:52:48 -05:00
|
|
|
|
2021-07-01 14:03:51 -05:00
|
|
|
fn concat_trees(
|
|
|
|
&mut self,
|
|
|
|
base: Option<Self::TokenStream>,
|
2022-07-03 00:04:31 -05:00
|
|
|
trees: Vec<TokenTree<Self::TokenStream, Self::Span, Self::Symbol>>,
|
2021-07-01 14:03:51 -05:00
|
|
|
) -> Self::TokenStream {
|
Remove `TokenStreamBuilder`.
`TokenStreamBuilder` exists to concatenate multiple `TokenStream`s
together. This commit removes it, and moves the concatenation
functionality directly into `TokenStream`, via two new methods
`push_tree` and `push_stream`. This makes things both simpler and
faster.
`push_tree` is particularly important. `TokenStreamBuilder` only had a
single `push` method, which pushed a stream. But in practice most of the
time we push a single token tree rather than a stream, and `push_tree`
avoids the need to build a token stream with a single entry (which
requires two allocations, one for the `Lrc` and one for the `Vec`).
The main `push_tree` use arises from a change to one of the `ToInternal`
impls in `proc_macro_server.rs`. It now returns a `SmallVec` instead of
a `TokenStream`. This return value is then iterated over by
`concat_trees`, which does `push_tree` on each element. Furthermore, the
use of `SmallVec` avoids more allocations, because there is always only
one or two token trees.
Note: the removed `TokenStreamBuilder::push` method had some code to
deal with a quadratic blowup case from #57735. This commit removes the
code. I tried and failed to reproduce the blowup from that PR, before
and after this change. Various other changes have happened to
`TokenStreamBuilder` in the meantime, so I suspect the original problem
is no longer relevant, though I don't have proof of this. Generally
speaking, repeatedly extending a `Vec` without pre-determining its
capacity is *not* quadratic. It's also incredibly common, within rustc
and many other Rust programs, so if there were performance problems
there you'd think it would show up in other places, too.
2022-10-04 18:38:15 -05:00
|
|
|
let mut stream =
|
|
|
|
if let Some(base) = base { base } else { tokenstream::TokenStream::default() };
|
2021-07-01 14:03:51 -05:00
|
|
|
for tree in trees {
|
Remove `TokenStreamBuilder`.
`TokenStreamBuilder` exists to concatenate multiple `TokenStream`s
together. This commit removes it, and moves the concatenation
functionality directly into `TokenStream`, via two new methods
`push_tree` and `push_stream`. This makes things both simpler and
faster.
`push_tree` is particularly important. `TokenStreamBuilder` only had a
single `push` method, which pushed a stream. But in practice most of the
time we push a single token tree rather than a stream, and `push_tree`
avoids the need to build a token stream with a single entry (which
requires two allocations, one for the `Lrc` and one for the `Vec`).
The main `push_tree` use arises from a change to one of the `ToInternal`
impls in `proc_macro_server.rs`. It now returns a `SmallVec` instead of
a `TokenStream`. This return value is then iterated over by
`concat_trees`, which does `push_tree` on each element. Furthermore, the
use of `SmallVec` avoids more allocations, because there is always only
one or two token trees.
Note: the removed `TokenStreamBuilder::push` method had some code to
deal with a quadratic blowup case from #57735. This commit removes the
code. I tried and failed to reproduce the blowup from that PR, before
and after this change. Various other changes have happened to
`TokenStreamBuilder` in the meantime, so I suspect the original problem
is no longer relevant, though I don't have proof of this. Generally
speaking, repeatedly extending a `Vec` without pre-determining its
capacity is *not* quadratic. It's also incredibly common, within rustc
and many other Rust programs, so if there were performance problems
there you'd think it would show up in other places, too.
2022-10-04 18:38:15 -05:00
|
|
|
for tt in (tree, &mut *self).to_internal() {
|
|
|
|
stream.push_tree(tt);
|
|
|
|
}
|
2021-07-01 14:03:51 -05:00
|
|
|
}
|
Remove `TokenStreamBuilder`.
`TokenStreamBuilder` exists to concatenate multiple `TokenStream`s
together. This commit removes it, and moves the concatenation
functionality directly into `TokenStream`, via two new methods
`push_tree` and `push_stream`. This makes things both simpler and
faster.
`push_tree` is particularly important. `TokenStreamBuilder` only had a
single `push` method, which pushed a stream. But in practice most of the
time we push a single token tree rather than a stream, and `push_tree`
avoids the need to build a token stream with a single entry (which
requires two allocations, one for the `Lrc` and one for the `Vec`).
The main `push_tree` use arises from a change to one of the `ToInternal`
impls in `proc_macro_server.rs`. It now returns a `SmallVec` instead of
a `TokenStream`. This return value is then iterated over by
`concat_trees`, which does `push_tree` on each element. Furthermore, the
use of `SmallVec` avoids more allocations, because there is always only
one or two token trees.
Note: the removed `TokenStreamBuilder::push` method had some code to
deal with a quadratic blowup case from #57735. This commit removes the
code. I tried and failed to reproduce the blowup from that PR, before
and after this change. Various other changes have happened to
`TokenStreamBuilder` in the meantime, so I suspect the original problem
is no longer relevant, though I don't have proof of this. Generally
speaking, repeatedly extending a `Vec` without pre-determining its
capacity is *not* quadratic. It's also incredibly common, within rustc
and many other Rust programs, so if there were performance problems
there you'd think it would show up in other places, too.
2022-10-04 18:38:15 -05:00
|
|
|
stream
|
2018-03-15 18:09:22 -05:00
|
|
|
}
|
2022-06-19 22:52:48 -05:00
|
|
|
|
2021-07-01 14:03:51 -05:00
|
|
|
fn concat_streams(
|
|
|
|
&mut self,
|
|
|
|
base: Option<Self::TokenStream>,
|
|
|
|
streams: Vec<Self::TokenStream>,
|
|
|
|
) -> Self::TokenStream {
|
Remove `TokenStreamBuilder`.
`TokenStreamBuilder` exists to concatenate multiple `TokenStream`s
together. This commit removes it, and moves the concatenation
functionality directly into `TokenStream`, via two new methods
`push_tree` and `push_stream`. This makes things both simpler and
faster.
`push_tree` is particularly important. `TokenStreamBuilder` only had a
single `push` method, which pushed a stream. But in practice most of the
time we push a single token tree rather than a stream, and `push_tree`
avoids the need to build a token stream with a single entry (which
requires two allocations, one for the `Lrc` and one for the `Vec`).
The main `push_tree` use arises from a change to one of the `ToInternal`
impls in `proc_macro_server.rs`. It now returns a `SmallVec` instead of
a `TokenStream`. This return value is then iterated over by
`concat_trees`, which does `push_tree` on each element. Furthermore, the
use of `SmallVec` avoids more allocations, because there is always only
one or two token trees.
Note: the removed `TokenStreamBuilder::push` method had some code to
deal with a quadratic blowup case from #57735. This commit removes the
code. I tried and failed to reproduce the blowup from that PR, before
and after this change. Various other changes have happened to
`TokenStreamBuilder` in the meantime, so I suspect the original problem
is no longer relevant, though I don't have proof of this. Generally
speaking, repeatedly extending a `Vec` without pre-determining its
capacity is *not* quadratic. It's also incredibly common, within rustc
and many other Rust programs, so if there were performance problems
there you'd think it would show up in other places, too.
2022-10-04 18:38:15 -05:00
|
|
|
let mut stream =
|
|
|
|
if let Some(base) = base { base } else { tokenstream::TokenStream::default() };
|
|
|
|
for s in streams {
|
|
|
|
stream.push_stream(s);
|
2021-07-01 14:03:51 -05:00
|
|
|
}
|
Remove `TokenStreamBuilder`.
`TokenStreamBuilder` exists to concatenate multiple `TokenStream`s
together. This commit removes it, and moves the concatenation
functionality directly into `TokenStream`, via two new methods
`push_tree` and `push_stream`. This makes things both simpler and
faster.
`push_tree` is particularly important. `TokenStreamBuilder` only had a
single `push` method, which pushed a stream. But in practice most of the
time we push a single token tree rather than a stream, and `push_tree`
avoids the need to build a token stream with a single entry (which
requires two allocations, one for the `Lrc` and one for the `Vec`).
The main `push_tree` use arises from a change to one of the `ToInternal`
impls in `proc_macro_server.rs`. It now returns a `SmallVec` instead of
a `TokenStream`. This return value is then iterated over by
`concat_trees`, which does `push_tree` on each element. Furthermore, the
use of `SmallVec` avoids more allocations, because there is always only
one or two token trees.
Note: the removed `TokenStreamBuilder::push` method had some code to
deal with a quadratic blowup case from #57735. This commit removes the
code. I tried and failed to reproduce the blowup from that PR, before
and after this change. Various other changes have happened to
`TokenStreamBuilder` in the meantime, so I suspect the original problem
is no longer relevant, though I don't have proof of this. Generally
speaking, repeatedly extending a `Vec` without pre-determining its
capacity is *not* quadratic. It's also incredibly common, within rustc
and many other Rust programs, so if there were performance problems
there you'd think it would show up in other places, too.
2022-10-04 18:38:15 -05:00
|
|
|
stream
|
2018-03-15 18:09:22 -05:00
|
|
|
}
|
2022-06-19 22:52:48 -05:00
|
|
|
|
2022-06-17 21:10:07 -05:00
|
|
|
fn into_trees(
|
2018-03-15 18:09:22 -05:00
|
|
|
&mut self,
|
2021-07-01 14:03:51 -05:00
|
|
|
stream: Self::TokenStream,
|
2022-07-03 00:04:31 -05:00
|
|
|
) -> Vec<TokenTree<Self::TokenStream, Self::Span, Self::Symbol>> {
|
2021-07-01 16:36:38 -05:00
|
|
|
FromInternal::from_internal((stream, self))
|
2018-03-15 18:09:22 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-07-18 14:53:06 -05:00
|
|
|
impl server::SourceFile for Rustc<'_, '_> {
|
2018-03-15 18:09:22 -05:00
|
|
|
fn eq(&mut self, file1: &Self::SourceFile, file2: &Self::SourceFile) -> bool {
|
|
|
|
Lrc::ptr_eq(file1, file2)
|
|
|
|
}
|
2022-06-19 22:52:48 -05:00
|
|
|
|
2018-03-15 18:09:22 -05:00
|
|
|
fn path(&mut self, file: &Self::SourceFile) -> String {
|
|
|
|
match file.name {
|
2020-05-29 10:31:55 -05:00
|
|
|
FileName::Real(ref name) => name
|
|
|
|
.local_path()
|
2021-04-08 18:54:51 -05:00
|
|
|
.expect("attempting to get a file path in an imported file in `proc_macro::SourceFile::path`")
|
2018-03-15 18:09:22 -05:00
|
|
|
.to_str()
|
|
|
|
.expect("non-UTF8 file path in `proc_macro::SourceFile::path`")
|
|
|
|
.to_string(),
|
2021-04-19 17:27:02 -05:00
|
|
|
_ => file.name.prefer_local().to_string(),
|
2018-03-15 18:09:22 -05:00
|
|
|
}
|
|
|
|
}
|
2022-06-19 22:52:48 -05:00
|
|
|
|
2018-03-15 18:09:22 -05:00
|
|
|
fn is_real(&mut self, file: &Self::SourceFile) -> bool {
|
|
|
|
file.is_real_file()
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-07-18 14:53:06 -05:00
|
|
|
impl server::Span for Rustc<'_, '_> {
|
2018-03-15 18:09:22 -05:00
|
|
|
fn debug(&mut self, span: Self::Span) -> String {
|
2021-07-18 14:53:06 -05:00
|
|
|
if self.ecx.ecfg.span_debug {
|
2020-05-31 15:20:50 -05:00
|
|
|
format!("{:?}", span)
|
|
|
|
} else {
|
|
|
|
format!("{:?} bytes({}..{})", span.ctxt(), span.lo().0, span.hi().0)
|
|
|
|
}
|
2018-03-15 18:09:22 -05:00
|
|
|
}
|
2022-06-19 22:52:48 -05:00
|
|
|
|
2018-03-15 18:09:22 -05:00
|
|
|
fn source_file(&mut self, span: Self::Span) -> Self::SourceFile {
|
2021-07-18 14:53:06 -05:00
|
|
|
self.sess().source_map().lookup_char_pos(span.lo()).file
|
2018-03-15 18:09:22 -05:00
|
|
|
}
|
2022-06-19 22:52:48 -05:00
|
|
|
|
2018-03-15 18:09:22 -05:00
|
|
|
fn parent(&mut self, span: Self::Span) -> Option<Self::Span> {
|
2021-04-18 07:27:04 -05:00
|
|
|
span.parent_callsite()
|
2018-03-15 18:09:22 -05:00
|
|
|
}
|
2022-06-19 22:52:48 -05:00
|
|
|
|
2018-03-15 18:09:22 -05:00
|
|
|
fn source(&mut self, span: Self::Span) -> Self::Span {
|
|
|
|
span.source_callsite()
|
|
|
|
}
|
2022-06-19 22:52:48 -05:00
|
|
|
|
2018-03-15 18:09:22 -05:00
|
|
|
fn start(&mut self, span: Self::Span) -> LineColumn {
|
2021-07-18 14:53:06 -05:00
|
|
|
let loc = self.sess().source_map().lookup_char_pos(span.lo());
|
2018-03-15 18:09:22 -05:00
|
|
|
LineColumn { line: loc.line, column: loc.col.to_usize() }
|
|
|
|
}
|
2022-06-19 22:52:48 -05:00
|
|
|
|
2018-03-15 18:09:22 -05:00
|
|
|
fn end(&mut self, span: Self::Span) -> LineColumn {
|
2021-07-18 14:53:06 -05:00
|
|
|
let loc = self.sess().source_map().lookup_char_pos(span.hi());
|
2018-03-15 18:09:22 -05:00
|
|
|
LineColumn { line: loc.line, column: loc.col.to_usize() }
|
|
|
|
}
|
2022-06-19 22:52:48 -05:00
|
|
|
|
2021-06-09 07:37:10 -05:00
|
|
|
fn before(&mut self, span: Self::Span) -> Self::Span {
|
|
|
|
span.shrink_to_lo()
|
|
|
|
}
|
2022-06-19 22:52:48 -05:00
|
|
|
|
2021-06-09 07:37:10 -05:00
|
|
|
fn after(&mut self, span: Self::Span) -> Self::Span {
|
|
|
|
span.shrink_to_hi()
|
|
|
|
}
|
2022-06-19 22:52:48 -05:00
|
|
|
|
2018-03-15 18:09:22 -05:00
|
|
|
fn join(&mut self, first: Self::Span, second: Self::Span) -> Option<Self::Span> {
|
2021-07-18 14:53:06 -05:00
|
|
|
let self_loc = self.sess().source_map().lookup_char_pos(first.lo());
|
|
|
|
let other_loc = self.sess().source_map().lookup_char_pos(second.lo());
|
2018-03-15 18:09:22 -05:00
|
|
|
|
|
|
|
if self_loc.file.name != other_loc.file.name {
|
|
|
|
return None;
|
|
|
|
}
|
|
|
|
|
|
|
|
Some(first.to(second))
|
|
|
|
}
|
2022-06-19 22:52:48 -05:00
|
|
|
|
2022-07-09 10:34:06 -05:00
|
|
|
fn subspan(
|
|
|
|
&mut self,
|
|
|
|
span: Self::Span,
|
|
|
|
start: Bound<usize>,
|
|
|
|
end: Bound<usize>,
|
|
|
|
) -> Option<Self::Span> {
|
|
|
|
let length = span.hi().to_usize() - span.lo().to_usize();
|
|
|
|
|
|
|
|
let start = match start {
|
|
|
|
Bound::Included(lo) => lo,
|
|
|
|
Bound::Excluded(lo) => lo.checked_add(1)?,
|
|
|
|
Bound::Unbounded => 0,
|
|
|
|
};
|
|
|
|
|
|
|
|
let end = match end {
|
|
|
|
Bound::Included(hi) => hi.checked_add(1)?,
|
|
|
|
Bound::Excluded(hi) => hi,
|
|
|
|
Bound::Unbounded => length,
|
|
|
|
};
|
|
|
|
|
|
|
|
// Bounds check the values, preventing addition overflow and OOB spans.
|
|
|
|
if start > u32::MAX as usize
|
|
|
|
|| end > u32::MAX as usize
|
|
|
|
|| (u32::MAX - start as u32) < span.lo().to_u32()
|
|
|
|
|| (u32::MAX - end as u32) < span.lo().to_u32()
|
|
|
|
|| start >= end
|
|
|
|
|| end > length
|
|
|
|
{
|
|
|
|
return None;
|
|
|
|
}
|
|
|
|
|
|
|
|
let new_lo = span.lo() + BytePos::from_usize(start);
|
|
|
|
let new_hi = span.lo() + BytePos::from_usize(end);
|
|
|
|
Some(span.with_lo(new_lo).with_hi(new_hi))
|
|
|
|
}
|
|
|
|
|
2018-03-15 18:09:22 -05:00
|
|
|
fn resolved_at(&mut self, span: Self::Span, at: Self::Span) -> Self::Span {
|
|
|
|
span.with_ctxt(at.ctxt())
|
|
|
|
}
|
2022-06-19 22:52:48 -05:00
|
|
|
|
2018-11-08 03:07:02 -06:00
|
|
|
fn source_text(&mut self, span: Self::Span) -> Option<String> {
|
2021-07-18 14:53:06 -05:00
|
|
|
self.sess().source_map().span_to_snippet(span).ok()
|
2018-11-08 03:07:02 -06:00
|
|
|
}
|
Remove `TokenStreamBuilder`.
`TokenStreamBuilder` exists to concatenate multiple `TokenStream`s
together. This commit removes it, and moves the concatenation
functionality directly into `TokenStream`, via two new methods
`push_tree` and `push_stream`. This makes things both simpler and
faster.
`push_tree` is particularly important. `TokenStreamBuilder` only had a
single `push` method, which pushed a stream. But in practice most of the
time we push a single token tree rather than a stream, and `push_tree`
avoids the need to build a token stream with a single entry (which
requires two allocations, one for the `Lrc` and one for the `Vec`).
The main `push_tree` use arises from a change to one of the `ToInternal`
impls in `proc_macro_server.rs`. It now returns a `SmallVec` instead of
a `TokenStream`. This return value is then iterated over by
`concat_trees`, which does `push_tree` on each element. Furthermore, the
use of `SmallVec` avoids more allocations, because there is always only
one or two token trees.
Note: the removed `TokenStreamBuilder::push` method had some code to
deal with a quadratic blowup case from #57735. This commit removes the
code. I tried and failed to reproduce the blowup from that PR, before
and after this change. Various other changes have happened to
`TokenStreamBuilder` in the meantime, so I suspect the original problem
is no longer relevant, though I don't have proof of this. Generally
speaking, repeatedly extending a `Vec` without pre-determining its
capacity is *not* quadratic. It's also incredibly common, within rustc
and many other Rust programs, so if there were performance problems
there you'd think it would show up in other places, too.
2022-10-04 18:38:15 -05:00
|
|
|
|
Implement span quoting for proc-macros
This PR implements span quoting, allowing proc-macros to produce spans
pointing *into their own crate*. This is used by the unstable
`proc_macro::quote!` macro, allowing us to get error messages like this:
```
error[E0412]: cannot find type `MissingType` in this scope
--> $DIR/auxiliary/span-from-proc-macro.rs:37:20
|
LL | pub fn error_from_attribute(_args: TokenStream, _input: TokenStream) -> TokenStream {
| ----------------------------------------------------------------------------------- in this expansion of procedural macro `#[error_from_attribute]`
...
LL | field: MissingType
| ^^^^^^^^^^^ not found in this scope
|
::: $DIR/span-from-proc-macro.rs:8:1
|
LL | #[error_from_attribute]
| ----------------------- in this macro invocation
```
Here, `MissingType` occurs inside the implementation of the proc-macro
`#[error_from_attribute]`. Previosuly, this would always result in a
span pointing at `#[error_from_attribute]`
This will make many proc-macro-related error message much more useful -
when a proc-macro generates code containing an error, users will get an
error message pointing directly at that code (within the macro
definition), instead of always getting a span pointing at the macro
invocation site.
This is implemented as follows:
* When a proc-macro crate is being *compiled*, it causes the `quote!`
macro to get run. This saves all of the sapns in the input to `quote!`
into the metadata of *the proc-macro-crate* (which we are currently
compiling). The `quote!` macro then expands to a call to
`proc_macro::Span::recover_proc_macro_span(id)`, where `id` is an
opaque identifier for the span in the crate metadata.
* When the same proc-macro crate is *run* (e.g. it is loaded from disk
and invoked by some consumer crate), the call to
`proc_macro::Span::recover_proc_macro_span` causes us to load the span
from the proc-macro crate's metadata. The proc-macro then produces a
`TokenStream` containing a `Span` pointing into the proc-macro crate
itself.
The recursive nature of 'quote!' can be difficult to understand at
first. The file `src/test/ui/proc-macro/quote-debug.stdout` shows
the output of the `quote!` macro, which should make this eaier to
understand.
This PR also supports custom quoting spans in custom quote macros (e.g.
the `quote` crate). All span quoting goes through the
`proc_macro::quote_span` method, which can be called by a custom quote
macro to perform span quoting. An example of this usage is provided in
`src/test/ui/proc-macro/auxiliary/custom-quote.rs`
Custom quoting currently has a few limitations:
In order to quote a span, we need to generate a call to
`proc_macro::Span::recover_proc_macro_span`. However, proc-macros
support renaming the `proc_macro` crate, so we can't simply hardcode
this path. Previously, the `quote_span` method used the path
`crate::Span` - however, this only works when it is called by the
builtin `quote!` macro in the same crate. To support being called from
arbitrary crates, we need access to the name of the `proc_macro` crate
to generate a path. This PR adds an additional argument to `quote_span`
to specify the name of the `proc_macro` crate. Howver, this feels kind
of hacky, and we may want to change this before stabilizing anything
quote-related.
Additionally, using `quote_span` currently requires enabling the
`proc_macro_internals` feature. The builtin `quote!` macro
has an `#[allow_internal_unstable]` attribute, but this won't work for
custom quote implementations. This will likely require some additional
tricks to apply `allow_internal_unstable` to the span of
`proc_macro::Span::recover_proc_macro_span`.
2020-08-02 18:52:16 -05:00
|
|
|
/// Saves the provided span into the metadata of
|
|
|
|
/// *the crate we are currently compiling*, which must
|
|
|
|
/// be a proc-macro crate. This id can be passed to
|
|
|
|
/// `recover_proc_macro_span` when our current crate
|
|
|
|
/// is *run* as a proc-macro.
|
|
|
|
///
|
|
|
|
/// Let's suppose that we have two crates - `my_client`
|
|
|
|
/// and `my_proc_macro`. The `my_proc_macro` crate
|
|
|
|
/// contains a procedural macro `my_macro`, which
|
|
|
|
/// is implemented as: `quote! { "hello" }`
|
|
|
|
///
|
|
|
|
/// When we *compile* `my_proc_macro`, we will execute
|
|
|
|
/// the `quote` proc-macro. This will save the span of
|
|
|
|
/// "hello" into the metadata of `my_proc_macro`. As a result,
|
|
|
|
/// the body of `my_proc_macro` (after expansion) will end
|
2022-03-03 05:47:23 -06:00
|
|
|
/// up containing a call that looks like this:
|
Implement span quoting for proc-macros
This PR implements span quoting, allowing proc-macros to produce spans
pointing *into their own crate*. This is used by the unstable
`proc_macro::quote!` macro, allowing us to get error messages like this:
```
error[E0412]: cannot find type `MissingType` in this scope
--> $DIR/auxiliary/span-from-proc-macro.rs:37:20
|
LL | pub fn error_from_attribute(_args: TokenStream, _input: TokenStream) -> TokenStream {
| ----------------------------------------------------------------------------------- in this expansion of procedural macro `#[error_from_attribute]`
...
LL | field: MissingType
| ^^^^^^^^^^^ not found in this scope
|
::: $DIR/span-from-proc-macro.rs:8:1
|
LL | #[error_from_attribute]
| ----------------------- in this macro invocation
```
Here, `MissingType` occurs inside the implementation of the proc-macro
`#[error_from_attribute]`. Previosuly, this would always result in a
span pointing at `#[error_from_attribute]`
This will make many proc-macro-related error message much more useful -
when a proc-macro generates code containing an error, users will get an
error message pointing directly at that code (within the macro
definition), instead of always getting a span pointing at the macro
invocation site.
This is implemented as follows:
* When a proc-macro crate is being *compiled*, it causes the `quote!`
macro to get run. This saves all of the sapns in the input to `quote!`
into the metadata of *the proc-macro-crate* (which we are currently
compiling). The `quote!` macro then expands to a call to
`proc_macro::Span::recover_proc_macro_span(id)`, where `id` is an
opaque identifier for the span in the crate metadata.
* When the same proc-macro crate is *run* (e.g. it is loaded from disk
and invoked by some consumer crate), the call to
`proc_macro::Span::recover_proc_macro_span` causes us to load the span
from the proc-macro crate's metadata. The proc-macro then produces a
`TokenStream` containing a `Span` pointing into the proc-macro crate
itself.
The recursive nature of 'quote!' can be difficult to understand at
first. The file `src/test/ui/proc-macro/quote-debug.stdout` shows
the output of the `quote!` macro, which should make this eaier to
understand.
This PR also supports custom quoting spans in custom quote macros (e.g.
the `quote` crate). All span quoting goes through the
`proc_macro::quote_span` method, which can be called by a custom quote
macro to perform span quoting. An example of this usage is provided in
`src/test/ui/proc-macro/auxiliary/custom-quote.rs`
Custom quoting currently has a few limitations:
In order to quote a span, we need to generate a call to
`proc_macro::Span::recover_proc_macro_span`. However, proc-macros
support renaming the `proc_macro` crate, so we can't simply hardcode
this path. Previously, the `quote_span` method used the path
`crate::Span` - however, this only works when it is called by the
builtin `quote!` macro in the same crate. To support being called from
arbitrary crates, we need access to the name of the `proc_macro` crate
to generate a path. This PR adds an additional argument to `quote_span`
to specify the name of the `proc_macro` crate. Howver, this feels kind
of hacky, and we may want to change this before stabilizing anything
quote-related.
Additionally, using `quote_span` currently requires enabling the
`proc_macro_internals` feature. The builtin `quote!` macro
has an `#[allow_internal_unstable]` attribute, but this won't work for
custom quote implementations. This will likely require some additional
tricks to apply `allow_internal_unstable` to the span of
`proc_macro::Span::recover_proc_macro_span`.
2020-08-02 18:52:16 -05:00
|
|
|
/// `proc_macro::Ident::new("hello", proc_macro::Span::recover_proc_macro_span(0))`
|
|
|
|
///
|
|
|
|
/// where `0` is the id returned by this function.
|
|
|
|
/// When `my_proc_macro` *executes* (during the compilation of `my_client`),
|
|
|
|
/// the call to `recover_proc_macro_span` will load the corresponding
|
|
|
|
/// span from the metadata of `my_proc_macro` (which we have access to,
|
|
|
|
/// since we've loaded `my_proc_macro` from disk in order to execute it).
|
|
|
|
/// In this way, we have obtained a span pointing into `my_proc_macro`
|
2021-07-10 15:44:22 -05:00
|
|
|
fn save_span(&mut self, span: Self::Span) -> usize {
|
2021-07-18 14:53:06 -05:00
|
|
|
self.sess().save_proc_macro_span(span)
|
Implement span quoting for proc-macros
This PR implements span quoting, allowing proc-macros to produce spans
pointing *into their own crate*. This is used by the unstable
`proc_macro::quote!` macro, allowing us to get error messages like this:
```
error[E0412]: cannot find type `MissingType` in this scope
--> $DIR/auxiliary/span-from-proc-macro.rs:37:20
|
LL | pub fn error_from_attribute(_args: TokenStream, _input: TokenStream) -> TokenStream {
| ----------------------------------------------------------------------------------- in this expansion of procedural macro `#[error_from_attribute]`
...
LL | field: MissingType
| ^^^^^^^^^^^ not found in this scope
|
::: $DIR/span-from-proc-macro.rs:8:1
|
LL | #[error_from_attribute]
| ----------------------- in this macro invocation
```
Here, `MissingType` occurs inside the implementation of the proc-macro
`#[error_from_attribute]`. Previosuly, this would always result in a
span pointing at `#[error_from_attribute]`
This will make many proc-macro-related error message much more useful -
when a proc-macro generates code containing an error, users will get an
error message pointing directly at that code (within the macro
definition), instead of always getting a span pointing at the macro
invocation site.
This is implemented as follows:
* When a proc-macro crate is being *compiled*, it causes the `quote!`
macro to get run. This saves all of the sapns in the input to `quote!`
into the metadata of *the proc-macro-crate* (which we are currently
compiling). The `quote!` macro then expands to a call to
`proc_macro::Span::recover_proc_macro_span(id)`, where `id` is an
opaque identifier for the span in the crate metadata.
* When the same proc-macro crate is *run* (e.g. it is loaded from disk
and invoked by some consumer crate), the call to
`proc_macro::Span::recover_proc_macro_span` causes us to load the span
from the proc-macro crate's metadata. The proc-macro then produces a
`TokenStream` containing a `Span` pointing into the proc-macro crate
itself.
The recursive nature of 'quote!' can be difficult to understand at
first. The file `src/test/ui/proc-macro/quote-debug.stdout` shows
the output of the `quote!` macro, which should make this eaier to
understand.
This PR also supports custom quoting spans in custom quote macros (e.g.
the `quote` crate). All span quoting goes through the
`proc_macro::quote_span` method, which can be called by a custom quote
macro to perform span quoting. An example of this usage is provided in
`src/test/ui/proc-macro/auxiliary/custom-quote.rs`
Custom quoting currently has a few limitations:
In order to quote a span, we need to generate a call to
`proc_macro::Span::recover_proc_macro_span`. However, proc-macros
support renaming the `proc_macro` crate, so we can't simply hardcode
this path. Previously, the `quote_span` method used the path
`crate::Span` - however, this only works when it is called by the
builtin `quote!` macro in the same crate. To support being called from
arbitrary crates, we need access to the name of the `proc_macro` crate
to generate a path. This PR adds an additional argument to `quote_span`
to specify the name of the `proc_macro` crate. Howver, this feels kind
of hacky, and we may want to change this before stabilizing anything
quote-related.
Additionally, using `quote_span` currently requires enabling the
`proc_macro_internals` feature. The builtin `quote!` macro
has an `#[allow_internal_unstable]` attribute, but this won't work for
custom quote implementations. This will likely require some additional
tricks to apply `allow_internal_unstable` to the span of
`proc_macro::Span::recover_proc_macro_span`.
2020-08-02 18:52:16 -05:00
|
|
|
}
|
2022-06-19 22:52:48 -05:00
|
|
|
|
Implement span quoting for proc-macros
This PR implements span quoting, allowing proc-macros to produce spans
pointing *into their own crate*. This is used by the unstable
`proc_macro::quote!` macro, allowing us to get error messages like this:
```
error[E0412]: cannot find type `MissingType` in this scope
--> $DIR/auxiliary/span-from-proc-macro.rs:37:20
|
LL | pub fn error_from_attribute(_args: TokenStream, _input: TokenStream) -> TokenStream {
| ----------------------------------------------------------------------------------- in this expansion of procedural macro `#[error_from_attribute]`
...
LL | field: MissingType
| ^^^^^^^^^^^ not found in this scope
|
::: $DIR/span-from-proc-macro.rs:8:1
|
LL | #[error_from_attribute]
| ----------------------- in this macro invocation
```
Here, `MissingType` occurs inside the implementation of the proc-macro
`#[error_from_attribute]`. Previosuly, this would always result in a
span pointing at `#[error_from_attribute]`
This will make many proc-macro-related error message much more useful -
when a proc-macro generates code containing an error, users will get an
error message pointing directly at that code (within the macro
definition), instead of always getting a span pointing at the macro
invocation site.
This is implemented as follows:
* When a proc-macro crate is being *compiled*, it causes the `quote!`
macro to get run. This saves all of the sapns in the input to `quote!`
into the metadata of *the proc-macro-crate* (which we are currently
compiling). The `quote!` macro then expands to a call to
`proc_macro::Span::recover_proc_macro_span(id)`, where `id` is an
opaque identifier for the span in the crate metadata.
* When the same proc-macro crate is *run* (e.g. it is loaded from disk
and invoked by some consumer crate), the call to
`proc_macro::Span::recover_proc_macro_span` causes us to load the span
from the proc-macro crate's metadata. The proc-macro then produces a
`TokenStream` containing a `Span` pointing into the proc-macro crate
itself.
The recursive nature of 'quote!' can be difficult to understand at
first. The file `src/test/ui/proc-macro/quote-debug.stdout` shows
the output of the `quote!` macro, which should make this eaier to
understand.
This PR also supports custom quoting spans in custom quote macros (e.g.
the `quote` crate). All span quoting goes through the
`proc_macro::quote_span` method, which can be called by a custom quote
macro to perform span quoting. An example of this usage is provided in
`src/test/ui/proc-macro/auxiliary/custom-quote.rs`
Custom quoting currently has a few limitations:
In order to quote a span, we need to generate a call to
`proc_macro::Span::recover_proc_macro_span`. However, proc-macros
support renaming the `proc_macro` crate, so we can't simply hardcode
this path. Previously, the `quote_span` method used the path
`crate::Span` - however, this only works when it is called by the
builtin `quote!` macro in the same crate. To support being called from
arbitrary crates, we need access to the name of the `proc_macro` crate
to generate a path. This PR adds an additional argument to `quote_span`
to specify the name of the `proc_macro` crate. Howver, this feels kind
of hacky, and we may want to change this before stabilizing anything
quote-related.
Additionally, using `quote_span` currently requires enabling the
`proc_macro_internals` feature. The builtin `quote!` macro
has an `#[allow_internal_unstable]` attribute, but this won't work for
custom quote implementations. This will likely require some additional
tricks to apply `allow_internal_unstable` to the span of
`proc_macro::Span::recover_proc_macro_span`.
2020-08-02 18:52:16 -05:00
|
|
|
fn recover_proc_macro_span(&mut self, id: usize) -> Self::Span {
|
2021-07-18 14:53:06 -05:00
|
|
|
let (resolver, krate, def_site) = (&*self.ecx.resolver, self.krate, self.def_site);
|
Implement span quoting for proc-macros
This PR implements span quoting, allowing proc-macros to produce spans
pointing *into their own crate*. This is used by the unstable
`proc_macro::quote!` macro, allowing us to get error messages like this:
```
error[E0412]: cannot find type `MissingType` in this scope
--> $DIR/auxiliary/span-from-proc-macro.rs:37:20
|
LL | pub fn error_from_attribute(_args: TokenStream, _input: TokenStream) -> TokenStream {
| ----------------------------------------------------------------------------------- in this expansion of procedural macro `#[error_from_attribute]`
...
LL | field: MissingType
| ^^^^^^^^^^^ not found in this scope
|
::: $DIR/span-from-proc-macro.rs:8:1
|
LL | #[error_from_attribute]
| ----------------------- in this macro invocation
```
Here, `MissingType` occurs inside the implementation of the proc-macro
`#[error_from_attribute]`. Previosuly, this would always result in a
span pointing at `#[error_from_attribute]`
This will make many proc-macro-related error message much more useful -
when a proc-macro generates code containing an error, users will get an
error message pointing directly at that code (within the macro
definition), instead of always getting a span pointing at the macro
invocation site.
This is implemented as follows:
* When a proc-macro crate is being *compiled*, it causes the `quote!`
macro to get run. This saves all of the sapns in the input to `quote!`
into the metadata of *the proc-macro-crate* (which we are currently
compiling). The `quote!` macro then expands to a call to
`proc_macro::Span::recover_proc_macro_span(id)`, where `id` is an
opaque identifier for the span in the crate metadata.
* When the same proc-macro crate is *run* (e.g. it is loaded from disk
and invoked by some consumer crate), the call to
`proc_macro::Span::recover_proc_macro_span` causes us to load the span
from the proc-macro crate's metadata. The proc-macro then produces a
`TokenStream` containing a `Span` pointing into the proc-macro crate
itself.
The recursive nature of 'quote!' can be difficult to understand at
first. The file `src/test/ui/proc-macro/quote-debug.stdout` shows
the output of the `quote!` macro, which should make this eaier to
understand.
This PR also supports custom quoting spans in custom quote macros (e.g.
the `quote` crate). All span quoting goes through the
`proc_macro::quote_span` method, which can be called by a custom quote
macro to perform span quoting. An example of this usage is provided in
`src/test/ui/proc-macro/auxiliary/custom-quote.rs`
Custom quoting currently has a few limitations:
In order to quote a span, we need to generate a call to
`proc_macro::Span::recover_proc_macro_span`. However, proc-macros
support renaming the `proc_macro` crate, so we can't simply hardcode
this path. Previously, the `quote_span` method used the path
`crate::Span` - however, this only works when it is called by the
builtin `quote!` macro in the same crate. To support being called from
arbitrary crates, we need access to the name of the `proc_macro` crate
to generate a path. This PR adds an additional argument to `quote_span`
to specify the name of the `proc_macro` crate. Howver, this feels kind
of hacky, and we may want to change this before stabilizing anything
quote-related.
Additionally, using `quote_span` currently requires enabling the
`proc_macro_internals` feature. The builtin `quote!` macro
has an `#[allow_internal_unstable]` attribute, but this won't work for
custom quote implementations. This will likely require some additional
tricks to apply `allow_internal_unstable` to the span of
`proc_macro::Span::recover_proc_macro_span`.
2020-08-02 18:52:16 -05:00
|
|
|
*self.rebased_spans.entry(id).or_insert_with(|| {
|
2021-07-10 15:44:22 -05:00
|
|
|
// FIXME: `SyntaxContext` for spans from proc macro crates is lost during encoding,
|
|
|
|
// replace it with a def-site context until we are encoding it properly.
|
|
|
|
resolver.get_proc_macro_quoted_span(krate, id).with_ctxt(def_site.ctxt())
|
Implement span quoting for proc-macros
This PR implements span quoting, allowing proc-macros to produce spans
pointing *into their own crate*. This is used by the unstable
`proc_macro::quote!` macro, allowing us to get error messages like this:
```
error[E0412]: cannot find type `MissingType` in this scope
--> $DIR/auxiliary/span-from-proc-macro.rs:37:20
|
LL | pub fn error_from_attribute(_args: TokenStream, _input: TokenStream) -> TokenStream {
| ----------------------------------------------------------------------------------- in this expansion of procedural macro `#[error_from_attribute]`
...
LL | field: MissingType
| ^^^^^^^^^^^ not found in this scope
|
::: $DIR/span-from-proc-macro.rs:8:1
|
LL | #[error_from_attribute]
| ----------------------- in this macro invocation
```
Here, `MissingType` occurs inside the implementation of the proc-macro
`#[error_from_attribute]`. Previosuly, this would always result in a
span pointing at `#[error_from_attribute]`
This will make many proc-macro-related error message much more useful -
when a proc-macro generates code containing an error, users will get an
error message pointing directly at that code (within the macro
definition), instead of always getting a span pointing at the macro
invocation site.
This is implemented as follows:
* When a proc-macro crate is being *compiled*, it causes the `quote!`
macro to get run. This saves all of the sapns in the input to `quote!`
into the metadata of *the proc-macro-crate* (which we are currently
compiling). The `quote!` macro then expands to a call to
`proc_macro::Span::recover_proc_macro_span(id)`, where `id` is an
opaque identifier for the span in the crate metadata.
* When the same proc-macro crate is *run* (e.g. it is loaded from disk
and invoked by some consumer crate), the call to
`proc_macro::Span::recover_proc_macro_span` causes us to load the span
from the proc-macro crate's metadata. The proc-macro then produces a
`TokenStream` containing a `Span` pointing into the proc-macro crate
itself.
The recursive nature of 'quote!' can be difficult to understand at
first. The file `src/test/ui/proc-macro/quote-debug.stdout` shows
the output of the `quote!` macro, which should make this eaier to
understand.
This PR also supports custom quoting spans in custom quote macros (e.g.
the `quote` crate). All span quoting goes through the
`proc_macro::quote_span` method, which can be called by a custom quote
macro to perform span quoting. An example of this usage is provided in
`src/test/ui/proc-macro/auxiliary/custom-quote.rs`
Custom quoting currently has a few limitations:
In order to quote a span, we need to generate a call to
`proc_macro::Span::recover_proc_macro_span`. However, proc-macros
support renaming the `proc_macro` crate, so we can't simply hardcode
this path. Previously, the `quote_span` method used the path
`crate::Span` - however, this only works when it is called by the
builtin `quote!` macro in the same crate. To support being called from
arbitrary crates, we need access to the name of the `proc_macro` crate
to generate a path. This PR adds an additional argument to `quote_span`
to specify the name of the `proc_macro` crate. Howver, this feels kind
of hacky, and we may want to change this before stabilizing anything
quote-related.
Additionally, using `quote_span` currently requires enabling the
`proc_macro_internals` feature. The builtin `quote!` macro
has an `#[allow_internal_unstable]` attribute, but this won't work for
custom quote implementations. This will likely require some additional
tricks to apply `allow_internal_unstable` to the span of
`proc_macro::Span::recover_proc_macro_span`.
2020-08-02 18:52:16 -05:00
|
|
|
})
|
|
|
|
}
|
2018-03-15 18:09:22 -05:00
|
|
|
}
|
2021-06-29 13:49:54 -05:00
|
|
|
|
2022-06-30 20:05:46 -05:00
|
|
|
impl server::Symbol for Rustc<'_, '_> {
|
|
|
|
fn normalize_and_validate_ident(&mut self, string: &str) -> Result<Self::Symbol, ()> {
|
|
|
|
let sym = nfc_normalize(string);
|
|
|
|
if rustc_lexer::is_ident(sym.as_str()) { Ok(sym) } else { Err(()) }
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-06-25 11:11:44 -05:00
|
|
|
impl server::Server for Rustc<'_, '_> {
|
2022-06-26 11:48:33 -05:00
|
|
|
fn globals(&mut self) -> ExpnGlobals<Self::Span> {
|
|
|
|
ExpnGlobals {
|
|
|
|
def_site: self.def_site,
|
|
|
|
call_site: self.call_site,
|
|
|
|
mixed_site: self.mixed_site,
|
|
|
|
}
|
2021-06-29 13:49:54 -05:00
|
|
|
}
|
2022-06-30 20:05:46 -05:00
|
|
|
|
|
|
|
fn intern_symbol(string: &str) -> Self::Symbol {
|
|
|
|
Symbol::intern(string)
|
|
|
|
}
|
|
|
|
|
|
|
|
fn with_symbol_string(symbol: &Self::Symbol, f: impl FnOnce(&str)) {
|
|
|
|
f(&symbol.as_str())
|
|
|
|
}
|
2021-06-29 13:49:54 -05:00
|
|
|
}
|