Suggest add missing , before doc comments in parsing item list

[xizheyin]

Fixes #142311

[compiler-errors]

This approach feels larger than the issue it's trying to fix, and it also isn't applied to other generalizations of this problem like struct fields. I'm not sure if it's warranted--I think we could simply suppress the doc comment /// -> // / suggestion when a trailing comma is in the expected tokens list, which would be a good enough approximation of this without needing to add a whole new "parse context" tracking to the parser.

[xizheyin]

That's what I thought at first, but I'm worried that there are many similar cases in the code.

If only record the case, fixing every such error will make the code ugly like patching. But I haven't got a detailed investigation of the specific situations where context is needed. Maybe the current one can be used without context. But in the future, this context refactoring may be useful to enhance the maintainability of the code to solve multiple similar problem.

[compiler-errors]

Well right now it doesn't seem particularly worthwhile. I'm not totally sure if the original issue report is really worth fixing, since the suggestion is valid in some cases, and suppressing it seems like more work than is worth it.

[xizheyin]

For that edge situation, it is really worth fixing, at least it should be set to maybeincorrect, not machineappreciate.At present, the testcase related to that doc comment suggestion does not cover this situation.

[fee1-dead]

This isn't needed because the edible parameter on expected_one_of_not_found already contains information on what tokens we expect.

It would be much better to suggest adding a comma before the doc comment if a comma was expected, so this case works out too:

fn a() {
    [
        a /// Test
        b
    ]
}

[xizheyin]

@rustbot ready

[xizheyin]

I modified the fixme and used the E0585 code in two new commits. :3

[xizheyin]

The current version is much better.
@rustbot ready