- 27 6月, 2022 3 次提交
-
-
由 Nika Layzell 提交于
This greatly reduces round-trips to fetch relevant extra information about the token in proc macro code, and avoids RPC messages to create Group tokens.
-
由 Nika Layzell 提交于
This greatly reduces round-trips to fetch relevant extra information about the token in proc macro code, and avoids RPC messages to create Punct tokens.
-
由 Nika Layzell 提交于
-
- 26 6月, 2022 1 次提交
-
-
由 Nika Layzell 提交于
-
- 25 6月, 2022 1 次提交
-
-
由 Nika Layzell 提交于
This greatly improves the performance of the very frequently called `call_site()` macro when running in a cross-thread configuration.
-
- 20 6月, 2022 2 次提交
-
-
由 Nicholas Nethercote 提交于
Because that's the standard way of doing it.
-
由 Nicholas Nethercote 提交于
It's a weird function: it lets you modify the token stream in the middle of iteration. There is only one call site, and it is only used for the rare `ProceduralMasquerade` legacy case.
-
- 18 6月, 2022 1 次提交
-
-
由 Nika Layzell 提交于
-
- 17 6月, 2022 2 次提交
-
-
由 Nika Layzell 提交于
This is an experimental patch to try to reduce the codegen complexity of TokenStream's FromIterator and Extend implementations for downstream crates, by moving the core logic into a helper type. This might help improve build performance of crates which depend on proc_macro as iterators are used less, and the compiler may take less time to do things like attempt specializations or other iterator optimizations. The change intentionally sacrifices some optimization opportunities, such as using the specializations for collecting iterators derived from Vec::into_iter() into Vec. This is one of the simpler potential approaches to reducing the amount of code generated in crates depending on proc_macro, so it seems worth trying before other more-involved changes.
-
由 Nika Layzell 提交于
This significantly reduces the cost of common interactions with TokenStream when running with the CrossThread execution strategy, by reducing the number of RPC calls required.
-
- 16 6月, 2022 1 次提交
-
-
由 xFrednet 提交于
-
- 22 5月, 2022 1 次提交
-
-
由 Vadim Petrochenkov 提交于
-
- 18 5月, 2022 1 次提交
-
-
由 klensy 提交于
-
- 11 5月, 2022 1 次提交
-
-
由 Vadim Petrochenkov 提交于
And use them to avoid constructing some artificial `Nonterminal` tokens during expansion
-
- 28 4月, 2022 1 次提交
-
-
由 Vadim Petrochenkov 提交于
-
- 05 4月, 2022 1 次提交
-
-
由 David Wood 提交于
`MultiSpan` contains labels, which are more complicated with the introduction of diagnostic translation and will use types from `rustc_errors` - however, `rustc_errors` depends on `rustc_span` so `rustc_span` cannot use types like `DiagnosticMessage` without dependency cycles. Introduce a new `rustc_error_messages` crate that can contain `DiagnosticMessage` and `MultiSpan`. Signed-off-by: NDavid Wood <david.wood@huawei.com>
-
- 27 3月, 2022 1 次提交
-
-
由 David Tolnay 提交于
-
- 26 3月, 2022 1 次提交
-
-
由 Vadim Petrochenkov 提交于
-
- 21 3月, 2022 1 次提交
-
-
由 Camille GILLOT 提交于
Taking a Diagnostic by move would break the usual pattern `diag.label(..).emit()`.
-
- 03 3月, 2022 1 次提交
-
-
由 cuishuang 提交于
Signed-off-by: Ncuishuang <imcusg@gmail.com>
-
- 23 2月, 2022 1 次提交
-
-
由 Eduard-Mihai Burtescu 提交于
-
- 20 2月, 2022 1 次提交
-
-
由 est31 提交于
-
- 09 1月, 2022 1 次提交
-
-
由 Lucas Kent 提交于
-
- 15 12月, 2021 1 次提交
-
-
由 Nicholas Nethercote 提交于
-
- 05 12月, 2021 1 次提交
-
-
由 Mara Bos 提交于
-
- 13 11月, 2021 1 次提交
-
-
由 Nika Layzell 提交于
This feature is aimed at giving proc macros access to powers similar to those used by builtin macros such as `format_args!` or `concat!`. These macros are able to accept macros in place of string literal parameters, such as the format string, as they perform recursive macro expansion while being expanded. This can be especially useful in many cases thanks to helper macros like `concat!`, `stringify!` and `include_str!` which are often used to construct string literals at compile-time in user code. For now, this method only allows expanding macros which produce literals, although more expresisons will be supported before the method is stabilized.
-
- 08 11月, 2021 1 次提交
-
-
由 Joshua Nelson 提交于
The only reason to use `abort_if_errors` is when the program is so broken that either: 1. later passes get confused and ICE 2. any diagnostics from later passes would be noise This is never the case for lints, because the compiler has to be able to deal with `allow`-ed lints. So it can continue to lint and compile even if there are lint errors.
-
- 22 9月, 2021 1 次提交
-
-
由 bjorn3 提交于
It is used exactly once and can be replaced with the equally fast .as_str().len()
-
- 11 9月, 2021 1 次提交
-
-
由 Camille GILLOT 提交于
-
- 26 8月, 2021 1 次提交
-
-
由 Léo Lanteri Thauvin 提交于
-
- 04 8月, 2021 1 次提交
-
-
由 David Tolnay 提交于
-
- 25 7月, 2021 1 次提交
-
-
由 Matthias Krüger 提交于
-
- 19 7月, 2021 1 次提交
-
-
由 David Tolnay 提交于
-
- 11 7月, 2021 3 次提交
-
-
由 Vadim Petrochenkov 提交于
- The `Rustc::expn_id` field kept redundant information - `SyntaxContext` is no longer thrown away before `save_proc_macro_span` because it's thrown away during metadata encoding anyway
-
由 Vadim Petrochenkov 提交于
This information is already available from `ExpnData`
-
由 Vadim Petrochenkov 提交于
The flag has a vague meaning and is used for a single diagnostic change that is low benefit and appears only under `-Z macro_backtrace`.
-
- 02 7月, 2021 1 次提交
-
-
由 Bernhard Schuster 提交于
Ref #73921
-
- 09 6月, 2021 1 次提交
-
-
由 Mara Bos 提交于
-
- 20 5月, 2021 1 次提交
-
-
由 David Tolnay 提交于
-
- 12 5月, 2021 1 次提交
-
-
由 Aaron Hill 提交于
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`.
-