about summary refs log tree commit diff
path: root/src/test/ui/macros
AgeCommit message (Collapse)AuthorLines
2022-03-30Clarify comments about doc comments in macros.Nicholas Nethercote-2/+3
2022-03-28Ignore doc comments in a declarative macro matcher.Nicholas Nethercote-0/+13
Fixes #95267. Reverts to the old behaviour before #95159 introduced a regression.
2022-03-16Rollup merge of #94868 - dtolnay:noblock, r=Dylan-DPCDylan DPC-1/+1
Format core and std macro rules, removing needless surrounding blocks Many of the asserting and printing macros in `core` and `std` are written with prehistoric-looking formatting, like this: https://github.com/rust-lang/rust/blob/335ffbfa547df94ac236f5c56130cecf99c8d82b/library/std/src/macros.rs#L96-L101 In modern Rust style this would conventionally be written as follows instead, always using braces and a trailing semicolon on the macro arms: https://github.com/rust-lang/rust/blob/af53809c874e0afb7be966df4d3cfcaa05277c53/library/std/src/macros.rs#L98-L105 Getting rid of the unneeded braces inside the expansion reduces extraneous indentation in macro-expanded code. For example: ```rust println!("repro {}", true); ``` ```rust // before: { ::std::io::_print( ::core::fmt::Arguments::new_v1( &["repro ", "\n"], &[::core::fmt::ArgumentV1::new_display(&true)], ), ); }; ``` ```rust // after: ::std::io::_print( ::core::fmt::Arguments::new_v1( &["repro ", "\n"], &[::core::fmt::ArgumentV1::new_display(&true)], ), ); ```
2022-03-11Format core and std macro rules, removing needless surrounding blocksDavid Tolnay-1/+1
2022-03-11Implement macro meta-variable expressionCaio-83/+689
2022-03-10Rollup merge of #94368 - c410-f3r:metaaaaaaaaaaaaaaaaaaaaaaaaaaa, r=petrochenkovDylan DPC-0/+578
[1/2] Implement macro meta-variable expressions See https://github.com/rust-lang/rust/pull/93545#issuecomment-1050963295 The logic behind `length`, `index` and `count` was removed but the parsing code is still present, i.e., everything is simply ignored like `ignored`. r? ``@petrochenkov``
2022-03-09Permit `#[deprecated]` in stdlibJacob Pratt-2/+2
2022-03-09Implement macro meta-variable expressionsCaio-0/+578
2022-03-04Change `rustc_deprecated` to use `note`Jacob Pratt-6/+6
This keeps `reason` around for the time being. This is necessary to avoid breakage during the bootstrap process. This change, as a whole, brings `#[rustc_deprecated]` more in line with `#[deprecated]`.
2022-03-03Cleanup feature gates.Camille GILLOT-14/+13
2022-02-07Auto merge of #93179 - Urgau:unreachable-2021, r=m-ou-se,oli-obkbors-0/+70
Fix invalid special casing of the unreachable! macro This pull-request fix an invalid special casing of the `unreachable!` macro in the same way the `panic!` macro was solved, by adding two new internal only macros `unreachable_2015` and `unreachable_2021` edition dependent and turn `unreachable!` into a built-in macro that do dispatching. This logic is stolen from the `panic!` macro. ~~This pull-request also adds an internal feature `format_args_capture_non_literal` that allows capturing arguments from formatted string that expanded from macros. The original RFC #2795 mentioned this as a future possibility. This feature is [required](https://github.com/rust-lang/rust/issues/92137#issuecomment-1018630522) because of concatenation that needs to be done inside the macro:~~ ```rust $crate::concat!("internal error: entered unreachable code: ", $fmt) ``` **In summary** the new behavior for the `unreachable!` macro with this pr is: Edition 2021: ```rust let x = 5; unreachable!("x is {x}"); ``` ``` internal error: entered unreachable code: x is 5 ``` Edition <= 2018: ```rust let x = 5; unreachable!("x is {x}"); ``` ``` internal error: entered unreachable code: x is {x} ``` Also note that the change in this PR are **insta-stable** and **breaking changes** but this a considered as being a [bug](https://github.com/rust-lang/rust/issues/92137#issuecomment-998441613). If someone could start a perf run and then a crater run this would be appreciated. Fixes https://github.com/rust-lang/rust/issues/92137
2022-02-03Bless all pretty printer tests and ui testsDavid Tolnay-10/+10
2022-01-31Take in account the unreachable! macro in the non_fmt_panic lintLoïc BRANSTETT-0/+31
2022-01-31Fix invalid special casing of the unreachable! macroLoïc BRANSTETT-0/+39
2022-01-18Rollup merge of #91150 - dtolnay:qpath, r=davidtwcoMatthias Krüger-1/+13
Let qpath contain NtTy: `<$:ty as $:ty>::…` Example: ```rust macro_rules! m { (<$type:ty as $trait:ty>::$name:ident) => { <$type as $trait>::$name }; } fn main() { let _: m!(<str as ToOwned>::Owned); } ``` Previous behavior: ```console error: expected identifier, found `ToOwned` --> src/main.rs:3:19 | 3 | <$type as $trait>::$name | ^^^^^^ expected identifier ... 8 | let _: m!(<str as ToOwned>::Owned); | --------------------------- | | | this macro call doesn't expand to a type | in this macro invocation ``` The <code>expected identifier, found \`ToOwned\`</code> error is particularly silly. I think it should be fine to accept this code as long as $trait is of the form `TyKind::Path(None, path)`; if it is any other kind of `NtTy`, we'll keep the same behavior as before.
2022-01-17Auto merge of #92816 - tmiasko:rm-llvm-asm, r=Amanieubors-36/+34
Remove deprecated LLVM-style inline assembly The `llvm_asm!` was deprecated back in #87590 1.56.0, with intention to remove it once `asm!` was stabilized, which already happened in #91728 1.59.0. Now it is time to remove `llvm_asm!` to avoid continued maintenance cost. Closes #70173. Closes #92794. Closes #87612. Closes #82065. cc `@rust-lang/wg-inline-asm` r? `@Amanieu`
2022-01-16Rollup merge of #92487 - dtolnay:traitalias, r=matthewjasperMatthias Krüger-1/+1
Fix unclosed boxes in pretty printing of TraitAlias This was causing trait aliases to not even render at all in stringified / pretty printed output. ```rust macro_rules! repro { ($item:item) => { stringify!($item) }; } fn main() { println!("{:?}", repro!(pub trait Trait<T> = Sized where T: 'a;)); } ``` Before:&ensp;`""` After:&ensp;`"pub trait Trait<T> = Sized where T: 'a;"` The fix is copied from how `head`/`end` for `ItemKind::Use`, `ItemKind::ExternCrate`, and `ItemKind::Mod` are all done in the pretty printer: https://github.com/rust-lang/rust/blob/dd3ac41495e85a9b7b5cb3186379d02ce17e51fe/compiler/rustc_ast_pretty/src/pprust/state.rs#L1178-L1184
2022-01-12Remove ui tests for LLVM-style inline assemblyTomasz Miąsko-36/+34
2022-01-06Rollup merge of #92417 - dtolnay:printimpl, r=jackh726Matthias Krüger-1/+7
Fix spacing and ordering of words in pretty printed Impl Follow-up to #92238 fixing one of the FIXMEs. ```rust macro_rules! repro { ($item:item) => { stringify!($item) }; } fn main() { println!("{}", repro!(impl<T> Struct<T> {})); println!("{}", repro!(impl<T> const Trait for T {})); } ``` Before:&ensp;`impl <T> Struct<T> {}` After:&ensp;`impl<T> Struct<T> {}` Before:&ensp;`impl const <T> Trait for T {}` :crying_cat_face: After:&ensp;`impl<T> const Trait for T {}`
2022-01-03Rollup merge of #92418 - dtolnay:emptystructpat, r=michaelwoeristerMatthias Krüger-4/+4
Fix spacing in pretty printed PatKind::Struct with no fields Follow-up to #92238 fixing one of the FIXMEs. ```rust macro_rules! repro { ($pat:pat) => { stringify!($pat) }; } fn main() { println!("{}", repro!(Struct {})); } ``` Before:&ensp;<code>Struct&nbsp;{&nbsp;&nbsp;}</code> After:&ensp;<code>Struct&nbsp;{}</code>
2022-01-02Auto merge of #92066 - Smittyvb:concat_bytes-repeat, r=nagisabors-2/+70
Support [x; n] expressions in concat_bytes! Currently trying to use `concat_bytes!` with a repeating array value like `[42; 5]` results in an error: ``` error: expected a byte literal --> src/main.rs:3:27 | 3 | let x = concat_bytes!([3; 4]); | ^^^^^^ | = note: only byte literals (like `b"foo"`, `b's'`, and `[3, 4, 5]`) can be passed to `concat_bytes!()` ``` This makes it so repeating array syntax can be used the same way normal arrays can be. The RFC doesn't explicitly mention repeat expressions, but it seems reasonable to allow them as well, since normal arrays are allowed. It is possible to make the compiler get stuck compiling forever with `concat_bytes!([3; 999999999])`, but I don't think that's much of an issue since you can do that already with `const X: [u8; 999999999] = [3; 999999999];`. Contributes to #87555.
2022-01-01Fix unclosed boxes in pretty printing of TraitAliasDavid Tolnay-1/+1
2022-01-01Rollup merge of #92460 - dwrensha:fix-92267, r=petrochenkovMatthias Krüger-0/+19
[rustc_builtin_macros] add indices to format_foreign::printf::Substitution::Escape Fixes #92267. The problem was that the escape string "%%" does not need to appear at the very beginning of the format string, but the iterator implementation assumed that it did. The solution follows the pattern used by `format_foregin::shell::Subtitution::Escape`: https://github.com/rust-lang/rust/blob/8ed935e92dfb09ae388344b12284bf5110cf9265/compiler/rustc_builtin_macros/src/format_foreign.rs#L629
2022-01-01Rollup merge of #92420 - dtolnay:patrange, r=Mark-SimulacrumMatthias Krüger-4/+4
Fix whitespace in pretty printed PatKind::Range Follow-up to #92238 fixing one of the FIXMEs. ```rust macro_rules! repro { ($pat:pat) => { stringify!($pat) }; } fn main() { println!("{}", repro!(0..=1)); } ``` Before:&ensp;`0 ..=1` After:&ensp;`0..=1` The canonical spacing applied by rustfmt has no space after the lower expr. Rustc's parser diagnostics also do not put a space there: https://github.com/rust-lang/rust/blob/df96fb166f59431e3de443835e50d5b8a7a4adb0/compiler/rustc_parse/src/parser/pat.rs#L754
2022-01-01Rollup merge of #92412 - dtolnay:tryspace, r=Mark-SimulacrumMatthias Krüger-1/+1
Fix double space in pretty printed TryBlock Follow-up to #92238 fixing one of the FIXMEs. ```rust macro_rules! repro { ($expr:expr) => { stringify!($expr) }; } fn main() { println!("{}", repro!(try {})); } ``` Before:&ensp;<code>try&nbsp;&nbsp;{}</code> After:&ensp;<code>try&nbsp;{}</code> The `head` helper already appends a space: https://github.com/rust-lang/rust/blob/2b67c30bfece00357d5fc09d99b49f21066f04ba/compiler/rustc_ast_pretty/src/pprust/state.rs#L654-L664 so doing `head` followed by `space` resulted in a double space: https://github.com/rust-lang/rust/blob/2b67c30bfece00357d5fc09d99b49f21066f04ba/compiler/rustc_ast_pretty/src/pprust/state.rs#L2241-L2242
2021-12-31[rustc_builtin_macros] add indices to ↵David Renshaw-0/+19
format_foreign::printf::Substitution::Escape
2021-12-29Fix whitespace in pretty printed PatKind::RangeDavid Tolnay-4/+4
2021-12-29Fix spacing in pretty printed PatKind::Struct with no fieldsDavid Tolnay-4/+4
2021-12-29Fix spacing of pretty printed const item without bodyDavid Tolnay-3/+3
2021-12-29Fix spacing and ordering of words in pretty printed ImplDavid Tolnay-2/+2
2021-12-29Add a pretty printer test of impl<T> const TraitDavid Tolnay-0/+6
2021-12-29Fix double space in pretty printed TryBlockDavid Tolnay-1/+1
2021-12-29Rollup merge of #92372 - dtolnay:fntype, r=jackh726Matthias Krüger-1/+1
Print space after formal generic params in fn type Follow-up to #92238 fixing one of the FIXMEs. ```rust macro_rules! repro { ($ty:ty) => { stringify!($ty) }; } fn main() { println!("{}", repro!(for<'a> fn(&'a u8))); } ``` Before:&ensp;`for<'a>fn(&'a u8)` After:&ensp;`for<'a> fn(&'a u8)` The pretty printer's `print_formal_generic_params` already prints formal generic params correctly with a space, we just need to call it when printing BareFn types instead of reimplementing the printing incorrectly without a space. https://github.com/rust-lang/rust/blob/83b15bfe1c15f325bc186ebfe3691b729ed59f2b/compiler/rustc_ast_pretty/src/pprust/state.rs#L1394-L1400
2021-12-28Print space after formal generic params in fn typeDavid Tolnay-1/+1
2021-12-28Remove pretty printer space inside block with only outer attrsDavid Tolnay-1/+1
2021-12-27Clarify that repeat count must be positiveSmitty-8/+8
2021-12-23Fix tidy line length lint in stringify testsDavid Tolnay-4/+16
2021-12-23Format with rust-lang/rust's rustfmt settingsDavid Tolnay-41/+14
2021-12-23Add a test suite for stringify macroDavid Tolnay-0/+894
2021-12-18Support [x; n] expressions in concat_bytes!Smitty-2/+70
Contributes to #87555.
2021-12-12Address review feedbackAmanieu d'Antras-37/+36
2021-12-12Stabilize asm! and global_asm!Amanieu d'Antras-13/+16
They are also removed from the prelude as per the decision in https://github.com/rust-lang/rust/issues/87228. stdarch and compiler-builtins are updated to work with the new, stable asm! and global_asm! macros.
2021-12-09Add needs-unwind to tests that depend on panickingDavid Koloski-0/+1
This directive isn't automatically set by compiletest or x.py, but can be turned on manually for targets that require it.
2021-12-06Implement concat_bytes!Smitty-0/+180
The tracking issue for this is #87555.
2021-12-05Rollup merge of #91437 - dtolnay:emptybrace, r=nagisaMatthias Krüger-2/+2
Pretty print empty blocks as {} **Example:** ```rust macro_rules! p { ($e:expr) => { println!("{}", stringify!($e)); }; ($i:item) => { println!("{}", stringify!($i)); }; } fn main() { p!(if true {}); p!(struct S {}); } ``` **Before:** ```console if true { } struct S { } ``` **After:** ```console if true {} struct S {} ``` This affects [`dbg!`](https://doc.rust-lang.org/std/macro.dbg.html), as well as ecosystem uses of stringify such as in [`anyhow::ensure!`](https://docs.rs/anyhow/1/anyhow/macro.ensure.html). Printing a `{ }` in today's heavily rustfmt'd world comes out looking jarring/sloppy.
2021-12-01Pretty print empty blocks as {}David Tolnay-2/+2
2021-11-29Bless duplicate testDylan MacKenzie-3/+9
2021-11-29Bless tests with new suggestionDylan MacKenzie-3/+9
2021-11-25Add test of NtTy in a qpathDavid Tolnay-2/+7
Currently fails: error: expected identifier, found `ToOwned` --> src/test/ui/macros/macro-interpolation.rs:23:19 | LL | <$type as $trait>::$name | ^^^^^^ expected identifier ... LL | let _: qpath!(ty, <str as ToOwned>::Owned); | ----------------------------------- | | | this macro call doesn't expand to a type | in this macro invocation
2021-11-25Add test of qpath interpolationsDavid Tolnay-1/+8