Should we work around msvc failing to compile tab-complete.c?

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Should we work around msvc failing to compile tab-complete.c?
Date: 2024-07-08 17:48:04
Message-ID: 20240708174804.pfrnxtzusudznhfd@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Compiling postgres on windows with tab-completion support fails either with
"fatal error C1026: parser stack overflow, program too complex”.
or (in recent versions) with
"…/src/bin/psql/tab-complete.c(4023): fatal error C1001: Internal compiler error."

I've reported this to the visual studio folks at [1] and supposedly a fix is
waiting to be released. I don't know if that's just for the internal compiler
error in 2022 or lifting the limitation.

It's pretty easy to work around the error [2]. I wonder if we should just do
that, then we don't have to insist on a very new msvc version being used and
it'll work even if they just decide to fix the internal compiler error.

Besides just breaking the if-else-if chain at some arbitrary point, we could
alternatively make a more general efficiency improvement, and add a bit of
nesting at a few places. E.g. instead of having ~33 checks for COMMENT being
the first word, we could use "outer" else-if for COMMENT and check the
sub-variants inside that branch:

else if (HeadMatches("COMMENT"))
{
if (Matches("COMMENT"))
COMPLETE_WITH("ON");
else if (Matches("COMMENT", "ON"))
...
}

if we do that to one or two common keywords (COMMENT and DROP seems easiest)
we'd be out from that limitation, and would probably reduce the number of
cycles for completions noticeably.

OTOH, that'd be a more noisy change and it'd be less defensible to apply it to
17 - which IMO would be nice to do.

Greetings,

Andres Freund

[1] https://developercommunity.visualstudio.com/t/tab-completec4023:-fatal-error-C1001:/10685868
[2] https://postgr.es/m/CACLU5mRRLAW2kca3k2gVDM8kow6wgvT_BCaeg37jz%3DKyj1afvw%40mail.gmail.com

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message MARK CALLAGHAN 2024-07-08 17:49:31 Re: debugging what might be a perf regression in 17beta2
Previous Message David E. Wheeler 2024-07-08 17:34:45 Re: jsonpath: Inconsistency of timestamp_tz() Output