summary refs log tree commit diff
path: root/src/test/ui/proc-macro
AgeCommit message (Collapse)AuthorLines
2021-03-18Extend `proc_macro_back_compat` lint to `actix-web`Aaron Hill-7/+79
Unlike the other cases of this lint, there's no simple way to detect if an old version of the relevant crate (`syn`) is in use. The `actix-web` crate only depends on `pin-project` v1.0.0, so checking the version of `actix-web` does not guarantee that a new enough version of `pin-project` (and therefore `syn`) is in use. Instead, we rely on the fact that virtually all of the regressed crates are pinned to a pre-1.0 version of `pin-project`. When this is the case, bumping the `actix-web` dependency will pull in the *latest* version of `pin-project`, which has an explicit dependency on a newer v dependency on a newer version of `syn`. The lint message tells users to update `actix-web`, since that's what they're most likely to have control over. We could potentially tell them to run `cargo update -p syn`, but I think it's more straightforward to suggest an explicit change to the `Cargo.toml` The `actori-web` fork had its last commit over a year ago, and appears to just be a renamed fork of `actix-web`. Therefore, I've removed the `actori-web` check entirely - any crates that actually get broken can simply update `syn` themselves.
2021-03-15Extend `proc_macro_back_compat` lint to `procedural-masquerade`Aaron Hill-0/+60
We now lint on *any* use of `procedural-masquerade` crate. While this crate still exists, its main reverse dependency (`cssparser`) no longer depends on it. Any crates still depending off should stop doing so, as it only exists to support very old Rust versions. If a crate actually needs to support old versions of rustc via `procedural-masquerade`, then they'll just need to accept the warning until we remove it entirely (at the same time as the back-compat hack). The latest version of `procedural-masquerade` does not work with the latest rustc, but trying to check for the version seems like more trouble than it's worth. While working on this, I realized that the `proc-macro-hack` check was never actually doing anything. The corresponding enum variant in `proc-macro-hack` is named `Value` or `Nested` - it has never been called `Input`. Due to a strange Crater issue, the Crater run that tested adding this did *not* end up testing it - some of the crates that would have failed did not actually have their tests checked, making it seem as though the `proc-macro-hack` check was working. The Crater issue is being discussed at https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/Nearly.20identical.20Crater.20runs.20processed.20a.20crate.20differently/near/230406661 Despite the `proc-macro-hack` check not actually doing anything, we haven't gotten any reports from users about their build being broken. I went ahead and removed it entirely, since it's clear that no one is being affected by the `proc-macro-hack` regression in practice.
2021-03-14Introduce `proc_macro_back_compat` lint, and emit for `time-macros-impl`Aaron Hill-11/+83
Now that future-incompat-report support has landed in nightly Cargo, we can start to make progress towards removing the various proc-macro back-compat hacks that have accumulated in the compiler. This PR introduces a new lint `proc_macro_back_compat`, which results in a future-incompat-report entry being generated. All proc-macro back-compat warnings will be grouped under this lint. Note that this lint will never actually become a hard error - instead, we will remove the special cases for various macros, which will cause older versions of those crates to emit some other error. I've added code to fire this lint for the `time-macros-impl` case. This is the easiest case out of all of our current back-compat hacks - the crate was renamed to `time-macros`, so seeing a filename with `time-macros-impl` guarantees that an older version of the parent `time` crate is in use. When Cargo's future-incompat-report feature gets stabilized, affected users will start to see future-incompat warnings when they build their crates.
2021-03-14expand: Resolve and expand inner attributes on out-of-line modulesVadim Petrochenkov-0/+138
2021-03-10Rollup merge of #82217 - m-ou-se:edition-prelude, r=nikomatsakisDylan DPC-2/+2
Edition-specific preludes This changes `{std,core}::prelude` to export edition-specific preludes under `rust_2015`, `rust_2018` and `rust_2021`. (As suggested in https://github.com/rust-lang/rust/issues/51418#issuecomment-395630382.) For now they all just re-export `v1::*`, but this allows us to add things to the 2021edition prelude soon. This also changes the compiler to make the automatically injected prelude import dependent on the selected edition. cc `@rust-lang/libs` `@djc`
2021-03-06Implement built-in attribute macro `#[cfg_eval]`Vadim Petrochenkov-0/+196
2021-02-28Add more proc-macro attribute testsAaron Hill-371/+2249
2021-02-27Rollup merge of #82419 - petrochenkov:inertord, r=Aaron1011Dylan DPC-38/+112
expand: Preserve order of inert attributes during expansion Fixes https://github.com/rust-lang/rust/issues/67839 Fixes https://github.com/rust-lang/rust/issues/81871 r? `````@Aaron1011`````
2021-02-25Update test output for edition preludes.Mara Bos-2/+2
2021-02-23expand: Preserve order of inert attributes during expansionVadim Petrochenkov-48/+41
2021-02-23Add testsVadim Petrochenkov-6/+87
2021-02-21reword `;` suggestions to have consistent wordingEsteban Küber-1/+1
2021-02-09Visit more targets when checking attrsRyan Levick-6/+6
2021-02-07Address review commentsVadim Petrochenkov-0/+38
2021-02-07Feature gate macro attributes in `#[derive]` outputVadim Petrochenkov-29/+89
2021-02-07expand/resolve: Turn `#[derive]` into a regular macro attributeVadim Petrochenkov-420/+688
2021-02-02Rollup merge of #81608 - Aaron1011:macro-res-parse-err, r=davidtwcoJonas Schievink-1/+28
Improve handling of spans around macro result parse errors Fixes #81543 After we expand a macro, we try to parse the resulting tokens as a AST node. This commit makes several improvements to how we handle spans when an error occurs: * Only ovewrite the original `Span` if it's a dummy span. This preserves a more-specific span if one is available. * Use `self.prev_token` instead of `self.token` when emitting an error message after encountering EOF, since an EOF token always has a dummy span * Make `SourceMap::next_point` leave dummy spans unused. A dummy span does not have a logical 'next point', since it's a zero-length span. Re-using the span span preserves its 'dummy-ness' for other checks
2021-02-02Bless testsDanuel-3/+3
2021-02-01Fixed #[inline] to be warned in fields, arms, macro defsDanuel-2/+13
Add visitors for checking #[inline] Add visitors for checking #[inline] with struct field Fix test for #[inline] Add visitors for checking #[inline] with #[macro_export] macro Add visitors for checking #[inline] without #[macro_export] macro Add use alias with Visitor Fix lint error Reduce unnecessary variable Co-authored-by: LingMan <LingMan@users.noreply.github.com> Change error to warning Add warning for checking field, arm with #[allow_internal_unstable] Add name resolver Formatting Formatting Fix error fixture Add checking field, arm, macro def
2021-01-31Improve handling of spans around macro result parse errorsAaron Hill-1/+28
Fixes #81543 After we expand a macro, we try to parse the resulting tokens as a AST node. This commit makes several improvements to how we handle spans when an error occurs: * Only ovewrite the original `Span` if it's a dummy span. This preserves a more-specific span if one is available. * Use `self.prev_token` instead of `self.token` when emitting an error message after encountering EOF, since an EOF token always has a dummy span * Make `SourceMap::next_point` leave dummy spans unused. A dummy span does not have a logical 'next point', since it's a zero-length span. Re-using the span span preserves its 'dummy-ness' for other checks
2021-01-28Clone entire `TokenCursor` when collecting tokensAaron Hill-0/+40
Reverts PR #80830 Fixes taiki-e/pin-project#312 We can have an arbitrary number of `None`-delimited group frames pushed on the stack due to proc-macro invocations, which can legally be exited. Attempting to account for this would add a lot of complexity for a tiny performance gain, so let's just use the original strategy.
2021-01-20Force token collection to run when parsing nonterminalsAaron Hill-0/+130
Fixes #81007 Previously, we would fail to collect tokens in the proper place when only builtin attributes were present. As a result, we would end up with attribute tokens in the collected `TokenStream`, leading to duplication when we attempted to prepend the attributes from the AST node. We now explicitly track when token collection must be performed due to nomterminal parsing.
2021-01-17resolve: Reject ambiguity built-in attr vs different built-in attrVadim Petrochenkov-2/+20
2021-01-13Update code to account for extern ABI requirementMark Rousskov-5/+5
2021-01-13Update tests for extern block lintingMark Rousskov-3/+5
2021-01-09Synthesize a `TokenStream` for `StmtKind::Empty`Aaron Hill-0/+40
Fixes #80760
2021-01-07rustc_parse: Better spans for synthesized token streamsVadim Petrochenkov-137/+137
2020-12-19Auto merge of #79073 - davidtwco:issue-78957-const-param-attrs, r=lcnrbors-5/+13
passes: prohibit invalid attrs on generic params Fixes #78957. This PR modifies the `check_attr` pass so that attribute placement on generic parameters is checked for validity. r? `@lcnr`
2020-12-12Properly capture trailing 'unglued' tokenAaron Hill-0/+48
If we try to capture the `Vec<u8>` in `Option<Vec<u8>>`, we'll need to capture a `>` token which was 'unglued' from a `>>` token. The processing of unglueing a token for parsing purposes bypasses the usual capturing infrastructure, so we currently lose the trailing `>`. As a result, we fall back to the reparsed `TokenStream`, causing us to lose spans. This commit makes token capturing keep track of a trailing 'unglued' token. Note that we don't need to care about unglueing except at the end of the captured tokens - if we capture both the first and second unglued tokens, then we'll end up capturing the full 'glued' token, which already works correctly.
2020-12-05Add a regression test for issue-66286Yuki Okushi-0/+39
2020-11-29passes: prohibit attrs on generic paramsDavid Wood-5/+13
This commit modifies the `check_attr` pass so that attribute placement on generic parameters is checked for validity. Signed-off-by: David Wood <david@davidtw.co>
2020-11-28Auto merge of #78296 - Aaron1011:fix/stmt-tokens, r=petrochenkovbors-99/+346
Properly handle attributes on statements We now collect tokens for the underlying node wrapped by `StmtKind` nstead of storing tokens directly in `Stmt`. `LazyTokenStream` now supports capturing a trailing semicolon after it is initially constructed. This allows us to avoid refactoring statement parsing to wrap the parsing of the semicolon in `parse_tokens`. Attributes on item statements (e.g. `fn foo() { #[bar] struct MyStruct; }`) are now treated as item attributes, not statement attributes, which is consistent with how we handle attributes on other kinds of statements. The feature-gating code is adjusted so that proc-macro attributes are still allowed on item statements on stable. Two built-in macros (`#[global_allocator]` and `#[test]`) needed to be adjusted to support being passed `Annotatable::Stmt`.
2020-11-26Use custom macro instead of printlnAaron Hill-141/+152
Loading a macro from libstd causes us to load serialized `SyntaxContext`s in a platform-dependent way, causing the printed spans to differ between platforms.
2020-11-26Add additional semicolon testAaron Hill-108/+126
2020-11-26Only eat semicolons for statements that need themAaron Hill-6/+1
When parsing a statement (e.g. inside a function body), we now consider `struct Foo {};` and `$stmt;` to each consist of two statements: `struct Foo {}` and `;`, and `$stmt` and `;`. As a result, an attribute macro invoke as `fn foo() { #[attr] struct Bar{}; }` will see `struct Bar{}` as its input. Additionally, the 'unused semicolon' lint now fires in more places.
2020-11-26Properly handle attributes on statementsAaron Hill-74/+297
We now collect tokens for the underlying node wrapped by `StmtKind` instead of storing tokens directly in `Stmt`. `LazyTokenStream` now supports capturing a trailing semicolon after it is initially constructed. This allows us to avoid refactoring statement parsing to wrap the parsing of the semicolon in `parse_tokens`. Attributes on item statements (e.g. `fn foo() { #[bar] struct MyStruct; }`) are now treated as item attributes, not statement attributes, which is consistent with how we handle attributes on other kinds of statements. The feature-gating code is adjusted so that proc-macro attributes are still allowed on item statements on stable. Two built-in macros (`#[global_allocator]` and `#[test]`) needed to be adjusted to support being passed `Annotatable::Stmt`.
2020-11-26Auto merge of #79338 - Aaron1011:fix/token-reparse-cache, r=petrochenkovbors-0/+50
Cache pretty-print/retokenize result to avoid compile time blowup Fixes #79242 If a `macro_rules!` recursively builds up a nested nonterminal (passing it to a proc-macro at each step), we will end up repeatedly pretty-printing/retokenizing the same nonterminals. Unfortunately, the 'probable equality' check we do has a non-trivial cost, which leads to a blowup in compilation time. As a workaround, we cache the result of the 'probable equality' check, which eliminates the compilation time blowup for the linked issue. This commit only touches a single file (other than adding tests), so it should be easy to backport. The proper solution is to remove the pretty-print/retokenize hack entirely. However, this will almost certainly break a large number of crates that were relying on hygiene bugs created by using the reparsed `TokenStream`. As a result, we will definitely not want to backport such a change.
2020-11-24Invoke attributes on the statement for statement itemsAaron Hill-4/+524
2020-11-23Cache pretty-print/retokenize result to avoid compile time blowupAaron Hill-0/+50
Fixes #79242 If a `macro_rules!` recursively builds up a nested nonterminal (passing it to a proc-macro at each step), we will end up repeatedly pretty-printing/retokenizing the same nonterminals. Unfortunately, the 'probable equality' check we do has a non-trivial cost, which leads to a blowup in compilation time. As a workaround, we cache the result of the 'probable equality' check, which eliminates the compilation time blowup for the linked issue. This commit only touches a single file (other than adding tests), so it should be easy to backport. The proper solution is to remove the pretty-print/retokenize hack entirely. However, this will almost certainly break a large number of crates that were relying on hygiene bugs created by using the reparsed `TokenStream`. As a result, we will definitely not want to backport such a change.
2020-11-20rustc_expand: Mark inner `#![test]` attributes as soft-unstableVadim Petrochenkov-1/+16
2020-11-19resolve: Centralize some error reporting for unexpected macro resolutionsVadim Petrochenkov-16/+16
2020-11-06More detailed output for the nonterminal marking testVadim Petrochenkov-1/+95
2020-11-06rustc_ast: Visit tokens stored in AST nodes in mutable visitorVadim Petrochenkov-0/+27
2020-11-04Auto merge of #78677 - Aaron1011:fix/capture-inner-attrs, r=petrochenkovbors-0/+118
Use reparsed `TokenStream` if we captured any inner attributes Fixes #78675 We now bail out of `prepend_attrs` if we ended up capturing any inner attributes (which can happen in several places, due to token capturing for `macro_rules!` arguments.
2020-11-03Rollup merge of #78376 - Aaron1011:feature/consistent-empty-expr, r=petrochenkovYuki Okushi-1/+1
Treat trailing semicolon as a statement in macro call See #61733 (comment) We now preserve the trailing semicolon in a macro invocation, even if the macro expands to nothing. As a result, the following code no longer compiles: ```rust macro_rules! empty { () => { } } fn foo() -> bool { //~ ERROR mismatched { true } //~ ERROR mismatched empty!(); } ``` Previously, `{ true }` would be considered the trailing expression, even though there's a semicolon in `empty!();` This makes macro expansion more token-based.
2020-11-03Expand `NtExpr` tokens only in key-value attributesVadim Petrochenkov-0/+85
2020-11-02Use reparsed `TokenStream` if we captured any inner attributesAaron Hill-0/+118
Fixes #78675 We now bail out of `prepend_attrs` if we ended up capturing any inner attributes (which can happen in several places, due to token capturing for `macro_rules!` arguments.
2020-11-02Treat trailing semicolon as a statement in macro callAaron Hill-1/+1
See https://github.com/rust-lang/rust/issues/61733#issuecomment-716188981 We now preserve the trailing semicolon in a macro invocation, even if the macro expands to nothing. As a result, the following code no longer compiles: ```rust macro_rules! empty { () => { } } fn foo() -> bool { //~ ERROR mismatched { true } //~ ERROR mismatched empty!(); } ``` Previously, `{ true }` would be considered the trailing expression, even though there's a semicolon in `empty!();` This makes macro expansion more token-based.
2020-10-21Unconditionally capture tokens for attributes.Aaron Hill-8/+8
This allows us to avoid synthesizing tokens in `prepend_attr`, since we have the original tokens available. We still need to synthesize tokens when expanding `cfg_attr`, but this is an unavoidable consequence of the syntax of `cfg_attr` - the user does not supply the `#` and `[]` tokens that a `cfg_attr` expands to.
2020-10-19Calculate visibilities once in resolveVadim Petrochenkov-22/+4
Then use them through a query based on resolver outputs
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-08 00:23:23 +0000