summaryrefslogtreecommitdiffstats
path: root/clang/lib/Frontend
Commit message (Collapse)AuthorAgeFilesLines
...
* [Clang] Rename -split-dwarf-file to -split-dwarf-outputAaron Puchert2019-06-151-1/+1
| | | | | | | | | | | | | | | | | | Summary: This is the first in a series of changes trying to align clang -cc1 flags for Split DWARF with those of llc. The unfortunate side effect of having -split-dwarf-output for single file Split DWARF will disappear again in a subsequent change. The change is the result of a discussion in D59673. Reviewers: dblaikie, echristo Reviewed By: dblaikie Differential Revision: https://reviews.llvm.org/D63130 llvm-svn: 363494
* Add --print-supported-cpus flag for clang.Ziang Wan2019-06-141-0/+1
| | | | | | | | | | | | This patch allows clang users to print out a list of supported CPU models using clang [--target=<target triple>] --print-supported-cpus Then, users can select the CPU model to compile to using clang --target=<triple> -mcpu=<model> a.c It is a handy feature to help cross compilation. llvm-svn: 363464
* [WebAssembly] Modernize include path handlingSam Clegg2019-06-131-0/+8
| | | | | | | | | | Move include path construction from InitHeaderSearch::AddDefaultIncludePaths in the Driver which appears to be the more modern/correct way of doing things. Differential Revision: https://reviews.llvm.org/D63030 llvm-svn: 363241
* [libclang] Allow skipping warnings from all included filesNikolai Kosjar2019-06-111-22/+46
| | | | | | | | | | | | Depending on the included files and the used warning flags, e.g. - Weverything, a huge number of warnings can be reported for included files. As processing that many diagnostics comes with a performance impact and not all clients are interested in those diagnostics, add a flag to skip them. Differential Revision: https://reviews.llvm.org/D48116 llvm-svn: 363067
* [Frontend] SetUpDiagnosticLog should handle unowned diagnostic consumerAlex Lorenz2019-06-101-3/+7
| | | | | | | | | | | | | in the compiler The function SetUpDiagnosticLog that was called from createDiagnostics didn't handle the case where the diagnostics engine didn't own the diagnostics consumer. This is a potential problem for a clang tool, in particular some of the follow-up patches for clang-scan-deps will need this fix. Differential Revision: https://reviews.llvm.org/D63101 llvm-svn: 363009
* [analyzer] Add werror flag for analyzer warningsKeno Fischer2019-06-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | Summary: We're using the clang static analyzer together with a number of custom analyses in our CI system to ensure that certain invariants are statiesfied for by the code every commit. Unfortunately, there currently doesn't seem to be a good way to determine whether any analyzer warnings were emitted, other than parsing clang's output (or using scan-build, which then in turn parses clang's output). As a simpler mechanism, simply add a `-analyzer-werror` flag to CC1 that causes the analyzer to emit its warnings as errors instead. I briefly tried to have this be `Werror=analyzer` and make it go through that machinery instead, but that seemed more trouble than it was worth in terms of conflicting with options to the actual build and special cases that would be required to circumvent the analyzers usual attempts to quiet non-analyzer warnings. This is simple and it works well. Reviewed-By: NoQ, Szelethusw Differential Revision: https://reviews.llvm.org/D62885 llvm-svn: 362855
* Driver, IRGen: Set partitions on GlobalValues according to ↵Peter Collingbourne2019-06-071-0/+2
| | | | | | | | -fsymbol-partition flag. Differential Revision: https://reviews.llvm.org/D62636 llvm-svn: 362829
* Convert MemberExpr creation and serialization to work the same way asRichard Smith2019-06-062-43/+35
| | | | | | | | | | most / all other Expr subclasses. This reinstates r362551, reverted in r362597, with a fix to a bug that caused MemberExprs to sometimes have a null FoundDecl after a round-trip through an AST file. llvm-svn: 362756
* Revert "Factor out duplicated code building a MemberExpr and marking it" and ↵Benjamin Kramer2019-06-052-35/+43
| | | | | | | | "Convert MemberExpr creation and serialization to work the same way as" This reverts commits r362551 and r362563. Crashes during modules selfhost. llvm-svn: 362597
* Initial support for vectorization using MASSV (IBM MASS vector library)Nemanja Ivanovic2019-06-051-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Part 2 (the Clang portion) of D59881. This patch (first of two patches) enables the vectorizer to recognize the IBM MASS vector library routines. This patch specifically adds support for recognizing the -vector-library=MASSV option, and defines mappings from IEEE standard scalar math functions to generic PowerPC MASS vector counterparts. For instance, the generic PowerPC MASS vector entry for double-precision cbrt function is __cbrtd2_massv. The second patch will further lower the generic PowerPC vector entries to PowerPC subtarget-specific entries. For instance, the PowerPC generic entry cbrtd2_massv is lowered to cbrtd2_P9 for Power9 subtarget. The overall support for MASS vector library is presented as such in two patches for ease of review. Patch by Jeeva Paudel. Differential revision: https://reviews.llvm.org/D59881 llvm-svn: 362571
* Convert MemberExpr creation and serialization to work the same way asRichard Smith2019-06-042-43/+35
| | | | | | most / all other Expr subclasses. llvm-svn: 362551
* Add clang source minimizer that reduces source to directivesAlex Lorenz2019-06-032-1/+37
| | | | | | | | | | | | | | | | | | | | | that might affect the dependency list for a compilation This commit introduces a dependency directives source minimizer to clang that minimizes header and source files to the minimum necessary preprocessor directives for evaluating includes. It reduces the source down to #define, #include, The source minimizer works by lexing the input with a custom fast lexer that recognizes the preprocessor directives it cares about, and emitting those directives in the minimized source. It ignores source code, comments, and normalizes whitespace. It gives up and fails if seems any directives that it doesn't recognize as valid (e.g. #define 0). In addition to the source minimizer this patch adds a -print-dependency-directives-minimized-source CC1 option that allows you to invoke the minimizer from clang directly. Differential Revision: https://reviews.llvm.org/D55463 llvm-svn: 362459
* [OpenCL] Declare builtin functions using TableGenSven van Haastregt2019-06-031-1/+2
| | | | | | | | | | | | | | | | | | | | | | | This patch adds a `-fdeclare-opencl-builtins` command line option to the clang frontend. This enables clang to verify OpenCL C builtin function declarations using a fast StringMatcher lookup, instead of including the opencl-c.h file with the `-finclude-default-header` option. This avoids the large parse time penalty of the header file. This commit only adds the basic infrastructure and some of the OpenCL builtins. It does not cover all builtins defined by the various OpenCL specifications. As such, it is not a replacement for `-finclude-default-header` yet. RFC: http://lists.llvm.org/pipermail/cfe-dev/2018-November/060041.html Co-authored-by: Pierre Gondois Co-authored-by: Joey Gouly Co-authored-by: Sven van Haastregt Differential Revision: https://reviews.llvm.org/D60763 llvm-svn: 362371
* Fix the predefined exponent limit macros for the 16-bit IEEE format.John McCall2019-05-311-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The magnitude range of normalized _Float16 is 2^-14 (~6e-5) to (2-2^-10)*2^15 (65504). You might think, then, that the code is correct to defne FLT16_MIN_EXP and FLT16_MAX_EXP to be -14 and 15 respectively. However, for some reason the C specification actually specifies a bias for these macros: C11 5.2.4.2.2: - minimum negative integer such that FLT_RADIX raised to one less than that power is a normalized floating-point number, e_min: FLT_MIN_EXP DBL_MIN_EXP LDBL_MIN_EXP - maximum integer such that FLT_RADIX raised to one less than that power is a representable finite floating-point number, e_max: FLT_MAX_EXP DBL_MAX_EXP LDBL_MAX_EXP FLT16_MIN_EXP and FLT16_MAX_EXP should clearly be biased the same way, and other compilers do in fact do so, as do our OpenCL headers for `half`. Additionally, FLT16_MIN_10_EXP is just wrong. llvm-svn: 362183
* Do not resolve directory junctions for `-fdiagnostics-absolute-paths` on ↵Igor Kudrin2019-05-241-0/+21
| | | | | | | | | | | | | | Windows. If the source file path contains directory junctions, and we resolve them when printing diagnostic messages, these paths look independent for an IDE. For example, both Visual Studio and Visual Studio Code open separate editors for such paths, which is not only inconvenient but might even result in losing changes made in one of them. Differential Revision: https://reviews.llvm.org/D59415 llvm-svn: 361598
* [analyzer] List checker/plugin options in 3 categories: released, alpha, ↵Kristof Umann2019-05-231-0/+4
| | | | | | | | | | | | developer Same patch as D62093, but for checker/plugin options, the only difference being that options for alpha checkers are implicitly marked as alpha. Differential Revision: https://reviews.llvm.org/D62093 llvm-svn: 361566
* [analyzer] Hide developer-only checker/package options by defaultKristof Umann2019-05-231-0/+2
| | | | | | | | | These options are now only visible under -analyzer-checker-option-help-developer. Differential Revision: https://reviews.llvm.org/D61839 llvm-svn: 361561
* [analyzer] List checkers in 3 categories: released, alpha, developerKristof Umann2019-05-231-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, the only way to display the list of available checkers was to invoke the analyzer with -analyzer-checker-help frontend flag. This however wasn't really great from a maintainer standpoint: users came across checkers meant strictly for development purposes that weren't to be tinkered with, or those that were still in development. This patch creates a clearer division in between these categories. From now on, we'll have 3 flags to display the list checkers. These lists are mutually exclusive and can be used in any combination (for example to display both stable and alpha checkers). -analyzer-checker-help: Displays the list for stable, production ready checkers. -analyzer-checker-help-alpha: Displays the list for in development checkers. Enabling is discouraged for non-development purposes. -analyzer-checker-help-developer: Modeling and debug checkers. Modeling checkers shouldn't be enabled/disabled by hand, and debug checkers shouldn't be touched by users. Differential Revision: https://reviews.llvm.org/D62093 llvm-svn: 361558
* [analyzer] Add a new frontend flag to display all checker optionsKristof Umann2019-05-231-0/+1
| | | | | | | | | Add the new frontend flag -analyzer-checker-option-help to display all checker/package options. Differential Revision: https://reviews.llvm.org/D57858 llvm-svn: 361552
* [Frontend] Return an error on bad inputs to PrecompiledPreabmleIlya Biryukov2019-05-222-8/+10
| | | | | | | | | | | | | | | | | | Summary: Instead of failing with assertions. Fixes a crash found by oss-fuzz: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=12865 Reviewers: sammccall Reviewed By: sammccall Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D62137 llvm-svn: 361376
* [PragmaHandler] Expose `#pragma` locationJoel E. Denny2019-05-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Currently, a pragma AST node's recorded location starts at the namespace token (such as `omp` in the case of OpenMP) after the `#pragma` token, and the `#pragma` location isn't available. However, the `#pragma` location can be useful when, for example, rewriting a directive using Clang's Rewrite facility. This patch makes `#pragma` locations available in any `PragmaHandler` but it doesn't yet make use of them. This patch also uses the new `struct PragmaIntroducer` to simplify `Preprocessor::HandlePragmaDirective`. It doesn't do the same for `PPCallbacks::PragmaDirective` because that changes the API documented in `clang-tools-extra/docs/pp-trace.rst`, and I'm not sure about backward compatibility guarantees there. Reviewed By: ABataev, lebedev.ri, aaron.ballman Differential Revision: https://reviews.llvm.org/D61643 llvm-svn: 361335
* [clang][Darwin] Refactor header search path logic into the driverLouis Dionne2019-05-211-51/+15
| | | | | | | | | | | | | | | | | | | | | | | Summary: This commit moves the logic for determining system, resource and C++ header search paths from CC1 to the driver. This refactor has already been made for several platforms, but Darwin had been left behind. This refactor tries to implement the previous search path logic with perfect accuracy. In particular, the order of all include paths inside CC1 and all paths that were skipped because nonexistent are conserved after the refactor. This change was also tested against a code base of significant size and revealed no problems. Reviewers: jfb, arphaman Subscribers: nemanjai, javed.absar, kbarton, christof, jkorous, dexonsmith, jsji, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61963 llvm-svn: 361278
* [ARM][CMSE] Add commandline option and feature macroJaved Absar2019-05-211-0/+1
| | | | | | | | | | | Defines macro ARM_FEATURE_CMSE to 1 for v8-M targets and introduces -mcmse option which for v8-M targets sets ARM_FEATURE_CMSE to 3. A diagnostic is produced when the option is given on architectures without support for Security Extensions. Reviewed By: dmgreen, snidertm Differential Revision: https://reviews.llvm.org/D59879 llvm-svn: 361261
* [Preamble] Reuse preamble even if an unsaved file does not existNikolai Kosjar2019-05-212-17/+33
| | | | | | | | | | | | | | | | | | | | | When a preamble is created an unsaved file not existing on disk is already part of PrecompiledPreamble::FilesInPreamble. However, when checking whether the preamble can be re-used, a failed stat of such an unsaved file invalidated the preamble, which led to pointless and time consuming preamble regenerations on subsequent reparses. Do not require anymore that unsaved files should exist on disk. This avoids costly preamble invalidations depending on timing issues for the cases where the file on disk might be removed just to be regenerated a bit later. It also allows an IDE to provide in-memory files that might not exist on disk, e.g. because the build system hasn't generated those yet. Differential Revision: https://reviews.llvm.org/D41005 llvm-svn: 361226
* [Lex] Allow to consume tokens while preprocessingIlya Biryukov2019-05-171-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: By adding a hook to consume all tokens produced by the preprocessor. The intention of this change is to make it possible to consume the expanded tokens without re-runnig the preprocessor with minimal changes to the preprocessor and minimal performance penalty when preprocessing without recording the tokens. The added hook is very low-level and reconstructing the expanded token stream requires more work in the client code, the actual algorithm to collect the tokens using this hook can be found in the follow-up change. Reviewers: rsmith Reviewed By: rsmith Subscribers: eraman, nemanjai, kbarton, jsji, riccibruno, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D59885 llvm-svn: 361007
* [ASTImporter] Use llvm::Expected and Error in the importer APIGabor Marton2019-05-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | Summary: This is the final phase of the refactoring towards using llvm::Expected and llvm::Error in the ASTImporter API. This involves the following: - remove old Import functions which returned with a pointer, - use the Import_New functions (which return with Err or Expected) everywhere and handle their return value - rename Import_New functions to Import This affects both Clang and LLDB. Reviewers: shafik, teemperor, aprantl, a_sidorin, balazske, a.sidorin Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits, lldb-commits Tags: #clang, #lldb Differential Revision: https://reviews.llvm.org/D61438 llvm-svn: 360760
* Temporarily revert "Change -gz and -Wa,--compress-debug-sections to use gABI ↵Eric Christopher2019-05-141-1/+2
| | | | | | | | | | | | | compression (SHF_COMPRESSED)" This affects users of older (pre 2.26) binutils in such a way that they can't necessarily work around it as it doesn't support the compress option on the command line. Reverting to unblock them and we can revisit whether to make this change now or fix how we want to express the option. This reverts commit bdb21337e6e1732c9895966449c33c408336d295/r360403. llvm-svn: 360703
* Add a new language mode for C2x; enable [[attribute]] support by default in C2x.Aaron Ballman2019-05-141-2/+6
| | | | llvm-svn: 360667
* Introduce the ability to dump the AST to JSON.Aaron Ballman2019-05-133-17/+35
| | | | | | This adds the -ast-dump=json cc1 flag (in addition to -ast-dump=default, which is the default if no dump format is specified), as well as some initial AST dumping functionality and tests. llvm-svn: 360622
* Change -gz and -Wa,--compress-debug-sections to use gABI compression ↵Fangrui Song2019-05-101-2/+1
| | | | | | | | | | | | | | | | | | | | | | | (SHF_COMPRESSED) Since July 15, 2015 (binutils-gdb commit 19a7fe52ae3d0971e67a134bcb1648899e21ae1c, included in 2.26), gas --compress-debug-sections=zlib (gcc -gz) means zlib-gabi: SHF_COMPRESSED. Before that it meant zlib-gnu (.zdebug). clang's -gz was introduced in rC306115 (Jun 2017) to indicate zlib-gnu. It is 2019 now and it is not unreasonable to assume users of the new feature to have new linkers (ld.bfd/gold >= 2.26, lld >= rLLD273661). Change clang's default accordingly to improve standard conformance. zlib-gnu becomes out of fashion and gets poorer toolchain support. Its mangled names confuse tools and are more likely to cause problems. Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D61689 llvm-svn: 360403
* [SPIR] Simplified target checking.Anastasia Stulova2019-05-092-5/+2
| | | | | | | | | | Switched to Triple::isSPIR() helper to simplify code. Patch by kpet (Kevin Petit)! Differential revision: https://reviews.llvm.org/D61639 llvm-svn: 360325
* [c++20] Add support for explicit(bool), as described in P0892R2.Richard Smith2019-05-091-0/+2
| | | | | | | | Patch by Tyker! Differential Revision: https://reviews.llvm.org/D60934 llvm-svn: 360311
* Revert r359949 "[clang] adding explicit(bool) from c++2a"Hans Wennborg2019-05-061-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This caused Clang to start erroring on the following: struct S {   template <typename = int> explicit S(); }; struct T : S {}; struct U : T {   U(); }; U::U() {} $ clang -c /tmp/x.cc /tmp/x.cc:10:4: error: call to implicitly-deleted default constructor of 'T' U::U() {}    ^ /tmp/x.cc:5:12: note: default constructor of 'T' is implicitly deleted because base class 'S' has no default constructor struct T : S {};            ^ 1 error generated. See discussion on the cfe-commits email thread. This also reverts the follow-ups r359966 and r359968. > this patch adds support for the explicit bool specifier. > > Changes: > - The parsing for the explicit(bool) specifier was added in ParseDecl.cpp. > - The storage of the explicit specifier was changed. the explicit specifier was stored as a boolean value in the FunctionDeclBitfields and in the DeclSpec class. now it is stored as a PointerIntPair<Expr*, 2> with a flag and a potential expression in CXXConstructorDecl, CXXDeductionGuideDecl, CXXConversionDecl and in the DeclSpec class. > - Following the AST change, Serialization, ASTMatchers, ASTComparator and ASTPrinter were adapted. > - Template instantiation was adapted to instantiate the potential expressions of the explicit(bool) specifier When instantiating their associated declaration. > - The Add*Candidate functions were adapted, they now take a Boolean indicating if the context allowing explicit constructor or conversion function and this boolean is used to remove invalid overloads that required template instantiation to be detected. > - Test for Semantic and Serialization were added. > > This patch is not yet complete. I still need to check that interaction with CTAD and deduction guides is correct. and add more tests for AST operations. But I wanted first feedback. > Perhaps this patch should be spited in smaller patches, but making each patch testable as a standalone may be tricky. > > Patch by Tyker > > Differential Revision: https://reviews.llvm.org/D60934 llvm-svn: 360024
* [clang] adding explicit(bool) from c++2aNicolas Lesser2019-05-041-0/+2
| | | | | | | | | | | | | | | | | | | | | this patch adds support for the explicit bool specifier. Changes: - The parsing for the explicit(bool) specifier was added in ParseDecl.cpp. - The storage of the explicit specifier was changed. the explicit specifier was stored as a boolean value in the FunctionDeclBitfields and in the DeclSpec class. now it is stored as a PointerIntPair<Expr*, 2> with a flag and a potential expression in CXXConstructorDecl, CXXDeductionGuideDecl, CXXConversionDecl and in the DeclSpec class. - Following the AST change, Serialization, ASTMatchers, ASTComparator and ASTPrinter were adapted. - Template instantiation was adapted to instantiate the potential expressions of the explicit(bool) specifier When instantiating their associated declaration. - The Add*Candidate functions were adapted, they now take a Boolean indicating if the context allowing explicit constructor or conversion function and this boolean is used to remove invalid overloads that required template instantiation to be detected. - Test for Semantic and Serialization were added. This patch is not yet complete. I still need to check that interaction with CTAD and deduction guides is correct. and add more tests for AST operations. But I wanted first feedback. Perhaps this patch should be spited in smaller patches, but making each patch testable as a standalone may be tricky. Patch by Tyker Differential Revision: https://reviews.llvm.org/D60934 llvm-svn: 359949
* [analyzer] Don't display implementation checkers under ↵Kristof Umann2019-05-011-0/+1
| | | | | | | | | | | | | | | | | | | | | | | -analyzer-checker-help, but do under the new flag -analyzer-checker-help-hidden During my work on analyzer dependencies, I created a great amount of new checkers that emitted no diagnostics at all, and were purely modeling some function or another. However, the user shouldn't really disable/enable these by hand, hence this patch, which hides these by default. I intentionally chose not to hide alpha checkers, because they have a scary enough name, in my opinion, to cause no surprise when they emit false positives or cause crashes. The patch introduces the Hidden bit into the TableGen files (you may remember it before I removed it in D53995), and checkers that are either marked as hidden, or are in a package that is marked hidden won't be displayed under -analyzer-checker-help. -analyzer-checker-help-hidden, a new flag meant for developers only, displays the full list. Differential Revision: https://reviews.llvm.org/D60925 llvm-svn: 359720
* [analyzer][NFC] Reimplement checker optionsKristof Umann2019-04-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TL;DR: * Add checker and package options to the TableGen files * Added a new class called CmdLineOption, and both Package and Checker recieved a list<CmdLineOption> field. * Added every existing checker and package option to Checkers.td. * The CheckerRegistry class * Received some comments to most of it's inline classes * Received the CmdLineOption and PackageInfo inline classes, a list of CmdLineOption was added to CheckerInfo and PackageInfo * Added addCheckerOption and addPackageOption * Added a new field called Packages, used in addPackageOptions, filled up in addPackage Detailed description: In the last couple months, a lot of effort was put into tightening the analyzer's command line interface. The main issue is that it's spectacularly easy to mess up a lenghty enough invocation of the analyzer, and the user was given no warnings or errors at all in that case. We can divide the effort of resolving this into several chapters: * Non-checker analyzer configurations: Gather every analyzer configuration into a dedicated file. Emit errors for non-existent configurations or incorrect values. Be able to list these configurations. Tighten AnalyzerOptions interface to disallow making such a mistake in the future. * Fix the "Checker Naming Bug" by reimplementing checker dependencies: When cplusplus.InnerPointer was enabled, it implicitly registered unix.Malloc, which implicitly registered some sort of a modeling checker from the CStringChecker family. This resulted in all of these checker objects recieving the name "cplusplus.InnerPointer", making AnalyzerOptions asking for the wrong checker options from the command line: cplusplus.InnerPointer:Optimisic istead of unix.Malloc:Optimistic. This was resolved by making CheckerRegistry responsible for checker dependency handling, instead of checkers themselves. * Checker options: (this patch included!) Same as the first item, but for checkers. (+ minor fixes here and there, and everything else that is yet to come) There were several issues regarding checker options, that non-checker configurations didn't suffer from: checker plugins are loaded runtime, and they could add new checkers and new options, meaning that unlike for non-checker configurations, we can't collect every checker option purely by generating code. Also, as seen from the "Checker Naming Bug" issue raised above, they are very rarely used in practice, and all sorts of skeletons fell out of the closet while working on this project. They were extremely problematic for users as well, purely because of how long they were. Consider the following monster of a checker option: alpha.cplusplus.UninitializedObject:CheckPointeeInitialization=false While we were able to verify whether the checker itself (the part before the colon) existed, any errors past that point were unreported, easily resulting in 7+ hours of analyses going to waste. This patch, similarly to how dependencies were reimplemented, uses TableGen to register checker options into Checkers.td, so that Checkers.inc now contains entries for both checker and package options. Using the preprocessor, Checkers.inc is converted into code in CheckerRegistry, adding every builtin (checkers and packages that have an entry in the Checkers.td file) checker and package option to the registry. The new addPackageOption and addCheckerOption functions expose the same functionality to statically-linked non-builtin and plugin checkers and packages as well. Emitting errors for incorrect user input, being able to list these options, and some other functionalies will land in later patches. Differential Revision: https://reviews.llvm.org/D57855 llvm-svn: 358752
* [CodeComplete] Remove obsolete isOutputBinary().Sam McCall2019-04-182-8/+1
| | | | | | | | | | | | | | | | Summary: It's never set to true. Its only effect would be to set stdout to binary mode. Hopefully we have better ways of doing this by now :-) Reviewers: hokein Subscribers: jkorous, arphaman, kadircet, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60871 llvm-svn: 358696
* [c++20] Enable driver and frontend support for building and usingRichard Smith2019-04-141-3/+3
| | | | | | modules when -std=c++2a is specified. llvm-svn: 358355
* [verify] Add support for location markers in directives.Richard Smith2019-04-131-145/+289
| | | | | | | | | | | | | | | A marker (matching /#[A-Za-z0-9_-]/) is specified by attaching a comment containing the marker to the line at which the diagnostic is expected, and then can be referenced from an expected-* directive after an @: foo // #1 // expected-error@#1 {{undeclared identifier 'foo'}} The intent is for markers to be used in situations where relative line numbers are currently used, to avoid the need to renumber when the test case is rearranged. llvm-svn: 358326
* [C++20] Implement context-sensitive header-name lexing and pp-import parsing ↵Richard Smith2019-04-112-4/+18
| | | | | | in the preprocessor. llvm-svn: 358231
* Changed every use of ASTImporter::Import to Import_NewBalazs Keri2019-04-081-3/+5
| | | | | | | | | | | | | | Reviewers: a.sidorin, shafik, martong, a_sidorin Reviewed By: a_sidorin Subscribers: rnkovacs, dkrupp, martong, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D55049 llvm-svn: 357913
* Make SourceManager::createFileID(UnownedTag, ...) take a const ↵Nico Weber2019-04-041-1/+1
| | | | | | | | | | | | | | | | | | | | | llvm::MemoryBuffer* Requires making the llvm::MemoryBuffer* stored by SourceManager const, which in turn requires making the accessors for that return const llvm::MemoryBuffer*s and updating all call sites. The original motivation for this was to use it and fix the TODO in CodeGenAction.cpp's ConvertBackendLocation() by using the UnownedTag version of createFileID, and since llvm::SourceMgr* hands out a const llvm::MemoryBuffer* this is required. I'm not sure if fixing the TODO this way actually works, but this seems like a good change on its own anyways. No intended behavior change. Differential Revision: https://reviews.llvm.org/D60247 llvm-svn: 357724
* Range-style std::find{,_if} -> llvm::find{,_if}. NFCFangrui Song2019-03-312-5/+4
| | | | llvm-svn: 357359
* Adds `-ftime-trace` option to clang that produces Chrome `chrome://tracing` ↵Anton Afanasyev2019-03-302-0/+5
| | | | | | | | | | | | | | compatible JSON profiling output dumps. This change adds hierarchical "time trace" profiling blocks that can be visualized in Chrome, in a "flame chart" style. Each profiling block can have a "detail" string that for example indicates the file being processed, template name being instantiated, function being optimized etc. This is taken from GitHub PR: https://github.com/aras-p/llvm-project-20170507/pull/2 Patch by Aras Pranckevičius. Differential Revision: https://reviews.llvm.org/D58675 llvm-svn: 357340
* Basic: Return a reference from FileManager::getVirtualFileSystem, NFCDuncan P. N. Exon Smith2019-03-263-13/+14
| | | | | | | | | | FileManager constructs a VFS in its constructor if it isn't passed one, and there's no way to reset it. Make that contract clear by returning a reference from its accessor. https://reviews.llvm.org/D59388 llvm-svn: 357038
* Frontend: Remove CompilerInstance::VirtualFileSystem, NFCDuncan P. N. Exon Smith2019-03-262-29/+21
| | | | | | | | | | | | | | | Remove CompilerInstance::VirtualFileSystem and CompilerInstance::setVirtualFileSystem, instead relying on the VFS in the FileManager. CompilerInstance and its clients already went to some trouble to make these match. Now they are guaranteed to match. As part of this, I added a VFS parameter (defaults to nullptr) to CompilerInstance::createFileManager, to avoid repeating construction logic in clients that just wanted to customize the VFS. https://reviews.llvm.org/D59377 llvm-svn: 357037
* Add PragmaHandler for MSVC pragma execution_character_setReid Kleckner2019-03-141-0/+20
| | | | | | | | | | | | __pragma(execution_character_set(push, "UTF-8")) is used in TraceLoggingProvider.h. This commit implements a no-op handler for compatability, similar to how the flag -fexec_charset is handled. Patch by Matt Gardner! Differential Revision: https://reviews.llvm.org/D58530 llvm-svn: 356185
* Reland "[Remarks] Add -foptimization-record-passes to filter remark emission"Francis Visoiu Mistrih2019-03-121-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | Currently we have -Rpass for filtering the remarks that are displayed as diagnostics, but when using -fsave-optimization-record, there is no way to filter the remarks while generating them. This adds support for filtering remarks by passes using a regex. Ex: `clang -fsave-optimization-record -foptimization-record-passes=inline` will only emit the remarks coming from the pass `inline`. This adds: * `-fsave-optimization-record` to the driver * `-opt-record-passes` to cc1 * `-lto-pass-remarks-filter` to the LTOCodeGenerator * `--opt-remarks-passes` to lld * `-pass-remarks-filter` to llc, opt, llvm-lto, llvm-lto2 * `-opt-remarks-passes` to gold-plugin Differential Revision: https://reviews.llvm.org/D59268 Original llvm-svn: 355964 llvm-svn: 355984
* Revert "[Remarks] Add -foptimization-record-passes to filter remark emission"Francis Visoiu Mistrih2019-03-121-5/+0
| | | | | | This reverts commit 20fff32b7d1f1a1bd417b22aa9f26ededd97a3e5. llvm-svn: 355976
* [Remarks] Add -foptimization-record-passes to filter remark emissionFrancis Visoiu Mistrih2019-03-121-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | Currently we have -Rpass for filtering the remarks that are displayed as diagnostics, but when using -fsave-optimization-record, there is no way to filter the remarks while generating them. This adds support for filtering remarks by passes using a regex. Ex: `clang -fsave-optimization-record -foptimization-record-passes=inline` will only emit the remarks coming from the pass `inline`. This adds: * `-fsave-optimization-record` to the driver * `-opt-record-passes` to cc1 * `-lto-pass-remarks-filter` to the LTOCodeGenerator * `--opt-remarks-passes` to lld * `-pass-remarks-filter` to llc, opt, llvm-lto, llvm-lto2 * `-opt-remarks-passes` to gold-plugin Differential Revision: https://reviews.llvm.org/D59268 llvm-svn: 355964
OpenPOWER on IntegriCloud