summaryrefslogtreecommitdiffstats
path: root/Modules/Compiler/Clang-C.cmake
Commit message (Collapse)AuthorAgeFilesLines
* Clang: use -std=c23 for Clang 18+Raul Tambre2023-08-151-1/+4
| | | | Canonical flag changed in LLVM commit 13629b140801870feff855ca168edf6b34dbef8d.
* IWYU: Add `--driver-mode=cl` when applicablePigeonF2021-09-101-0/+1
| | | | | | We already do this for `clang-tidy`. Fixes: #16554
* Clang: Default C standard doesn't depend on compatibility modeRaul Tambre2021-02-251-5/+1
| | | | MSVC compatibility mode doesn't affect the default standard.
* Clang: Set standard flags according to frontend variantRaul Tambre2021-02-251-1/+1
| | | | | | They depend on the frontend not which compiler we're simulating. Fixes #21771.
* Clang: MSVC-style C flagsRaul Tambre2021-02-251-4/+14
| | | | | Support added in LLVM commit d087d805acb664e885e9c31a916f6cfa5dbc2186, will be released in Clang 13.
* Clang: C23 supportRaul Tambre2021-02-251-0/+5
| | | | | Added in LLVM commit d06f3917913d2558b771ccc48d838f8cd8993c01, released in Clang 9.0.
* Clang: C17 default versionRaul Tambre2021-02-251-1/+1
| | | | | | | Switched in LLVM commit 91cdbd521a38495c66e30636943563ca70d3c022, released in Clang 11. Issue: #17755
* Clang: C17 supportRaul Tambre2021-02-251-0/+7
| | | | | | | Added in LLVM commit 5b6c0f75e01571851b767dc63a3229c962f464f1, available since Clang 6. Issue: #17755
* Clang: Correct default C standards for ancient versionsRaul Tambre2021-02-251-1/+1
| | | | | | | | C11 was made default in LLVM commit ab506adf7d3ced6abcaf42f92de3d6cd15fa19e8, released in 3.5.2. C99 was made default in LLVM commit 17f76e04d244c80e70f1c81c94d4524b53d9772d, released in 2.1. It was flipped a few times between C89 and C99 during the 2.1 cycle, but the C89 default never made it into a release.
* Clang: Correct C standards flags for ancient versionsRaul Tambre2021-02-251-15/+22
| | | | | | | | | | | | | C89, C99 flags in LLVM commit ff43821d5380ee38aff421701f1d461242b524ee. C90 flag in LLVM commit 229ce60fc9983df5f7e83e25fa6b5c0ca4d2b135. C1x flag in LLVM commit a686b5f8bf7b5a2ab636c0c2de5ad4c174aa33e0. C11 flag in LLVM commit 6784aeb9ef96e5735850fa7226ed0cb45cb82e75. Mark C90, C99 full support since 2.1. Might've been possibly a little later, but source spelunking that much back is difficult. Mark C11 full support since 3.0, which added _Static_assert in LLVM commit 3d9cbdc3e66e274d5d3cb94ce81a65478d9baae0.
* Clang: C flags cleanupRaul Tambre2021-02-251-6/+4
| | | | Don't need to set the options to empty strings if not supported.
* Compile with explicit language flag when source LANGUAGE property is setBrad King2020-12-021-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | This change was originally made by commit 74b1c9fc8e (Explicitly specify language flag when source LANGUAGE property is set, 2020-06-01, v3.19.0-rc1~722^2), but it was reverted by commit 30aa715fac (Revert "specify language flag when source LANGUAGE property is set", 2020-11-19) to restore compatibility with pre-3.19 behavior. Implement the change again, but add policy CMP0119 to make this change while preserving compatibility with existing projects. Note that the `Compiler/{Clang,Intel,MSVC}-CXX` modules do not need to specify `-TP` for their MSVC-like variants because we already use the flag in `CMAKE_CXX_COMPILE_OBJECT`. Similarly for `Compiler/XL-CXX` and `Platform/Windows-Embarcadero`. Note also that this does not seem possible to implement for XL C. Even with `-qsourcetype=c`, `xlc` complains about an unknown suffix: `1501-218 (W) file /.../AltExtC.zzz contains an incorrect file suffix`. It returns non-zero even with `-qsuppress=1501-218`. Co-Author: Robert Maynard <robert.maynard@kitware.com> Fixes: #14516, #20716
* Makefiles Generators: use compiler for dependencies generationMarc Chevrier2020-11-291-0/+13
| | | | | | | | | | | Each source compilation generates a dependencies file. These dependencies files are consolidated in one file per target. This consolidation is done as part of command 'cmake -E cmake_depends` launched before evaluation of makefile dependency graph. The consolidation uses the same approach as `CMake` dependencies management. Fixes: #21321
* Revert "specify language flag when source LANGUAGE property is set"Brad King2020-11-191-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | Revert commit 74b1c9fc8e (Explicitly specify language flag when source LANGUAGE property is set, 2020-06-01, v3.19.0-rc1~722^2) and the lookup tables from its two immediate ancestors. The purpose of that change was to convert an explicit `LANGUAGE` source file property into an explicit language specification compiler flag like `-x c`. This seems reasonable since the property is documented as meaning "indicate what programming language the source file is". It is also needed to help compilers deal with non-standard source file extensions they don't recognize. However, some projects have been setting `LANGUAGE C` on `.S` assembler source files to mean "use the C compiler". Passing `-x c` for them breaks the build because the `.S` sources are not written in C. These projects should be updated to use `enable_language(ASM)`, for which CMake often chooses the C compiler as the assembler when using toolchains that support it (which would have to be the case for projects using the approach). Revert the change for now to preserve the old behavior for such projects. We can re-introduce it with a policy in a future version of CMake. Fixes: #21469 Issue: #14516, #20716
* C: Compile when possible with explicit `C` language flag setRobert Maynard2020-06-091-0/+2
| | | | Issue: #14516, #20716
* clang-tidy: Add driver mode argumentHanjiang Yu2020-01-271-0/+4
| | | | | | | `clang-tidy` does not infer driver mode if it is not provided with a JSON compilation database. This is exactly the way cmake launches it. Hence clang-tidy will only use the default driver mode. Add an explicit driver mode argument to avoid this.
* CompileFeatures: Record which C features the MSVC compiler supportsRobert Maynard2019-04-121-0/+3
| | | | | | Use the infrastructure added by commit f92ccbc306c20554af (CompileFeatures: memoize C compilers with full language level support) to avoid using a `try_compile` to check for C 90/99/11 feature support when the running compiler is known to have a fixed set of feature support.
* Record when C compilers have gained full support for 90,99,11Robert Maynard2019-03-271-0/+3
|
* Record C compile features flags for MinGW Clang on WindowsBrad King2017-11-011-1/+1
| | | | | | | | | | | | | | This was done for C++ by commit v3.5.0-rc1~69^2 (Record compile features for MinGW Clang on Windows, 2016-01-11). Make the same change for C. The `UNIX` condition on Clang C compiler features was already dropped by refactoring in commit v3.9.0-rc1~17^2~4 (Compilers: Port to use default cmake_record_lang_compile_features macros, 2017-05-10). Our documentation already claims support for this combination. This was simply an oversight when support was added for MinGW Clang C++. Issue: #15897 Issue: #15943
* Clang: Do not add '-std=' options when simulating MSVCRuben Van Boxem2017-06-271-7/+23
| | | | | | | The `cl.exe` style command line does not accept the `-std=` options. Instead behave like MSVC where we don't define standard levels. Fixes: #16266
* Compilers: Port to use default cmake_record_lang_compile_features macrosChuck Atkins2017-05-301-15/+0
|
* Clang: Use common compiler macros for language standard defaultChuck Atkins2017-05-021-15/+1
|
* Features: Make feature recording conditions more consistentBrad King2016-12-021-1/+3
| | | | | | | | | Condition all calls to `_record_compiler_features_{c,cxx}` on `_result EQUAL 0` so that adding new language standards later does not need to update them. Avoid some duplicate compiler version checks by conditioning C11 and CXX14 feature recording on the existence of `CMAKE_{C11,CXX14}_STANDARD_COMPILE_OPTION` (whose setting already used the version check).
* Features: Centralize per-compiler recording macrosBrad King2016-11-021-7/+3
| | | | | Simplify and de-duplicate per-compiler feature recording macros and convert to a centralized per-language macro.
* Project: Guess default standard dialect if compiler was forced (#15852)Brad King2015-11-191-0/+7
| | | | | | | | | | | | | | | | | | | | | Prior to commit v3.4.0-rc1~71^2 (Project: Determine default language dialect for the compiler, 2015-09-15) we always guessed the default language standard dialect based on the compiler version. This was not reliable so that commit switched to computing the default language standard dialect while detecting the compiler id. When a toolchain file uses CMakeForceCompiler to set the compiler id then the detection does not occur. Therefore commit v3.4.0-rc1~54^2 (Project: Don't require computed default dialect if compiler was forced, 2015-09-22) made the lack of detection an error only if the compiler was not forced. However, this means that projects using CMakeForceCompiler no longer even get the guess that we had before so <LANG>_COMPILER does not work. Due to the sophistication of CMake's compiler detection logic projects should be ported away from using CMakeForceCompiler. In the meantime, restore a guess of the default language standard dialect when the compiler is forced.
* Project: Don't require computed default dialect if compiler was forced.Stephen Kelly2015-09-221-3/+5
| | | | | | | | | | | | | | | | Commit 7235334a (Project: Determine default language dialect for the compiler., 2015-09-15) introduced a mechanism to determine the default dialect used for the running compiler. If conditions in the <CompilerId>-<Lang>.cmake file are such that compile features for that version of the compiler should be supported, the _DEFAULT_STANDARD is set to the computed value. However, the CMakeForceCompiler module allows users to bypass execution of the compiler by CMake. In that case, do not set the _DEFAULT_STANDARD variable at all, which effectively disables the compile-features where the module is used. No compile features have ever been recorded where the module is used so no functionality is lost.
* Project: Determine default language dialect for the compiler.Stephen Kelly2015-09-181-4/+5
| | | | | | Use the __cplusplus and __STDC_VERSION__ macros to automatically determine the default dialect for the compiler while determining its id and version.
* Features: Ensure appropriate return value from feature test macros.Stephen Kelly2015-01-151-2/+1
| | | | | | | GNU-CXX already has complex logic and sets the _result to 0 before tests which may set it to something else. Change the other modules to be consistent with that.
* Merge branch 'default-lang-dialect' into step2Stephen Kelly2014-11-201-3/+7
|\ | | | | | | | | Conflicts: Modules/Compiler/Clang-C.cmake
| * Features: Fix the default C dialect for Clang and GNU.Stephen Kelly2014-11-201-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Clang 3.4 uses C99 by default, and Clang 3.6 uses C11 by default: http://thread.gmane.org/gmane.comp.compilers.clang.devel/39379 GNU 4.9 uses C90 by default, and GNU 5.0 uses C11 by default: https://gcc.gnu.org/gcc-5/changes.html Test that the default compiler settings result in the expected dialect macros being defined for both C and CXX. Remove the unused main.c file from the CompileFeatures unit test.
| * Features: Fix references to CXX compiler version in Clang-C.cmake.Stephen Kelly2014-11-181-2/+2
| |
* | Features: Use the correct dialect flag when recording features.Stephen Kelly2014-11-121-4/+4
|/ | | | | Avoid using -std=c++1y for compilers which support -std=c++14, for example.
* Features: Record for Clang 3.4Stephen Kelly2014-05-201-0/+36
| | | | Clang 3.4 supports all features currently known to CMake.
* Clang: Split Compiler/Clang* modules out from GNU (#13550)Brad King2012-09-191-1/+2
| | | | | | | While Clang presents an almost identical interface to GNU there will be some differences. Split the compiler information modules to allow separate rules for Clang. Start by loading the GNU rules but leave a place to add Clang-specific information.
* Recognize Clang C and C++ compilers (see #10693)Brad King2010-05-171-0/+1
Map to the platform and compiler information for GNU because the compilers are command-line compatible for common operations. Later we can add Clang-specific features as necessary. We honor the preferred capitalization is "Clang", not the common mis-spelling "CLang".