GCC's '-fno-syntax-only' is missing from Clang

[surrealoatmeal]

This ''-fno-'' flag exists over in GCC but not in clang: godbolt.

[llvmbot]

@llvm/issue-subscribers-clang-driver

Author: None (surrealoatmeal)

This ''-fno-'' flag exists over in GCC but not in clang: [godbolt](https://godbolt.org/z/xKKqfdGn7).

[MaskRay]

I can only find one occurrence gcc/gcc/d/gdc.texi (this file is copied to many repostories) in all public repositories. It doesn't seem common enough to justify support.

The presence would make action selection (-fsyntax-only -E -c -S) more confusing.

[AaronBallman]

Agreed, unless there's a motivating use case for the option, I don't think this should be supported.

[pinskia]

From https://gcc.gnu.org/onlinedocs/gcc-15.1.0/gcc/Invoking-GCC.html :

Many options have long names starting with ‘-f’ or with ‘-W’—for example, -fmove-loop-invariants, -Wformat and so on. Most of these have both positive and negative forms; the negative form of -ffoo is -fno-foo. This manual documents only one of these two forms, whichever one is not the default.

So GCC not documenting explicitly -fno-syntax-only is expected.

https://gcc.gnu.org/onlinedocs/gcc-15.1.0/gcc/Warning-Options.html#index-fsyntax-only

[AaronBallman]

Thanks, @pinskia! Do you happen to know why GCC supports -fno-syntax-only?

[pinskia]

Thanks, @pinskia! Do you happen to know why GCC supports -fno-syntax-only?

No idea because the support of -fno-syntax-only dates before 1992.

[AaronBallman]

Thanks, @pinskia! Do you happen to know why GCC supports -fno-syntax-only?

No idea because the support of -fno-syntax-only dates before 1992.

Lost to the mists of time! Thank you for checking though. :-)

[surrealoatmeal]

The motivating example in my case is the following:

When scanning dependencies for C++20 modules in CMake, the clang-scan-deps call is hardcoded to inherit from the current CXXFLAGS.

https://github.com/Kitware/CMake/blob/64b35e8fcbb703ae3a6068985b1b88f98325686b/Modules/Compiler/Clang-CXX.cmake#L47

When running a -fsyntax-only static analysis pass through the codebase, the module discovery fails with:

$ clang-scan-deps -format=p1689 -- clang++ -std=c++23 -fsyntax-only -x c++ /tmp/demo/add.cpp -c -o CMakeFiles/main.dir/add.cpp.o -resource-dir "/nix/store/l0wiwralq6jv917lv2s9dm05lcligf3p-clang-wrapper-19.1.7/resource-root" -MT CMakeFiles/main.dir/add.cpp.o.ddi -MD -MF CMakeFiles/main.dir/add.cpp.o.ddi.d

Exactly one output file is required in the per-file mode ('--').

I am unsure if scanning could actually not be supported when the driver is invoked with -fsyntax-only (as the output file is really required as reported) or there is a feature improvement possibility in the scanner here. Regardless, splicing in a -fno-syntax-only after <FLAGS> would compile only the module related source files (making the overall -fsyntax-only still meaningful) and remedy this case. This approach does work for GCC, but because of the missing flag, not on Clang, hence the issue.

On a simpler albeit hypothetical note: This flag can also be used to selectively exclude source files from a target-wide -fsyntax-only via source file properties. As one does not get to first inherit then modify target-wide properties on a source file and only append to them, this would be the only way of achieving the above (to my knowledge).

The general idea is to allow disabling -fsyntax-only later down in a command line invocation where one does not have explicit control of the former flags. I thought this overriding behavior that can be agnostic towards its preceding flags was the main motivator behind the -fno/ -Wno etc. paradigm.

[AaronBallman]

Thank you for the explanation, that's helpful perspective!

CC @Bigcheese @ChuanqiXu9 about whether there's anything to be done to clang-scan-deps and for more opinions.