Format function types. #1288
Merged
Format function types. #1288
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This involves formatting parameter lists which is a big piece of work.
They work similar to argument lists and collection literals... except
for the special syntax around `[ ... ]` and `{ ... }` for optional
parameters.
Getting that working right involved adding some more functionality to
DelimitedListBuilder and ListPiece.
Getting comments working with that syntax was particularly difficult.
I ended up deciding that the formatter can move comments before or after
the optional parameter delimiters if it needs to. Doing so produces
better looking output, as in:
```
// Before:
f(// weird comment location
[param] // another
);
// After:
f([
// weird comment location
param, // another
]);
```
It also, I think is cleaner to implement than trying to laboriously
keep the comment where the user authored it.
In the process of reworking how comments are handled in lists, I also
tweaked how inline block comments are handled before commas. Previously,
they would get moved after the comma, like:
```
// Before:
[element /* comment */, another];
// After:
[element, /* comment */ another];
```
Now, they stay where they were, which is I think what users want. A
common use case for block comments in argument/collection lists is
describing the meaning of a preceding null argument and this keeps that.
Line after an element but before the comma continue to be moved after
the comma:
```
// Before:
f(param // comment
,);
// After:
f(
param, // comment
);
```
Also:
- Added tests for the loosened behavior of equalIgnoringWhitespace().
- Added a test for a corner case of variable splitting that I ran into
with parameters, which use the same VariablePiece.
lrhn
reviewed
Oct 19, 2023
equalIgnoringWhitespace().
kallentu
approved these changes
Oct 19, 2023
test/type/function_comment.stmt
Outdated
| @@ -0,0 +1,202 @@ | |||
| 40 columns | | |||
| >>> Block comment before first parameter. | |||
There was a problem hiding this comment.
Do we have tests for inline block comments?
(And less exciting, but doc comments also)
There was a problem hiding this comment.
These ones are all inline block comments. Updated the descriptions to match and added tests of non-inline block and doc comments.
Deciding how comprehensive to be in tests is always a challenge. In this case, you were exactly right. These tests turned up some bugs. Thanks!
|
Forgot to say :D |
natebosch
approved these changes
Oct 20, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This involves formatting parameter lists which is a big piece of work. They work similar to argument lists and collection literals... except for the special syntax around
[ ... ]and{ ... }for optional parameters.Getting that working right involved adding some more functionality to DelimitedListBuilder and ListPiece.
Getting comments working with that syntax was particularly difficult. I ended up deciding that the formatter can move comments before or after the optional parameter delimiters if it needs to. Doing so produces better looking output, as in:
It also, I think is cleaner to implement than trying to laboriously keep the comment where the user authored it.
In the process of reworking how comments are handled in lists, I also tweaked how inline block comments are handled before commas. Previously, they would get moved after the comma, like:
Now, they stay where they were, which is I think what users want. A common use case for block comments in argument/collection lists is describing the meaning of a preceding null argument and this keeps that.
Line after an element but before the comma continue to be moved after the comma:
Also: