Обсуждение: 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.

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