-
Notifications
You must be signed in to change notification settings - Fork 121
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove a bunch of TODO(tall) and TODO(perf) comments that aren't needed. #1484
Conversation
These are all things we have either done already, have filed issues, or I don't have any plans to do at this point.
// example I tried. Leaving this here as a TODO to investigate more when | ||
// there are other benchmarks we can try. | ||
var solutions = <Solution>[]; | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried this optimization, but it had no measurable effects on any of the benchmarks or on formatting the entire Flutter repo.
@@ -520,9 +520,6 @@ class AstNodeVisitor extends ThrowingAstVisitor<void> with PieceFactory { | |||
if (node.members.isEmpty) { | |||
// If there are no members, format the constants like a delimited list. | |||
// This keeps the enum declaration on one line if it fits. | |||
// TODO(tall): The old style preserves blank lines and newlines between | |||
// enum values. A newline will also force the enum to split even if it | |||
// would otherwise fit. Do we want to do that with the new style too? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is done now as of e49a9f3.
@@ -302,8 +302,6 @@ class PieceWriter { | |||
void _flushSpace() { | |||
if (!_pendingSpace) return; | |||
|
|||
// TODO(perf): See if we can make SpacePiece a constant to avoid creating | |||
// multiple. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried this optimization a while back and it actually made things slower. (I'm guessing because it required SpacePiece
to implement Piece
instead of extending it and that in turn made a bunch of calls on Piece
methods polymorphic?)
// For now, we do not implement this special case behavior. Once more of the | ||
// language is implemented in the new back end and we can run the formatter | ||
// on a large corpus of code, we can try it out and see if the special case | ||
// behavior is worth it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tracked by #1465.
@@ -47,7 +47,6 @@ someReceiverObject.property1.property2 | |||
.property5 | |||
.property6; | |||
<<< | |||
### TODO(tall): Allow splitting between successive indexes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this just isn't worth doing. It never looks good and users are better off either reorganizing their code or allowing it to run long.
These are all things we have either done already, have filed issues, or I don't have any plans to do at this point.