about summary refs log tree commit diff
path: root/src/test/ui/macros
AgeCommit message (Collapse)AuthorLines
2021-10-03Practice diagnostic message conventionHirochika Matsumoto-1/+1
2021-10-02resolve: Cache module loading for all foreign modulesVadim Petrochenkov-0/+23
It was previously cached for modules loaded from `fn get_module`, but not for modules loaded from `fn build_reduced_graph_for_external_crate_res`. This also makes all foreign modules use their real parent, span and expansion instead of possibly a parent/span/expansion of their reexport. An ICE happening on attempt to decode expansions for foreign enums and traits is avoided. Also local enums and traits are now added to the module map.
2021-09-28Improve help for recursion limit errorsRoss MacArthur-3/+3
2021-09-24Give better error for `macro_rules! name!`Nixon Enraght-Moony-0/+24
2021-09-19Rollup merge of #88996 - Aaron1011:trailing-macro-semi, r=petrochenkovYuki Okushi-0/+34
Fix linting when trailing macro expands to a trailing semi When a macro is used in the trailing expression position of a block (e.g. `fn foo() { my_macro!() }`), we currently parse it as an expression, rather than a statement. As a result, we ended up using the `NodeId` of the containing statement as our `lint_node_id`, even though we don't normally do this for macro calls. If such a macro expands to an expression with a `#[cfg]` attribute, then the trailing statement can get removed entirely. This lead to an ICE, since we were usng the `NodeId` of the expression to emit a lint. Ths commit makes us skip updating `lint_node_id` when handling a macro in trailing expression position. This will cause us to lint at the closest parent of the macro call.
2021-09-15Fix linting when trailing macro expands to a trailing semiAaron Hill-0/+34
When a macro is used in the trailing expression position of a block (e.g. `fn foo() { my_macro!() }`), we currently parse it as an expression, rather than a statement. As a result, we ended up using the `NodeId` of the containing statement as our `lint_node_id`, even though we don't normally do this for macro calls. If such a macro expands to an expression with a `#[cfg]` attribute, then the trailing statement can get removed entirely. This lead to an ICE, since we were usng the `NodeId` of the expression to emit a lint. Ths commit makes us skip updating `lint_node_id` when handling a macro in trailing expression position. This will cause us to lint at the closest parent of the macro call.
2021-09-15Move some tests to more reasonable directoriesCaio-0/+37
2021-09-02expand: Treat more macro calls as statement macro callsVadim Petrochenkov-0/+25
2021-08-28Update testsinquisitivecrystal-1/+2
2021-08-23Improve wording of macro-not-found-but-name-exists note.Mara Bos-2/+2
2021-08-23Show what things are, but also what they are not.Mara Bos-7/+7
2021-08-23Clarify what attribute and derive macros look like.Mara Bos-3/+3
2021-08-23Say what things are, instead of what they are not.Mara Bos-28/+46
2021-08-23Silence confusing 'unused import' warnings.Mara Bos-39/+18
2021-08-23Update tests.Mara Bos-1/+6
2021-08-23Add tests for macro-not-found diagnostics.Mara Bos-0/+183
2021-08-22Rollup merge of #88229 - m-ou-se:macro-suggest-right-kind, r=estebankGuillaume Gomez-0/+48
Suggest importing the right kind of macro. Fixes #88228. r? `@estebank`
2021-08-22Suggest importing the right kind of macro.Mara Bos-0/+48
2021-08-17Add needs-asm-support to more testsJosh Stone-1/+1
These were found as test failures on s390x for RHEL and Fedora.
2021-08-15Fix ui tests for llvm_asm! deprecationAmanieu d'Antras-29/+30
2021-08-12Rollup merge of #87885 - m-ou-se:edition-guide-links, r=rylevGuillaume Gomez-4/+4
Link to edition guide instead of issues for 2021 lints. This changes the 2021 lints to not link to github issues, but to the edition guide instead. Fixes #86996
2021-08-11Modify structured suggestion outputEsteban Küber-18/+18
* On suggestions that include deletions, use a diff inspired output format * When suggesting addition, use `+` as underline * Color highlight modified span
2021-08-09Link to edition guide instead of issues for 2021 lints.Mara Bos-4/+4
2021-08-04Remove trailing whitespace from error messagesFabian Wolff-3/+3
2021-08-02Rollup merge of #86183 - inquisitivecrystal:env-nul, r=m-ou-seYuki Okushi-0/+10
Change environment variable getters to error recoverably This PR changes the standard library environment variable getter functions to error recoverably (i.e. not panic) when given an invalid value. On some platforms, it is invalid for environment variable names to contain `'\0'` or `'='`, or for their values to contain `'\0'`. Currently, the standard library panics when manipulating environment variables with names or values that violate these invariants. However, this behavior doesn't make a lot of sense, at least in the case of getters. If the environment variable is missing, the standard library just returns an error value, rather than panicking. It doesn't make sense to treat the case where the variable is invalid any differently from that. See the [internals thread](https://internals.rust-lang.org/t/why-should-std-var-panic/14847) for discussion. Thus, this PR changes the functions to error recoverably in this case as well. If desired, I could change the functions that manipulate environment variables in other ways as well. I didn't do that here because it wasn't entirely clear what to change them to. Should they error silently or do something else? If someone tells me how to change them, I'm happy to implement the changes. This fixes #86082, an ICE that arises from the current behavior. It also adds a regression test to make sure the ICE does not occur again in the future. `@rustbot` label +T-libs r? `@joshtriplett`
2021-07-31Rollup merge of #87385 - Aaron1011:final-enable-semi, r=petrochenkovYuki Okushi-3/+59
Make `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` warn by default This PR makes the `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` lint warn by default. To avoid showing a large number of un-actionable warnings to users, we only enable the lint for macros defined in the same crate. This ensures that users will be able to fix the warning by simply removing a semicolon. In the future, I'd like to enable this lint unconditionally, and eventually make it into a hard error in a future edition. This PR is a step towards that goal.
2021-07-27Update stderrAaron Hill-1/+11
2021-07-27Prohibit `#[default]` in invalid placesJacob Pratt-26/+94
2021-07-27Permit deriving default on enums with `#[default]`Jacob Pratt-20/+156
2021-07-27Make `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` warn by defaultAaron Hill-3/+49
2021-07-19Various diagnostics clean ups/tweaksEsteban Küber-3/+5
* Always point at macros, including derive macros * Point at non-local items that introduce a trait requirement * On private associated item, point at definition
2021-07-16fix ui testsJane Lusby-1/+1
2021-07-08Move [debug_]assert_matches to mod {core, std}::assert.Mara Bos-0/+2
2021-07-06Add s to non_fmt_panicRyan Levick-7/+12
2021-07-06Change or_patterns_back_compat lint to rust_2021_incompatible_or_patternsRyan Levick-4/+4
2021-07-05Add test to prevent regressionAris Merchant-0/+10
2021-06-30Move some UI tests to more suitable subdirsYuki Okushi-0/+14
2021-06-25Fix new broken testsRyan Levick-12/+12
2021-06-24Don't lint :pat when re-parsing a macro from another crate.Mara Bos-5/+23
2021-06-22Rollup merge of #86192 - hi-rustin:rustin-patch-lint, r=nikomatsakisYuki Okushi-12/+41
Make OR_PATTERNS_BACK_COMPAT be a 2021 future-incompatible lint close https://github.com/rust-lang/rust/issues/84869 r? `@nikomatsakis`
2021-06-21Do not set depth to 0 in fully_expand_fragmentDeadbeef-0/+30
2021-06-10Make OR_PATTERNS_BACK_COMPAT be a 2021 future-incompatible linthi-rustin-12/+41
2021-06-07Include macro name in 'local ambiguity' errorAaron Hill-2/+2
Currently, we only point at the span of the macro argument. When the macro call is itself generated by another macro, this can make it difficult or impossible to determine which macro is responsible for producing the error.
2021-05-29Use correct edition when parsing `:pat` matchersAaron Hill-0/+32
As described in issue #85708, we currently do not properly decode `SyntaxContext::root()` and `ExpnId::root()` from foreign crates. As a result, when we decode a span from a foreign crate with `SyntaxContext::root()`, we end up up considering it to have the edition of the *current* crate, instead of the foreign crate where it was originally created. A full fix for this issue will be a fairly significant undertaking. Fortunately, it's possible to implement a partial fix, which gives us the correct edition-dependent behavior for `:pat` matchers when the macro is loaded from another crate. Since we have the edition of the macro's defining crate available, we can 'recover' from seeing a `SyntaxContext::root()` and use the edition of the macro's defining crate. Any solution to issue #85708 must reproduce the behavior of this targeted fix - properly preserving a foreign `SyntaxContext::root()` means (among other things) preserving its edition, which by definition is the edition of the foreign crate itself. Therefore, this fix moves us closer to the correct overall solution, and does not expose any new incorrect behavior to macros.
2021-05-15Remove some unncessary spaces from pretty-printed tokenstream outputAaron Hill-7/+7
In addition to making the output look nicer for all crates, this also aligns the pretty-printing output with what the `rental` crate expects. This will allow us to eventually disable a backwards-compat hack in a follow-up PR.
2021-05-13Add support for const operands and options to global_asm!Amanieu d'Antras-5/+5
On x86, the default syntax is also switched to Intel to match asm!
2021-05-12Show macro name in 'this error originates in macro' messageAaron Hill-54/+54
When there are multiple macros in use, it can be difficult to tell which one was responsible for producing an error.
2021-05-12Update stderrAaron Hill-23/+8
The spans generated by `quote!` are (intentionally) no longer all the same, so I removed that check entirely.
2021-04-28Auto merge of #83386 - mark-i-m:stabilize-pat2015, r=nikomatsakisbors-43/+41
Stabilize `:pat_param` and remove `:pat2021` Blocked on #83384 cc `@rust-lang/lang` #79278 If I understand `@nikomatsakis` in https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/or.20patterns/near/231133873, another FCP is not needed. r? `@nikomatsakis`
2021-04-27remove pat2021mark-27/+25
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-03-01 01:59:20 +0000