GeezerVison

PR Summary

UseConsistentWhitespace's CheckInnerBrace breaks braced member access ($a.{Prop}) by inserting whitespace after the opening and before the closing curly brace ($a.{ Prop }). The inner content of the braces must match the referenced property name exactly. No formatting of the inner content should occur.

Unlike the variable curly-brace format, ${a}, which is tokenised as a variable, no special tokenisation happens for this bracing.

Disclaimer: I don't know the correct names for things

PR introduces a new function, GetBracedMemberAccessRanges(), in TokenOperations.cs, which walks the token list looking for the shape of a braced member access:

• One of these tokens:
  • TokenKind.Variable
  • TokenKind.Identifier
  • TokenKind.StringLiteral
  • TokenKind.StringExpandable
  • TokenKind.HereStringLiteral
  • TokenKind.HereStringExpandable
  • TokenKind.RParen
  • TokenKind.RCurly
  • TokenKind.RBracket
• Optional inline comments(but no whitespace, new lines, line continuations)
• Dot (or QuestionDot on PS7+) Token.
• Optional inline comments, whitespace, new lines, line continuations
• Left Curly Brace
• Inner content
• Matched Right Curly Brace

The function returns a list of int pairs which represent a range from the startoffset of a LCurly to the endoffset of a RCurly. Formatting within these ranges could break braced member access.

In UseConsistentWhitespace when checking for inner brace violations in FindInnerBraceViolations(), call the function to get the ranges to exclude. Skip whitespace checking for braces within any range (inclusive).

Fixes #2066

When asking copilot to look this over, it told me I could instead have used the AST, looking for MemberExpressionAst who's Member started with a { and ended with a }. I could then infer the offsets of the braces. I could explore that if it's a more desirable/correct solution.

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Change is not breaking
• Make sure all .cs, .ps1 and .psm1 files have the correct copyright header
• Make sure you've added a new test if existing tests do not effectively test the code changed and/or updated documentation
• This PR is ready to merge and is not Work in Progress.
  • If the PR is work in progress, please add the prefix WIP: to the beginning of the title and remove the prefix when the PR is ready.