rust/tests/ui/lint/issue-49588-non-shorthand-field-patterns-in-pattern-macro.rs

// run-pass
#![allow(unused_variables)]
#![deny(non_shorthand_field_patterns)]

pub struct Value<A> { pub value: A }

#[macro_export]
macro_rules! pat {
    ($a:pat) => {
        Value { value: $a }
    };
}

fn main() {
    let pat!(value) = Value { value: () };
}
Add `// run-pass` annotations to all the tests under `ui/run-pass/`. (I may have accidentally added it to some auxilliary crates as well; my emacs-macro-based methodology was pretty crude.) 2018-08-30 07:18:55 -05:00			`// run-pass`
Add `#![allow(..)]` as necessary to get re-migrated run-pass tests compiling with clean stderr again. Most were added mechanically. 2018-09-25 16:51:35 -05:00			`#![allow(unused_variables)]`
in which the non-shorthand patterns lint keeps its own counsel in macros In issue #49588, Michael Lamparski pointed out a scenario in which the non-shorthand-field-patterns lint could be triggered by a macro-expanded pattern, in a way which was direly unwieldy for the macro author to guard against and unreasonable to expect the macro user to take into account. We can avoid this by not linting patterns that come from macro-expansions. Although this entails accepting "false negatives" where the lint could genuinely improve macro-templated code, avoiding the reported "true-but-super-annoying positive" may be worth the trade? (Some precedent for these relative priorities exists as no. 47775 (5985b0b0).) Resolves #49588. 2018-04-02 21:34:52 -05:00			`#![deny(non_shorthand_field_patterns)]`

			`pub struct Value<A> { pub value: A }`

			`#[macro_export]`
			`macro_rules! pat {`
			`($a:pat) => {`
			`Value { value: $a }`
			`};`
			`}`

			`fn main() {`
			`let pat!(value) = Value { value: () };`
			`}`