Add regression test for comment preservation in func-to-computed-property refactoring#3362
Conversation
…ed-property refactoring ConvertZeroParameterFunctionToComputedProperty already preserves the leading trivia (e.g. a doc comment) of the converted declaration, since the binding specifier is derived from the detached funcKeyword and the attributes/modifiers are carried over. Add a regression test covering a doc comment with no modifiers, a modifier, an attribute, and a block comment, so the behavior reported in swiftlang#3236 stays correct. Refs swiftlang#3236.
|
@swift-ci Please test |
|
Thanks, @nenadvulic. |
|
@ahoppen The two CI failures look unrelated to this change 😞
All the jobs that actually run the new test are green. |
|
Yeah, the failure are unrelated. Let me trigger CI again. @swift-ci Please test Windows |
Refs #3236.
#3236 reports that
ConvertZeroParameterFunctionToComputedPropertydrops a leading comment (e.g. a doc comment) when converting a zero-parameter function to a computed property.I couldn't reproduce this on
main: the refactoring already preserves the converted declaration's leading trivia. The binding specifier is derived from the detachedfuncKeyword(which keeps its leading trivia), andattributes/modifiersare carried over — so the comment survives whether it sits on thefunckeyword, a modifier, or an attribute.This adds a regression test (
testRefactoringFunctionToComputedPropertyPreservesLeadingComment) so the behavior stays correct, covering:///doc comment with no modifiers,///comment with a modifier (public),///comment with an attribute (@inlinable),/** */block comment.All pass on
main. Given this, #3236 looks resolved and could be closed once this lands (or if someone has a precise case that still drops the comment, the test is a good place to add it).