summaryrefslogtreecommitdiffstats
path: root/clang/include
Commit message (Collapse)AuthorAgeFilesLines
...
* [Clang][Driver] Re-use the calling process instead of creating a new process ↵Alexandre Ganea2020-01-133-1/+29
| | | | | | | | | | | | | | | for the cc1 invocation With this patch, the clang tool will now call the -cc1 invocation directly inside the same process. Previously, the -cc1 invocation was creating, and waiting for, a new process. This patch therefore reduces the number of created processes during a build, thus it reduces build times on platforms where process creation can be costly (Windows) and/or impacted by a antivirus. It also makes debugging a bit easier, as there's no need to attach to the secondary -cc1 process anymore, breakpoints will be hit inside the same process. Crashes or signaling inside the -cc1 invocation will have the same side-effect as before, and will be reported through the same means. This behavior can be controlled at compile-time through the CLANG_SPAWN_CC1 cmake flag, which defaults to OFF. Setting it to ON will revert to the previous behavior, where any -cc1 invocation will create/fork a secondary process. At run-time, it is also possible to tweak the CLANG_SPAWN_CC1 environment variable. Setting it and will override the compile-time setting. A value of 0 calls -cc1 inside the calling process; a value of 1 will create a secondary process, as before. Differential Revision: https://reviews.llvm.org/D69825
* Sema::getOwningModule - take const Decl* type.Simon Pilgrim2020-01-131-1/+3
| | | | Fixes static analyzer warning that const_cast was being used despite only const methods being called.
* This option allows selecting the TLS size in the local exec TLS model,KAWASHIMA Takahiro2020-01-132-0/+6
| | | | | | | | | | | | | | | | | | which is the default TLS model for non-PIC objects. This allows large/ many thread local variables or a compact/fast code in an executable. Specification is same as that of GCC. For example, the code model option precedes the TLS size option. TLS access models other than local-exec are not changed. It means supoort of the large code model is only in the local exec TLS model. Patch By KAWASHIMA Takahiro (kawashima-fj <t-kawashima@fujitsu.com>) Reviewers: dmgreen, mstorsjo, t.p.northover, peter.smith, ostannard Reviewd By: peter.smith Committed by: peter.smith Differential Revision: https://reviews.llvm.org/D71688
* Fix "pointer is null" static analyzer warning. NFCI.Simon Pilgrim2020-01-121-0/+1
|
* Revert "[ASTMatchers] extract public matchers from const-analysis into own ↵Jonas Toth2020-01-111-110/+0
| | | | | | | | patch" This reverts commit 4c48ea68e491cb42f1b5d43ffba89f6a7f0dadc4. The powerpc buildbots had an internal compiler error after this patch. This requires some inspection.
* [ASTMatchers] extract public matchers from const-analysis into own patchJonas Toth2020-01-111-0/+110
| | | | | | | | | | | | | | | | | | | Summary: The analysis for const-ness of local variables required a view generally useful matchers that are extracted into its own patch. They are `decompositionDecl` and `forEachArgumentWithParamType`, that works for calls through function pointers as well. Reviewers: aaron.ballman Reviewed By: aaron.ballman Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D72505
* [Driver] Fix OptionClass of -fconvergent-functions and -fms-volatile (Joined ↵Fangrui Song2020-01-101-2/+2
| | | | -> Flag)
* driver: Allow -fdebug-compilation-dir=foo in joined form.Nico Weber2020-01-101-0/+3
| | | | | | | All 130+ f_Group flags that take an argument allow it after a '=', except for fdebug-complation-dir. Add a Joined<> alias so that it behaves consistently with all the other f_Group flags. (Keep the old Separate flag for backwards compat.)
* Improve precision of documentation comment.Richard Smith2020-01-101-2/+2
|
* Implement new AST matcher hasAnyCapture to match on LambdaExpr captures.Reid2020-01-101-0/+45
| | | | Accepts child matchers cxxThisExpr to match on capture of this and also on varDecl.
* [analyzer] Move PlacementNewChecker to alphaGabor Marton2020-01-101-6/+6
|
* [Driver][CodeGen] Add -fpatchable-function-entry=N[,0]Fangrui Song2020-01-103-0/+6
| | | | | | | | | | | In the backend, this feature is implemented with the function attribute "patchable-function-entry". Both the attribute and XRay use TargetOpcode::PATCHABLE_FUNCTION_ENTER, so the two features are incompatible. Reviewed By: ostannard, MaskRay Differential Revision: https://reviews.llvm.org/D72222
* Support function attribute patchable_function_entryFangrui Song2020-01-102-0/+21
| | | | | | | | | This feature is generic. Make it applicable for AArch64 and X86 because the backend has only implemented NOP insertion for AArch64 and X86. Reviewed By: nickdesaulniers, aaron.ballman Differential Revision: https://reviews.llvm.org/D72221
* [analyzer] Add PlacementNewCheckerGabor Marton2020-01-101-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This checker verifies if default placement new is provided with pointers to sufficient storage capacity. Noncompliant Code Example: #include <new> void f() { short s; long *lp = ::new (&s) long; } Based on SEI CERT rule MEM54-CPP https://wiki.sei.cmu.edu/confluence/display/cplusplus/MEM54-CPP.+Provide+placement+new+with+properly+aligned+pointe This patch does not implement checking of the alignment. Reviewers: NoQ, xazax.hun Subscribers: mgorny, whisperity, xazax.hun, baloghadamsoftware, szepet, rnkovacs, a.sidorin, mikhail.ramalho, donat Tags: #clang Differential Revision: https://reviews.llvm.org/D71612
* Add support for __declspec(guard(nocf))Andrew Paverd2020-01-102-0/+29
| | | | | | | | | | | | | | | | | | Summary: Avoid using the `nocf_check` attribute with Control Flow Guard. Instead, use a new `"guard_nocf"` function attribute to indicate that checks should not be added on indirect calls within that function. Add support for `__declspec(guard(nocf))` following the same syntax as MSVC. Reviewers: rnk, dmajor, pcc, hans, aaron.ballman Reviewed By: aaron.ballman Subscribers: aaron.ballman, tomrittervg, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D72167
* [ARM,MVE] Make `vqrshrun` generate the right instruction.Simon Tatham2020-01-101-1/+1
| | | | | | | | | | | | | | | | | | Summary: A copy-paste error in `arm_mve.td` meant that the MVE `vqrshrun` intrinsic family was generating the `vqshrun` machine instruction, because in the IR intrinsic call, the rounding flag argument was set to 0 rather than 1. Reviewers: dmgreen, MarkMurrayARM, miyuki, ostannard Reviewed By: dmgreen Subscribers: kristof.beyls, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D72496
* Allow system header to provide their own implementation of some builtinserge-sans-paille2020-01-101-0/+3
| | | | | | | | | | | | | | | | | | If a system header provides an (inline) implementation of some of their function, clang still matches on the function name and generate the appropriate llvm builtin, e.g. memcpy. This behavior is in line with glibc recommendation « users may not provide their own version of symbols » but doesn't account for the fact that glibc itself can provide inline version of some functions. It is the case for the memcpy function when -D_FORTIFY_SOURCE=1 is on. In that case an inline version of memcpy calls __memcpy_chk, a function that performs extra runtime checks. Clang currently ignores the inline version and thus provides no runtime check. This code fixes the issue by detecting functions whose name is a builtin name but also have an inline implementation. Differential Revision: https://reviews.llvm.org/D71082
* [Syntax] Update comment, remove stale FIXME. NFCIlya Biryukov2020-01-101-3/+3
|
* CWG2352: Allow qualification conversions during reference binding.Richard Smith2020-01-092-5/+7
| | | | | | | | | | | | | | | | | | | | | | The language wording change forgot to update overload resolution to rank implicit conversion sequences based on qualification conversions in reference bindings. The anticipated resolution for that oversight is implemented here -- we order candidates based on qualification conversion, not only on top-level cv-qualifiers, including ranking reference bindings against non-reference bindings if they differ in non-top-level qualification conversions. For OpenCL/C++, this allows reference binding between pointers with differing (nested) address spaces. This makes the behavior of reference binding consistent with that of implicit pointer conversions, as is the purpose of this change, but that pre-existing behavior for pointer conversions is itself probably not correct. In any case, it's now consistently the same behavior and implemented in only one place. This reinstates commit de21704ba96fa80d3e9402f12c6505917a3885f4, reverted in commit d8018233d1ea4234de68d5b4593abd773db79484, with workarounds for some overload resolution ordering problems introduced by CWG2352.
* When diagnosing the lack of a viable conversion function, also listRichard Smith2020-01-093-17/+15
| | | | | | | | | | | | | | explicit functions that are not candidates. It's not always obvious that the reason a conversion was not possible is because the function you wanted to call is 'explicit', so explicitly say if that's the case. It would be nice to rank the explicit candidates higher in the diagnostic if an implicit conversion sequence exists for their arguments, but unfortunately we can't determine that without potentially triggering non-immediate-context errors that we're not permitted to produce.
* Add builtins for aligning and checking alignment of pointers and integersAlex Richardson2020-01-093-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change introduces three new builtins (which work on both pointers and integers) that can be used instead of common bitwise arithmetic: __builtin_align_up(x, alignment), __builtin_align_down(x, alignment) and __builtin_is_aligned(x, alignment). I originally added these builtins to the CHERI fork of LLVM a few years ago to handle the slightly different C semantics that we use for CHERI [1]. Until recently these builtins (or sequences of other builtins) were required to generate correct code. I have since made changes to the default C semantics so that they are no longer strictly necessary (but using them does generate slightly more efficient code). However, based on our experience using them in various projects over the past few years, I believe that adding these builtins to clang would be useful. These builtins have the following benefit over bit-manipulation and casts via uintptr_t: - The named builtins clearly convey the semantics of the operation. While checking alignment using __builtin_is_aligned(x, 16) versus ((x & 15) == 0) is probably not a huge win in readably, I personally find __builtin_align_up(x, N) a lot easier to read than (x+(N-1))&~(N-1). - They preserve the type of the argument (including const qualifiers). When using casts via uintptr_t, it is easy to cast to the wrong type or strip qualifiers such as const. - If the alignment argument is a constant value, clang can check that it is a power-of-two and within the range of the type. Since the semantics of these builtins is well defined compared to arbitrary bit-manipulation, it is possible to add a UBSAN checker that the run-time value is a valid power-of-two. I intend to add this as a follow-up to this change. - The builtins avoids int-to-pointer casts both in C and LLVM IR. In the future (i.e. once most optimizations handle it), we could use the new llvm.ptrmask intrinsic to avoid the ptrtoint instruction that would normally be generated. - They can be used to round up/down to the next aligned value for both integers and pointers without requiring two separate macros. - In many projects the alignment operations are already wrapped in macros (e.g. roundup2 and rounddown2 in FreeBSD), so by replacing the macro implementation with a builtin call, we get improved diagnostics for many call-sites while only having to change a few lines. - Finally, the builtins also emit assume_aligned metadata when used on pointers. This can improve code generation compared to the uintptr_t casts. [1] In our CHERI compiler we have compilation mode where all pointers are implemented as capabilities (essentially unforgeable 128-bit fat pointers). In our original model, casts from uintptr_t (which is a 128-bit capability) to an integer value returned the "offset" of the capability (i.e. the difference between the virtual address and the base of the allocation). This causes problems for cases such as checking the alignment: for example, the expression `if ((uintptr_t)ptr & 63) == 0` is generally used to check if the pointer is aligned to a multiple of 64 bytes. The problem with offsets is that any pointer to the beginning of an allocation will have an offset of zero, so this check always succeeds in that case (even if the address is not correctly aligned). The same issues also exist when aligning up or down. Using the alignment builtins ensures that the address is used instead of the offset. While I have since changed the default C semantics to return the address instead of the offset when casting, this offset compilation mode can still be used by passing a command-line flag. Reviewers: rsmith, aaron.ballman, theraven, fhahn, lebedev.ri, nlopes, aqjune Reviewed By: aaron.ballman, lebedev.ri Differential Revision: https://reviews.llvm.org/D71499
* Improve support of GNU mempcpyserge-sans-paille2020-01-091-0/+1
| | | | | | | - Lower to the memcpy intrinsic - Raise warnings when size/bounds are known Differential Revision: https://reviews.llvm.org/D71374
* [ARM,MVE] Fix valid immediate range for vsliq_n.Simon Tatham2020-01-091-1/+1
| | | | | | | | | | | In common with most MVE immediate shift instructions, the left shift takes an immediate in the range [0,n-1], while the right shift takes one in the range [1,n]. I had absent-mindedly made them both the latter. While I'm here, I've added a set of regression tests checking both ends of the immediate range for a representative sample of the immediate shifts.
* [Concepts] Function trailing requires clausesSaar Raz2020-01-0912-38/+352
| | | | | | Function trailing requires clauses now parsed, supported in overload resolution and when calling, referencing and taking the address of functions or function templates. Differential Revision: https://reviews.llvm.org/D43357
* [NFC] Whitespace fixesGabor Horvath2020-01-082-3/+3
|
* Add a new AST matcher 'optionally'.Rihan Yang2020-01-082-0/+34
| | | | | | | | This matcher matches any node and at the same time executes all its inner matchers to produce any possbile result bindings. This is useful when a user wants certain supplementary information that's not always present along with the main match result.
* [ARM,MVE] Intrinsics for variable shift instructions.Simon Tatham2020-01-082-2/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This batch of intrinsics fills in all the shift instructions that take a variable shift distance in a register, instead of an immediate. Some of these instructions take a single shift distance in a scalar register and apply it to all lanes; others take a vector of per-lane distances. These instructions are all basically one family, varying in whether they saturate out-of-range values, and whether they round when bits are shifted off the bottom. I've implemented them at the IR level by a much smaller family of IR intrinsics, which take flag parameters to indicate saturating and/or rounding (along with the usual one to specify signed/unsigned integers). An oddity is that all of them are //left// shift instructions – but if you pass a negative shift count, they'll shift right. So the vector shift distances are always vectors of //signed// integers, regardless of whether you're considering the other input vector to be of signed or unsigned. Also, even the simplest `vshlq` instruction in this family (neither saturating nor rounding) has to be implemented as an IR intrinsic, because the ordinary LLVM IR `shl` operation would consider an out-of-range shift count to be undefined behavior. Reviewers: dmgreen, MarkMurrayARM, miyuki, ostannard Reviewed By: dmgreen Subscribers: kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D72329
* [ARM,MVE] Intrinsics for partial-overwrite imm shifts.Simon Tatham2020-01-082-5/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This batch of intrinsics covers two sets of immediate shift instructions, which have in common that they only overwrite part of their output register and so they need an extra input giving its previous value. The VSLI and VSRI instructions shift each lane of the input vector left or right just as if they were normal immediate VSHL/VSHR, but then they only overwrite the output bits that correspond to actual shifted bits of the input. So VSLI will leave the low n bits of each output lane unchanged, and VSRI the same with the top n bits. The V[Q][R]SHR[U]N family are all narrowing shifts: they take an input vector of 2n-bit integers, shift each lane right by a constant, and then narrowing the shifted result to only n bits. So they only overwrite half of the n-bit lanes in the output register, and the B/T suffix indicates whether it's the bottom or top half of each 2n-bit lane. I've implemented the whole of the latter family using a single IR intrinsic `vshrn`, which takes a lot of i32 parameters indicating which instruction it expands to (by specifying signedness of the input and output types, whether it saturates and/or rounds, etc). Reviewers: dmgreen, MarkMurrayARM, miyuki, ostannard Reviewed By: dmgreen Subscribers: kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D72328
* Disallow an empty string literal in an asm labelAaron Ballman2020-01-082-5/+4
| | | | | | | | An empty string literal in an asm label does not make a whole lot of sense. GCC does not diagnose such a construct, but it also generates code that cannot be assembled by gas should two symbols have an empty asm label within the same TU. This does not affect an asm statement with an empty string literal, which is still a useful construct.
* [clang-tidy] modernize-use-using uses AST and now supports struct defintions ↵Mitchell Balan2020-01-071-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | and multiple types in a typedef Summary: It now handles `typedef`s that include comma-separated multiple types, and handles embedded struct definitions, which previously could not be automatically converted. For example, with this patch `modernize-use-using` now can convert: typedef struct { int a; } R_t, *R_p; to: using R_t = struct { int a; }; using R_p = R_t*; `-ast-dump` showed that the `CXXRecordDecl` definitions and multiple `TypedefDecl`s come consecutively in the tree, so `check()` stores information between calls to determine when it is receiving a second or additional `TypedefDecl` within a single `typedef`, or when the current `TypedefDecl` refers to an embedded `CXXRecordDecl` like a `struct`. Reviewers: alexfh, aaron.ballman Patch by: poelmanc Subscribers: riccibruno, sammccall, cfe-commits, aaron.ballman Tags: clang-tools-extra, clang Differential Revision: https://reviews.llvm.org/D70270
* [OPENMP]Allow using of members in standalone declaration pragmas.Alexey Bataev2020-01-071-1/+25
| | | | | | | | | If standalone OpenMP declaration pragma, like declare mapper or declare reduction, is declared in the class context, it may reference a member (data or function) in its internal expressions/statements. So, the parsing of such pragmas must be dalayed just like the parsing of the member initializers/definitions before the completion of the class declaration.
* [analyzer] Update help text to reflect sarif supportGabor Horvath2020-01-071-1/+1
| | | | Differential Revision: https://reviews.llvm.org/D72289
* [LifetimeAnalysis] Do not forbid void deref type in gsl::Pointer/gsl::Owner ↵Gabor Horvath2020-01-072-3/+3
| | | | | | | | | | | annotations It turns out it is useful to be able to define the deref type as void. In case we have a type erased owner, we want to express that the pointee can be basically any type. It should not be unnatural to have a void deref type as we already familiar with "pointers to void". Differential Revision: https://reviews.llvm.org/D72097
* [HIP] Add option --gpu-max-threads-per-block=nYaxun (Sam) Liu2020-01-072-0/+4
| | | | | | Add this option to change the default launch bounds. Differential Revision: https://reviews.llvm.org/D71221
* [NFC] Use isX86() instead of getArch()Jim Lin2020-01-071-6/+2
| | | | | | | | | | | | | | Summary: This is a clean up for https://reviews.llvm.org/D72247. Reviewers: MaskRay, craig.topper, jhenderson Reviewed By: MaskRay Subscribers: hiraditya, rupprecht, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D72320
* Always deduce the lengths of contained parameter packs when deducing aRichard Smith2020-01-061-3/+5
| | | | | | | | | | | | | | | | | pack expansion. Previously, if all parameter / argument pairs for a pack expansion deduction were non-deduced contexts, we would not deduce the arity of the pack, and could end up deducing a different arity (leading to failures during substitution) or defaulting to an arity of 0 (leading to bad diagnostics about passing the wrong number of arguments to a variadic function). Instead, we now always deduce the arity for all involved packs any time we deduce a pack expansion. This will result in less substitution happening in some cases, which could avoid non-SFINAEable errors, and should generally improve the quality of diagnostics when passing initializer lists to variadic functions.
* Adds -Wrange-loop-analysis to -WallMark de Wever2020-01-061-1/+1
| | | | | | | | | | This makes the range loop warnings part of -Wall. Fixes PR32823: Warn about accidental coping of data in range based for Differential Revision: https://reviews.llvm.org/D68912 Recomitted after fixing the warnings it created.
* [ARM,MVE] Fix many signedness errors in MVE intrinsics.Simon Tatham2020-01-061-38/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Running an end-to-end test last week I noticed that a lot of the ACLE intrinsics that operate differently on vectors of signed and unsigned integers were ending up generating the signed version of the instruction unconditionally. This is because the IR intrinsics had no way to distinguish signed from unsigned: the LLVM type system just calls them both `v8i16` (or whatever), so you need either separate intrinsics for signed and unsigned, or a flag parameter that tells ISel which one to choose. This patch fixes all the problems of that kind that I've noticed, by adding an i32 flag parameter to many of the IR intrinsics which is set to 1 for unsigned (matching the existing practice in cases where we got it right), and conditioning all the isel patterns on that flag. So the fundamental change is in `IntrinsicsARM.td`, changing the low-level IR intrinsics API; there are knock-on changes in `arm_mve.td` (adjusting code gen for the ACLE intrinsics to use the modified API) and in `ARMInstrMVE.td` (adjusting isel to expect the new unsigned flags). The rest of this patch is boringly updating tests. Reviewers: dmgreen, miyuki, MarkMurrayARM Reviewed By: dmgreen Subscribers: kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D72270
* [ARM,MVE] Support -ve offsets in gather-load intrinsics.Simon Tatham2020-01-061-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The ACLE intrinsics with `gather_base` or `scatter_base` in the name are wrappers on the MVE load/store instructions that take a vector of base addresses and an immediate offset. The immediate offset can be up to 127 times the alignment unit, and it can be positive or negative. At the MC layer, we got that right. But in the Sema error checking for the wrapping intrinsics, the offset was erroneously constrained to be positive. To fix this I've adjusted the `imm_mem7bit` class in the Tablegen that defines the intrinsics. But that causes integer literals like `0xfffffffffffffe04` to appear in the autogenerated calls to `SemaBuiltinConstantArgRange`, which provokes a compiler warning because that's out of the non-overflowing range of an `int64_t`. So I've also tweaked `MveEmitter` to emit that as `-0x1fc` instead. Updated the tests of the Sema checks themselves, and also adjusted a random sample of the CodeGen tests to actually use negative offsets and prove they get all the way through code generation without causing a crash. Reviewers: dmgreen, miyuki, MarkMurrayARM Reviewed By: dmgreen Subscribers: kristof.beyls, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D72268
* Allow using traverse() with bindingsStephen Kelly2020-01-051-0/+11
|
* [SystemZ] Don't allow CL option -mpacked-stack with -mbackchain.Jonas Paulsson2020-01-031-0/+1
| | | | | | | -mpacked-stack is currently not supported with -mbackchain, so this should result in a compilation error message instead of being silently ignored. Review: Ulrich Weigand
* [OpenMP] diagnose zero-length array section in the depend clauseKelvin Li2020-01-031-0/+2
| | | | | | | The OpenMP specification disallows having zero-length array sections in the depend clause (OpenMP 5.0 2.17.11). Differential Revision: https://reviews.llvm.org/D71969
* Handle init statements in readability-else-after-returnNathan James2020-01-021-0/+29
| | | | | | | | | | Adds a new ASTMatcher condition called 'hasInitStatement()' that matches if, switch and range-for statements with an initializer. Reworked clang-tidy readability-else-after-return to handle variables in the if condition or init statements in c++17 ifs. Also checks if removing the else would affect object lifetimes in the else branch. Fixes PR44364.
* Revert "Adds -Wrange-loop-analysis to -Wall"Mark de Wever2020-01-011-1/+1
| | | | | | The sanitizer-x86_64-linux buildbot failed to build lld with -Werror. This reverts commit d8117542ac57f6051674ca70ea14c0e0d7d9b046.
* Adds -Wrange-loop-analysis to -WallMark de Wever2020-01-011-1/+1
| | | | | | | | This makes the range loop warnings part of -Wall. Fixes PR32823: Warn about accidental coping of data in range based for Differential Revision: https://reviews.llvm.org/D68912
* Adds fixit hints to the -Wrange-loop-analysisMark de Wever2020-01-011-0/+1
| | | | Differential Revision: https://reviews.llvm.org/D68913
* Implement additional traverse() overloadsStephen Kelly2019-12-312-0/+64
| | | | | | | | | | | | | | Summary: These overloads make it possible to wrap unless(), anyOf(), has() etc with the traverse matcher. Reviewers: aaron.ballman Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D71977
* Unnest struct in Matcher implementationStephen Kelly2019-12-311-18/+23
| | | | | This allows implementation of the traverse() matcher to surround matchers like unless().
* Revert "CWG2352: Allow qualification conversions during reference binding."David Blaikie2019-12-271-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit de21704ba96fa80d3e9402f12c6505917a3885f4. Regressed/causes this to error due to ambiguity: void f(const int * const &); void f(int *); int main() { int * x; f(x); } (in case it's important - the original case where this turned up was a member function overload in a class template with, essentially: f(const T1&) f(T2*) (where T1 == X const *, T2 == X)) It's not super clear to me if this ^ is expected behavior, in which case I'm sorry about the revert & happy to look into ways to fix the original code.
* Allow newlines in AST Matchers in clang-query filesStephen Kelly2019-12-271-13/+11
| | | | | | | | | | Reviewers: aaron.ballman Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D71842
OpenPOWER on IntegriCloud