Rafia Sabih <rafia.sa...@enterprisedb.com> writes:
> Okay, I am marking it as 'Ready for committer' with the following note
> to committer,
> I am getting whitespace errors in v3 of patch, which I corrected in
> v4, however, Fabien is of the opinion that v3 is clean and is showing
> whitespace errors because of downloader, etc. issues in my setup.
FWIW, what I see is that v3 saves out with Windows-style newlines (\r\n)
while v4 saves out with Unix newlines. It wouldn't really matter, because
"patch" converts Windows newlines (at least mine does), but Unix newlines
are our project style.
As for the substance of the patch ... the fix for continuations in
the INITIAL state is not this simple. You have rules for
{nonspace}+
{space}+
{newline}
{continuation}
Remember that flex always takes the rule that produces the longest match
starting at the current point. {space}+ and {newline} don't conflict with
continuations, but {nonspace}+ does: suppose that the next four characters
are "a" "b" "\" newline. flex will decide that the token is "ab\", rather
than taking the token as being "ab" and letting the "\" wait till next
time when it can be parsed as {continuation}.
In other words, it works to write backslash-newline immediately after a
token in the EXPR state (mainly because backslash isn't a legal part of
any token EXPR state currently allows), but not to write it immediately
after a token in INITIAL state. I think this is surprising and
inconsistent.
Probably the easiest fix is to add a rule that explicitly matches this
situation:
{nonspace}+{continuation} { ... throw back 2 chars and return the rest ... }
The "throw back" part is easily done with "yyless(yyleng - 2)"; compare
some rules in the core lexer. I have not actually tested this,
but I think it will work, because when it applies it would always be
the longest possible match.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
