At the time of writing, built-in attr include is not permitted to expand into a pattern context (its expander doesn't override make_pat):
fn main() {
match () { include!("/dev/null") => {} } //~ ERROR non-pattern macro in pattern position: include
}For nothing but "completeness" (item, expr, pat trifecta) and for consistency with include_str and include_bytes I propose that we permit them in this position.
include's expander would then parse a PatternNoTopGuard (as defined in RFC 3637), i.e., top-level or-patterns are permitted (and guards aren't – ignoring guard_patterns for now). Meaning let include!("file"); with file containing false | true would be permitted despite let false | true; not being valid (requiring parentheses) since the macro expansion would act as invisible delimiters. Leading vert / bar would be permitted as well, naturally.
Lastly, don't strip shebang or frontmatter (meaning they'll lead to an error since the pattern parser won't accept it). Edit: Well, it depends on the outcome of #146377.
At the time of writing, built-in attr
includeis not permitted to expand into a pattern context (its expander doesn't overridemake_pat):For nothing but "completeness" (item, expr, pat trifecta) and for consistency with
include_strandinclude_bytesI propose that we permit them in this position.include's expander would then parse a PatternNoTopGuard (as defined in RFC 3637), i.e., top-level or-patterns are permitted (and guards aren't – ignoringguard_patternsfor now). Meaninglet include!("file");withfilecontainingfalse | truewould be permitted despitelet false | true;not being valid (requiring parentheses) since the macro expansion would act as invisible delimiters. Leading vert / bar would be permitted as well, naturally.Lastly, don't strip shebang or frontmatter (meaning they'll lead to an error since the pattern parser won't accept it). Edit: Well, it depends on the outcome of #146377.