Respect user settings around 'Blocks' when adding parameter null checks.

[CyrusNajmabadi]

Fixes #19172
Followup to #19424

[sharwell]

I'm not convinced this is the right answer. It seems to be applied to all cases where the simplifier annotation is used, and not just to the null check case described in the original issue. In particular, it doesn't account for cases which I find important:

1. if statements which include an else clause
2. Child statements which span more than one line

At minimum this will need several new tests covering the simplification behavior change.

[CyrusNajmabadi]

It seems to be applied to all cases where the simplifier annotation is used, and not just to the null check case described in the original issue

Yes. Any time someone uses the generator (which is what puts on the SimplifierAnnotation) and creates a single-statement block, that single-statement block will be simplified if that's what the user preference is.

[sharwell]

@CyrusNajmabadi I'm worried that somewhere something is going to start doing this to code, and I'd rather be ignoring the setting than having that happen. At this point I'm not comfortable with the potential impact of this change given the current inability to specify finer-grain control over the behavior.

[CyrusNajmabadi]

@sharwell We could certainly tweak the 'prefer block' preference to have another option for single-lines. but, right now, this is just making it so that our codegen APIs respect user preferences as currently stated.

[CyrusNajmabadi]

Adding tests for the other constructs.

[CyrusNajmabadi]

@DustinCampbell What do you think? I think it's appropriate for the syntax-generator to be updated to respect the user's option here. I would also support future work to have a more fine-grained option. like "Use braces for multiline nested statements" (actual text to be massage later).

[CyrusNajmabadi]

retest windows_release_vs-integration_prtest please

[CyrusNajmabadi]

Tagging @Pilchie

[Pilchie]

I'm with Cyrus here, I think we can take this and then consider extending the flexibility of the option.

[CyrusNajmabadi]

Ok. Merging.

[CyrusNajmabadi]

tagging @MattGertz

Customer scenario

This makes one of our new features better respect user codestyle-options. Specifically, when adding a null check, we'll respect the user's preferences around if that null check should use a { } block in it.

Bugs this fixes:

Fixes #19172

Workarounds, if any

None.

Risk

Low.

Performance impact

Low.

Is this a regression from a previous update?

No.

Root cause analysis:

Didn't validate all new features against all codestyle permutations.

How was the bug found?

Customer report.

[MattGertz]

Approving per Kevin's comment. (The scenario meets the bar at any rate.) We should file an issue to track extending it, though.

[CyrusNajmabadi]

I'll open hte issue.

[CyrusNajmabadi]

#19451