aboutsummaryrefslogtreecommitdiff
path: root/clang/include
AgeCommit message (Collapse)AuthorFilesLines
2022-09-15Downgrade implicit int and implicit function declaration to warning onlyAaron Ballman1-4/+4
The changes in Clang 15.0.0 which enabled these diagnostics as a warning which defaulted to an error caused disruption for people working on distributions such as Gentoo. There was an explicit request to downgrade these to be warning-only in Clang 15.0.1 with the expectation that Clang 16 will default the diagnostics to an error. See https://discourse.llvm.org/t/configure-script-breakage-with-the-new-werror-implicit-function-declaration/65213 for more details on the discussion. See https://reviews.llvm.org/D133800 for the public review of these changes.
2022-09-02[clang] Add __is_target_variant_{os,environment} builtinsNico Weber1-0/+2
Xcode 13's clang has them. For the included testcase, Xcode's clang behaves like the implementation in this patch. Availability.h in the macOS 12.0 SDK (part of Xcode 13, and the current stable version of the macOS SDK) does something like: #if defined(__has_builtin) ... #if __has_builtin(__is_target_os) #if __has_builtin(__is_target_environment) #if __has_builtin(__is_target_variant_os) #if __has_builtin(__is_target_variant_environment) #if (... && ((__is_target_os(ios) && __is_target_environment(macabi)) || (__is_target_variant_os(ios) && __is_target_variant_environment(macabi)))) #define __OSX_AVAILABLE_STARTING(_osx, _ios) ... #define __OSX_AVAILABLE_BUT_DEPRECATED(_osxIntro, _osxDep, _iosIntro, _iosDep) ... #define __OSX_AVAILABLE_BUT_DEPRECATED_MSG(_osxIntro, _osxDep, _iosIntro, _iosDep, _msg) ... So if __has_builtin(__is_target_variant_os) or __has_builtin(__is_target_variant_environment) are false, these defines are not defined. Most of the time, this doesn't matter. But open-source clang currently fails to commpile a file containing only `#include <Security/cssmtype.h>` when building for catalyst by adding a `-target arm64-apple-ios13.1-macabi` triple, due to those __OSX_AVAILABLE macros not being set correctly. If a potential future SDK version were to include cssmtype.h transitively from a common header such as `<Foundation/Foundation.h>`, then it would become close to impossible to build Catalyst binaries with open-source clang. To fix this for normal catalyst builds, it's only necessary that __has_builtin() evaluates to true for these two built-ins -- the implementation of them doesn't matter. But as a courtesy, a correct (at least on the test cases I tried) implementation is provided. (This should also help people who try to build zippered code, where having the correct implementation does matter.) Differential Revision: https://reviews.llvm.org/D132754
2022-09-01[Frontend] Restore Preprocessor::getPredefines()Roy Jacobson1-0/+5
https://reviews.llvm.org/rG6bbf51f3ed59ae37f0fec729f25af002111c9e74 from May removed Preprocessor::getPredefines() from Clang's API, presumably as a cleanup because this method is unused in the LLVM codebase. However, it was/is used by a small number of third-party tools and is pretty harmless, so this patch adds it back and documents why it's here. The issue was raised in https://github.com/llvm/llvm-project/issues/57483, it would be nice to be able to land it into Clang 15 as it breaks those third-party tools and we can't easily add it back in bug fix releases. Reviewed By: brad.king, thieta Differential Revision: https://reviews.llvm.org/D133044 (cherry picked from commit bb9dedce5d01f5608acd784942481f386c710c0d)
2022-08-12[clang] Require strict matches for defines for PCH in GCC style directoriesMartin Storsjö1-1/+2
When clang includes a PCH, it tolerates some amount of differences between the defines used when creating and when including the PCH - this seems to be intentionally allowed in c379c072405f39bca1d3552408fc0427328e8b6d (and later extended in b63687519610a73dd565be1fec28332211b4df5b). When using a PCH (or when picking a PCH out of a directory containing multiple candidates) Clang used to accept the header if there were defines on the command line when creating the PCH that are missing when using the PCH, or vice versa, defines only set when using the PCH. The only cases where Clang explicitly rejected the use of a PCH is if there was an explicit conflict between the options, e.g. -DFOO=1 vs -DFOO=2, or -DFOO vs -UFOO. The latter commit added a FIXME that we really should check whether mismatched defines actually were used somewhere in the PCH, so that the define would affect the outcome. This FIXME has stood unaddressed since 2012. This differs from GCC, which rejects PCH files if the defines differ at all. When explicitly including a single PCH file, the relaxed policy of allowing minor differences is harmless for correct use cases (but may fail to diagnose mismtaches), and potentially allow using PCHs in wider cases (where the user intentionally know that the differences in defines are harmless for the PCH). However, for GCC style PCH directories, with a directory containing multiple PCH variants and the compiler should pick the correct match out of them, Clang's relaxed logic was problematic. The directory could contain two otherwise identical PCHs, but one built with -DFOO and one without. When attempting to include a PCH and iterating over the candidates in the directory, Clang would essentially pick the first one out of the two, even if there existed a better, exact match in the directory. Keep the relaxed checking when specificlly including one named PCH file, but require strict matches when trying to pick the right candidate out of a GCC style directory with alternatives. This fixes https://github.com/lhmouse/mcfgthread/issues/63. Differential Revision: https://reviews.llvm.org/D126676 (cherry picked from commit c843c921a1a385bb805b2338d980436c94f83f19)
2022-08-08[C++20] [Modules] Merge same concept decls in global module fragmentChuanqi Xu2-0/+7
According to [basic.def.odr]p14, the same redeclarations in different TU but not attached to a named module are allowed. But we didn't take care of concept decl for this condition. This patch tries to fix this problem. Reviewed By: ilya-biryukov Differention Revision: https://reviews.llvm.org/D130614 (cherry picked from commit 4d9251bd780d20eebbcb124608b36a69787d5575)
2022-08-08[Sema] Return primary merged decl as canonical for conceptsIlya Biryukov1-2/+6
Otherwise we get invalid results for ODR checks. See changed test for an example: despite the fact that we merge the first concept, its **uses** were considered different by `Profile`, leading to redefinition errors. After this change, canonical decl for a concept can come from a different module and may not be visible. This behavior looks suspicious, but does not break any tests. We might want to add a mechanism to make the canonical concept declaration visible if we find code that relies on this invariant. Additionally make sure we always merge with the canonical declaration to avoid chains of merged concepts being reported as redefinitions. An example was added to the test. Also change the order of includes in the test. Importing a moduralized header before its textual part causes the include guard macro to be exported and the corresponding `#include` becomes a no-op. Reviewed By: ChuanqiXu Differential Revision: https://reviews.llvm.org/D130585 (cherry picked from commit 42f87bb62d0719848842da60d2a8180b9e4d7c52)
2022-07-27[clang][AIX] Add option to control quadword lock free atomics ABI on AIXKai Luo2-0/+5
We are supporting quadword lock free atomics on AIX. For the situation that users on AIX are using a libatomic that is lock-based for quadword types, we can't enable quadword lock free atomics by default on AIX in case user's new code and existing code accessing the same shared atomic quadword variable, we can't guarentee atomicity. So we need an option to enable quadword lock free atomics on AIX, thus we can build a quadword lock-free libatomic(also for advanced users considering atomic performance critical) for users to make the transition smooth. Reviewed By: shchenz Differential Revision: https://reviews.llvm.org/D127189
2022-07-26[CGDebugInfo] Access the current working directory from the `VFS`Argyrios Kyrtzidis1-1/+7
...instead of calling `llvm::sys::fs::current_path()` directly. Differential Revision: https://reviews.llvm.org/D130443
2022-07-26Revert "[clang-offload-bundler] Library-ize ClangOffloadBundler"Lambert, Jacob1-89/+0
This reverts commit 8348c4095600ec2c0beee293267832799d2ebee3.
2022-07-26[clang][dataflow] Analyze calls to in-TU functionsSam Estep3-2/+33
This patch adds initial support for context-sensitive analysis of simple functions whose definition is available in the translation unit, guarded by the `ContextSensitive` flag in the new `TransferOptions` struct. When this option is true, the `VisitCallExpr` case in the builtin transfer function has a fallthrough case which checks for a direct callee with a body. In that case, it constructs a CFG from that callee body, uses the new `pushCall` method on the `Environment` to make an environment to analyze the callee, and then calls `runDataflowAnalysis` with a `NoopAnalysis` (disabling context-sensitive analysis on that sub-analysis, to avoid problems with recursion). After the sub-analysis completes, the `Environment` from its exit block is simply assigned back to the environment at the callsite. The `pushCall` method (which currently only supports non-method functions with some restrictions) maps the `SourceLocation`s for all the parameters to the existing source locations for the corresponding arguments from the callsite. This patch adds a few tests to check that this context-sensitive analysis works on simple functions. More sophisticated functionality will be added later; the most important next step is to explicitly model context in some fields of the `DataflowAnalysisContext` class, as mentioned in a `FIXME` comment in the `pushCall` implementation. Reviewed By: ymandel, xazax.hun Differential Revision: https://reviews.llvm.org/D130306
2022-07-26Revert "[clang][dataflow] Analyze calls to in-TU functions"Sam Estep3-33/+2
This reverts commit fa2b83d07ecab3b24b4c5ee2e7dc4b6bbc895317.
2022-07-26[clang][dataflow] Analyze calls to in-TU functionsSam Estep3-2/+33
Depends On D130305 This patch adds initial support for context-sensitive analysis of simple functions whose definition is available in the translation unit, guarded by the `ContextSensitive` flag in the new `TransferOptions` struct. When this option is true, the `VisitCallExpr` case in the builtin transfer function has a fallthrough case which checks for a direct callee with a body. In that case, it constructs a CFG from that callee body, uses the new `pushCall` method on the `Environment` to make an environment to analyze the callee, and then calls `runDataflowAnalysis` with a `NoopAnalysis` (disabling context-sensitive analysis on that sub-analysis, to avoid problems with recursion). After the sub-analysis completes, the `Environment` from its exit block is simply assigned back to the environment at the callsite. The `pushCall` method (which currently only supports non-method functions with some restrictions) first calls `initGlobalVars`, then maps the `SourceLocation`s for all the parameters to the existing source locations for the corresponding arguments from the callsite. This patch adds a few tests to check that this context-sensitive analysis works on simple functions. More sophisticated functionality will be added later; the most important next step is to explicitly model context in some fields of the `DataflowAnalysisContext` class, as mentioned in a `TODO` comment in the `pushCall` implementation. Reviewed By: ymandel, xazax.hun Differential Revision: https://reviews.llvm.org/D130306
2022-07-26[clang-offload-bundler] Library-ize ClangOffloadBundlerJacob Lambert1-0/+89
Lifting the core functionalities of the clang-offload-bundler into a user-facing library/API. This will allow online and JIT compilers to bundle and unbundle files without spawning a new process. This patch lifts the classes and functions used to implement the clang-offload-bundler into a separate OffloadBundler.cpp, and defines three top-level API functions in OfflaodBundler.h. BundleFiles() UnbundleFiles() UnbundleArchives() This patch also introduces a Config class that locally stores the previously global cl::opt options and arrays to allow users to call the APIs in a multi-threaded context, and introduces an OffloadBundler class to encapsulate the top-level API functions. We also lift the BundlerExecutable variable, which is specific to the clang-offload-bundler tool, from the API, and replace its use with an ObjcopyPath variable. This variable must be set in order to internally call llvm-objcopy. Finally, we move the API files from clang/tools/clang-offload-bundler into clang/lib/Driver and clang/include/clang/Driver. Differential Revision: https://reviews.llvm.org/D129873
2022-07-26[C++20] [Modules] Disable preferred_name when writing a C++20 Module interfaceChuanqi Xu2-0/+10
Currently, the use of preferred_name would block implementing std modules in libcxx. See https://github.com/llvm/llvm-project/issues/56490 for example. The problem is pretty hard and it looks like we couldn't solve it in a short time. So we sent this patch as a workaround to avoid blocking us to modularize STL. This is intended to be fixed properly in the future. Reviewed By: erichkeane, aaron.ballman, tahonermann Differential Revision: https://reviews.llvm.org/D130331
2022-07-26[clang][dataflow] Add explicit "AST" nodes for implications and iffDmitri Gribenko2-4/+59
Previously we used to desugar implications and biconditionals into equivalent CNF/DNF as soon as possible. However, this desugaring makes debug output (Environment::dump()) less readable than it could be. Therefore, it makes sense to keep the sugared representation of a boolean formula, and desugar it in the solver. Reviewed By: sgatev, xazax.hun, wyt Differential Revision: https://reviews.llvm.org/D130519
2022-07-26[NFC] Fix some C++20 warningsEvgeny Mandrikov1-12/+12
Without this patch when using CMAKE_CXX_STANDARD=20 Microsoft compiler produces following warnings clang\include\clang/Basic/DiagnosticIDs.h(48): warning C5054: operator '+': deprecated between enumerations of different types clang\include\clang/Basic/DiagnosticIDs.h(49): warning C5054: operator '+': deprecated between enumerations of different types clang\include\clang/Basic/DiagnosticIDs.h(50): warning C5054: operator '+': deprecated between enumerations of different types clang\include\clang/Basic/DiagnosticIDs.h(51): warning C5054: operator '+': deprecated between enumerations of different types clang\include\clang/Basic/DiagnosticIDs.h(52): warning C5054: operator '+': deprecated between enumerations of different types clang\include\clang/Basic/DiagnosticIDs.h(53): warning C5054: operator '+': deprecated between enumerations of different types clang\include\clang/Basic/DiagnosticIDs.h(54): warning C5054: operator '+': deprecated between enumerations of different types clang\include\clang/Basic/DiagnosticIDs.h(55): warning C5054: operator '+': deprecated between enumerations of different types clang\include\clang/Basic/DiagnosticIDs.h(56): warning C5054: operator '+': deprecated between enumerations of different types clang\include\clang/Basic/DiagnosticIDs.h(57): warning C5054: operator '+': deprecated between enumerations of different types clang\include\clang/Basic/DiagnosticIDs.h(58): warning C5054: operator '+': deprecated between enumerations of different types clang\include\clang/Basic/DiagnosticIDs.h(59): warning C5054: operator '+': deprecated between enumerations of different types Patch By: Godin Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D130476
2022-07-26[Clang] [P2025] Analyze only potential scopes for NRVORoman Rusyaev1-19/+19
Before the patch we calculated the NRVO candidate looking at the variable's whole enclosing scope. The research in [P2025] shows that looking at the variable's potential scope is better and covers more cases where NRVO would be safe and desirable. Many thanks to @Izaron for the original implementation. Reviewed By: ChuanqiXu Differential Revision: https://reviews.llvm.org/D119792
2022-07-26[RISCV][Clang] Refactor RISCVVEmitter. (NFC)Zakk Chen1-6/+4
Remove MaskedPrototype and add several fields in RVVIntrinsicRecord, compute Prototype in runtime. Reviewed By: rogfer01 Differential Revision: https://reviews.llvm.org/D126741
2022-07-26[RISCV][Clang] Refactor and rename rvv intrinsic related stuff. (NFC)Zakk Chen2-49/+59
This changed is based on https://reviews.llvm.org/D111617 Reviewed By: rogfer01 Differential Revision: https://reviews.llvm.org/D126740
2022-07-26[RISCV] Lazily add RVV C intrinsics.Kito Cheng6-21/+127
Leverage the method OpenCL uses that adds C intrinsics when the lookup failed. There is no need to define C intrinsics in the header file any more. It could help to avoid the large header file to speed up the compilation of RVV source code. Besides that, only the C intrinsics used by the users will be added into the declaration table. This patch is based on https://reviews.llvm.org/D103228 and inspired by OpenCL implementation. ### Experimental Results #### TL;DR: - Binary size of clang increase ~200k, which is +0.07% for debug build and +0.13% for release build. - Single file compilation speed up ~33x for debug build and ~8.5x for release build - Regression time reduce ~10% (`ninja check-all`, enable all targets) #### Header size change ``` | size | LoC | ------------------------------ Before | 4,434,725 | 69,749 | After | 6,140 | 162 | ``` #### Single File Compilation Time Testcase: ``` #include <riscv_vector.h> vint32m1_t test_vadd_vv_vfloat32m1_t(vint32m1_t op1, vint32m1_t op2, size_t vl) { return vadd(op1, op2, vl); } ``` ##### Debug build: Before: ``` real 0m19.352s user 0m19.252s sys 0m0.092s ``` After: ``` real 0m0.576s user 0m0.552s sys 0m0.024s ``` ~33x speed up for debug build ##### Release build: Before: ``` real 0m0.773s user 0m0.741s sys 0m0.032s ``` After: ``` real 0m0.092s user 0m0.080s sys 0m0.012s ``` ~8.5x speed up for release build #### Regression time Note: the failed case is `tools/llvm-debuginfod-find/debuginfod.test` which is unrelated to this patch. ##### Debug build Before: ``` Testing Time: 1358.38s Skipped : 11 Unsupported : 446 Passed : 75767 Expectedly Failed: 190 Failed : 1 ``` After ``` Testing Time: 1220.29s Skipped : 11 Unsupported : 446 Passed : 75767 Expectedly Failed: 190 Failed : 1 ``` ##### Release build Before: ``` Testing Time: 381.98s Skipped : 12 Unsupported : 1407 Passed : 74765 Expectedly Failed: 176 Failed : 1 ``` After: ``` Testing Time: 346.25s Skipped : 12 Unsupported : 1407 Passed : 74765 Expectedly Failed: 176 Failed : 1 ``` #### Binary size of clang ##### Debug build Before ``` text data bss dec hex filename 335261851 12726004 552812 348540667 14c64efb bin/clang ``` After ``` text data bss dec hex filename 335442803 12798708 552940 348794451 14ca2e53 bin/clang ``` +253K, +0.07% code size ##### Release build Before ``` text data bss dec hex filename 144123975 8374648 483140 152981763 91e5103 bin/clang ``` After ``` text data bss dec hex filename 144255762 8447296 483268 153186326 9217016 bin/clang ``` +204K, +0.13% Authored-by: Kito Cheng <kito.cheng@sifive.com> Co-Authored-by: Hsiangkai Wang <kai.wang@sifive.com> Reviewed By: khchen, aaron.ballman Differential Revision: https://reviews.llvm.org/D111617
2022-07-26[analyzer] Lambda capture non-POD type arrayisuckatcs2-8/+52
This patch introduces a new `ConstructionContext` for lambda capture. This `ConstructionContext` allows the analyzer to construct the captured object directly into it's final region, and makes it possible to capture non-POD arrays. Differential Revision: https://reviews.llvm.org/D129967
2022-07-26[analyzer] ArrayInitLoopExpr with array of non-POD typeisuckatcs2-1/+33
This patch introduces the evaluation of ArrayInitLoopExpr in case of structured bindings and implicit copy/move constructor. The idea is to call the copy constructor for every element in the array. The parameter of the copy constructor is also manually selected, as it is not a part of the CFG. Differential Revision: https://reviews.llvm.org/D129496
2022-07-25[clang][dataflow] Fix MapLattice::insert() to not drop return valueEric Li1-3/+6
Fix `MapLattice` API to return `std::pair<iterator, bool>`, allowing users to detect when an element has been inserted without performing a redundant map lookup. Differential Revision: https://reviews.llvm.org/D130497
2022-07-25Reapply "[NFC] Add some additional features to MultiLevelTemplateArgumentList""Erich Keane1-0/+34
This reverts commit 6a1ccf61cdf80c793f9c699ada33af5d85263b30. A typo in an assert escaped my local testing thanks to being a release build :/
2022-07-25[C++20][Modules] Update ADL to handle basic.lookup.argdep p4 [P1815R2 part 1]Iain Sandoe1-0/+4
This includes the revised provisions of [basic.lookup.argdep] p4 1. ADL is amended to handle p 4.3 where functions in trasitively imported modules may become visible when they are exported in the same namespace as a visible type. 2. If a function is in a different modular TU, and has internal-linkage, we invalidate its entry in an overload set. [basic.lookup.argdep] p5 ex 2 now passes. Differential Revision: https://reviews.llvm.org/D129174
2022-07-25[Sema] Merge C++20 concept definitions from different modules in same TUIlya Biryukov2-0/+5
Currently the C++20 concepts are only merged in `ASTReader`, i.e. when coming from different TU. This can causes ambiguious reference errors when trying to access the same concept that should otherwise be merged. Please see the added test for an example. Note that we currently use `ASTContext::isSameEntity` to check for ODR violations. However, it will not check that concept requirements match. The same issue holds for mering concepts from different TUs, I added a FIXME and filed a GH issue to track this: https://github.com/llvm/llvm-project/issues/56310 Reviewed By: ChuanqiXu Differential Revision: https://reviews.llvm.org/D128921
2022-07-25Rewording "static_assert" diagnosticsMuhammad Usman Shahid3-6/+6
This patch rewords the static assert diagnostic output. Failing a _Static_assert in C should not report that static_assert failed. This changes the wording to be more like GCC and uses "static assertion" when possible instead of hard coding the name. This also changes some instances of 'static_assert' to instead be based on the token in the source code. Differential Revision: https://reviews.llvm.org/D129048
2022-07-24Remove redundaunt override specifiers (NFC)Kazu Hirata5-8/+8
Identified with modernize-use-override.
2022-07-24[clang] Remove unused forward declarations (NFC)Kazu Hirata5-7/+0
2022-07-25[clang] better error message for while loops outside of control flowinclyc1-0/+2
report an error when encountering 'while' token parsing declarator ``` clang/test/Parser/while-loop-outside-function.c:3:1: error: while loop outside of a function while // expected-error {{while loop outside of a function}} ^ clang/test/Parser/while-loop-outside-function.c:7:1: error: while loop outside of a function while // expected-error {{while loop outside of a function}} ^ ``` Fixes: https://github.com/llvm/llvm-project/issues/34462 Differential Revision: https://reviews.llvm.org/D129573
2022-07-24[Clang] De-deprecate volatile compound operationsCorentin Jabot1-1/+2
As per P2327R1, |=, &= and ^= are no longer deprecated in all languages mode. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D130421
2022-07-24clang/include/clang/module.modulemap: Mark `Tooling/Inclusions/*.inc` as ↵NAKAMURA Takumi1-1/+4
textual. Fixes llvmorg-15-init-917-g46a6f5ae148a
2022-07-23Use the range-based overload of llvm::sort where possibleDmitri Gribenko1-1/+1
Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D130403
2022-07-23[Clang] Adjust extension warnings for #warningCorentin Jabot1-1/+9
The #warning directive is standard in C++2b and C2x, this adjusts the pedantic and extensions warning accordingly. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D130415
2022-07-22[Driver] Error for -gsplit-dwarf with RISC-V linker relaxationFangrui Song1-0/+3
-gsplit-dwarf produces a .dwo file which will not be processed by the linker. If .dwo files contain relocations, they will not be resolved. Therefore the practice is that .dwo files do not contain relocations. Address ranges and location description need to use forms/entry kinds indexing into .debug_addr (DW_FORM_addrx/DW_RLE_startx_endx/etc), which is currently not implemented. There is a difficult-to-read MC error with -gsplit-dwarf with RISC-V for both -mrelax and -mno-relax. ``` % clang --target=riscv64-linux-gnu -g -gsplit-dwarf -c a.c error: A dwo section may not contain relocations ``` We expect to fix -mno-relax soon, so report a driver error for -mrelax for now. Link: https://github.com/llvm/llvm-project/issues/56642 Reviewed By: compnerd, kito-cheng Differential Revision: https://reviews.llvm.org/D130190
2022-07-23[clang][dataflow] Add DataflowEnvironment::dump()Dmitri Gribenko3-1/+19
Start by dumping the flow condition. Reviewed By: ymandel Differential Revision: https://reviews.llvm.org/D130398
2022-07-22Move "clang/Basic/TokenKinds.h" into a separate top-level module.Volodymyr Sapsai1-1/+8
Fixes modular build for clangPseudoGrammar from clang-tools-extra. Starting from https://reviews.llvm.org/D126731 clangPseudoGrammar doesn't depend on generated .inc headers but still depends on "Basic/TokenKinds.h". It means clangPseudoGrammar depends on module 'Clang_Basic' which does depend on generated .inc headers. To avoid these coarse dependencies and extra build steps, extract "clang/Basic/TokenKinds.h" into a top-level module 'Clang_Basic_TokenKinds'. rdar://97387951 Differential Revision: https://reviews.llvm.org/D130377
2022-07-23[clang][dataflow] Expose stringification functions for SAT solver enumsDmitri Gribenko1-0/+7
Reviewed By: ymandel Differential Revision: https://reviews.llvm.org/D130399
2022-07-23[clang][dataflow] ArrayRef'ize debugString()Dmitri Gribenko1-1/+1
Reviewed By: ymandel Differential Revision: https://reviews.llvm.org/D130400
2022-07-22Revert "[NFC] Add some additional features to MultiLevelTemplateArgumentList"Nuno Lopes1-34/+0
This reverts commit 0b36a62d5f3505e21692ae0abf25ef00836329e3. It breaks the assertion build
2022-07-22[NFC] Add some additional features to MultiLevelTemplateArgumentListErich Keane1-0/+34
These are useful when dealing with multi-depth instantiation in deferred concepts, so this is split off of that patch.
2022-07-22[NFC] give getParentFunctionOrMethod a 'Lexical' parameterErich Keane1-4/+6
Split up from the deferred concepts implementation, this function is useful for determining the containing function of a different function. However, in some cases it is valuable to instead get the lexical parent. This adds a parameter to the existing function to allow a 'Lexical' parameter to instead select the lexical parent.
2022-07-22[NFC] Start saving InstantiatedFromDecl in non-template functionsErich Keane1-8/+19
In cases where a non-template function is defined inside a function template, we don't have information about the original uninstantiated version. In the case of concepts instantiation, we will need the ability to get back to the original template. This patch splits a piece of the deferred concepts instantaition patch off to accomplish the storage of this, with minor runtime overhead, and zero additional storage.
2022-07-22Strengthen -Wint-conversion to default to an errorAaron Ballman1-36/+6
Clang has traditionally allowed C programs to implicitly convert integers to pointers and pointers to integers, despite it not being valid to do so except under special circumstances (like converting the integer 0, which is the null pointer constant, to a pointer). In C89, this would result in undefined behavior per 3.3.4, and in C99 this rule was strengthened to be a constraint violation instead. Constraint violations are most often handled as an error. This patch changes the warning to default to an error in all C modes (it is already an error in C++). This gives us better security posture by calling out potential programmer mistakes in code but still allows users who need this behavior to use -Wno-error=int-conversion to retain the warning behavior, or -Wno-int-conversion to silence the diagnostic entirely. Differential Revision: https://reviews.llvm.org/D129881
2022-07-22[clang][dataflow] Refactor ApplyBuiltinTransfer field out into ↵Sam Estep3-11/+30
DataflowAnalysisOptions struct Depends On D130304 This patch pulls the `ApplyBuiltinTransfer` from the `TypeErasedDataflowAnalysis` class into a new `DataflowAnalysisOptions` struct, to allow us to add additional options later without breaking existing code. Reviewed By: gribozavr2, sgatev Differential Revision: https://reviews.llvm.org/D130305
2022-07-22[clang][dataflow] Move NoopAnalysis from unittests to includeSam Estep1-0/+43
This patch moves `Analysis/FlowSensitive/NoopAnalysis.h` from `clang/unittests/` to `clang/include/clang/`, so that we can use it for doing context-sensitive analysis. Reviewed By: ymandel, gribozavr2, sgatev Differential Revision: https://reviews.llvm.org/D130304
2022-07-22re-land [C++20][Modules] Build module static initializers per P1874R1.Iain Sandoe3-0/+26
The re-land fixes module map module dependencies seen on Greendragon, but not in the clang test suite. --- Currently we only implement this for the Itanium ABI since the correct mangling for the initializers in other ABIs is not yet known. Intended result: For a module interface [which includes partition interface and implementation units] (instead of the generic CXX initializer) we emit a module init that: - wraps the contained initializations in a control variable to ensure that the inits only happen once, even if a module is imported many times by imports of the main unit. - calls module initializers for imported modules first. Note that the order of module import is not significant, and therefore neither is the order of imported module initializers. - We then call initializers for the Global Module Fragment (if present) - We then call initializers for the current module. - We then call initializers for the Private Module Fragment (if present) For a module implementation unit, or a non-module TU that imports at least one module we emit a regular CXX init that: - Calls the initializers for any imported modules first. - Then proceeds as normal with remaining inits. For all module unit kinds we include a global constructor entry, this allows for the (in most cases unusual) possibility that a module object could be included in a final binary without a specific call to its initializer. Implementation: - We provide the module pointer in the AST Context so that CodeGen can act on it and its sub-modules. - We need to account for module build lines like this: ` clang -cc1 -std=c++20 Foo.pcm -emit-obj -o Foo.o` or ` clang -cc1 -std=c++20 -xc++-module Foo.cpp -emit-obj -o Foo.o` - in order to do this, we add to ParseAST to set the module pointer in the ASTContext, once we establish that this is a module build and we know the module pointer. To be able to do this, we make the query for current module public in Sema. - In CodeGen, we determine if the current build requires a CXX20-style module init and, if so, we defer any module initializers during the "Eagerly Emitted" phase. - We then walk the module initializers at the end of the TU but before emitting deferred inits (which adds any hidden and static ones, fixing https://github.com/llvm/llvm-project/issues/51873 ). - We then proceed to emit the deferred inits and continue to emit the CXX init function. Differential Revision: https://reviews.llvm.org/D126189
2022-07-21[modules] Replace `-Wauto-import` with `-Rmodule-include-translation`.Volodymyr Sapsai2-3/+4
Diagnostic for `-Wauto-import` shouldn't be a warning because it doesn't represent a potential problem in code that should be fixed. And the emitted fix-it is likely to trigger `-Watimport-in-framework-header` which makes it challenging to have a warning-free codebase. But it is still useful to see how include directives are translated into modular imports and which module a header belongs to, that's why keep it as a remark. Keep `-Wauto-import` for now to allow a gradual migration for codebases using `-Wno-auto-import`, e.g., `-Weverything -Wno-auto-import`. rdar://79594287 Differential Revision: https://reviews.llvm.org/D130138
2022-07-21[ASTMatchers] Adding a new matcher for callee declarations of Obj-CZiqing Luo1-5/+28
message expressions For an Obj-C message expression `[o m]`, the adding matcher will match the declaration of the method `m`. This commit overloads the existing `callee` ASTMatcher, which originally was only for C/C++ nodes but also applies to Obj-C messages now. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D129398
2022-07-21[clang] Add -fdiagnostics-format=sarif option for future SARIF outputAbraham Corea Diaz3-3/+7
Adds `sarif` option to the existing `-fdiagnostics-format` flag for intended future work with SARIF diagnostics. Currently issues a warning against the use of diagnostics in SARIF mode, then defaults to clang style for diagnostics. Reviewed By: cjdb, denik, aaron.ballman Differential Revision: https://reviews.llvm.org/D129886
generated by cgit v1.1 at 2024-09-07 14:03:31 +0000