This is an archive of the discontinued LLVM Phabricator instance.

clang-format: [JS] Better support for fat arrows.
ClosedPublic

Authored by mprobst on May 21 2015, 4:35 AM.

Details

Reviewers
klimek
Summary

Assigns a token type (TT_JsFatArrow) to => tokens, and uses that to
more easily recognize and format fat arrow functions.
Improves function parsing to better recognize formal parameter
lists and return type declarations.
Recognizes arrow functions and parse function bodies as child blocks.

Diff Detail

Event Timeline

mprobst updated this revision to Diff 26216.May 21 2015, 4:35 AM
mprobst retitled this revision from to clang-format: [JS] Better support for fat arrows..
mprobst updated this object.
mprobst edited the test plan for this revision. (Show Details)
mprobst added a reviewer: klimek.
mprobst added subscribers: Unknown Object (MLST), djasper.
klimek added inline comments.May 21 2015, 4:49 AM
lib/Format/UnwrappedLineParser.cpp
885–887

Seems like they have TokenKind TT_JsFatArrow now.

1042–1043

Most of the time we enter parse* functions with the first token of that projection. In this case, I'd expect the current token still be the OpenKind.

1046

Nit: add '.'

1048

Use pre-increment in C++.

lib/Format/UnwrappedLineParser.h
110–114

a) use doxygen comments for functions
b) we usually don't have nested parens or nested blocks where there can't be anything in we'd want to parse explicitly; I assume you know what you're doing for JS here, but I find that really curious

mprobst updated this revision to Diff 26221.May 21 2015, 5:02 AM

PTAL.

lib/Format/UnwrappedLineParser.cpp
885–887

It has TokenType TT_JsFatArrow, but tok::TokenKind tok::equal. Don't blame me, I'm just the messenger :-)

Updated the comment to be explicit about tok::TokenKind.

1042–1043

Done, that's better indeed.

1046

Done.

1048

Done.

lib/Format/UnwrappedLineParser.h
110–114

(a): done.
(b): this matches what the code used to do before. In the positions where I call it, there can never be stuff that belongs on separate lines (it's within a formal parameter list or within inline type declarations). I'm not 100% certain this will always be the best thing to do, but it's definitely not a regression and I cannot come up with a case where it'd be wrong right now.

klimek accepted this revision.May 21 2015, 5:18 AM
klimek edited edge metadata.

lg

This revision is now accepted and ready to land.May 21 2015, 5:18 AM
mprobst closed this revision.May 29 2015, 2:57 PM

This has gone in.