nr2.0: Update IdentifierPattern's subpattern name resolution

[Polygonalr]

Addresses this comment, thanks to @P-E-P for explaining the rationale for this change over meeting :)

• GCC development requires copyright assignment or the Developer's Certificate of Origin sign-off, see https://gcc.gnu.org/contribute.html or https://gcc.gnu.org/dco.html
• Read contributing guidelines
• make check-rust passes locally
• Run clang-format
• Added any relevant test cases to gcc/testsuite/rust/

[powerboat9]

@P-E-P it looks like IdentifierPattern::get_subpattern doesn't return an optional and has the line

rust_assert (has_subpattern ());

[P-E-P]

@P-E-P it looks like IdentifierPattern::get_subpattern doesn't return an optional and has the line

rust_assert (has_subpattern ());

Right now the focus is the semantic aspect within the class ("yes that value can be missing and that null pointer IS a bug"), not at the class boundaries. This means you can keep the assert on the getter, if you really want to go the extra mile you can even rename it to get_subpattern_unchecked (it has been done in the codebase before, grep for _unchecked within the rust directory). If we have some time later we'll introduce proper optional APIs for the getters (and grepping "unchecked" will help) but for now the true goal is communicating the intent of the class to easily tell appart buggy null pointers from none values.

[powerboat9]

Oh, wait, nvm -- I should have read the patch more closely. Looks good

[P-E-P]

LGTM