about summary refs log tree commit diff
path: root/tests/ui/macros
AgeCommit message (Collapse)AuthorLines
2025-07-15Auto merge of #143958 - samueltardieu:rollup-lh1s143, r=samueltardieubors-6/+15
Rollup of 13 pull requests Successful merges: - rust-lang/rust#142301 (tests: Fix duplicated-path-in-error fail with musl) - rust-lang/rust#143630 (Drop `./x suggest`) - rust-lang/rust#143736 (Give all bytes of TypeId provenance) - rust-lang/rust#143752 (Don't panic if WASI_SDK_PATH not set when detecting compiler) - rust-lang/rust#143837 (Adjust `run_make_support::symbols` helpers) - rust-lang/rust#143878 (Port `#[pointee]` to the new attribute parsing infrastructure) - rust-lang/rust#143905 (Recover and suggest to use `;` to construct array type) - rust-lang/rust#143907 (core: make `str::split_at_unchecked()` inline) - rust-lang/rust#143910 (Add experimental `backtrace-trace-only` std feature) - rust-lang/rust#143927 (Preserve constness in trait objects up to hir ty lowering) - rust-lang/rust#143935 (rustc_type_ir/walk: move docstring to `TypeWalker` itself) - rust-lang/rust#143938 (Update books) - rust-lang/rust#143941 (update `cfg_select!` documentation) Failed merges: - rust-lang/rust#143926 (Remove deprecated fields in bootstrap) r? `@ghost` `@rustbot` modify labels: rollup
2025-07-15Changes to diagnosticsJonathan Brouwer-10/+4
2025-07-14update `cfg_select!` documentationFolkert de Vries-6/+15
and make internal terminology consistent Co-authored-by: Travis Cross <tc@traviscross.com>
2025-07-13Auto merge of #143461 - folkertdev:cfg-select-builtin-macro, r=petrochenkovbors-0/+52
make `cfg_select` a builtin macro tracking issue: https://github.com/rust-lang/rust/issues/115585 This parses mostly the same as the `macro cfg_select` version, except: 1. wrapping in double brackets is no longer supported (or needed): `cfg_select {{ /* ... */ }}` is now rejected. 2. in an expression context, the rhs is no longer wrapped in a block, so that this now works: ```rust fn main() { println!(cfg_select! { unix => { "foo" } _ => { "bar" } }); } ``` 3. a single wildcard rule is now supported: `cfg_select { _ => 1 }` now works I've also added an error if none of the rules evaluate to true, and warnings for any arms that follow the `_` wildcard rule. cc `@traviscross` if I'm missing any feature that should/should not be included r? `@petrochenkov` for the macro logic details
2025-07-13make `cfg_select` a builtin macroFolkert de Vries-0/+52
2025-07-11Rollup merge of #143302 - Kivooeo:tf27, r=tgross35Matthias Krüger-0/+29
`tests/ui`: A New Order [27/N] > [!NOTE] > > Intermediate commits are intended to help review, but will be squashed prior to merge. Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895. r? ``@tgross35``
2025-07-10cleaned up some testsKivooeo-5/+8
2025-07-10Rollup merge of #143298 - Kivooeo:tf23, r=tgross35Trevor Gross-0/+32
`tests/ui`: A New Order [23/N] > [!NOTE] > > Intermediate commits are intended to help review, but will be squashed prior to merge. Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895. r? ``@tgross35``
2025-07-09mbe: Refactor the diagnostic for unrecognized metavariable expressionsTrevor Gross-3/+5
Change to a structural diagnostic, update the valid list, and move the valid list to a note.
2025-07-09mbe: Refactor diagnostics for invalid metavar expression syntaxTrevor Gross-107/+110
Give a more user-friendly diagnostic about the following: * Trailing tokens within braces, e.g. `${foo() extra}` * Missing parentheses, e.g. `${foo}` * Incorrect number of arguments, with a hint about correct usage.
2025-07-05cleaned up some testsKivooeo-3/+5
2025-07-02Auto merge of #143338 - matthiaskrgr:rollup-ykaxh04, r=matthiaskrgrbors-1/+3
Rollup of 11 pull requests Successful merges: - rust-lang/rust#131923 (Derive `Copy` and `Hash` for `IntErrorKind`) - rust-lang/rust#138340 (Remove some unsized tuple impls now that we don't support unsizing tuples anymore) - rust-lang/rust#141219 (Change `{Box,Arc,Rc,Weak}::into_raw` to only work with `A = Global`) - rust-lang/rust#142212 (bootstrap: validate `rust.codegen-backends` & `target.<triple>.codegen-backends`) - rust-lang/rust#142237 (Detect more cases of unused_parens around types) - rust-lang/rust#142964 (Attribute rework: a parser for single attributes without arguments) - rust-lang/rust#143070 (Rewrite `macro_rules!` parser to not use the MBE engine itself) - rust-lang/rust#143235 (Assemble const bounds via normal item bounds in old solver too) - rust-lang/rust#143261 (Feed `explicit_predicates_of` instead of `predicates_of`) - rust-lang/rust#143276 (loop match: handle opaque patterns) - rust-lang/rust#143306 (Add `track_caller` attributes to trace origin of Clippy lints) r? `@ghost` `@rustbot` modify labels: rollup try-job: aarch64-apple try-job: x86_64-msvc-1 try-job: x86_64-gnu try-job: dist-i586-gnu-i586-i686-musl try-job: test-various
2025-07-02Rollup merge of #143070 - joshtriplett:macro-rules-parse, r=petrochenkovMatthias Krüger-1/+3
Rewrite `macro_rules!` parser to not use the MBE engine itself The `macro_rules!` parser was written to match the series of rules using the macros-by-example (MBE) engine and a hand-written equivalent of the left-hand side of a MBE macro. This was complex to read, difficult to extend, and produced confusing error messages. Because it was using the MBE engine, any parse failure would be reported as if some macro was being applied to the `macro_rules!` invocation itself; for instance, errors would talk about "macro invocation", "macro arguments", and "macro call", when they were actually about the macro *definition*. And in practice, the `macro_rules!` parser only used the MBE engine to extract the left-hand side and right-hand side of each rule as a token tree, and then parsed the rest using a separate parser. Rewrite it to parse the series of rules using a simple loop, instead. This makes it more extensible in the future, and improves error messages. For instance, omitting a semicolon between rules will result in "expected `;`" and "unexpected token", rather than the confusing "no rules expected this token in macro call". This work was greatly aided by pair programming with Vincenzo Palazzo (`@vincenzopalazzo)` and Eric Holk (`@eholk).` For review, I recommend reading the two commits separately.
2025-07-02Auto merge of #143214 - camsteffen:remove-let-chains-feature, r=est31bors-2/+1
Remove let_chains unstable feature Per https://github.com/rust-lang/rust/issues/53667#issuecomment-3016742982 (but then I also noticed rust-lang/rust#140722) This replaces the feature gate with a parser error that says let chains require 2024. A lot of tests were using the unstable feature. I either added edition:2024 to the test or split out the parts that require 2024.
2025-07-01moved testsKivooeo-0/+26
2025-07-01Auto merge of #142030 - oli-obk:wfck-less-hir, r=compiler-errorsbors-4/+4
Start moving wf checking away from HIR I'm trying to only access the HIR in the error path. My hope is that once we move significant portions of wfcheck off HIR that incremental will be able to cache wfcheck queries significantly better. I think I am reaching a blocker because we normally need to provide good spans to `ObligationCause`, so that the trait solver can report good errors. In some cases I have been able to use bad spans and improve them depending on the `ObligationCauseCode` (by loading HIR in the case where we actually want to error). To scale that further we'll likely need to remove spans from the `ObligationCause` entirely (leaving it to some variants of `ObligationCauseCode` to have a span when they can't recompute the information later). Unsure this is the right approach, but we've already been using it. I will create an MCP about it, but that should not affect this PR, which is fairly limited in where it does those kind of tricks. Especially https://github.com/rust-lang/rust/commit/b862d8828e375ab8c128a9d9e93bf98b77cb5928 is interesting here, because I think it improves spans in all cases
2025-07-01Rollup merge of #143245 - tgross35:metavariable-expr-organization, ↵Matthias Krüger-604/+666
r=petrochenkov mbe: Add tests and restructure metavariable expressions Add tests that show better diagnostics, and factor `concat` handling to a separate function. Each commit message has further details. This performs the nonfunctional perparation for further changes such as https://github.com/rust-lang/rust/pull/142950 and https://github.com/rust-lang/rust/pull/142975 .
2025-07-01moved testsKivooeo-0/+30
2025-06-30mbe: Extend metavariable expression testsTrevor Gross-62/+247
Add tests showing the current state to make it more clear when output gets updated later in refactoring.
2025-06-30mbe: Split metavariable usage tests off from syntax testsTrevor Gross-378/+253
`syntax-errors` currently contains both syntax error tests (which don't need expansion) and tests for incorrect instantiations of the `count` metavariable expression (which do need expansion). Split the expansion-dependent tests to a separate file and remove unneeded invocations from `syntax-errors`, to ensure we are catching these before expansion.
2025-06-30Remove let_chains featureCameron Steffen-2/+1
2025-06-30Unconditionally run `check_item_type` on all itemsOli Scherer-4/+4
2025-06-29Rollup merge of #143030 - Urgau:issue-143025, r=SparrowLiiGuillaume Gomez-1/+4
Fix suggestion spans inside macros for the `unused_must_use` lint This PR fixes the suggestion spans inside macros for the `unused_must_use` lint by trying to find the oldest ancestor span. Fixes https://github.com/rust-lang/rust/issues/143025
2025-06-27Rollup merge of #139858 - oli-obk:new-const-traits-syntax, r=fee1-deadMatthias Krüger-3/+2
New const traits syntax This PR only affects the AST and doesn't actually change anything semantically. All occurrences of `~const` outside of libcore have been replaced by `[const]`. Within libcore we have to wait for rustfmt to be bumped in the bootstrap compiler. This will happen "automatically" (when rustfmt is run) during the bootstrap bump, as rustfmt converts `~const` into `[const]`. After this we can remove the `~const` support from the parser Caveat discovered during impl: there is no legacy bare trait object recovery for `[const] Trait` as that snippet in type position goes down the slice /array parsing code and will error r? ``@fee1-dead`` cc ``@nikomatsakis`` ``@traviscross`` ``@compiler-errors``
2025-06-27Report infer ty errors during hir ty loweringOli Scherer-23/+35
This centralizes the placeholder type error reporting in one location, but it also exposes the granularity at which we convert things from hir to ty more. E.g. previously infer types in where bounds were errored together with the function signature, but now they are independent.
2025-06-26Rewrite `macro_rules!` parser to not use the MBE engine itselfJosh Triplett-1/+3
The `macro_rules!` parser was written to match the series of rules using the macros-by-example (MBE) engine and a hand-written equivalent of the left-hand side of a MBE macro. This was complex to read, difficult to extend, and produced confusing error messages. Because it was using the MBE engine, any parse failure would be reported as if some macro was being applied to the `macro_rules!` invocation itself; for instance, errors would talk about "macro invocation", "macro arguments", and "macro call", when they were actually about the macro *definition*. And in practice, the `macro_rules!` parser only used the MBE engine to extract the left-hand side and right-hand side of each rule as a token tree, and then parsed the rest using a separate parser. Rewrite it to parse the series of rules using a simple loop, instead. This makes it more extensible in the future, and improves error messages. For instance, omitting a semicolon between rules will result in "expected `;`" and "unexpected token", rather than the confusing "no rules expected this token in macro call". This work was greatly aided by pair programming with Vincenzo Palazzo and Eric Holk.
2025-06-26Change const trait bound syntax from ~const to [const]Oli Scherer-3/+2
2025-06-25Bless `tests/ui/macros/must-use-in-macro-55516.rs`Urgau-1/+4
2025-06-24Auto merge of #142979 - matthiaskrgr:rollup-szqah4e, r=matthiaskrgrbors-24/+77
Rollup of 9 pull requests Successful merges: - rust-lang/rust#142645 (Also emit suggestions for usages in the `non_upper_case_globals` lint) - rust-lang/rust#142657 (mbe: Clean up code with non-optional `NonterminalKind`) - rust-lang/rust#142799 (rustc_session: Add a structure for keeping both explicit and default sysroots) - rust-lang/rust#142805 (Emit a single error when importing a path with `_`) - rust-lang/rust#142882 (Lazy init diagnostics-only local_names in borrowck) - rust-lang/rust#142883 (Add impl_trait_in_bindings tests from rust-lang/rust#61773) - rust-lang/rust#142943 (Don't include current rustc version string in feature removed help) - rust-lang/rust#142965 ([RTE-497] Ignore `c-link-to-rust-va-list-fn` test on SGX platform) - rust-lang/rust#142972 (Add a missing mailmap entry) r? `@ghost` `@rustbot` modify labels: rollup
2025-06-24Rollup merge of #142943 - jieyouxu:no-rustc-version, r=compiler-errorsMatthias Krüger-4/+3
Don't include current rustc version string in feature removed help The version string is difficult to properly normalize out, and removing it isn't a huge deal (the user can query version info easily through `rustc --version` or `cargo --version`). The normalization options were all non-ideal (see https://github.com/rust-lang/rust/pull/142940#issuecomment-2998518450): - Per-test version string normalization is nasty to maintain, and we need to maintain `n` copies of it. See rust-lang/rust#142930 where the regex wasn't robust against different release channels. - Centralized compiletest normalization (with a directive opt-out) is also not ideal, because `cfg(version(..))` tests can't have those accidentally normalized out (and you'd have to remember to opt-out). r? `@workingjubilee` (discussed in rust-lang/rust#142940)
2025-06-24Rollup merge of #142657 - tgross35:nonoptional-fragment-specifiers-cleanup, ↵Matthias Krüger-20/+74
r=petrochenkov mbe: Clean up code with non-optional `NonterminalKind` Since [rust-lang/rust#128425], the fragment specifier is unconditionally required in all editions. This means `NonTerminalKind` no longer needs to be optional, as we can reject this code during the expansion of `macro_rules!` rather than handling it throughout the code. Do this cleanup here. [rust-lang/rust#128425]: https://github.com/rust-lang/rust/pull/128425
2025-06-24Don't include current rustc version string in feature removed helpJieyou Xu-4/+3
The version string is difficult to properly normalize out, and removing it isn't a huge deal (the user can query version info easily through `rustc --version` or `cargo --version`). The normalization options were all non-ideal: - Per-test version string normalization is nasty to maintain, and we need to maintain `n` copies of it. - Centralized compiletest normalization (with a directive opt-out) is also not ideal, because `cfg(version(..))` tests can't have those accidentally normalized out (and you'd have to remember to opt-out).
2025-06-24Rollup merge of #142704 - tgross35:remove-concat_idents, r=fee1-deadGuillaume Gomez-53/+63
Remove the deprecated unstable `concat_idents!` macro In [rust-lang/rust#137653], the lang and libs-API teams did a joint FCP to deprecate and eventually remove the long-unstable `concat_idents!` macro. The deprecation is landing in 1.88, so do the removal here (target version 1.90). This macro has been superseded by the more recent `${concat(...)}` metavariable expression language feature, which avoids some of the limitations of `concat_idents!`. The metavar expression is unstably available under the [`macro_metavar_expr_concat`] feature. History is mildly interesting here: `concat_idents!` goes back to 2011 when it was introduced with 513276e595f8 ("Add #concat_idents[] and #ident_to_str[]"). The syntax looks a bit different but it still works about the same: let asdf_fdsa = "<.<"; assert(#concat_idents[asd,f_f,dsa] == "<.<"); assert(#ident_to_str[use_mention_distinction] == "use_mention_distinction"); (That test existed from introduction until its removal here.) Closes: https://github.com/rust-lang/rust/issues/29599 [rust-lang/rust#137653]: https://github.com/rust-lang/rust/pull/137653 [`macro_metavar_expr_concat`]: https://github.com/rust-lang/rust/issues/124225
2025-06-24Remove the deprecated `concat_idents!` macroTrevor Gross-53/+32
In [137653], the lang and libs-API teams did a joint FCP to deprecate and eventually remove the long-unstable `concat_idents!` macro. The deprecation is landing in 1.88, so do the removal here (target version 1.90). This macro has been superseded by the more recent `${concat(...)}` metavariable expression language feature, which avoids some of the limitations of `concat_idents!`. The metavar expression is unstably available under the [`macro_metavar_expr_concat`] feature. History is mildly interesting here: `concat_idents!` goes back to 2011 when it was introduced with 513276e595f8 ("Add #concat_idents[] and about the same: let asdf_fdsa = "<.<"; assert(#concat_idents[asd,f_f,dsa] == "<.<"); assert(#ident_to_str[use_mention_distinction] == "use_mention_distinction"); (That test existed from introduction until its removal here.) Closes: https://www.github.com/rust-lang/rust/issues/29599 [137653]: https://www.github.com/rust-lang/rust/pull/137653 [`macro_metavar_expr_concat`]: https://www.github.com/rust-lang/rust/issues/124225
2025-06-24Move some `issues-*` tests to better homesTrevor Gross-0/+31
These tests were updated in the previous commit; while they are being cleaned up, move them to a non-issue directory.
2025-06-24mbe: Clean up code with non-optional `NonterminalKind`Trevor Gross-20/+74
Since [1], the fragment specifier is unconditionally required in all editions. This means `NonTerminalKind` no longer needs to be optional, as we can reject this code during the expansion of `macro_rules!` rather than handling it throughout the code. Do this cleanup here. [1]: https://github.com/rust-lang/rust/pull/128425
2025-06-24Auto merge of #142930 - cuviper:normalize-beta-versions, r=workingjubileebors-1/+1
Account for beta revisions when normalizing versions Several UI tests have a `normalize-stderr` for "you are using x.y.z" rustc versions, and that regex is flexible enough for suffixes like "-nightly" and "-dev", but not for "-beta.N". We can just add '.' to that trailing pattern to include this.
2025-06-23Account for beta revisions when normalizing versionsJosh Stone-1/+1
Several UI tests have a `normalize-stderr` for "you are using x.y.z" rustc versions, and that regex is flexible enough for suffixes like "-nightly" and "-dev", but not for "-beta.N". We can just add '.' to that trailing pattern to include this.
2025-06-23Rollup merge of #142873 - Urgau:issue-139830, r=BoxyUwUJubilee-0/+32
Don't suggest changing a method inside a expansion Fixes https://github.com/rust-lang/rust/issues/139830 r? compiler
2025-06-23mbe: Restructure `macro_metavar_expr` testsTrevor Gross-55/+57
These tests have expanded beyond the RFC, so rename the directory `rfc-3086-metavar-expr` to `metavar-expressions`. `concat` (which wasn't part of the RFC) now fits in this group, so merge its tests into the `metavar-expressions` directory. Additionally rename some related `issue-*` tests.
2025-06-22Don't suggest changing a method inside a expansionUrgau-0/+32
2025-06-21Rollup merge of #142698 - tgross35:concat-byte-cstr-diag, r=petrochenkovJana Dönszelmann-29/+95
Improve diagnostics for `concat_bytes!` with C string literals Use the same error as other invalid types for `concat_bytes!`, rather than using `ConcatCStrLit` from `concat!`. Also add more information with a note about why this doesn't work, and a suggestion to use a null-terminated byte string instead.
2025-06-19Auto merge of #140748 - m-ou-se:super-format-args3, r=jdonszelmannbors-10/+0
Allow storing `format_args!()` in variable Fixes https://github.com/rust-lang/rust/issues/92698 Tracking issue for super let: https://github.com/rust-lang/rust/issues/139076 Tracking issue for format_args: https://github.com/rust-lang/rust/issues/99012 This change allows: ```rust let name = "world"; let f = format_args!("hello {name}!"); // New: Store format_args!() for later! println!("{f}"); ``` This will need an FCP. This implementation makes use of `super let`, which is unstable and might not exist in the future in its current form. However, it is entirely reasonable to assume future Rust will always have _a_ way of expressing temporary lifetimes like this, since the (stable) `pin!()` macro needs this too. (This was also the motivation for merging https://github.com/rust-lang/rust/pull/139114.) (This is a second version of https://github.com/rust-lang/rust/pull/139135)
2025-06-19Improve diagnostics for `concat_bytes!` with C string literalsTrevor Gross-33/+45
Use the same error as other invalid types for `concat_bytes!`, rather than using `ConcatCStrLit` from `concat!`. Also add more information with a note about why this doesn't work, and a suggestion to use a null-terminated byte string instead.
2025-06-18Add a test for `concat_bytes!` with C stringsTrevor Gross-29/+83
Also ensure the suggestions are checked, since this will be updated.
2025-06-18Bless/update tests.Mara Bos-10/+0
2025-06-17make error codes reflect reality betterJana Dönszelmann-1/+1
2025-06-17fix bugs in inline/force_inline and diagnostics of all attr parsersJana Dönszelmann-1/+1
2025-06-15Rollup merge of #142543 - Urgau:span-borrowck-semicolon, r=fmeaseLeón Orell Valerian Liehr-0/+8
Suggest adding semicolon in user code rather than macro impl details This PR tries to find the right span (by peeling expansion) so that the suggestion for adding a semicolon is suggested in user code rather than in the expanded code (in the example a macro impl). Fixes rust-lang/rust#139049 r? `@fmease`
2025-06-15Suggest adding semicolon in user code rather than macro impl detailsUrgau-0/+8