summaryrefslogtreecommitdiffstats
path: root/clang/lib/Frontend
Commit message (Collapse)AuthorAgeFilesLines
...
* [clang-scan-deps] print the dependencies to stdoutAlex Lorenz2019-06-211-0/+4
| | | | | | | | and remove the need to use -MD options in the CDB Differential Revision: https://reviews.llvm.org/D63579 llvm-svn: 364088
* [clang-ifs] Clang Interface Stubs, first version (second landing attempt).Puyan Lotfi2019-06-203-0/+400
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change reverts r363649; effectively re-landing r363626. At this point clang::Index::CodegenNameGeneratorImpl has been refactored into clang::AST::ASTNameGenerator. This makes it so that the previous circular link dependency no longer exists, fixing the previous share lib (-DBUILD_SHARED_LIBS=ON) build issue which was the reason for r363649. Clang interface stubs (previously referred to as clang-ifsos) is a new frontend action in clang that allows the generation of stub files that contain mangled name info that can be used to produce a stub library. These stub libraries can be useful for breaking up build dependencies and controlling access to a library's internal symbols. Generation of these stubs can be invoked by: clang -fvisibility=<visibility> -emit-interface-stubs \ -interface-stub-version=<interface format> Notice that -fvisibility (along with use of visibility attributes) can be used to control what symbols get generated. Currently the interface format is experimental but there are a wide range of possibilities here. Currently clang-ifs produces .ifs files that can be thought of as analogous to object (.o) files, but just for the mangled symbol info. In a subsequent patch I intend to add support for merging the .ifs files into one .ifs/.ifso file that can be the input to something like llvm-elfabi to produce something like a .so file or .dll (but without any of the code, just symbols). Differential Revision: https://reviews.llvm.org/D60974 llvm-svn: 363948
* Unify DependencyFileGenerator class and DependencyCollector interface (NFCI)Alex Lorenz2019-06-192-215/+73
| | | | | | | | | | | | | | Make DependencyFileGenerator a DependencyCollector as it was intended when DependencyCollector was introduced. The missing PPCallbacks overrides are added to the DependencyCollector as well. This change will allow clang-scan-deps to access the produced dependencies without writing them out to .d files to disk, so that it will be able collate them and report them to the user. Differential Revision: https://reviews.llvm.org/D63290 llvm-svn: 363840
* [OpenCL] Split type and macro definitions into opencl-c-base.hSven van Haastregt2019-06-191-2/+8
| | | | | | | | | | | | | | | | Using the -fdeclare-opencl-builtins option will require a way to predefine types and macros such as `int4`, `CLK_GLOBAL_MEM_FENCE`, etc. Move these out of opencl-c.h into opencl-c-base.h such that the latter can be shared by -fdeclare-opencl-builtins and -finclude-default-header. This changes the behaviour of -finclude-default-header when -fdeclare-opencl-builtins is specified: instead of including the full header, it will include the header with only the base definitions. Differential revision: https://reviews.llvm.org/D63256 llvm-svn: 363794
* Revert D60974 "[clang-ifs] Clang Interface Stubs, first version."Fangrui Song2019-06-183-402/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit rC363626. clangIndex depends on clangFrontend. r363626 adds a dependency from clangFrontend to clangIndex, which creates a circular dependency. This is disallowed by -DBUILD_SHARED_LIBS=on builds: CMake Error: The inter-target dependency graph contains the following strongly connected component (cycle): "clangFrontend" of type SHARED_LIBRARY depends on "clangIndex" (weak) "clangIndex" of type SHARED_LIBRARY depends on "clangFrontend" (weak) At least one of these targets is not a STATIC_LIBRARY. Cyclic dependencies are allowed only among static libraries. Note, the dependency on clangIndex cannot be removed because libclangFrontend.so is linked with -Wl,-z,defs: a shared object must have its full direct dependencies specified on the linker command line. In -DBUILD_SHARED_LIBS=off builds, this appears to work when linking `bin/clang-9`. However, it can cause trouble to downstream clang library users. The llvm build system links libraries this way: clang main_program_object_file ... lib/libclangIndex.a ... lib/libclangFrontend.a -o exe libclangIndex.a etc are not wrapped in --start-group. If the downstream application depends on libclangFrontend.a but not any other clang libraries that depend on libclangIndex.a, this can cause undefined reference errors when the linker is ld.bfd or gold. The proper fix is to not include clangIndex files in clangFrontend. llvm-svn: 363649
* [NFC] Undoing r363646 to fix bots.Puyan Lotfi2019-06-181-0/+1
| | | | | | | | -DBUILD_SHARED_LIBS=ON is still having problem caused by layering issues with D60974. Locally there weren't problems building with shared libs on or off but the bots appear to be acting up. llvm-svn: 363648
* [NFC] Fixing -DBUILD_SHARED_LIBS=ON problem caused by layering issue in D60974Puyan Lotfi2019-06-181-1/+0
| | | | llvm-svn: 363646
* [clang-ifs] Clang Interface Stubs, first version.Puyan Lotfi2019-06-173-0/+402
| | | | | | | | | | | | | | | | | | | Clang interface stubs (previously referred to as clang-ifsos) is a new frontend action in clang that allows the generation of stub files that contain mangled name info that can be used to produce a stub library. These stub libraries can be useful for breaking up build dependencies and controlling access to a library's internal symbols. Generation of these stubs can be invoked by: clang -fvisibility=<visibility> -emit-interface-stubs \ -interface-stub-version=<interface format> Notice that -fvisibility (along with use of visibility attributes) can be used to control what symbols get generated. Currently the interface format is experimental but there are a wide range of possibilities here. Differential Revision: https://reviews.llvm.org/D60974 llvm-svn: 363626
* [Remarks] Extend -fsave-optimization-record to specify the formatFrancis Visoiu Mistrih2019-06-171-0/+5
| | | | | | | | | Use -fsave-optimization-record=<format> to specify a different format than the default, which is YAML. For now, only YAML is supported. llvm-svn: 363573
* [Clang] Harmonize Split DWARF options with llcAaron Puchert2019-06-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: With Split DWARF the resulting object file (then called skeleton CU) contains the file name of another ("DWO") file with the debug info. This can be a problem for remote compilation, as it will contain the name of the file on the compilation server, not on the client. To use Split DWARF with remote compilation, one needs to either * make sure only relative paths are used, and mirror the build directory structure of the client on the server, * inject the desired file name on the client directly. Since llc already supports the latter solution, we're just copying that over. We allow setting the actual output filename separately from the value of the DW_AT_[GNU_]dwo_name attribute in the skeleton CU. Fixes PR40276. Reviewers: dblaikie, echristo, tejohnson Reviewed By: dblaikie Differential Revision: https://reviews.llvm.org/D59673 llvm-svn: 363496
* [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
OpenPOWER on IntegriCloud