v16 fails to build w/ Visual Studio 2015
Visual Studio 2015 version "14.0.25431.01 Update 3" has an apparent compiler
bug that causes the build to fail with "readfuncs.switch.c(522): fatal error
C1026: parser stack overflow, program too complex (compiling source file
src/backend/nodes/readfuncs.c)". While I wouldn't mind revoking support for
Visual Studio 2015, changing the code to cope is easy. See attached.
https://stackoverflow.com/a/34266725/16371536 asserts having confirmation of
the compiler bug, but its reference is now a dead link. This became a problem
in v16 due to the 135% increase in node types known to parseNodeString().
https:/postgr.es/m/20221124004144.iosgze2qnmcctgsh@awork3.anarazel.de
previously reported this error message when overriding USE_READLINE in a
Visual Studio build, for tab-complete.c. If that combination ever becomes
supported, we may face a similar decision there.
Attachments:
vs2015-parseNodeString-v1.patchtext/plain; charset=us-asciiDownload
Author: Noah Misch <noah@leadboat.com>
Commit: Noah Misch <noah@leadboat.com>
Make parseNodeString() C idiom compatible with Visual Studio 2015.
Between v15 and now, this function's "else if" chain grew from 252 lines
to 592 lines, exceeding a compiler limit that manifests as "fatal error
C1026: parser stack overflow, program too complex (compiling source file
src/backend/nodes/readfuncs.c)". Use "if (...) return ...;" instead.
Reviewed by FIXME.
Discussion: https://postgr.es/m/FIXME
diff --git a/src/backend/nodes/gen_node_support.pl b/src/backend/nodes/gen_node_support.pl
index b89b491..72c7963 100644
--- a/src/backend/nodes/gen_node_support.pl
+++ b/src/backend/nodes/gen_node_support.pl
@@ -924,9 +924,9 @@ foreach my $n (@node_types)
. "\t\t\t\t_out${n}(str, obj);\n"
. "\t\t\t\tbreak;\n";
- print $rfs "\telse if (MATCH(\"$N\", "
+ print $rfs "\tif (MATCH(\"$N\", "
. length($N) . "))\n"
- . "\t\treturn_value = _read${n}();\n"
+ . "\t\treturn (Node *) _read${n}();\n"
unless $no_read;
next if elem $n, @custom_read_write;
diff --git a/src/backend/nodes/readfuncs.c b/src/backend/nodes/readfuncs.c
index 597e5b3..df72dc3 100644
--- a/src/backend/nodes/readfuncs.c
+++ b/src/backend/nodes/readfuncs.c
@@ -696,8 +696,6 @@ _readExtensibleNode(void)
Node *
parseNodeString(void)
{
- void *return_value;
-
READ_TEMP_LOCALS();
/* Guard against stack overflow due to overly complex expressions */
@@ -708,16 +706,10 @@ parseNodeString(void)
#define MATCH(tokname, namelen) \
(length == namelen && memcmp(token, tokname, namelen) == 0)
- if (false)
- ;
#include "readfuncs.switch.c"
- else
- {
- elog(ERROR, "badly formatted node string \"%.32s\"...", token);
- return_value = NULL; /* keep compiler quiet */
- }
- return (Node *) return_value;
+ elog(ERROR, "badly formatted node string \"%.32s\"...", token);
+ return NULL; /* keep compiler quiet */
}
Noah Misch <noah@leadboat.com> writes:
Visual Studio 2015 version "14.0.25431.01 Update 3" has an apparent compiler
bug that causes the build to fail with "readfuncs.switch.c(522): fatal error
C1026: parser stack overflow, program too complex (compiling source file
src/backend/nodes/readfuncs.c)". While I wouldn't mind revoking support for
Visual Studio 2015, changing the code to cope is easy. See attached.
+1, I think this reads better anyway.
regards, tom lane
Hi,
On 2023-06-07 11:54:58 -0700, Noah Misch wrote:
Visual Studio 2015 version "14.0.25431.01 Update 3" has an apparent compiler
bug that causes the build to fail with "readfuncs.switch.c(522): fatal error
C1026: parser stack overflow, program too complex (compiling source file
src/backend/nodes/readfuncs.c)". While I wouldn't mind revoking support for
Visual Studio 2015, changing the code to cope is easy. See attached.
I don't see a point in trying to keep Visual Studio 2015 working. We have no
automated testing for it, as evidenced by this issue. It seems quite possible
we're going to hit such issues in other places.
Greetings,
Andres Freund
On 07.06.23 23:21, Andres Freund wrote:
On 2023-06-07 11:54:58 -0700, Noah Misch wrote:
Visual Studio 2015 version "14.0.25431.01 Update 3" has an apparent compiler
bug that causes the build to fail with "readfuncs.switch.c(522): fatal error
C1026: parser stack overflow, program too complex (compiling source file
src/backend/nodes/readfuncs.c)". While I wouldn't mind revoking support for
Visual Studio 2015, changing the code to cope is easy. See attached.I don't see a point in trying to keep Visual Studio 2015 working. We have no
automated testing for it, as evidenced by this issue. It seems quite possible
we're going to hit such issues in other places.
Apparently, nobody has used it between Sat Jul 9 08:52:19 2022 and now?
On 07.06.23 23:16, Tom Lane wrote:
Noah Misch <noah@leadboat.com> writes:
Visual Studio 2015 version "14.0.25431.01 Update 3" has an apparent compiler
bug that causes the build to fail with "readfuncs.switch.c(522): fatal error
C1026: parser stack overflow, program too complex (compiling source file
src/backend/nodes/readfuncs.c)". While I wouldn't mind revoking support for
Visual Studio 2015, changing the code to cope is easy. See attached.+1, I think this reads better anyway.
I kind of like the style where there is only one return at the end,
because it makes it easier to inject debugging code that inspects the
return value.
On Wed, Jun 07, 2023 at 11:34:09PM +0200, Peter Eisentraut wrote:
On 07.06.23 23:21, Andres Freund wrote:
On 2023-06-07 11:54:58 -0700, Noah Misch wrote:
Visual Studio 2015 version "14.0.25431.01 Update 3" has an apparent compiler
bug that causes the build to fail with "readfuncs.switch.c(522): fatal error
C1026: parser stack overflow, program too complex (compiling source file
src/backend/nodes/readfuncs.c)". While I wouldn't mind revoking support for
Visual Studio 2015, changing the code to cope is easy. See attached.I don't see a point in trying to keep Visual Studio 2015 working. We have no
automated testing for it, as evidenced by this issue. It seems quite possible
we're going to hit such issues in other places.Apparently, nobody has used it between Sat Jul 9 08:52:19 2022 and now?
Essentially. I assume you're referring to commit 964d01a "Automatically
generate node support functions". I bet it actually broke a few days later,
at ff33a8c "Remove artificial restrictions on which node types have out/read
funcs."
On Wed, Jun 07, 2023 at 11:35:34PM +0200, Peter Eisentraut wrote:
I kind of like the style where there is only one return at the end, because
it makes it easier to inject debugging code that inspects the return value.
I kind of disagree here, the previous style is a bit ugly-ish, with
the code generated by gen_node_support.pl being dependent on this
local call because it is necessary to know about return_value:
- if (false)
- ;
#include "readfuncs.switch.c"
So +1 for what's proposed.
--
Michael
On Wed, Jun 07, 2023 at 03:04:16PM -0700, Noah Misch wrote:
On Wed, Jun 07, 2023 at 11:34:09PM +0200, Peter Eisentraut wrote:
Apparently, nobody has used it between Sat Jul 9 08:52:19 2022 and now?
One week close enough. I have run checks on VS 2015 back when working
on 6203583, but I don't have this environment at hand anymore.
Essentially. I assume you're referring to commit 964d01a "Automatically
generate node support functions". I bet it actually broke a few days later,
at ff33a8c "Remove artificial restrictions on which node types have out/read
funcs."
Note that the last version-dependent checks of _MSC_VER have been
removed in the commit I am mentioning above, so the gain in removing
VS 2015 is marginal. Even less once src/tools/msvc/ gets removed.
But perhaps it makes a few things easier with meson in mind?
I don't think that's a reason enough to officially remove support for
VS 2015 on 17~ and let it be for v16, though. It seems like my old
Windows env was one bug in the Matrix, and I've moved one to newer
versions already.
--
Michael