Comments should have no significance to the semantic meaning

[almazik]

Current parser tries to associate comments with the entities by assuming that the comment preceding the definition belongs to that definition.

According to the specification draft:

Comments are Ignored like white space and may appear after any token, or before a LineTerminator, and have no significance to the semantic meaning of a GraphQL Document.

So we should interpret comments just like the whitespace, skipping them during lex parsing.

This issue relates to #33 as documentation should replace the current comments annotation logic

[sungam3r]

I just have to note that this is just a draft specification requirement. So for now, support for this feature can wait a bit.

[almazik]

Agree that it may wait, but for example HotChocolate and all graphql syntax highlighting plugins I've used already support it.

I've started implementing #33, as we might have to just switch to HotChocolate otherwise.

As a side note (which may be extracted into a separate issue), the current parsing logic (not the entities) doesn't seem to match the structure of the spec. I don't know if it's due to the historical development reasons, or the GraphQL spec have evolved quite far, but I think it would be great to refactor the parser to match the structure of the specification. For example (as defined in the spec):
Document has a list of Definitions.
Definition is either ExecutableDefinition, TypeSystemDefinition or TypeSystemExtension.
ExecutableDefinition is either an OperationDefinition or FragmentDefinition.
etc.
And parse the input using exactly the same hierarchy. It will allow the code to match the spec 1:1, and future changes would be much easier to implement. What do you think? I can come up with the implementation POC if you think it's worthwhile

[sungam3r]

Document has a list of Definitions.
Definition is either ExecutableDefinition, TypeSystemDefinition or TypeSystemExtension.
ExecutableDefinition is either an OperationDefinition or FragmentDefinition.
etc.

The structure of the parser document is the same, isn't it?

[Shane32]

The current 2018 spec says the same thing about comments, by the way, that they are treated as white space. This seems like an important fix

[sungam3r]

Fixed by #105 ?

[Shane32]

Yes (optional). Also see #104 and #80

[Shane32]

Also see #101 (comment)