Revert SQL-related changes from last year

[Ingramz]

Description of the Change

This pull request reverts pull requests #330 and #332 due to causing more harm than good.

While in ideal conditions these pull requests do an amazing job at highlighting in SQL in PHP strings, it can break very easily by having invalid SQL in PHP strings. Do note that PHP has never required strings to contain valid SQL and never will, so it is incorrect of us to assume that.

Alternate Designs

Attempt fixing the current implementation: neither @50Wliu or I have the time to deal with this and it is fairly evident from pull requests that nobody else dares to touch it either. Since originally the intent was to fix any issues as they appear, this definitely does not apply today, so reverting is the next best thing to do.

Benefits

SQL may only be parsed inside PHP strings, leaving rest of the code to PHP grammar to parse.

Possible Drawbacks

In some situations we are going a step backwards due to some lost ability to highlight SQL more accurately. If anyone desires, these can be re-implemented afterwards, however they do require more thorough review before getting merged.

Applicable Issues

Fixes #333

[Ingramz]

Here's another idea, add the currently failing cases as tests, so they wouldn't break again.

[Ingramz]

atom/language-sql#70 is also part of the culprit. Python suffers from a similar issue, where a set of parentheses remains unclosed within same string:

<?php
echo "hello world";
$sql = "SELECT * from (";
echo "hello world";

print "hello world"
sql = "SELECT * from ("
print "hello world"

Edit: Currently I see two possible fixes, both less than ideal.

1. Limit SQL highlighting to a single line only (using match + patterns)
2. Do not depend on language-sql directly.

[lee-dohm]

@50Wliu do you have any thoughts on this?

[winstliu]

Here's another idea, add the currently failing cases as tests, so they wouldn't break again.

This should be done.

atom/language-sql#70 is also part of the culprit.

What would be the impact of reverting atom/language-sql#70?

[Ingramz]

What would be the impact of reverting atom/language-sql#70?

I'm not entirely sure, probably not much as it is the latest grammar related change on that repository. It will definitely reintroduce the issue it was supposed to fix, but otherwise looks harmless.

[winstliu]

I think atom/language-sql#70 was the main cause of this issue due to its introduction of begin/end captures. Maybe we can try reverting the punctuation-related changes of that one first?

[Ingramz]

Yes, probably. I agree that we should try that first.

I'll take a closer look at the left-injections of this pull request later and then analyze whether there's anything really wrong with them. But it is obvious now that language-sql change had a way bigger impact in terms of breaking highlighting in this case.

[KapitanOczywisty]

@sadick254 I'm not sure if this should be merged, It's very old and may break sql even more...

[KapitanOczywisty]

@sadick254 this isn't even fixing issues... We're only throwing away interpolation

[KapitanOczywisty]

FYI @roblourens we should do some checking before importing this commit to vscode

[KapitanOczywisty]

After some more testing seems that some issues were indeed "fixed" by this revert (besides broken stuff), but what is funny vscode have also fixed issues and at the same time I haven't find any degradations yet. With that I will not bother to fix any SQL issues in atom anymore.

And vscode changes