about summary refs log tree commit diff
path: root/src/test/ui/proc-macro
AgeCommit message (Collapse)AuthorLines
2020-07-26report kind of deprecated item in messageAndy Russell-2/+2
This is important for fields, which are incorrectly referred to as "items".
2020-07-01Rollup merge of #73569 - Aaron1011:fix/macro-rules-group, r=petrochenkovManish Goregaokar-1/+266
Handle `macro_rules!` tokens consistently across crates When we serialize a `macro_rules!` macro, we used a 'lowered' `TokenStream` for its body, which has all `Nonterminal`s expanded in-place via `nt_to_tokenstream`. This matters when an 'outer' `macro_rules!` macro expands to an 'inner' `macro_rules!` macro - the inner macro may use tokens captured from the 'outer' macro in its definition. This means that invoking a foreign `macro_rules!` macro may use a different body `TokenStream` than when the same `macro_rules!` macro is invoked in the same crate. This difference is observable by proc-macros invoked by a `macro_rules!` macro - a `None`-delimited group will be seen in the same-crate case (inserted when convering `Nonterminal`s to the `proc_macro` crate's structs), but no `None`-delimited group in the cross-crate case. To fix this inconsistency, we now insert `None`-delimited groups when 'lowering' a `Nonterminal` `macro_rules!` body, just as we do in `proc_macro_server`. Additionally, we no longer print extra spaces for `None`-delimited groups - as far as pretty-printing is concerned, they don't exist (only their contents do). This ensures that `Display` output of a `TokenStream` does not depend on which crate a `macro_rules!` macro was invoked from. This PR is necessary in order to patch the `solana-genesis-programs` for the upcoming hygiene serialization breakage (https://github.com/rust-lang/rust/pull/72121#issuecomment-646924847). The `solana-genesis-programs` crate will need to use a proc macro to re-span certain tokens in a nested `macro_rules!`, which requires us to consistently use a `None`-delimited group. See `src/test/ui/proc-macro/nested-macro-rules.rs` for an example of the kind of nested `macro_rules!` affected by this crate.
2020-07-01Handle `None`-delimited groups when parsing `macro_rules!` macroAaron Hill-0/+24
When a `macro_rules!` macro expands to another `macro_rules!` macro, we may see `None`-delimited groups in odd places when another crate deserializes the 'inner' macro. This commit 'unwraps' an outer `None`-delimited group to avoid breaking existing code. See https://github.com/rust-lang/rust/pull/73569#issuecomment-650860457 for more details. The proper fix is to handle `None`-delimited groups systematically throughout the parser, but that will require significant work. In the meantime, this hack lets us fix important hygiene bugs in macros
2020-07-01Don't print additional spaces when pretty-printing NoDelim groupsAaron Hill-3/+1
2020-07-01Insert NoDelim groups around nonterminals when lowering macro_rulesAaron Hill-0/+243
2020-07-01expand: Stop using nonterminals for passing tokens to attribute and derive ↵Vadim Petrochenkov-42/+31
macros
2020-06-30Add force-host to test aux file used by proc-macroAaron Hill-2/+4
2020-06-29Normalize symbol ids to 0 in test stdoutAaron Hill-9/+13
The number of symbols we allocate (even early on) seems to be platform dependent. We only care about hygiene for the purposes of this test, so just set all of the symbol ids to zero
2020-06-29Serialize all foreign `SourceFile`s into proc-macro crate metadataAaron Hill-1/+81
Normally, we encode a `Span` that references a foreign `SourceFile` by encoding information about the foreign crate. When we decode this `Span`, we lookup the foreign crate in order to decode the `SourceFile`. However, this approach does not work for proc-macro crates. When we load a proc-macro crate, we do not deserialzie any of its dependencies (since a proc-macro crate can only export proc-macros). This means that we cannot serialize a reference to an upstream crate, since the associated metadata will not be available when we try to deserialize it. This commit modifies foreign span handling so that we treat all foreign `SourceFile`s as local `SourceFile`s when serializing a proc-macro. All `SourceFile`s will be stored into the metadata of a proc-macro crate, allowing us to cotinue to deserialize a proc-macro crate without needing to load any of its dependencies. Since the number of foreign `SourceFile`s that we load during a compilation session may be very large, we only serialize a `SourceFile` if we have also serialized a `Span` which requires it.
2020-06-15Always capture tokens for `macro_rules!` argumentsAaron Hill-0/+179
2020-06-11Rollup merge of #73012 - Aaron1011:feature/span-debug-ctxt, r=matthewjasperDylan DPC-30/+30
Show `SyntaxContext` in formatted `Span` debug output This is only really useful in debug messages, so I've switched to calling `span_to_string` in any place that causes a `Span` to end up in user-visible output.
2020-06-10Rollup merge of #73157 - Aaron1011:where-oh-where-has-my-little-span-gone, ↵Dylan DPC-0/+39
r=ecstatic-morse Don't lose empty `where` clause when pretty-printing Previously, we would parse `struct Foo where;` and `struct Foo;` identically, leading to an 'empty' `where` clause being omitted during pretty printing. This will cause us to lose spans when proc-macros involved, since we will have a collected `where` token that does not appear in the pretty-printed item. We now explicitly track the presence of a `where` token during parsing, so that we can distinguish between `struct Foo where;` and `struct Foo;` during pretty-printing
2020-06-10Rollup merge of #72789 - petrochenkov:impcand, r=davidtwcoDylan DPC-4/+0
resolve: Do not suggest imports from the same module in which we are resolving Based on the idea from https://github.com/rust-lang/rust/pull/72623.
2020-06-08Show `SyntaxContext` in formatted `Span` debug outputAaron Hill-30/+30
This is only really useful in debug messages, so I've switched to calling `span_to_string` in any place that causes a `Span` to end up in user-visible output.
2020-06-08Don't lose empty `where` clause when pretty-printingAaron Hill-0/+39
Previously, we would parse `struct Foo where;` and `struct Foo;` identically, leading to an 'empty' `where` clause being omitted during pretty printing. This will cause us to lose spans when proc-macros involved, since we will have a collected `where` token that does not appear in the pretty-printed item. We now explicitly track the presence of a `where` token during parsing, so that we can distinguish between `struct Foo where;` and `struct Foo;` during pretty-printing
2020-06-04Add `-Z span-debug` to allow for easier debugging of proc macrosAaron Hill-0/+207
Currently, the `Debug` impl for `proc_macro::Span` just prints out the byte range. This can make debugging proc macros (either as a crate author or as a compiler developer) very frustrating, since neither the actual filename nor the `SyntaxContext` is displayed. This commit adds a perma-unstable flag `-Z span-debug`. When enabled, the `Debug` impl for `proc_macro::Span` simply forwards directly to `rustc_span::Span`. Once #72618 is merged, this will start displaying actual line numbers. While `Debug` impls are not subject to Rust's normal stability guarnatees, we probably shouldn't expose any additional information on stable until `#![feature(proc_macro_span)]` is stabilized. Otherwise, we would be providing a 'backdoor' way to access information that's supposed be behind unstable APIs.
2020-05-31Add a test for `$:ident` in proc macro inputVadim Petrochenkov-0/+94
2020-05-31test-macros: Avoid always producing errors in `#[derive(Print)]`Vadim Petrochenkov-33/+5
2020-05-30resolve: Do not suggest imports from the same module in which we are resolvingVadim Petrochenkov-4/+0
2020-05-29Revert "Add test for macro_rules! invoking a proc-macro with capture groups"Aaron Hill-30/+0
This reverts commit 30c00fd26a24f349df64a7c0f5c3490e9f624322.
2020-05-24Collect tokens for `ast::Expr`Aaron Hill-0/+30
2020-05-22Add test for macro_rules! invoking a proc-macro with capture groupsAaron Hill-0/+30
2020-05-20Fix testsAaron Hill-1/+1
2020-05-19Use a fixed-point iteration when breaking tokensAaron Hill-18/+37
Some tokens need to be broken in a loop until we reach 'unbreakable' tokens.
2020-05-19Break tokens before checking if they are 'probably equal'Aaron Hill-0/+18
Fixes #68489 When checking two `TokenStreams` to see if they are 'probably equal', we ignore the `IsJoint` information associated with each `TokenTree`. However, the `IsJoint` information determines whether adjacent tokens will be 'glued' (if possible) when construction the `TokenStream` - e.g. `[Gt Gt]` can be 'glued' to `BinOp(Shr)`. Since we are ignoring the `IsJoint` information, 'glued' and 'unglued' tokens are equivalent for determining if two `TokenStreams` are 'probably equal'. Therefore, we need to 'unglue' all tokens in the stream to avoid false negatives (which cause us to throw out the cached tokens, losing span information).
2020-05-19Auto merge of #68717 - petrochenkov:stabexpat, r=varkorbors-154/+66
Stabilize fn-like proc macros in expression, pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 ("Stabilize `Span::mixed_site`"). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.
2020-05-15Add test of proc_macro::TokenStream's DebugDavid Tolnay-0/+221
2020-05-07reword "possible candidate" import suggestionAndy Russell-7/+7
2020-05-05Ignore SGX on a few ui testsMohsen Zohrevandi-0/+1
2020-05-03Stabilize fn-like proc macros in expression, pattern and statement positionsVadim Petrochenkov-154/+66
2020-04-28Rollup merge of #71340 - Valloric:more-check-pass, r=nikomatsakisDylan DPC-1/+1
Moving more build-pass tests to check-pass One or two tests became build-pass without the FIXME because they really needed build-pass (were failing without it). Helps with #62277 --- <!-- Reviewable:start --> This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/rust-lang/rust/71340) <!-- Reviewable:end -->
2020-04-26Stabilize `Span::mixed_site`Vadim Petrochenkov-1/+0
2020-04-25Add a test for `Span::resolved_at` and `Span::located_at`Vadim Petrochenkov-0/+65
2020-04-23Moving more build-pass tests to check-passVal Markovic-1/+1
One or two tests became build-pass without the FIXME because they really needed build-pass (were failing without it). Helps with #62277
2020-04-21proc_macro::is_available()David Tolnay-0/+31
2020-04-11rustc: Add a warning count upon completionRoccoDev-2/+6
2020-04-02tests: remove ignore directives from tests that mention core/alloc/std spans.Eduard-Mihai Burtescu-43/+35
2020-03-24resolve: Remove `rustc_attrs` as a standalone feature gateVadim Petrochenkov-3/+74
Now it only gates specific built-in attributes
2020-03-24expand: address review commentsMazdak Farrokhzad-13/+14
2020-03-24defatalize ProcMacroDerive::expandMazdak Farrokhzad-13/+36
Also remove ExtCtxt::struct_span_fatal.
2020-03-24defatalize BangProcMacro::expandMazdak Farrokhzad-6/+25
2020-03-23Rollup merge of #70300 - aleksator:66636_reword_unused_variable_warning, ↵Mazdak Farrokhzad-1/+1
r=Dylan-DPC Reword unused variable warning Fixes #66636
2020-03-23Rollup merge of #70233 - petrochenkov:superproc, r=ecstatic-morseMazdak Farrokhzad-0/+39
resolve: Do not resolve visibilities on proc macro definitions twice Fixes https://github.com/rust-lang/rust/issues/68921
2020-03-23Rollup merge of #69942 - estebank:sized-verbose-sugg, r=matthewjasperMazdak Farrokhzad-3/+3
Increase verbosity when suggesting subtle code changes Do not suggest changes that are actually quite small inline, to minimize the likelihood of confusion. Fix #69243.
2020-03-23Reword unused variable warningAlex Tokarev-1/+1
2020-03-23resolve: Do not resolve visibilities on proc macro definitions twiceVadim Petrochenkov-0/+39
2020-03-23Rollup merge of #70227 - LeSeulArtichaut:typo-def, r=CentrilMazdak Farrokhzad-12/+8
Only display definition when suggesting a typo Closes #70206 r? @Centril
2020-03-22Normalize wording of privacy access labelsEsteban Küber-1/+1
2020-03-22Add span label to primary error spanEsteban Küber-2/+2
2020-03-22proc_macro_harness: Use item header spans for errorsVadim Petrochenkov-26/+12