summaryrefslogtreecommitdiffstats
path: root/clang/include
Commit message (Collapse)AuthorAgeFilesLines
...
* Change signature of __builtin_rotateright64 back to unsignedKarl-Johan Karlsson2019-09-161-1/+1
| | | | | | | | | | | | | | | | The signature of __builtin_rotateright64 was by misstake changed from unsigned to signed in r360863, this patch will change it back to unsigned as intended. This fixes pr43309 Reviewers: efriedma, hans Reviewed By: hans Differential Revision: https://reviews.llvm.org/D67606 llvm-svn: 371969
* [WebAssembly] Narrowing and widening SIMD opsThomas Lively2019-09-131-0/+14
| | | | | | | | | | | | | | | | Summary: Implements target-specific LLVM intrinsics and clang builtins for these new SIMD operations, as described at https://github.com/WebAssembly/simd/blob/master/proposals/simd/SIMD.md#integer-to-integer-narrowing. Reviewers: aheejin Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D67425 llvm-svn: 371906
* [clang-scan-deps] Fix for headers having the same name as a directoryAlex Lorenz2019-09-131-0/+3
| | | | | | | | | | | | Scan deps tool crashes when called on a C++ file, containing an include that has the same name as a directory. The tool crashes since it finds foo/dir and tries to read that as a file and fails. Patch by: kousikk (Kousik Kumar) Differential Revision: https://reviews.llvm.org/D67091 llvm-svn: 371903
* [OPENMP5.0]Add basic support for declare variant directive.Alexey Bataev2019-09-135-6/+59
| | | | | | | Added basic support for declare variant directive and its match clause with user context selector. llvm-svn: 371892
* Reland r371785: Add -Wpoison-system-directories warningManoj Gupta2019-09-131-0/+5
| | | | | | | | | | | | | | | | | | | | When using clang as a cross-compiler, we should not use system headers to do the compilation. This CL adds support of a new warning flag -Wpoison-system-directories which emits warnings if --sysroot is set and headers from common host system location are used. By default the warning is disabled. The intention of the warning is to catch bad includes which are usually generated by third party build system not targeting cross-compilation. Such cases happen in Chrome OS when someone imports a new package or upgrade one to a newer version from upstream. This is reland of r371785 with a fix to test file. Patch by: denik (Denis Nikitin) llvm-svn: 371878
* [NFCI]Create CommonAttributeInfo Type as base type of *Attr and ParsedAttr.Erich Keane2019-09-137-286/+390
| | | | | | | | | | | | In order to enable future improvements to our attribute diagnostics, this moves info from ParsedAttr into CommonAttributeInfo, then makes this type the base of the *Attr and ParsedAttr types. Quite a bit of refactoring took place, including removing a bunch of redundant Spelling Index propogation. Differential Revision: https://reviews.llvm.org/D67368 llvm-svn: 371875
* [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker2019-09-135-0/+98
| | | | | | | | | | | | | | | | | | Summary: This patch introduces the skeleton of the constexpr interpreter, capable of evaluating a simple constexpr functions consisting of if statements. The interpreter is described in more detail in the RFC. Further patches will add more features. Reviewers: Bigcheese, jfb, rsmith Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64146 llvm-svn: 371834
* For PR17164: split -fno-lax-vector-conversion into three differentRichard Smith2019-09-133-3/+17
| | | | | | | | | | | | | | | | | | | | | levels: -- none: no lax vector conversions [new GCC default] -- integer: only conversions between integer vectors [old GCC default] -- all: all conversions between same-size vectors [Clang default] For now, Clang still defaults to "all" mode, but per my proposal on cfe-dev (2019-04-10) the default will be changed to "integer" as soon as that doesn't break lots of testcases. (Eventually I'd like to change the default to "none" to match GCC and general sanity.) Following GCC's behavior, the driver flag -flax-vector-conversions is translated to -flax-vector-conversions=integer. This reinstates r371805, reverted in r371813, with an additional fix for lldb. llvm-svn: 371817
* Remove reliance on lax vector conversions from altivec.h and its test.Richard Smith2019-09-131-2/+2
| | | | llvm-svn: 371814
* Revert "For PR17164: split -fno-lax-vector-conversion into three different"Jonas Devlieghere2019-09-133-17/+3
| | | | | | | This breaks the LLDB build. I tried reaching out to Richard, but haven't gotten a reply yet. llvm-svn: 371813
* For PR17164: split -fno-lax-vector-conversion into three differentRichard Smith2019-09-133-3/+17
| | | | | | | | | | | | | | | | | | levels: -- none: no lax vector conversions [new GCC default] -- integer: only conversions between integer vectors [old GCC default] -- all: all conversions between same-size vectors [Clang default] For now, Clang still defaults to "all" mode, but per my proposal on cfe-dev (2019-04-10) the default will be changed to "integer" as soon as that doesn't break lots of testcases. (Eventually I'd like to change the default to "none" to match GCC and general sanity.) Following GCC's behavior, the driver flag -flax-vector-conversions is translated to -flax-vector-conversions=integer. llvm-svn: 371805
* Revert r371785.Manoj Gupta2019-09-131-5/+0
| | | | | | r371785 is causing fails on clang-hexagon-elf buildbots. llvm-svn: 371799
* [libclang] Expose abort()-ing LLVM fatal error handlerJan Korous2019-09-121-0/+33
| | | | | | Differential Revision: https://reviews.llvm.org/D66775 llvm-svn: 371787
* Add -Wpoison-system-directories warningManoj Gupta2019-09-121-0/+5
| | | | | | | | | | | | | | | | | | When using clang as a cross-compiler, we should not use system headers to do the compilation. This CL adds support of a new warning flag -Wpoison-system-directories which emits warnings if --sysroot is set and headers from common host system location are used. By default the warning is disabled. The intention of the warning is to catch bad includes which are usually generated by third party build system not targeting cross-compilation. Such cases happen in Chrome OS when someone imports a new package or upgrade one to a newer version from upstream. Patch by: denik (Denis Nikitin) llvm-svn: 371785
* Improve code generation for thread_local variables:Richard Smith2019-09-121-0/+6
| | | | | | | | | | | | | | | | | | | | | Summary: * Don't bother using a thread wrapper when the variable is known to have constant initialization. * Emit the thread wrapper as discardable-if-unused in TUs that don't contain a definition of the thread_local variable. * Don't emit the thread wrapper at all if the thread_local variable is unused and discardable; it will be emitted by all TUs that need it. Reviewers: rjmccall, jdoerfert Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67429 llvm-svn: 371767
* [CFG] Add dumps for CFGElement and CFGElementRefKristof Umann2019-09-121-2/+17
| | | | | | | | | Seems like we never had these, so here we go! I also did some refactoring as I was chasing a bug unrelated to this revision. Differential Revision: https://reviews.llvm.org/D66715 llvm-svn: 371765
* [analyzer][NFC] Fix inconsistent references to checkers as "checks"Kristof Umann2019-09-127-78/+89
| | | | | | | | | | | | | | Traditionally, clang-tidy uses the term check, and the analyzer uses checker, but in the very early years, this wasn't the case, and code originating from the early 2010's still incorrectly refer to checkers as checks. This patch attempts to hunt down most of these, aiming to refer to checkers as checkers, but preserve references to callback functions (like checkPreCall) as checks. Differential Revision: https://reviews.llvm.org/D67140 llvm-svn: 371760
* [MS] Warn when shadowing template parameters under -fms-compatibilityReid Kleckner2019-09-121-0/+2
| | | | | | | | | | | | | | | | | | | | Summary: C++ does not allow shadowing template parameters, but previously we allowed it under -fms-extensions. Now this behavior is controlled by -fms-compatibility, and we emit a -Wmicrosoft-template warning when it happens. Fixes PR43265 Reviewers: thakis, hans Subscribers: amccarth, rsmith, STL_MSFT, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67463 llvm-svn: 371753
* Removed some questionable default arguments from settersDmitri Gribenko2019-09-121-7/+5
| | | | | | | | | | | | | | | | | Summary: They can be confusing -- what does it mean to call a setter without a value? Also, some setters, like `setPrintTemplateTree` had `false` as the default value! The callers are largely not using these default arguments anyway. Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67491 llvm-svn: 371731
* Removed dead code from DiagnosticBuilderDmitri Gribenko2019-09-121-5/+0
| | | | llvm-svn: 371723
* [clang-format] Add new style option IndentGotoLabelsPaul Hoad2019-09-121-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This option determines whether goto labels are indented according to scope. Setting this option to false causes goto labels to be flushed to the left. This is mostly copied from [[ http://lists.llvm.org/pipermail/cfe-dev/2015-September/045014.html | this patch ]] submitted by Christian Neukirchen that didn't make its way into trunk. ``` true: false: int f() { vs. int f() { if (foo()) { if (foo()) { label1: label1: bar(); bar(); } } label2: label2: return 1; return 1; } } ``` Reviewers: klimek, MyDeveloperDay Reviewed By: MyDeveloperDay Subscribers: cfe-commits Tags: #clang, #clang-tools-extra Patch by: tetsuo-cpp Differential Revision: https://reviews.llvm.org/D67037 llvm-svn: 371719
* [WebAssembly] Add -fwasm-exceptions for wasm EHHeejin Ahn2019-09-122-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This adds `-fwasm-exceptions` (in similar fashion with `-fdwarf-exceptions` or `-fsjlj-exceptions`) that turns on everything with wasm exception handling from the frontend to the backend. We currently have `-mexception-handling` in clang frontend, but this is only about the architecture capability and does not turn on other necessary options such as the exception model in the backend. (This can be turned on with `llc -exception-model=wasm`, but llc is not invoked separately as a command line tool, so this option has to be transferred from clang.) Turning on `-fwasm-exceptions` in clang also turns on `-mexception-handling` if not specified, and will error out if `-mno-exception-handling` is specified. Reviewers: dschuff, tlively, sbc100 Subscribers: aprantl, jgravelle-google, sunfish, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67208 llvm-svn: 371708
* [analyzer] NFC: Move PathDiagnostic classes to libAnalysis.Artem Dergachev2019-09-113-2/+2
| | | | | | | | | | | | At this point the PathDiagnostic, PathDiagnosticLocation, PathDiagnosticPiece structures no longer rely on anything specific to Static Analyzer, so we can move them out of it for everybody to use. PathDiagnosticConsumers are still to be handed off. Differential Revision: https://reviews.llvm.org/D67419 llvm-svn: 371661
* [analyzer] NFC: Move resetDiagnosticLocationToMainFile() to BugReporter.Artem Dergachev2019-09-111-10/+13
| | | | | | | | | | This method of PathDiagnostic is a part of Static Analyzer's particular path diagnostic construction scheme. As such, it doesn't belong to the PathDiagnostic class, but to the Analyzer. Differential Revision: https://reviews.llvm.org/D67418 llvm-svn: 371660
* [analyzer] NFC: Move getStmt() and createEndOfPath() out of PathDiagnostic.Artem Dergachev2019-09-112-17/+32
| | | | | | | | | | These static functions deal with ExplodedNodes which is something we don't want the PathDiagnostic interface to know anything about, as it's planned to be moved out of libStaticAnalyzerCore. Differential Revision: https://reviews.llvm.org/D67382 llvm-svn: 371659
* [analyzer] NFC: Re-implement stack hints as a side map in BugReport.Artem Dergachev2019-09-112-64/+74
| | | | | | | | | | That's one of the few random entities in the PathDiagnostic interface that are specific to the Static Analyzer. By moving them out we could let everybody use path diagnostics without linking against Static Analyzer. Differential Revision: https://reviews.llvm.org/D67381 llvm-svn: 371658
* [clang-scan-deps] add skip excluded conditional preprocessor block ↵Alex Lorenz2019-09-118-3/+109
| | | | | | | | | | | | | | | preprocessing optimization This commit adds an optimization to clang-scan-deps and clang's preprocessor that skips excluded preprocessor blocks by bumping the lexer pointer, and not lexing the tokens until reaching appropriate #else/#endif directive. The skip positions and lexer offsets are computed when the file is minimized, directly from the minimized tokens. On an 18-core iMacPro with macOS Catalina Beta I got 10-15% speed-up from this optimization when running clang-scan-deps on the compilation database for a recent LLVM and Clang (3511 files). Differential Revision: https://reviews.llvm.org/D67127 llvm-svn: 371656
* Fix -Wnonportable-include-path suppression for header maps with absolute paths.Volodymyr Sapsai2019-09-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | In `DirectoryLookup::LookupFile` parameter `HasBeenMapped` doesn't cover the case when clang finds a file through a header map but doesn't remap the lookup filename because the target path is an absolute path. As a result, -Wnonportable-include-path suppression for header maps introduced in r301592 wasn't triggered. Change parameter `HasBeenMapped` to `IsInHeaderMap` and use parameter `MappedName` to track the filename remapping. This way we can handle both relative and absolute paths in header maps, and account for their specific properties, like filename remapping being a property preserved across lookups in multiple directories. rdar://problem/39516483 Reviewers: dexonsmith, bruno Reviewed By: dexonsmith Subscribers: jkorous, cfe-commits, ributzka Differential Revision: https://reviews.llvm.org/D58094 llvm-svn: 371655
* Reland "clang-misexpect: Profile Guided Validation of Performance ↵Petr Hosek2019-09-112-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Annotations in LLVM" This patch contains the basic functionality for reporting potentially incorrect usage of __builtin_expect() by comparing the developer's annotation against a collected PGO profile. A more detailed proposal and discussion appears on the CFE-dev mailing list (http://lists.llvm.org/pipermail/cfe-dev/2019-July/062971.html) and a prototype of the initial frontend changes appear here in D65300 We revised the work in D65300 by moving the misexpect check into the LLVM backend, and adding support for IR and sampling based profiles, in addition to frontend instrumentation. We add new misexpect metadata tags to those instructions directly influenced by the llvm.expect intrinsic (branch, switch, and select) when lowering the intrinsics. The misexpect metadata contains information about the expected target of the intrinsic so that we can check against the correct PGO counter when emitting diagnostics, and the compiler's values for the LikelyBranchWeight and UnlikelyBranchWeight. We use these branch weight values to determine when to emit the diagnostic to the user. A future patch should address the comment at the top of LowerExpectIntrisic.cpp to hoist the LikelyBranchWeight and UnlikelyBranchWeight values into a shared space that can be accessed outside of the LowerExpectIntrinsic pass. Once that is done, the misexpect metadata can be updated to be smaller. In the long term, it is possible to reconstruct portions of the misexpect metadata from the existing profile data. However, we have avoided this to keep the code simple, and because some kind of metadata tag will be required to identify which branch/switch/select instructions are influenced by the use of llvm.expect Patch By: paulkirth Differential Revision: https://reviews.llvm.org/D66324 llvm-svn: 371635
* [OPENMP] Update the diagnosis message for canonical loop form, by ChiAlexey Bataev2019-09-111-1/+1
| | | | | | | | | | | | | | | Chun Chen. The previous patch (https://reviews.llvm.org/D54441) support the relational-op != very well for openmp canonical loop form, however, it didn't update the diagnosis message. So this patch is simply update the diagnosis message by adding !=, update the test related to it, and update the section number for canonical loop form for OpenMP 5.0 in comment. Differential Revision: https://reviews.llvm.org/D66559 llvm-svn: 371631
* [Diagnostics] Add -Wsizeof-array-divDavid Bolvansky2019-09-111-0/+4
| | | | | | | | | | Summary: Clang version of https://www.viva64.com/en/examples/v706/ Reviewers: rsmith Differential Revision: https://reviews.llvm.org/D67287 llvm-svn: 371605
* Revert "clang-misexpect: Profile Guided Validation of Performance ↵Dmitri Gribenko2019-09-112-7/+1
| | | | | | | | | | | | | | | | | | | Annotations in LLVM" This reverts commit r371584. It introduced a dependency from compiler-rt to llvm/include/ADT, which is problematic for multiple reasons. One is that it is a novel dependency edge, which needs cross-compliation machinery for llvm/include/ADT (yes, it is true that right now compiler-rt included only header-only libraries, however, if we allow compiler-rt to depend on anything from ADT, other libraries will eventually get used). Secondly, depending on ADT from compiler-rt exposes ADT symbols from compiler-rt, which would cause ODR violations when Clang is built with the profile library. llvm-svn: 371598
* [ARM] Take into account -mcpu and -mfpu options while handling 'crypto' featureDiogo N. Sampaio2019-09-111-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Submittin in behalf of krisb (Kristina Bessonova) <ch.bessonova@gmail.com> Summary: '+crypto' means '+aes' and '+sha2' for arch >= ARMv8 when they were not disabled explicitly. But this is correctly handled only in case of '-march' option, though the feature may also be specified through the '-mcpu' or '-mfpu' options. In the following example: $ clang -mcpu=cortex-a57 -mfpu=crypto-neon-fp-armv8 'aes' and 'sha2' are disabled that is quite unexpected: $ clang -cc1 -triple armv8--- -target-cpu cortex-a57 <...> -target-feature -sha2 -target-feature -aes -target-feature +crypto This exposed by https://reviews.llvm.org/D63936 that makes the 'aes' and 'sha2' features disabled by default. So, while handling the 'crypto' feature we need to take into account: - a CPU name, as it provides the information about architecture (if no '-march' option specified), - features, specified by the '-mcpu' and '-mfpu' options. Reviewers: SjoerdMeijer, ostannard, labrinea, dnsampaio Reviewed By: dnsampaio Subscribers: ikudrin, javed.absar, kristof.beyls, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66018 Author: krisb llvm-svn: 371597
* clang-misexpect: Profile Guided Validation of Performance Annotations in LLVMPetr Hosek2019-09-112-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch contains the basic functionality for reporting potentially incorrect usage of __builtin_expect() by comparing the developer's annotation against a collected PGO profile. A more detailed proposal and discussion appears on the CFE-dev mailing list (http://lists.llvm.org/pipermail/cfe-dev/2019-July/062971.html) and a prototype of the initial frontend changes appear here in D65300 We revised the work in D65300 by moving the misexpect check into the LLVM backend, and adding support for IR and sampling based profiles, in addition to frontend instrumentation. We add new misexpect metadata tags to those instructions directly influenced by the llvm.expect intrinsic (branch, switch, and select) when lowering the intrinsics. The misexpect metadata contains information about the expected target of the intrinsic so that we can check against the correct PGO counter when emitting diagnostics, and the compiler's values for the LikelyBranchWeight and UnlikelyBranchWeight. We use these branch weight values to determine when to emit the diagnostic to the user. A future patch should address the comment at the top of LowerExpectIntrisic.cpp to hoist the LikelyBranchWeight and UnlikelyBranchWeight values into a shared space that can be accessed outside of the LowerExpectIntrinsic pass. Once that is done, the misexpect metadata can be updated to be smaller. In the long term, it is possible to reconstruct portions of the misexpect metadata from the existing profile data. However, we have avoided this to keep the code simple, and because some kind of metadata tag will be required to identify which branch/switch/select instructions are influenced by the use of llvm.expect Patch By: paulkirth Differential Revision: https://reviews.llvm.org/D66324 llvm-svn: 371584
* Revert "clang-misexpect: Profile Guided Validation of Performance ↵Petr Hosek2019-09-102-7/+1
| | | | | | | | Annotations in LLVM" This reverts commit r371484: this broke sanitizer-x86_64-linux-fast bot. llvm-svn: 371488
* clang-misexpect: Profile Guided Validation of Performance Annotations in LLVMPetr Hosek2019-09-102-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch contains the basic functionality for reporting potentially incorrect usage of __builtin_expect() by comparing the developer's annotation against a collected PGO profile. A more detailed proposal and discussion appears on the CFE-dev mailing list (http://lists.llvm.org/pipermail/cfe-dev/2019-July/062971.html) and a prototype of the initial frontend changes appear here in D65300 We revised the work in D65300 by moving the misexpect check into the LLVM backend, and adding support for IR and sampling based profiles, in addition to frontend instrumentation. We add new misexpect metadata tags to those instructions directly influenced by the llvm.expect intrinsic (branch, switch, and select) when lowering the intrinsics. The misexpect metadata contains information about the expected target of the intrinsic so that we can check against the correct PGO counter when emitting diagnostics, and the compiler's values for the LikelyBranchWeight and UnlikelyBranchWeight. We use these branch weight values to determine when to emit the diagnostic to the user. A future patch should address the comment at the top of LowerExpectIntrisic.cpp to hoist the LikelyBranchWeight and UnlikelyBranchWeight values into a shared space that can be accessed outside of the LowerExpectIntrinsic pass. Once that is done, the misexpect metadata can be updated to be smaller. In the long term, it is possible to reconstruct portions of the misexpect metadata from the existing profile data. However, we have avoided this to keep the code simple, and because some kind of metadata tag will be required to identify which branch/switch/select instructions are influenced by the use of llvm.expect Patch By: paulkirth Differential Revision: https://reviews.llvm.org/D66324 llvm-svn: 371484
* [analyzer] NFC: Simplify bug report equivalence classes to not be ilists.Artem Dergachev2019-09-091-15/+8
| | | | | | | | Use a vector of unique pointers instead. Differential Revision: https://reviews.llvm.org/D67024 llvm-svn: 371451
* [analyzer] NFC: Introduce sub-classes for path-sensitive and basic reports.Artem Dergachev2019-09-093-195/+289
| | | | | | | | | | | | | Checkers are now required to specify whether they're creating a path-sensitive report or a path-insensitive report by constructing an object of the respective type. This makes BugReporter more independent from the rest of the Static Analyzer because all Analyzer-specific code is now in sub-classes. Differential Revision: https://reviews.llvm.org/D66572 llvm-svn: 371450
* [Driver] Add -static-openmp driver optionPirama Arumuga Nainar2019-09-091-0/+2
| | | | | | | | | | | | | | | | | | | | | | Summary: For Gnu, FreeBSD and NetBSD, this option forces linking with the static OpenMP host runtime (similar to -static-libgcc and -static-libstdcxx). Android's NDK will start the shared OpenMP runtime in addition to the static libomp. In this scenario, the linker will prefer to use the shared library by default. Add this option to enable linking with the static libomp. Reviewers: Hahnfeld, danalbert, srhines, joerg, jdoerfert Subscribers: guansong, cfe-commits Tags: #clang Fixes https://github.com/android-ndk/ndk/issues/1028 Differential Revision: https://reviews.llvm.org/D67200 llvm-svn: 371437
* Merge note_ovl_builtin_candidate diagnostics; NFCSven van Haastregt2019-09-091-4/+1
| | | | | | | There is no difference between the unary and binary case, so merge them. llvm-svn: 371403
* [Sema][ObjC] Mark C union fields that have non-trivial ObjC ownershipAkira Hatanaka2019-09-071-0/+5
| | | | | | | | | | | | | | | | | qualifications as unavailable if the union is declared in a system header r365985 stopped marking those fields as unavailable, which caused the union's NonTrivialToPrimitive* bits to be set to true. This patch restores the behavior prior to r365985, except that users can explicitly specify the ownership qualification of the field to instruct the compiler not to mark it as unavailable. rdar://problem/53420753 Differential Revision: https://reviews.llvm.org/D65256 llvm-svn: 371276
* [Sema] Diagnose default-initialization, destruction, and copying ofAkira Hatanaka2019-09-075-9/+130
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | non-trivial C union types This recommits r365985, which was reverted because it broke a few projects using unions containing non-trivial ObjC pointer fields in system headers. We now have a patch to fix the problem (see https://reviews.llvm.org/D65256). Original commit message: This patch diagnoses uses of non-trivial C unions and structs/unions containing non-trivial C unions in the following contexts, which require default-initialization, destruction, or copying of the union objects, instead of disallowing fields of non-trivial types in C unions, which is what we currently do: - function parameters. - function returns. - assignments. - compound literals. - block captures except capturing of `__block` variables by non-escaping blocks. - local and global variable definitions. - lvalue-to-rvalue conversions of volatile types. See the discussion in https://reviews.llvm.org/D62988 for more background. rdar://problem/50679094 Differential Revision: https://reviews.llvm.org/D63753 llvm-svn: 371275
* [analyzer] Add minimal support for fix-it hints.Artem Dergachev2019-09-064-16/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | Allow attaching fixit hints to Static Analyzer BugReports. Fixits are attached either to the bug report itself or to its notes (path-sensitive event notes or path-insensitive extra notes). Add support for fixits in text output (including the default text output that goes without notes, as long as the fixit "belongs" to the warning). Add support for fixits in the plist output mode. Implement a fixit for the path-insensitive DeadStores checker. Only dead initialization warning is currently covered. Implement a fixit for the path-sensitive VirtualCall checker when the virtual method is not pure virtual (in this case the "fix" is to suppress the warning by qualifying the call). Both fixits are under an off-by-default flag for now, because they require more careful testing. Differential Revision: https://reviews.llvm.org/D65182 llvm-svn: 371257
* [analyzer] pr43179: Make CallDescription defensive against C variadic functions.Artem Dergachev2019-09-061-3/+17
| | | | | | | | | | | | | | | | | | | | | Most functions that our checkers react upon are not C-style variadic functions, and therefore they have as many actual arguments as they have formal parameters. However, it's not impossible to define a variadic function with the same name. This will crash any checker that relies on CallDescription to check the number of arguments but silently assumes that the number of parameters is the same. Change CallDescription to check both the number of arguments and the number of parameters by default. If we're intentionally trying to match variadic functions, allow specifying arguments and parameters separately (possibly omitting any of them). For now we only have one CallDescription which would make use of those, namely __builtin_va_start itself. Differential Revision: https://reviews.llvm.org/D67019 llvm-svn: 371256
* [clang][Index][NFC] Put IndexingOptions to a separate headerJan Korous2019-09-062-20/+43
| | | | llvm-svn: 371250
* [NFCI] Unbreak buildbotsDavid Bolvansky2019-09-061-4/+0
| | | | llvm-svn: 371226
* [Diagnostics] Refactor code for -Wsizeof-pointer-div, catch more cases; also ↵David Bolvansky2019-09-061-1/+5
| | | | | | | | | | | | | | | | add -Wsizeof-array-div Previously, -Wsizeof-pointer-div failed to catch: const int *r; sizeof(r) / sizeof(int); Now fixed. Also introduced -Wsizeof-array-div which catches bugs like: sizeof(r) / sizeof(short); (Array element type does not match type of sizeof operand). llvm-svn: 371222
* [X86] Prevent passing vectors of __int128 as <X x i128> in llvm IRCraig Topper2019-09-061-0/+6
| | | | | | | | | | | | | As far as I can tell, gcc passes 256/512 bit vectors __int128 in memory. And passes a vector of 1 _int128 in an xmm register. The backend considers <X x i128> as an illegal type and will scalarize any arguments with that type. So we need to coerce the argument types in the frontend to match to avoid the illegal type. I'm restricting this to change to Linux and NetBSD based on the how similar ABI changes have been handled in the past. PS4, FreeBSD, and Darwin are unaffected. I've also added a new -fclang-abi-compat version to restore the old behavior. This issue was identified in PR42607. Though even with the types changed, we still seem to be doing some unnecessary stack realignment. llvm-svn: 371169
* Implement Microsoft-compatible mangling for decomposition declarations.Nico Weber2019-09-051-4/+4
| | | | | | | | | | | | | | | Match cl.exe's mangling for decomposition declarations. Decomposition declarations are considered to be anonymous structs, and use the same convention as for anonymous struct/union declarations. Naming confirmed to match https://godbolt.org/z/K2osJa Patch from Eric Astor <epastor@google.com>! Differential Revision: https://reviews.llvm.org/D67202 llvm-svn: 371124
* [Diagnostics] Minor improvements for -Wxor-used-as-powDavid Bolvansky2019-09-051-1/+4
| | | | | | Extracted from D66397; implemented suggestion for 2^64; tests revisited. llvm-svn: 371122
OpenPOWER on IntegriCloud