grouped pattern is never identified

[lucasly-ba]

code

pub fn a() {

   let int_reference = &3;
   match int_reference {
       &(0..=5) => (), /// will give us a range pattern
       _ => (),
   };

   let x = 0;
   match x {
        (3) => {}, /// will give us a literal pattern
        ((3)) => {}, /// likewise
        _ => {},
    };

}

[powerboat9]

What do you mean by "never identified"? No warning for unnecessary parenthesis?

[Harishankar14]

@lucasly-ba This is weird, i kind of simulated the same, it kind of did preserve the parenthesis

match x { (3) => { }

AST is correctly identifying the GroupedPattern node (at least for the pretty printer)

[Harishankar14]

What do you mean by "never identified"? No warning for unnecessary parenthesis?

@powerboat9 I guess the "identification" he meant is nothing but a creating a specific node in the tree that represents exactly what the user wrote.

Something like : You write (3).

Correct Behavior: the compiler creates a GroupedPattern node wrapping a LiteralPattern. It "remembers" you used brackets.

The Bug is that the compiler sees (3), ignores the brackets, and just creates a LiteralPattern (the number 3). It "forgets" you used brackets

But weird i haven't faced the issue

[Harishankar14]

I kind of digged down a bit, and found that the Parser (AST): Actually does identify them, but the Lowering (HIR): Does not identify them (it throws them away).I think the issue title might be slightly misleading,the grouped pattern is identified initially by the parser (as seen in the AST), but it is lost during the transition to HIR. So it's not 'never identified,' but rather 'discarded during lowering.'

[powerboat9]

Yep, discarding of grouped patterns during lowering is intended (see #1783, blast from the past lol). Does it break anything?

[Harishankar14]

ohh damn, i just gave it a glance, havn't really gone through the whole, wlll let you know !!

[Harishankar14]

@powerboat9 looks fine to me.