Error in vscode: "`gcc.exe' failed in phase `C pre-processor'. (Exit code: 1)"

[fendor]

@jneira found that it happens on our install script project when you have never built it before.

Steps to reproduce:

git clone https://github.com/mpickering/haskell-ide-engine hie
cd hie/install
code .

or, if project is already cloned

cd <path-to-haskell-ide-engine>/install
rm -rf .stack-work/ dist-newstyle/ dist/
code .

where code . is just an arbitrary lsp-client.

In the project hie-install, the cradle Cabal-Helper-v2 will be selected due to the presence of cabal.project. Simply opening any haskell source file in the project will lead to the described error message. Error is specifically that a cabal_macros.h can not be found, which is not generated when c-h initialises the project context. Workaround: use stack build and cabal build respectively to generate this file.

EDIT: adding a hie.yaml works for me as expected even when the project has never been built before.

Originally posted by @fendor in https://github.com/mpickering/haskell-ide-engine/issues/47#issuecomment-555151240

Related issue https://github.com/haskell/cabal/issues/2209.

[ulidtko]

Hey, I got essentially the same error — but for a totally different reason.

In my case, the project is pre-built and cabal_macros.h is in place.

What trips gcc is malformed invocation.

[...]
/home/ulidtko/src/company/on-server/.stack-work/cabal-helper/cabal-helper /home/ulidtko/src/company/on-server/metrics/metrics.cabal /home/ulidtko/src/company/on-server/metrics/.stack-work/dist/x86_64-linux-tinfo6/Cabal-2.4.0.1 v2 package-id compiler-id flags config-flags non-default-config-flags component-info
gcc -E -undef -traditional -include .stack-work/dist/x86_64-linux-tinfo6/Cabal-2.4.0.1/build/autogen/cabal_macros.h -Wno-nonportable-include-path -Werror -I.stack-work/dist/x86_64-linux-tinfo6/Cabal-2.4.0.1/build -I.stack-work/dist/x86_64-linux-tinfo6/Cabal-2.4.0.1/build -I.stack-work/dist/x86_64-linux-tinfo6/Cabal-2.4.0.1/build/autogen -I.stack-work/dist/x86_64-linux-tinfo6/Cabal-2.4.0.1/build/global-autogen -I.stack-work/dist/x86_64-linux-tinfo6/Cabal-2.4.0.1/build -I/home/ulidtko/.stack/snapshots/x86_64-linux-tinfo6/474b6b844ef14a4f807e7e8e701da8a55bd48660fed10431b2f5fdc356c47ba4/8.6.5/lib/x86_64-linux-ghc-8.6.5/old-time-1.1.0.3-2XkcGgLYS3G4Bt8PCBG9iL/include -I/home/ulidtko/.stack/snapshots/x86_64-linux-tinfo6/474b6b844ef14a4f807e7e8e701da8a55bd48660fed10431b2f5fdc356c47ba4/8.6.5/lib/x86_64-linux-ghc-8.6.5/unix-compat-0.5.2-5CtkYVRMw4V15TQn19NMXa/include -I/home/ulidtko/.stack/programs/x86_64-linux/ghc-tinfo6-8.6.5/lib/ghc-8.6.5/process-1.6.5.0/include

Which, if retried by hand, barfs:

gcc: fatal error: no input files compilation terminated. $ echo $? 1

There indeed appear no input-file arguments in that gcc call (which comes from I don't know where).

Thoughts?

[ulidtko]

OK, I still don't know what I'm doing, but at least I understand why the preprocessor call is failing.

This is apparently incorrect way to use -include. Trivial repro:

$ echo '#warning "Foobar"' > /tmp/test.h
$
$ gcc -E -undef -include /tmp/test.h
gcc: fatal error: no input files
compilation terminated.

Correct call:

$ gcc -E -undef -include /tmp/test.h - < /dev/null

This hasn't changed any time recently (tested the same behavior across the 3 latest major releases of GCC: 8.4.0, 9.3.0, 10.1.0), and not a bug per man gcc:

-include file Process file as if "#include "file"" appeared as the first line of the primary source file.

No primary source file -- nothing to process; fatal error.

---

What's left is to understand where the preprocessor is invoked from. And why that code is trying to use -include [...]/cabal_macros.h instead of passing [...]/cabal_macros.h directly (which works).

Any hints appreciated.