fix: Print multi-line inner comments of arrowFunc

[liuxingbaoyu]

Q	A
Fixed Issues?	Fixes #1, Fixes #2
Patch: Bug Fix?
Major: Breaking Change?
Minor: New Feature?
Tests Added + Pass?	Yes
Documentation PR Link
Any Dependency Changes?
License	MIT

[babel-bot]

Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/53533/

[liuxingbaoyu]

I'm not sure if this is going to be removed, although we no longer wrap comments here.

[JLHwung]

I feel like we should just remove this test case.

In this case, the innerComments are not generated by the parser from a valid JS, instead it is manipulated by the AST transform.

The fact that

(x, y) /* line break here
*/ => {}

is invalid implies that the transformed AST is invalid. Babel generator should not guarantee that it work with an invalid AST. In this case, I think it is fine to do nothing and just remove this test case. The generator may generate invalid JS if the AST is invalid.

[liuxingbaoyu]

This test has nothing to do with this PR, this is a regression test, in #15160 (comment) we decided to never generate invalid code due to invalid comments.

[JLHwung]

As is mentioned there, #15160 conflicts with this PR. The #15160 ensures that the generator prints valid code in comments: false and it somehow works with multi-line inner comments in arrow function.

It seems to me this PR "more specifically" supports multi-line inner comments in the [NLTH] position of the arrow function () [No LineTerminator Here] => {}. I am not convinced that we should do that, because

1. The generator should spend the least efforts on in valid AST, as it is very likely a plugin issue. Moreover, a plugin can add inner comments to any AST nodes, e.g. var x = 1 would not have inner comments at all. The current behaviour is to treat them as trailing comments of VariableDeclaration, which I think is fine. Of course we could print them around the = location, but doing so requires more efforts.
2. If we really want to change the behaviour, it should be applied to other NLTH as well, such as async [NLTH] do, module [NLTH] {, yield [NLTH] AssignmentExpression, etc.

[liuxingbaoyu]

My personal preference is that we don't guarantee it but if someone wants to do it or if someone opens an issue about it we will accept it.
Because it's easy to implement without complicating the code.

Also this should restore the previous behavior where it was printed as inner comments a few PRs ago.