Remove dot character when replacing contextual enum with full name

[maniramezan]

Fixes issue by going back one character when suggesting fixit replacement of contextual enum with fully typed name. All the unit tests passing with this change locally. Couldn't figure out where to add the unit test for this specific change.

Resolves SR-8147.

[CodaFi]

Hi @maniramezan, thanks for the change. Generally, we don’t change the diagnostic engine when a fixit has the wrong source ranges. Could you instead change the offending replace call to do the right thing and add a test?

[jrose-apple]

This problem's also more subtle than just eating a leading dot: it's perfectly okay to do an unqualified rename of an enum case from "foo" to "bar".

[maniramezan]

@jrose-apple Yes, I've been looking into the code to see if I can do something smarter based on the type information but couldn't find a good solution based on my limited knowledge. here is where the error diagnostic is happening and this where the fixit is set. Also, would be nice to be able to change the error message to include . in it.

The eating a leading dot works only because this is the only known fixit message that we show that has dot in it, at least based on the existing tests that all passed locally.

Would appreciate any guidance on making it better. It's only trying to replace after dot with fully qualified name and ignores whether variable full-qualified or not.

[CodaFi]

@maniramezan It's been a year and the SR has been released back to the community. If you would like to pursue this change, please send us an updated pull request that responds to the review feedback. We can discuss any implementation details on bugs.swift.org.