Bug fix: L036 handle single-column SELECT with comment on same line as SELECT keyword

[barrywhart]

Brief summary of the change made

Fixes #3252

Are there any other side effects of this change that we should be aware of?

Pull Request checklist

• Please confirm you have completed any of the necessary steps below.

• Included test cases to demonstrate any code changes, which may be one or more of the following:

  • .yml rule test cases in test/fixtures/rules/std_rule_cases.
  • .sql/.yml parser test cases in test/fixtures/dialects (note YML files can be auto generated with tox -e generate-fixture-yml).
  • Full autofix test cases in test/fixtures/linter/autofix.
  • Other.

• Added appropriate documentation for the change.

• Created GitHub issues for any relevant followup/future enhancements if appropriate.

[barrywhart]

Unrelated to the issue, but no longer necessary to call _choose_anchor_segment() here due to recent improvements in the core linter.

[tunetheweb]

Instead of moving the select target up, before the comment, could we move the comment down after the select target (or temporary delete it)? Then fix the select target as it would if not comment was there?

[barrywhart]

Review this section with "Hide whitespace" enabled.

[codecov]

Codecov Report

Merging #3259 (48136f9) into main (179289a) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##              main     #3259   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files          167       167           
  Lines        12531     12539    +8     
=========================================
+ Hits         12531     12539    +8     

Impacted Files	Coverage Δ
src/sqlfluff/rules/L036.py	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 179289a...48136f9. Read the comment docs.

[barrywhart]

@tunetheweb: We could. I don't think I'm up for tackling it now. Would you want to create a separate issue for this? Often when I look at one of these rules that moves stuff around, I am surprised how complicated it is and how many special cases arise, and how easy it is to make a mistake and corrupt the code. Here are a couple of other test cases that occur to me if we try to handle this:

SELECT -- comment 1
a -- comment 2;

SELECT --comment 1
/* comment 2 */ a -- comment 3;

🤯

I feel like rule #1 is, don't corrupt anyone's code. Auto-fixing is nice, but definitely lower priority, and the balance between effort, risk, and reward is important.

[tunetheweb]

Fair enough!