Remove special handling of __FILE__, __LINE__, etc.

[DougGregor]

These were replaced by #file, #line, etc. with SE-0028, prior to Swift 3. We don't need this custom error message any more, and they shouldn't be keywords. Stop treating them as keywords in the lexer.

[DougGregor]

@swift-ci please smoke test and merge

[AnthonyLatsis]

@DougGregor Why are we sacrificing the migration paths? Is this a simplification that assumes the number of users that will need this has become negligible at this point? (asking out of curiosity.)

[DougGregor]

@DougGregor Why are we sacrificing the migration paths? Is this a simplification that assumes the number of users that will need this has become negligible at this point? (asking out of curiosity.)

It has been an error in the parser since 2016, so it's not really a feasible migration path anymore, and the number of users who need it should be close to zero.

I'm removing these because the implementation is not correct. For one, __FILE__ et al should not be keywords, they should be normal identifiers. Additionally, we shouldn't produce this kind of error in the parser: if we care about this diagnostic (say, to help folks who come from C and try to use __FILE__), we should implement it in the type checker when the constraint solver fails to find a declaration named __FILE__.

Regardless, this implementation of this special diagnostic had to go. I'm calling it low-value enough that it's better to remove it rather than reimplement it.

[AnthonyLatsis]

Thank you for clarifying!

I'm removing these because the implementation is not correct. For one, __FILE__ et al should not be keywords, they should be normal identifiers. Additionally, we shouldn't produce this kind of error in the parser: if we care about this diagnostic (say, to help folks who come from C and try to use __FILE__), we should implement it in the type checker when the constraint solver fails to find a declaration named __FILE__.

This makes a lot of sense.