Issue 15127 - Parser assertion on wrong code

[9rnsr]

https://issues.dlang.org/show_bug.cgi?id=15127

[quickfur]

I don't understand this fix. The comment here says that the code expects the next token to be = but we've just removed the assertion that checks this assumption. Doesn't that mean that malformed user input may cause the following code to malfunction? Shouldn't this be turned into a check with a compile error message when the next token isn't = instead?

[9rnsr]

Doesn't that mean that malformed user input may cause the following code to malfunction?

Parser should accept any possible token streams. If the input tokens could be treated as valid D code representation, parser will generate AST. If not, parser will report some parsing errors. Both are valid as "parser program output".
In other words, any input token streams must not be treated as malformed. If any assumptions exist for the input token streams, it's just wrong. In here, I've just removed wrong assertion.

Shouldn't this be turned into a check with a compile error message when the next token isn't = instead?

In parseTemplateParameterList function, it's already reported errors for the parsing failures. But, indeed it would be better to have own error check here. I'll replace the bare nextToken() call with check(TOKassign).

[quickfur]

Makes sense. Thanks!

[yebblies]

Auto-merge toggled on

[9rnsr]

@yebblies Thanks!