summaryrefslogtreecommitdiffstats
path: root/clang
Commit message (Collapse)AuthorAgeFilesLines
...
* [Extract] Fixed SemicolonExtractionPolicy for SwitchStmt and SwitchCaseShaurya Gupta2019-08-082-1/+17
| | | | | | | | | | | | Reviewers: arphaman, sammccall Subscribers: dexonsmith, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D65883 llvm-svn: 368267
* [diagtool] Use `operator<<(Colors)` to print out colored output.Rui Ueyama2019-08-081-36/+13
| | | | | | | | | | r368131 introduced this new API to print out messages in colors. If the colored output is disabled, `operator<<(Colors)` becomes nop. No functionality change intended. Differential Revision: https://reviews.llvm.org/D65854 llvm-svn: 368259
* [Driver] Delete XFAIL: windows-msvc after D65880/r368245Fangrui Song2019-08-081-1/+0
| | | | | | `-target %itanium_abi_triple` fixed the problem. llvm-svn: 368251
* [Driver] Move LIBRARY_PATH before user inputsFangrui Song2019-08-082-9/+10
| | | | | | | | | | | | | | | | Fixes PR16786 Currently, library paths specified by LIBRARY_PATH are placed after inputs: `inputs LIBRARY_PATH stdlib` In gcc, the order is: `LIBRARY_PATH inputs stdlib` if not cross compiling. (On Darwin targets, isCrossCompiling() always returns false.) This patch changes the behavior to match gcc. Reviewed By: hfinkel Differential Revision: https://reviews.llvm.org/D65880 llvm-svn: 368245
* Inline diagnostic text into .td file. NFC.Richard Trieu2019-08-082-10/+21
| | | | llvm-svn: 368244
* Update fix-it hints for std::move warnings.Richard Trieu2019-08-083-32/+76
| | | | | | | | | | | Fix -Wpessimizing-move and -Wredundant-move when warning on initializer lists. The new fix-it hints for removing the std::move call will now also suggest removing the braces for the initializer list so that the resulting code will still be compilable. This fixes PR42832 llvm-svn: 368237
* Add target requirements for those bots which don't handle x86.Bill Wendling2019-08-071-0/+1
| | | | llvm-svn: 368202
* [Tooling] Expose ExecutorConcurrency option.Diego Astiazaran2019-08-072-1/+2
| | | | | | | | D65628 requires a flag to specify the number of threads for a clang-doc step. It would be good to use ExecutorConcurrency after exposing it instead of creating a new one that has the same purpose. Differential Revision: https://reviews.llvm.org/D65833 llvm-svn: 368196
* [clang][NFC] Fix typo in matcher commentYitzhak Mandelbaum2019-08-072-2/+2
| | | | | | Also updates corresponding html doc. llvm-svn: 368188
* Remove LLVM mutexes from clang in favor of std::mutexBenjamin Kramer2019-08-075-11/+7
| | | | | | | None of those need to be recursive mutexes. No functionality change intended. llvm-svn: 368173
* [OPENMP]Set default version to OpenMP 4.5.Alexey Bataev2019-08-074-10/+13
| | | | | | | Since clang fully supports OpenMP 4.5, set the default version to 4.5 instead of 3.1. llvm-svn: 368172
* [OPENMP]Add standard macro value _OPENMP for OpenMP 5.0.Alexey Bataev2019-08-073-0/+7
| | | | | | | | | According to the OpenMP standard, compiler must define _OPENMP macro, which has value in format yyyymm, where yyyy is the year of the standard and mm is the month of the standard. For OpenMP 5.0 this value must be set to 201811. llvm-svn: 368170
* [ASTImporter] Do not import FunctionTemplateDecl in record twice.Balazs Keri2019-08-072-2/+58
| | | | | | | | | | | | | | | | | | | | | Summary: For functions there is a check to not duplicate the declaration if it is in a record (class). For function templates there was no similar check, if a template (in the same class) was imported multiple times the FunctionTemplateDecl was created multiple times with the same templated FunctionDecl. This can result in problems with the declaration chain. Reviewers: martong, a.sidorin, shafik, a_sidorin Reviewed By: a_sidorin Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D65203 llvm-svn: 368163
* Replace non-recursive sys::Mutex users with std::mutexBenjamin Kramer2019-08-073-11/+9
| | | | | | | Also remove a use of sys::MutexImpl, that's just evil. No functionality change intended. llvm-svn: 368157
* [clang] Fix mismatched args constructing AddressSpaceAttr.Anton Bikineev2019-08-072-3/+16
| | | | | | Differential Revision: https://reviews.llvm.org/D65589 llvm-svn: 368152
* Replace llvm::MutexGuard/UniqueLock with their standard equivalentsBenjamin Kramer2019-08-073-8/+8
| | | | | | | All supported platforms have <mutex> now, so we don't need our own copies any longer. No functionality change intended. llvm-svn: 368149
* gsl::Owner/gsl::Pointer: Add implicit annotations for some std typesMatthias Gehre2019-08-076-2/+268
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Hard code gsl::Owner/gsl::Pointer for std types. The paper mentions some types explicitly. Generally, all containers and their iterators are covered. For iterators, we cover both the case that they are defined as an nested class or as an typedef/using. I have started to test this implementation against some real standard library implementations, namely libc++ 7.1.0, libc++ 8.0.1rc2, libstdc++ 4.6.4, libstdc++ 4.8.5, libstdc++ 4.9.4, libstdc++ 5.4.0, libstdc++ 6.5.0, libstdc++ 7.3.0, libstdc++ 8.3.0 and libstdc++ 9.1.0. The tests are currently here https://github.com/mgehre/llvm-project/blob/lifetime-ci/lifetime-attr-test.sh https://github.com/mgehre/llvm-project/blob/lifetime-ci/lifetime-attr-test.cpp I think due to their dependency on a standard library, they are not a good fit for clang/test/. Where else could I put them? Reviewers: gribozavr, xazax.hun Subscribers: rnkovacs, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64448 llvm-svn: 368147
* Remove inclusion of a private gmock header from a testDmitri Gribenko2019-08-071-1/+0
| | | | llvm-svn: 368132
* Re-submit r367649: Improve raw_ostream so that you can "write" colors using ↵Rui Ueyama2019-08-071-1/+2
| | | | | | | | | operator<< The original patch broke buildbots, perhaps because it changed the default setting whether colors are enabled or not. llvm-svn: 368131
* [RISCV] Remove duplicated logic when determining the target ABIRoger Ferrer Ibanez2019-08-072-13/+9
| | | | | | | | We were calculating twice ilp32/lp64. Do this in one place instead. Differential Revision: https://reviews.llvm.org/D48357 llvm-svn: 368128
* [clang][DirectoryWatcher][NFC] Swapping asserts for llvm fatal_error in createPuyan Lotfi2019-08-064-62/+110
| | | | | | | | | | | | | | I also have replaced all the instances of "auto DW = DirectoryWatcher::create" with llvm::Expected<std::unique_ptr<DirectoryWatcher>> DW = DirectoryWatcher::create to make it more clear that DirectoryWatcher::create is returning an Expected. I've also allowed for logAllUnhandledErrors to consume errors in the case were DirectoryWatcher::create produces them. Differential Revision: https://reviews.llvm.org/D65829 llvm-svn: 368108
* Delay diagnosing asm constraints that require immediates until after inliningBill Wendling2019-08-066-62/+35
| | | | | | | | | | | | | | | | Summary: An inline asm call may result in an immediate input value after inlining. Therefore, don't emit a diagnostic here if the input isn't an immediate. Reviewers: joerg, eli.friedman, rsmith Subscribers: asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, s.egerton, krytarowski, mgorny, riccibruno, eraman, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D60943 llvm-svn: 368104
* hwasan: Instrument globals.Peter Collingbourne2019-08-062-0/+7
| | | | | | | | | | | | | | | | | | Globals are instrumented by adding a pointer tag to their symbol values and emitting metadata into a special section that allows the runtime to tag their memory when the library is loaded. Due to order of initialization issues explained in more detail in the comments, shadow initialization cannot happen during regular global initialization. Instead, the location of the global section is marked using an ELF note, and we require libc support for calling a function provided by the HWASAN runtime when libraries are loaded and unloaded. Based on ideas discussed with @evgeny777 in D56672. Differential Revision: https://reviews.llvm.org/D65770 llvm-svn: 368102
* [WebAssembly] Lower ASan constructor priority on EmscriptenGuanzhong Chen2019-08-061-0/+5
| | | | | | | | | | | | | | | | | | | | | | | Summary: This change gives Emscripten the ability to use more than one constructor priorities that runs before ASan. By convention, constructor priorites 0-100 are reserved for use by the system. ASan on Emscripten now uses priority 50, leaving plenty of room for use by Emscripten before and after ASan. This change is done in response to: https://github.com/emscripten-core/emscripten/pull/9076#discussion_r310323723 Reviewers: kripken, tlively, aheejin Reviewed By: tlively Subscribers: cfe-commits, dschuff, sbc100, jgravelle-google, hiraditya, sunfish, llvm-commits Tags: #llvm, #clang Differential Revision: https://reviews.llvm.org/D65684 llvm-svn: 368101
* fix clang-scan-deps test to match filepaths on WindowsAlex Lorenz2019-08-061-2/+2
| | | | llvm-svn: 368092
* [clang-scan-deps] Implementation of dependency scanner over minimized sourcesAlex Lorenz2019-08-0617-21/+608
| | | | | | | | | | | | | | | | | | | This commit implements the fast dependency scanning mode in clang-scan-deps: the preprocessing is done on files that are minimized using the dependency directives source minimizer. A shared file system cache is used to ensure that the file system requests and source minimization is performed only once. The cache assumes that the underlying filesystem won't change during the course of the scan (or if it will, it will not affect the output), and it can't be evicted. This means that the service and workers can be used for a single run of a dependency scanner, and can't be reused across multiple, incremental runs. This is something that we'll most likely support in the future though. Note that the driver still utilizes the underlying real filesystem. This commit is also still missing the fast skipped PP block skipping optimization that I mentioned at EuroLLVM talk. Additionally, the file manager is still not reused by the threads as well. Differential Revision: https://reviews.llvm.org/D63907 llvm-svn: 368086
* Teach some warnings to respect gsl::Pointer and gsl::Owner attributesGabor Horvath2019-08-063-9/+233
| | | | | | | | This patch extends some existing warnings to utilize the knowledge about the gsl::Pointer and gsl::Owner attributes. Differential Revision: https://reviews.llvm.org/D64256 llvm-svn: 368072
* [Syntax] Do not add a node for 'eof' into the treeIlya Biryukov2019-08-062-13/+16
| | | | | | | | | | | | | | | | | | Summary: While useful as a sentinel value when iterating over tokens, having 'eof' in the tree, seems to do more harm than good. Reviewers: sammccall Reviewed By: sammccall Subscribers: javed.absar, kristof.beyls, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64576 llvm-svn: 368062
* [AST] Traverse attributes inside DEF_TRAVERSE_DECL macroIlya Biryukov2019-08-063-6/+112
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Instead of traversing inside the TraverseDecl() function. Previously the attributes were traversed after Travese(Some)Decl returns. Logically attributes are properties of particular Decls and should be traversed alongside other "child" nodes. None of the tests relied on this behavior, hopefully this is an indication that the change is relatively safe. This change started with a discussion on cfe-dev, for details see: https://lists.llvm.org/pipermail/cfe-dev/2019-July/062899.html Reviewers: rsmith, gribozavr Reviewed By: gribozavr Subscribers: mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64907 llvm-svn: 368052
* Improve MSVC visualizations so the parser shows where we are in the codeMike Spertus2019-08-061-0/+46
| | | | | | Also provide a visualizer for lambda introducers llvm-svn: 368029
* [CrossTU] Handle case when no USR could be generated during Decl search.Balazs Keri2019-08-067-12/+56
| | | | | | | | | | | | | | | | | | | Summary: When searching for a declaration to be loaded the "lookup name" for every other Decl is computed. If the USR can not be determined here should be not an assert, instead skip this Decl. Reviewers: martong Reviewed By: martong Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D65445 llvm-svn: 368020
* Add User docs for ASTImporterGabor Marton2019-08-062-0/+614
| | | | | | | | | | | | | | | | | Summary: This document includes the description of the ASTImporter from the user/client perspective. A subsequent patch will describe the development internals. Reviewers: a_sidorin, shafik, gamesh411, balazske, a.sidorin Subscribers: rnkovacs, dkrupp, arphaman, Szelethus, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D65573 llvm-svn: 368009
* [DirectoryWatcher] Fix asserts Mac buildsShoaib Meenai2019-08-061-1/+1
| | | | | | | Add a missing semicolon after an assert. Remove the period from the assert message while I'm here, because we don't usually have those. llvm-svn: 367984
* [Driver] Introduce -stdlib++-isystemShoaib Meenai2019-08-065-5/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are times when we wish to explicitly control the C++ standard library search paths used by the driver. For example, when we're building against the Android NDK, we might want to use the NDK's C++ headers (which have a custom inline namespace) even if we have C++ headers installed next to the driver. We might also be building against a non-standard directory layout and wanting to specify the C++ standard library include directories explicitly. We could accomplish this by passing -nostdinc++ and adding an explicit -isystem for our custom search directories. However, users of our toolchain may themselves want to use -nostdinc++ and a custom C++ search path (libc++'s build does this, for example), and our added -isystem won't respect the -nostdinc++, leading to multiple C++ header directories on the search path, which causes build failures. Add a new driver option -stdlib++-isystem to support this use case. Passing this option suppresses adding the default C++ library include paths in the driver, and it also respects -nostdinc++ to allow users to still override the C++ library paths themselves. It's a bit unfortunate that we end up with both -stdlib++-isystem and -cxx-isystem, but their semantics differ significantly. -cxx-isystem is unaffected by -nostdinc++ and is added to the end of the search path (which is not appropriate for C++ standard library headers, since they often #include_next into other system headers), while -stdlib++-isystem respects -nostdinc++, is added to the beginning of the search path, and suppresses the default C++ library include paths. Differential Revision: https://reviews.llvm.org/D64089 llvm-svn: 367982
* [Driver] Prioritize SYSROOT/usr/include over RESOURCE_DIR/include on linux-muslFangrui Song2019-08-062-5/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On a musl-based Linux distribution, stdalign.h stdarg.h stdbool.h stddef.h stdint.h stdnoreturn.h are expected to be provided by musl (/usr/include), instead of RESOURCE_DIR/include. Reorder RESOURCE_DIR/include to fix the search order problem. (Currently musl doesn't provide stdatomic.h. stdatomic.h is still found in RESOURCE_DIR/include.) gcc on musl has a similar search order: ``` /usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../include/c++/8.3.0 /usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../include/c++/8.3.0/x86_64-alpine-linux-musl /usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../include/c++/8.3.0/backward /usr/local/include /usr/include/fortify /usr/include /usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/include ``` This is different from a glibc-based distribution where RESOURCE_DIR/include is placed before SYSROOT/usr/include. According to the maintainer of musl: > musl does not support use/mixing of compiler-provided std headers with its headers, and intentionally has no mechanism for communicating with such headers as to which types have already been defined or still need to be defined. If the current include order, with clang's headers before the libc ones, works in some situations, it's only by accident. Reviewed by: phosek Differential Revision: https://reviews.llvm.org/D65699 llvm-svn: 367981
* [clang][DirectoryWatcher] Adding llvm::Expected error handling to create.Puyan Lotfi2019-08-065-25/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prior to this patch Unix style errno error reporting from the inotify layer was used by DirectoryWatcher::create to simply return a nullptr on error. This would generally be ok, except that in LLVM we have much more robust error reporting through the facilities of llvm::Expected. The other critical thing I stumbled across was that the unit tests for DirectoryWatcher were not failing abruptly when inotify_init() was reporting an error, but would continue with the testing and eventually hit a deadlock in a pathological machine state (ie in the unit test, the return nullptr on ::create was ignored). Generally this pathological state never happens on any build bot, so it is totally understandable that it was overlooked, but on a Linux desktop running a dubious desktop environment (which I will not name) there is a chance that said desktop environment could use up enough inotify instances to exceed the user's limit. These are the conditions that led me to hit the deadlock I am addressing in this patch with more robust error handling. With the new llvm::Expected error handling when your system runs out of inotify instances for your user, the unit test will be forced to handle the error or crash and report the issue to the user instead of weirdly deadlocking on a condition variable wait. Differential Revision: https://reviews.llvm.org/D65704 llvm-svn: 367979
* Builtins: Start adding half versions of math builtinsMatt Arsenault2019-08-063-0/+113
| | | | | | | | | | The implementation of the OpenCL builtin currently library uses 2 different hacks to get to the corresponding IR intrinsics from the source. This will allow removal of those. This is the set that is currently used (minus a few vector ones). llvm-svn: 367973
* [NFC][DirectoryWatchedTests] Unlocks mutexes before signaling condition variablePuyan Lotfi2019-08-061-2/+6
| | | | | | | | | | | | | | | | | This should not affect actual behavior, but should pessimize the threading less by avoiding the situation where: * mutex is still locked * T1 notifies on condition variable * T2 wakes to check mutex * T2 sees mutex is still locked * T2 waits * T1 unlocks mutex * T2 tries again, acquires mutex. Differential Revision: https://reviews.llvm.org/D65708 llvm-svn: 367968
* [Sema] attempt to appease buildbots after r367940George Burgess IV2019-08-051-1/+1
| | | | | | | | | | | | A buildbot got angry about this new test, with error messages like: warn-nullchar-nullptr.c Line 16: use of undeclared identifier 'u' It looks like this `u'c'` syntax was introduced in C11; I'm guessing some bots may default to something before that. Let's see if explicitly specifying the standard version makes it happy... llvm-svn: 367947
* [Sema] Add -Wpointer-compareGeorge Burgess IV2019-08-054-0/+84
| | | | | | | | | | | | This patch adds a warning that diagnoses comparisons of pointers to '\0'. This is often indicative of a bug (e.g. the user might've forgotten to dereference the pointer). Patch by Elaina Guan! Differential Revision: https://reviews.llvm.org/D65595 llvm-svn: 367940
* [docs] don't use :option: for Wall WextraJF Bastien2019-08-051-7/+7
| | | | | | The bots are sad that they're not documented. llvm-svn: 367918
* [docs] don't use :option: for C++ compatJF Bastien2019-08-051-2/+2
| | | | | | The bots are sad that they're not documented. llvm-svn: 367914
* Fix another uninit read found by msan after r367829Nico Weber2019-08-051-1/+1
| | | | llvm-svn: 367912
* [DirectoryWatcher][linux] Fix build for older kernelsJan Korous2019-08-051-2/+1
| | | | | | | | Apparently kernel support for IN_EXCL_UNLINK in inotify_add_watch() doesn't imply it's defined in sys/inotify.h. https://bugs.llvm.org/show_bug.cgi?id=42824 llvm-svn: 367906
* [OpenMP 5.0] Codegen support for user-defined mappers.Michael Kruse2019-08-057-87/+887
| | | | | | | | | | | | | | | | | | | This patch implements the code generation for OpenMP 5.0 declare mapper (user-defined mapper) constructs. For each declare mapper, a mapper function is generated. These mapper functions will be called by the runtime and/or other mapper functions to achieve user defined mapping. The design slides can be found at https://github.com/lingda-li/public-sharing/blob/master/mapper_runtime_design.pptx Re-commit after revert in r367773 because r367755 changed the LLVM-IR output such that a CHECK line failed. Patch by Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D59474 llvm-svn: 367905
* [AST] Fix buildbot failure because of raw string inside macro from 367839.Johan Vikstrom2019-08-051-1/+1
| | | | llvm-svn: 367892
* [docs] document -Weveything more bettererJF Bastien2019-08-051-7/+18
| | | | | | | | | | | | Reviewers: aaron.ballman Subscribers: jkorous, dexonsmith, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D65706 llvm-svn: 367889
* [AST] Fix RecursiveASTVisitorTest multiline string literal. NFCDavid Green2019-08-051-3/+3
| | | | | | | | Some compiler, notably older gccs (< 8) can have trouble with multiline raw string literals inside macros. This just moves the code outsize the macro, to attempt to appease the bots. llvm-svn: 367885
* Undo what looks like an unintentional change in r367829Nico Weber2019-08-051-3/+3
| | | | | | | | | The MSan bot was (rightfully) complaining that NumASTLoaded was unitialized, so put the initialization removed in r367829 back in. While here, remove two needless semicolons added in that change. llvm-svn: 367875
* [Driver] Properly use values-X[ca].o, values-xpg[46].o on SolarisRainer Orth2019-08-0511-1/+144
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Builtins-*-sunos :: compiler_rt_logbf_test.c currently FAILs on Solaris, both SPARC and x86, 32 and 64-bit. It turned out that this is due to different behaviour of logb depending on the C standard compiled for, as documented on logb(3M): RETURN VALUES Upon successful completion, these functions return the exponent of x. If x is subnormal: o For SUSv3-conforming applications compiled with the c99 com- piler driver (see standards(7)), the exponent of x as if x were normalized is returned. o Otherwise, if compiled with the cc compiler driver, -1022, -126, and -16382 are returned for logb(), logbf(), and logbl(), respectively. Studio c99 and gcc control this by linking with the appropriate version of values-xpg[46].o, but clang uses neither of those. The following patch fixes this by following what gcc does, as corrected some time ago in Fix use of Solaris values-Xc.o (PR target/40411) https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02350.html and https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02384.html. Tested on x86_64-pc-solaris2.11, sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu. Differential Revision: https://reviews.llvm.org/D64793 llvm-svn: 367866
OpenPOWER on IntegriCloud