Trailing trivia dropped from open curly brace

[evmar]

{/** foo */
  // bar
  let x = 3;
}

The "foo" comment is dropped: http://www.typescriptlang.org/Playground#src=%7B%2F**%20foo%20*%2F%0A%20%20%2F%2F%20bar%0A%20%20let%20x%20%3D%203%3B%0A%7D%0A

Inserting a newline before it preserves the comment:
http://www.typescriptlang.org/Playground#src=%7B%0A%09%2F**%20foo%20*%2F%0A%20%20%2F%2F%20bar%0A%20%20let%20x%20%3D%203%3B%0A%7D%0A

var x = /** foo */ () => 12;

The "foo" comment is dropped:
http://www.typescriptlang.org/Playground#src=var%20x%20%3D%20%2F**%20foo%20*%2F%20()%20%3D%3E%2012%3B

Inserting a newline before the /** causes it to be emitted twice(!):
http://www.typescriptlang.org/Playground#src=var%20x%20%3D%0A%2F**%20foo%20*%2F%20()%20%3D%3E%2012%3B

[evmar]

I've spent some time digging into this bug and I think the problem is in getCommentRanges. This function accepts a trailing parameter that controls whether it's gathering "leading" or "trailing" comments, but what that actually means is pretty confusing to me.

When emitting, the usage of leading and trailing is maybe what you'd naively expect given the terms "leading" and "trailing", which is to say comments that occur before or after the node:

                    const emitComments = shouldEmitLeadingAndTrailingComments(node);
                    if (emitComments) {
                        emitLeadingComments(node);
                    }

                    emitNodeConsideringSourcemap(node);

                    if (emitComments) {
                        emitTrailingComments(node);
                    }

But within getCommentRanges the trailing flag instead has this rather subtle meaning:

     * @param trailing
     * If false, whitespace is skipped until the first line break and comments between that location
     * and the next token are returned.
     * If true, comments occurring between the given position and the next line break are returned.

It's not clear to me why whitespace and in particular line breaks are relevant to the notion of whether a comment should emit before or after a node. Any pointers are welcome; I will continue digging otherwise.

[evmar]

Here's the test case I've been playing with. The comments are numbered so you can see which ones are dropped from the output and which are duplicated:

http://www.typescriptlang.org/Playground#src=%2F*%20trivia1%20*%2F%0D%0A%7B%2F*%20trivia2%20*%2F%0D%0A%20%201%3B%20%2F*%20trivia3%20*%2F%0D%0A%7D%2F*%20trivia4%20*%2F%0D%0A%0D%0Alet%20%2F*%20trivia5%20*%2F%20x%20%3D%0D%0A%2F*%20trivia6%20*%2F%0D%0A()%20%3D%3E%20%2F*%20trivia7%20*%2F%203%3B%0D%0A

[evmar]

Further reduction:

{/* trivia1 */1;
/* trivia2 */}

drops both comments.

The ExpressionStatement node with text "/* trivia1 */1" has neither leading nor trailing comments according to the code.

[joeskeen]

This also causes some problems if you have trailing line comments after an opening curly brace. This is a big deal if you need to ignore a single line in JSHint (see Playground example)

Context: In a Yeoman generator project, I need to be able to keep JSHint intact for the JS version of the generated app.

[Andarist]

I can no longer reproduce any of the mentioned cases, cc @jakebailey

[jakebailey]

The double comment emit (the last example) was fixed in #7948 (with new transforms becoming the default), then the missing comments were fixed later in #22141.