Include start offset in Comment

[overlookmotel]

#4045 replaced TriviasMap with a sorted Vec (bravo @lucab!)

After that change, there's no need to use a Vec<(u32, Comment)> - can change it to Vec<Comment> and move start field into Comment itself. Or, probably even better, make it struct Comment { span: Span, kind: CommentKind } to match AST nodes.

This would feel more natural to me - start was only external to Comment previously as it was key for the map.

Side note: I'm not sure if SortedComments should be a boxed slice rather than a Vec. Possible that some transforms may want to add/remove comments.

[overlookmotel]

@lucab By the way, FYI I made one other small change to your impl - #4067.

[lucab]

I did start going down the route of a Comment.start refactor in #4045, but then I backtracked and kept a smaller PR. I don't remember exactly, but I think I saw some consumer somewhere that wanted to touch comments positions, and I was a bit scared to break some more distant logic.
A span field makes sense. I'm not very familar with the AST design, but an alternative idea would be to store start and len instead. That would allow to shift comments around just by offsetting their start position.

I'm not sure if SortedComments should be a boxed slice rather than a Vec. Possible that some transforms may want to add/remove comments.

I did not see any library methods for consumers to manipulate trivia.comments, so I think that under the current API they are effectively immutable. If that's going to change, I think there is a need of some further wrappers otherwise consumers can easily break the "sorted" invariant by mistake.

Similar discussion point for irregular_whitespaces: they are currently stored in an immutable Vec.

[Boshen]

I think start and end fields with a .span() method should cover existing scenarios.

Trivias are immutable for the foreseeable future so it's fine to keep them as immutable. Or maybe we can encapsulate it for a stable API, to allow us to add mutable methods in the future.

[overlookmotel]

Thanks both for coming back. Yes I see the argument for keeping SortedComments as an immutable boxed slice. As you said @lucab, I guess irregular_whitespaces could/should be a boxed slice then too.

[lucab]

Ack. If nobody is in a hurry, I can tackle this one later in the week.

[overlookmotel]

No hurry at all!