aboutsummaryrefslogtreecommitdiff
path: root/clang/unittests/Frontend/CompilerInvocationTest.cpp
AgeCommit message (Collapse)AuthorFilesLines
2025-05-22Reapply "[clang] Remove intrusive reference count from `DiagnosticOptions` ↵Jan Svoboda1-1/+2
(#139584)" This reverts commit e2a885537f11f8d9ced1c80c2c90069ab5adeb1d. Build failures were fixed right away and reverting the original commit without the fixes breaks the build again.
2025-05-22Revert "[clang] Remove intrusive reference count from `DiagnosticOptions` ↵Kazu Hirata1-2/+1
(#139584)" This reverts commit 9e306ad4600c4d3392c194a8be88919ee758425c. Multiple builtbot failures have been reported: https://github.com/llvm/llvm-project/pull/139584
2025-05-22[clang] Remove intrusive reference count from `DiagnosticOptions` (#139584)Jan Svoboda1-1/+2
The `DiagnosticOptions` class is currently intrusively reference-counted, which makes reasoning about its lifetime very difficult in some cases. For example, `CompilerInvocation` owns the `DiagnosticOptions` instance (wrapped in `llvm::IntrusiveRefCntPtr`) and only exposes an accessor returning `DiagnosticOptions &`. One would think this gives `CompilerInvocation` exclusive ownership of the object, but that's not the case: ```c++ void shareOwnership(CompilerInvocation &CI) { llvm::IntrusiveRefCntPtr<DiagnosticOptions> CoOwner = &CI.getDiagnosticOptions(); // ... } ``` This is a perfectly valid pattern that is being actually used in the codebase. I would like to ensure the ownership of `DiagnosticOptions` by `CompilerInvocation` is guaranteed to be exclusive. This can be leveraged for a copy-on-write optimization later on. This PR changes usages of `DiagnosticOptions` across `clang`, `clang-tools-extra` and `lldb` to not be intrusively reference-counted.
2024-12-13[clang] Fix use of dangling ptr in CommandLineTest (#119798)macurtis-amd1-3/+5
If 'GeneratedArgsStorage' ever grows, contained strings may get copied and data pointers stored in 'GeneratedArgs' may become invalid, pointing to deallocated memory.
2024-11-21Reapply "[NFC] Explicitly pass a VFS when creating DiagnosticsEngine (#115852)"Kadir Cetinkaya1-3/+4
This reverts commit a1153cd6fedd4c906a9840987934ca4712e34cb2 with fixes to lldb breakages. Fixes https://github.com/llvm/llvm-project/issues/117145.
2024-11-21Revert "[NFC] Explicitly pass a VFS when creating DiagnosticsEngine (#115852)"Sylvestre Ledru1-4/+3
Reverted for causing: https://github.com/llvm/llvm-project/issues/117145 This reverts commit bdd10d9d249bd1c2a45e3de56a5accd97e953458.
2024-11-21[NFC] Explicitly pass a VFS when creating DiagnosticsEngine (#115852)kadir çetinkaya1-3/+4
Starting with 41e3919ded78d8870f7c95e9181c7f7e29aa3cc4 DiagnosticsEngine creation might perform IO. It was implicitly defaulting to getRealFileSystem. This patch makes it explicit by pushing the decision making to callers. It uses ambient VFS if one is available, and keeps using `getRealFileSystem` if there aren't any VFS.
2024-11-13Reapply "[clang] Introduce diagnostics suppression mappings (#112517)"Kadir Cetinkaya1-0/+11
This reverts commit 5f140ba54794fe6ca379362b133eb27780e363d7.
2024-11-12Revert "[clang] Introduce diagnostics suppression mappings (#112517)"Kadir Cetinkaya1-11/+0
This reverts commit 12e3ed8de8c6063b15916b3faf67c8c9cd17df1f. This reverts commit 41e3919ded78d8870f7c95e9181c7f7e29aa3cc4. There are some buildbot breakages in https://lab.llvm.org/buildbot/#/builders/18/builds/6832.
2024-11-12[clang] Introduce diagnostics suppression mappings (#112517)kadir çetinkaya1-0/+11
This implements https://discourse.llvm.org/t/rfc-add-support-for-controlling-diagnostics-severities-at-file-level-granularity-through-command-line/81292. Users now can suppress warnings for certain headers by providing a mapping with globs, a sample file looks like: ``` [unused] src:* src:*clang/*=emit ``` This will suppress warnings from `-Wunused` group in all files that aren't under `clang/` directory. This mapping file can be passed to clang via `--warning-suppression-mappings=foo.txt`. At a high level, mapping file is stored in DiagnosticOptions and then processed with rest of the warning flags when creating a DiagnosticsEngine. This is a functor that uses SpecialCaseLists underneath to match against globs coming from the mappings file. This implies processing warning options now performs IO, relevant interfaces are updated to take in a VFS, falling back to RealFileSystem when one is not available.
2023-09-07[clang] Introduce copy-on-write `CompilerInvocation` (#65412)Jan Svoboda1-0/+40
This PR introduces new copy-on-write `CompilerInvocation` class (`CowCompilerInvocation`), which will be used by the dependency scanner to reduce the number of copies performed when generating command lines for discovered modules.
2023-09-05[clang] NFCI: Change returned AnalyzerOptions smart pointer to referenceJan Svoboda1-8/+8
2023-09-05[clang] NFCI: Change returned LanguageOptions pointer to referenceJan Svoboda1-42/+42
2023-02-10[NFC][TargetParser] Replace uses of llvm/Support/Host.hArchibald Elliott1-1/+1
The forwarding header is left in place because of its use in `polly/lib/External/isl/interface/extract_interface.cc`, but I have added a GCC warning about the fact it is deprecated, because it is used in `isl` from where it is included by Polly.
2022-10-14Remove redundant option -menable-unsafe-fp-math.Zahira Ammarguellat1-9/+12
There are currently two options that are used to tell the compiler to perform unsafe floating-point optimizations: '-ffast-math' and '-funsafe-math-optimizations'. '-ffast-math' is enabled by default. It automatically enables the driver option '-menable-unsafe-fp-math'. Below is a table illustrating the special operations enabled automatically by '-ffast-math', '-funsafe-math-optimizations' and '-menable-unsafe-fp-math' respectively. Special Operations -ffast-math -funsafe-math-optimizations -menable-unsafe-fp-math MathErrno 0 1 1 FiniteMathOnly 1 0 0 AllowFPReassoc 1 1 1 NoSignedZero 1 1 1 AllowRecip 1 1 1 ApproxFunc 1 1 1 RoundingMath 0 0 0 UnsafeFPMath 1 0 1 FPContract fast on on '-ffast-math' enables '-fno-math-errno', '-ffinite-math-only', '-funsafe-math-optimzations' and sets 'FpContract' to 'fast'. The driver option '-menable-unsafe-fp-math' enables the same special options than '-funsafe-math-optimizations'. This is redundant. We propose to remove the driver option '-menable-unsafe-fp-math' and use instead, the setting of the special operations to set the function attribute 'unsafe-fp-math'. This attribute will be enabled only if those special operations are enabled and if 'FPContract' is either 'fast' or set to the default value. Differential Revision: https://reviews.llvm.org/D135097
2022-07-29Fix lack of cc1 flag in llvmcmd sections when assertions are enabledAiden Grossman1-0/+21
Currently when assertions are enabled, the cc1 flag is not inserted into the llvmcmd section of object files with embedded bitcode. This deviates from the normal behavior where this is the first flag that is inserted. This error stems from incorrect use of the function generateCC1CommandLine() which requires manually adding in the -cc1 flag which is currently not done. Reviewed By: jansvoboda11 Differential Revision: https://reviews.llvm.org/D130620
2022-04-11[test][clang] Use -clear-ast-before-backend instead of -flegacy-pass-manager ↵Arthur Eubanks1-11/+11
in CommandLineTest
2022-04-06[cmake] Remove LLVM_ENABLE_NEW_PASS_MANAGER cmake optionNikita Popov1-22/+11
Or rather, error out if it is set to something other than ON. This removes the ability to enable the legacy pass manager by default, but does not remove the ability to explicitly enable it through various flags like -flegacy-pass-manager or -enable-new-pm=0. I checked, and our test suite definitely doesn't pass with LLVM_ENABLE_NEW_PASS_MANAGER=OFF anymore. Differential Revision: https://reviews.llvm.org/D123126
2021-09-03[modules] Use `HashBuilder` and `MD5` for the module hash.Alexandre Rames1-3/+1
Per the comments, `hash_code` values "are not stable to save or persist", so are unsuitable for the module hash, which must persist across compilations for the implicit module hashes to match. Note that in practice, today, `hash_code` are stable. But this is an implementation detail, with a clear `FIXME` indicating we should switch to a per-execution seed. The stability of `MD5` also allows modules cross-compilation use-cases. The `size_t` underlying storage for `hash_code` varying across platforms could cause mismatching hashes when cross-compiling from a 64bit target to a 32bit target. Note that native endianness is still used for the hash computation. So hashes will differ between platforms of different endianness. Reviewed By: jansvoboda11 Differential Revision: https://reviews.llvm.org/D102943
2021-05-18Introduce SYCL 2020 modeAaron Ballman1-3/+87
Currently, we have support for SYCL 1.2.1 (also known as SYCL 2017). This patch introduces the start of support for SYCL 2020 mode, which is the latest SYCL standard available at (https://www.khronos.org/registry/SYCL/specs/sycl-2020/html/sycl-2020.html). This sets the default SYCL to be 2020 in the driver, and introduces the notion of a "default" version (set to 2020) when cc1 is in SYCL mode but there was no explicit -sycl-std= specified on the command line.
2021-04-19[clang] Implement CompilerInvocation copy assignmentJan Svoboda1-1/+12
This patch implements the copy assignment for `CompilerInvocation`. Eventually, the deep-copy operation will be moved into a `clone()` method (D100460), but until then, this is necessary for basic ergonomics. Depends on D100455. Reviewed By: Bigcheese Differential Revision: https://reviews.llvm.org/D100473
2021-04-14[clang] Fix copy constructor of CompilerInvocationJan Svoboda1-0/+12
The `CompilerInvocationBase` class factors out members of `CompilerInvocation` that need special handling (initialization or copy constructor), so that `CompilerInvocation` can be implemented as a simple value object. Currently, the `AnalyzerOpts` member of `CompilerInvocation` violates that setup. This patch extracts the member to `CompilerInvocationBase` and handles it in the copy constructor the same way other it handles other members. Reviewed By: dexonsmith Differential Revision: https://reviews.llvm.org/D99568
2021-04-06[clang][cli] Ensure plugin args are generated in deterministic orderJan Svoboda1-0/+11
The '-plugin-arg' command-line arguments are not being generated in deterministic order. This patch changes the storage from `std::unordered_map` to `std::map` to enforce ordering. Reviewed By: dexonsmith Differential Revision: https://reviews.llvm.org/D99879
2021-03-17[SYCL] Rework the SYCL driver optionsAaron Ballman1-9/+10
SYCL compilations initiated by the driver will spawn off one or more frontend compilation jobs (one for device and one for host). This patch reworks the driver options to make upstreaming this from the downstream SYCL fork easier. This patch introduces a language option to identify host executions (SYCLIsHost) and a -cc1 frontend option to enable this mode. -fsycl and -fno-sycl become driver-only options that are rejected when passed to -cc1. This is because the frontend and beyond should be looking at whether the user is doing a device or host compilation specifically. Because the frontend should only ever be in one mode or the other, -fsycl-is-device and -fsycl-is-host are mutually exclusive options.
2021-03-05[clang][modules] Use extensible RTTI for ModuleFileExtensionJan Svoboda1-0/+53
Clang exposes an interface for extending the PCM/PCH file format: `ModuleFileExtension`. Clang itself has only a single implementation of the interface: `TestModuleFileExtension` that can be instantiated via the `-ftest-module-file_extension=` command line argument (and is stored in `FrontendOptions::ModuleFileExtensions`). Clients of the Clang library can extend the PCM/PCH file format by pushing an instance of their extension class to the `FrontendOptions::ModuleFileExtensions` vector. When generating the `-ftest-module-file_extension=` command line argument from `FrontendOptions`, a downcast is used to distinguish between the Clang's testing extension and other (client) extensions. This functionality is enabled by LLVM-style RTTI. However, this style of RTTI is hard to extend, as it requires patching Clang (adding new case to the `ModuleFileExtensionKind` enum). This patch switches to the LLVM RTTI for open class hierarchies, which allows libClang users (e.g. Swift) to create implementations of `ModuleFileExtension` without patching Clang. (Documentation of the feature: https://llvm.org/docs/HowToSetUpLLVMStyleRTTI.html#rtti-for-open-class-hierarchies) Reviewed By: artemcm Differential Revision: https://reviews.llvm.org/D97702
2021-02-16[clang][cli] Add explicit round-trip testJan Svoboda1-0/+83
This patch adds a test that verifies all `CompilerInvocation` members are filled correctly during command line round-trip. Reviewed By: dexonsmith Differential Revision: https://reviews.llvm.org/D96705
2021-01-26[clang][cli] Store LangStandard::Kind in LangOptionsJan Svoboda1-0/+45
The `LangStandard::Kind` parsed from command line arguments is used to set up some `LangOption` defaults, but isn't stored anywhere. To be able to generate `-std=` (in future patch), we need `CompilerInvocation` to not forget it. This patch demonstrates another use-case: using `LangStd` to set up defaults of marshalled options. Reviewed By: dexonsmith Differential Revision: https://reviews.llvm.org/D95342
2021-01-11Reapply "[clang][cli] Port DiagnosticOpts to new option parsing system"Jan Svoboda1-0/+15
This reverts commit 8e3e148c This commit fixes two issues with the original patch: * The sanitizer build bot reported an uninitialized value. This was caused by normalizeStringIntegral not returning None on failure. * Some build bots complained about inaccessible keypaths. To mitigate that, "this->" was added back to the keypath to restore the previous behavior.
2021-01-08Revert "[clang][cli] Port DiagnosticOpts to new option parsing system"Jan Svoboda1-15/+0
This reverts commit 8e3230ff
2021-01-08[clang][cli] Port DiagnosticOpts to new option parsing systemJan Svoboda1-0/+15
This patch introduces additional infrastructure necessary to accommodate DiagnosticOptions. DiagnosticOptions are unique in that they are parsed by the same function in cc1 AND in the Clang driver. The call to the parsing function from the driver occurs early on in the compilation process, where no proper DiagnosticEngine exists, because the diagnostic options (passed through command line) are not known yet. To preserve the current behavior, we need to be able to selectively parse: * all options (for -cc1), * only diagnostic options (for driver). This patch achieves that in the following way: * new MacroPrefix field is added to the Option TableGen class, * new IsDiag TableGen mixin sets MacroPrefix to "DIAG_", * TableGen backend serializes option records into a macro with the prefix, * CompilerInvocation parse/generate methods define the [DIAG_]OPTION_WITH_MARSHALLING macros to handle diagnostic options separately. Depends on D93700, D93701 & D93702. Reviewed By: dexonsmith Differential Revision: https://reviews.llvm.org/D84673
2021-01-07[clang][cli] Report the actual argument parsing resultJan Svoboda1-99/+40
Reviewed By: Bigcheese Differential Revision: https://reviews.llvm.org/D93700
2021-01-07[clang][cli] Port a CommaJoined option to the marshalling infrastructureJan Svoboda1-0/+47
Reviewed By: dexonsmith Differential Revision: https://reviews.llvm.org/D93698
2021-01-07Reapply "[clang][cli] Allow users to specify a conditional to prevent ↵Jan Svoboda1-0/+62
parsing options with MarshallingInfo" This reverts commit d0fa7a05 and fixes failing OptionMarshallingTest by adding the SHOULD_PARSE macro argument
2021-01-07Revert "[clang][cli] Allow users to specify a conditional to prevent parsing ↵Jan Svoboda1-62/+0
options with MarshallingInfo" This reverts commit 77db83ae
2021-01-07[clang][cli] Implement ContainsN Google Test matcherJan Svoboda1-5/+65
This allows us to verify that we don't emit options multiple times. In most cases, that would be benign, but for options with `MarshallingInfoVectorString`, emitting wrong number of arguments might change the semantics. Reviewed By: Bigcheese Differential Revision: https://reviews.llvm.org/D93636
2021-01-07[clang][cli] Allow users to specify a conditional to prevent parsing options ↵Jan Svoboda1-0/+62
with MarshallingInfo Depends on D84189 & D93540. Reviewed By: Bigcheese Differential Revision: https://reviews.llvm.org/D84674
2021-01-06Reapply multiple "[clang][cli]" patchesJan Svoboda1-2/+82
This reverts 7ad666798f12 and 1876a2914fe0 that reverted: 741978d727a4 [clang][cli] Port CodeGen option flags to new option parsing system 383778e2171b [clang][cli] Port LangOpts option flags to new option parsing system aec2991d083a [clang][cli] Port LangOpts simple string based options to new option parsing system 95d3cc67caac [clang][cli] Port CodeGenOpts simple string flags to new option parsing system 27b7d646886d [clang][cli] Streamline MarshallingInfoFlag description 70410a264949 [clang][cli] Let denormalizer decide how to render the option based on the option class 63a24816f561 [clang][cli] Implement `getAllArgValues` marshalling Commit 741978d727a4 accidentally changed the `Group` attribute of `g[no_]column_info` options from `g_flags_Group` to `g_Group`, which changed the debug info options passed to cc1 by the driver. Similar change was also present in 383778e2171b, which accidentally added `Group<f_Group>` to `f[no_]const_strings` and `f[no_]signed_wchar`. This patch corrects all three accidental changes by replacing `Bool{G,F}Option` with `BoolCC1Option`.
2021-01-05[clang][cli] Specify correct integer width for -fbuild-session-timestampJan Svoboda1-0/+12
This fixes an issue where large integer values were rejected as invalid. Reviewed By: arphaman Differential Revision: https://reviews.llvm.org/D94101
2020-12-23Revert more changes that landed on top of 741978d727Nico Weber1-82/+2
This should've been in 7ad666798f12456d9 but wasn't. Squashes these twoc commits: Revert "[clang][cli] Let denormalizer decide how to render the option based on the option class" This reverts commit 70410a264949101ced3ce3458f37dd4cc2f5af85. Revert "[clang][cli] Implement `getAllArgValues` marshalling" This reverts commit 63a24816f561a5d8e28ca7054892bd8602618be4.
2020-12-22[clang][cli] Implement `getAllArgValues` marshallingJan Svoboda1-0/+40
This infrastructure can be used ~30 more command line options. Reviewed By: dexonsmith Differential Revision: https://reviews.llvm.org/D93631
2020-12-21[clang][cli] Let denormalizer decide how to render the option based on the ↵Jan Svoboda1-2/+42
option class Before this patch, you needed to use `AutoNormalizeEnumJoined` whenever you wanted to **de**normalize joined enum. Besides the naming confusion, this means the fact the option is joined is specified in two places: in the normalization multiclass and in the `Joined<["-"], ...>` multiclass. This patch makes this work automatically, taking into account the `OptionClass` of options. Also, the enum denormalizer now just looks up the spelling of the present enum case in a table and forwards it to the string denormalizer. I also added more tests that exercise this. Reviewed By: dexonsmith Original patch by Daniel Grumberg. Differential Revision: https://reviews.llvm.org/D84189
2020-12-16[clang][cli] Prevent double denormalizationJan Svoboda1-1/+1
If both flags created through BoolOption are CC1Option and the keypath has a non-default or non-implied value, the denormalizer gets called twice. If the denormalizer has the ability to generate both flags, we can end up generating the same flag twice. Reviewed By: dexonsmith, Bigcheese Differential Revision: https://reviews.llvm.org/D93094
2020-12-16[clang][cli] Do not marshall only CC1Option flags in BoolOptionJan Svoboda1-0/+49
We cannot be sure whether a flag is CC1Option inside the definition of `BoolOption`. Take the example below: ``` let Flags = [CC1Option] in { defm xxx : BoolOption<...>; } ``` where TableGen applies `Flags = [CC1Option]` to the `xxx` and `no_xxx` records **after** they have been is fully declared by `BoolOption`. For the refactored `-f[no-]debug-pass-manager` flags (see the diff), this means `BoolOption` never adds any marshalling info, as it doesn't see either of the flags as `CC1Option`. For that reason, we should defensively append the marshalling information to both flags inside `BoolOption`. Now the check for `CC1Option` needs to happen later, in the parsing macro, when all TableGen logic has been resolved. However, for some flags defined through `BoolOption`, we can run into issues: ``` // Options.td def fenable_xxx : /* ... */; // Both flags are CC1Option, the first is implied. defm xxx : BoolOption<"xxx, "Opts.Xxx", DefaultsToFalse, ChangedBy<PosFlag, [CC1Option], "", [fenable_xxx]>, ResetBy<NegFlag, [CC1Option]>>; ``` When parsing `clang -cc1 -fenable-xxx`: * we run parsing for `PosFlag`: * set `Opts.Xxx` to default `false`, * discover `PosFlag` is implied by `-fenable-xxx`: set `Opts.Xxx` to `true`, * don't see `-fxxx` on command line: do nothing, * we run parsing for `NegFlag`: * set `Opts.Xxx` to default `false`, * discover `NegFlag` cannot be implied: do nothing, * don't see `-fno-xxx` on command line: do nothing. Now we ended up with `Opts.Xxx` set to `false` instead of `true`. For this reason, we need to ensure to append the same `ImpliedByAnyOf` instance to both flags. This means both parsing runs now behave identically (they set the same default value, run the same "implied by" check, and call `makeBooleanOptionNormalizer` that already has information on both flags, so it returns the same value in both calls). The solution works well, but what might be confusing is this: you have defined a flag **A** that is not `CC1Option`, but can be implied by another flag **B** that is `CC1Option`: * if **A** is defined manually, it will never get implied, as the code never runs ``` def no_signed_zeros : Flag<["-"], "fno-signed-zeros">, Group<f_Group>, Flags<[]>, MarshallingInfoFlag<"LangOpts->NoSignedZero">, ImpliedByAnyOf<[menable_unsafe_fp_math]>; ``` * if **A** is defined by `BoolOption`, it could get implied, as the code is run by its `CC1Option` counterpart: ``` defm signed_zeros : BoolOption<"signed-zeros", "LangOpts->NoSignedZero", DefaultsToFalse, ChangedBy<NegFlag, [], "Allow optimizations that ignore the sign of floating point zeros", [cl_no_signed_zeros, menable_unsafe_fp_math]>, ResetBy<PosFlag, [CC1Option]>, "f">, Group<f_Group>; ``` This is a surprising inconsistency. One solution might be to somehow propagate the final `Flags` of the implied flag in `ImpliedByAnyOf` and check whether it has `CC1Option` in the parsing macro. However, I think it doesn't make sense to spend time thinking about a corner case that won't come up in real code. An observation: it is unfortunate that the marshalling information is a part of the flag definition. If we represented it in a separate structure, we could avoid the "double parsing" problem by having a single source of truth. This would require a lot of additional work though. Note: the original patch missed the `CC1Option` check in the parsing macro, making my reasoning here incomplete. Moreover, it contained a change to denormalization that wasn't necessarily related to these changes, so I've extracted that to a follow-up patch: D93094. Reviewed By: dexonsmith, Bigcheese Differential Revision: https://reviews.llvm.org/D93008
2020-12-12[clang][cli] Add flexible TableGen multiclass for boolean optionsJan Svoboda1-6/+18
This introduces more flexible multiclass for declaring two flags controlling the same boolean keypath. Compared to existing Opt{In,Out}FFlag multiclasses, the new syntax makes it easier to read option declarations and reason about the keypath. This also makes specifying common properties of both flags possible. I'm open to suggestions on the class names. Not 100% sure the benefits are worth the added complexity. Depends on D92774. Reviewed By: dexonsmith Differential Revision: https://reviews.llvm.org/D92775
2020-12-12[clang][cli] Don't always emit -f[no-]legacy-pass-managerJan Svoboda1-2/+2
We don't need to always generate `-f[no-]experimental-new-pass-manager`. This patch does not change the behavior of any other command line flag. (For example `-triple` is still being always generated.) Reviewed By: dexonsmith, Bigcheese Differential Revision: https://reviews.llvm.org/D92857
2020-12-12Reland "[clang][cli] CompilerInvocationTest: add tests for boolean options"Jan Svoboda1-0/+149
Add more tests of the command line marshalling infrastructure. The new tests now make a "round-trip": from arguments, to CompilerInvocation instance to arguments again in a single test case. The TODOs are resolved in a follow-up patch. Depends on D92830. Reviewed By: dexonsmith Differential Revision: https://reviews.llvm.org/D92774
2020-12-09Revert "[clang][cli] CompilerInvocationTest: add tests for boolean options"Jan Svoboda1-144/+0
Differential Revision of original patch: https://reviews.llvm.org/D92774
2020-12-09[clang][cli] CompilerInvocationTest: add tests for boolean optionsJan Svoboda1-0/+144
Add more tests of the command line marshalling infrastructure. The new tests now make a "round-trip": from arguments, to CompilerInvocation instance to arguments again in a single test case. The TODOs are resolved in a follow-up patch. Depends on D92830. Reviewed By: dexonsmith Differential Revision: https://reviews.llvm.org/D92774
2020-12-09[clang][cli] CompilerInvocationTest: join and add test casesJan Svoboda1-47/+74
Depends on D92829. Reviewed By: dexonsmith Differential Revision: https://reviews.llvm.org/D92830
2020-12-09[clang][cli] CompilerInvocationTest: check arg parsing does not produce ↵Jan Svoboda1-1/+34
diagnostics Depends on D92828. Reviewed By: dexonsmith Differential Revision: https://reviews.llvm.org/D92829