summary refs log tree commit diff
path: root/src/test/ui/proc-macro
AgeCommit message (Collapse)AuthorLines
2020-09-17Account for version number in NtIdent hackAaron Hill-7/+43
Issue #74616 tracks a backwards-compatibility hack for certain macros. This has is implemented by hard-coding the filenames and macro names of certain code that we want to continue to compile. However, the initial implementation of the hack was based on the directory structure when building the crate from its repository (e.g. `js-sys/src/lib.rs`). When the crate is build as a dependency, it will include a version number from the clone from the cargo registry (e.g. `js-sys-0.3.17/src/lib.rs`), which would fail the check. This commit modifies the backwards-compatibility hack to check that desired crate name (`js-sys` or `time-macros-impl`) is a prefix of the proper part of the path. See https://github.com/rust-lang/rust/issues/76070#issuecomment-687215646 for more details.
2020-08-23Auto merge of #75465 - Aaron1011:feature/short-fn-def-span, r=estebankbors-1/+1
Use smaller def span for functions Currently, the def span of a function encompasses the entire function signature and body. However, this is usually unnecessarily verbose - when we are pointing at an entire function in a diagnostic, we almost always want to point at the signature. The actual contents of the body tends to be irrelevant to the diagnostic we are emitting, and just takes up additional screen space. This commit changes the `def_span` of all function items (freestanding functions, `impl`-block methods, and `trait`-block methods) to be the span of the signature. For example, the function ```rust pub fn foo<T>(val: T) -> T { val } ``` now has a `def_span` corresponding to `pub fn foo<T>(val: T) -> T` (everything before the opening curly brace). Trait methods without a body have a `def_span` which includes the trailing semicolon. For example: ```rust trait Foo { fn bar(); } ``` the function definition `Foo::bar` has a `def_span` of `fn bar();` This makes our diagnostic output much shorter, and emphasizes information that is relevant to whatever diagnostic we are reporting. We continue to use the full span (including the body) in a few of places: * MIR building uses the full span when building source scopes. * 'Outlives suggestions' use the full span to sort the diagnostics being emitted. * The `#[rustc_on_unimplemented(enclosing_scope="in this scope")]` attribute points the entire scope body. All of these cases work only with local items, so we don't need to add anything extra to crate metadata.
2020-08-22Use smaller def span for functionsAaron Hill-1/+1
Currently, the def span of a funtion encompasses the entire function signature and body. However, this is usually unnecessarily verbose - when we are pointing at an entire function in a diagnostic, we almost always want to point at the signature. The actual contents of the body tends to be irrelevant to the diagnostic we are emitting, and just takes up additional screen space. This commit changes the `def_span` of all function items (freestanding functions, `impl`-block methods, and `trait`-block methods) to be the span of the signature. For example, the function ```rust pub fn foo<T>(val: T) -> T { val } ``` now has a `def_span` corresponding to `pub fn foo<T>(val: T) -> T` (everything before the opening curly brace). Trait methods without a body have a `def_span` which includes the trailing semicolon. For example: ```rust trait Foo { fn bar(); }``` the function definition `Foo::bar` has a `def_span` of `fn bar();` This makes our diagnostic output much shorter, and emphasizes information that is relevant to whatever diagnostic we are reporting. We continue to use the full span (including the body) in a few of places: * MIR building uses the full span when building source scopes. * 'Outlives suggestions' use the full span to sort the diagnostics being emitted. * The `#[rustc_on_unimplemented(enclosing_scope="in this scope")]` attribute points the entire scope body. * The 'unconditional recursion' lint uses the full span to show additional context for the recursive call. All of these cases work only with local items, so we don't need to add anything extra to crate metadata.
2020-08-22Add backwards-compat hack for certain '$name' tokensAaron Hill-0/+60
See issue #74616
2020-08-22Recursively expand `TokenKind::Interpolated` (take 2)Aaron Hill-62/+112
Fixes #68430 This is a re-attempt of PR #72388, which was previously reverted due to a large number of breakages. All of the known breakages should now be patched upstream.
2020-08-20Capture tokens for Pat used in macro_rules! argumentAaron Hill-2/+55
This extends PR #73293 to handle patterns (Pat). Unlike expressions, patterns do not support custom attributes, so we only need to capture tokens during macro_rules! argument parsing.
2020-08-10Auto merge of #74005 - estebank:type-ascription-redux, r=petrochenkovbors-10/+2
Clean up errors in typeck and resolve * Tweak ordering of suggestions * Do not suggest similarly named enclosing item * Point at item definition in foreign crates * Add missing primary label CC #34255.
2020-08-10Do not suggest similarly named enclosing itemEsteban Küber-10/+2
2020-08-09Remove normalization of `Span` debug output in proc-macro testsAaron Hill-163/+233
Fixes #74800 The definition of `is_x86_feature_detected!` (and similar macros) depends on the platform - it is produced by a `cfg_if!` invocation on x86, and a plain `#[cfg]` on other platforms. Since it is part of the prelude, we will end up importing different hygiene information depending on the platform. This previously required us to avoid printing raw `SyntaxContext` ids in any tests that uses the standard library, since the captured output will be platform-dependent. Previously, we replaced all `SyntaxContext` ids with "#CTXT", and the raw `Span` lo/hi bytes with "LO..HI". This commit adds `#![no_std]` and `extern crate std` to all proc-macro tests that print spans. This suppresses the prelude import, while still using lang items from `std` (which gives us a buildable binary). With this apporach, we will only load hygiene information for things which we explicitly import. This lets us re-add `-Z unpretty=expanded,hygiene`, since its output can now be made stable across all platforms. Additionally, we use `-Z span-debug` in more places, which lets us avoid the "LO..HI" normalization hack.
2020-08-06Add some comments for magic numbers + Add testsVadim Petrochenkov-0/+78
2020-08-03Stabilize Ident::new_rawAaron Hill-0/+61
Tracking issue: #54723 This is a continuation of PR #59002
2020-08-02fix typosliuzhenyu-1/+1
2020-08-02Auto merge of #74785 - euclio:deprecation-kinds, r=petrochenkovbors-2/+2
report kind of deprecated item in message This is important for fields, which are incorrectly referred to as "items".
2020-07-27mv std libs to library/mark-5/+5
2020-07-26Normalize the test output of hygiene-related testsAaron Hill-194/+142
A raw SyntaxContext id is implicitly dependent on the target platform, since libstd and libcore have platform-dependent #[cfg]s which affect which macros are invoked. As a result, we must strip out any SyntaxContext ids from test output to ensure that the captured stdout is not platform-dependent.
2020-07-26Remove explicit `extern crate` from proc-macro testAaron Hill-3/+1
We only want to load this auxiliary crate from a proc-macro, so that it only ever needs to get built for the host platform.
2020-07-26Add test for serializing hygiene *into* a proc-macro crateAaron Hill-12/+61
This is a very obscure corner case, and should never be hit in practice.
2020-07-26Hygiene serialization implementationAaron Hill-117/+124
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
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-07 18:04:22 +0000