| Commit message (Collapse) | Author | Age | Files | Lines | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
primitive.
https://bugs.llvm.org/show_bug.cgi?id=41741
Pretty much the same as D61246 and D61106, this time for __complex__ types. Upon
further investigation, I realized that we should regard all types
Type::isScalarType returns true for as primitive, so I merged 
isMemberPointerType(), isBlockPointerType() and isAnyComplexType()` into that
instead.
I also stumbled across yet another bug,
https://bugs.llvm.org/show_bug.cgi?id=41753, but it seems to be unrelated to
this checker.
Differential Revision: https://reviews.llvm.org/D61569
llvm-svn: 359998
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
false positives
where either the modification or the other access is unreachable.
........
Try to fix buildbots
llvm-svn: 359984
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Summary:
currently for:
```
 template<typename ... T>
void f(T... t) {
  auto l = [t...]{};
}
```
`clang -ast-print file.cpp`
outputs:
```
template <typename ...T> void f(T ...t) {
    auto l = [t]         {
        }
;
}
```
notice that there is not `...` in the capture list of the lambda. this patch fixes this issue. and add test for it.
Patch by Tyker
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D61556
llvm-svn: 359980
 | 
| | 
| 
| 
| 
| 
|  | 
instead of as parameter name without a type.
llvm-svn: 359979
 | 
| | 
| 
| 
|  | 
llvm-svn: 359968
 | 
| | 
| 
| 
| 
| 
|  | 
Differential Revision: https://reviews.llvm.org/D36527
llvm-svn: 359967
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
* __VA_OPT__ is expanded if the *expanded* __VA_ARGS__ is non-empty,
   not if the original argument contained no tokens.
 * Placemarkers at the start and end of __VA_OPT__ are retained just
   long enough to paste them with adjacent ## operators. We never paste
   "across" a discarded placemarker.
llvm-svn: 359964
 | 
| | 
| 
| 
| 
| 
|  | 
where either the modification or the other access is unreachable.
llvm-svn: 359962
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
When a FunctionProtoType is in the original type in a DecayedType, the decayed
type is a PointerType which points back the original FunctionProtoType.  The
visitor for ODRHashing will attempt to process both Type's, doing double work.
By chaining together multiple DecayedType's and FunctionProtoType's, this would
result in 2^N Type's visited only N DecayedType's and N FunctionProtoType's
exsit.  Another bug where VisitDecayedType and VisitAdjustedType did
redundant work doubled the work at each level, giving 4^N Type's visited.  This
patch removed the double work and detects when a FunctionProtoType decays to
itself to only check the Type once.  This lowers the exponential runtime to
linear runtime.  Fixes https://bugs.llvm.org/show_bug.cgi?id=41625
llvm-svn: 359960
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
state when it's encountered while evaluating a constexpr function.
We attempt to follow GCC trunk's behavior here, but it is somewhat
inscrutible, so our behavior is only approximately the same for now.
Specifically, we only permit modification of objects whose lifetime
began within the operand of the __builtin_constant_p. GCC appears to
have effectively the same restriction, but also some unknown restriction
based on where and how the local state of the constexpr function is
mentioned within the operand (see added testcases).
llvm-svn: 359958
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
When user specifies non-existent directory to -fcrash-diagnostics-dir,
create it rather than failing with an error as would be the case before.
Differential Revision: https://reviews.llvm.org/D61542
llvm-svn: 359954
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
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
 | 
| | 
| 
| 
| 
| 
|  | 
specializations for variable templates.
llvm-svn: 359947
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
Fixes PR41213
Differential Revision: https://reviews.llvm.org/D61276
llvm-svn: 359943
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Summary:
Related llvm patch: D60348.
Patch co-authored by Sanjin Sijaric.
Reviewers: rnk, efriedma, TomTan, ssijaric, ostannard
Reviewed By: efriedma
Subscribers: dmajor, richard.townsend.arm, ostannard, javed.absar, kristof.beyls, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60349
llvm-svn: 359932
 | 
| | 
| 
| 
|  | 
llvm-svn: 359913
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Summary:
The bug was reported on the OpenMP-dev list:
.../obj-release/lib/clang/9.0.0/include/__clang_cuda_intrinsics.h:173:35: error: '__nvvm_shfl_sync_idx_i32' needs target feature ptx60|ptx61|ptx63|ptx64
__MAKE_SYNC_SHUFFLES(__shfl_sync, __nvvm_shfl_sync_idx_i32,
This problem occurs when trying to compile a .cu file that requires a newer ptx version (>ptx60 in this case) than ptx42.
Reviewers: tra, ABataev, caomhin
Reviewed By: tra
Subscribers: jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D61474
llvm-svn: 359910
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Reviewers: alexfh
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D61480
llvm-svn: 359876
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
The warning isn't very useful when the function is an ObjC method.
rdar://problem/41561853
Differential Revision: https://reviews.llvm.org/D61147
llvm-svn: 359864
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
declaration"
This reverts commit fc40cbd9d8c63e65eed3590ba925321afe782e1d.
llvm-svn: 359859
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
internal-linkage declaration"
See cfe-commits thread for r359814.
llvm-svn: 359858
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
diagnostics emitted (or suppressed) during completion don't interfere with the overload notes
Because diagnostics and their notes are not connected at the API level,
if the error message for an overload is emitted, then the overload
candidates are completed - if a diagnostic is emitted during that work,
the notes related to overload candidates would be attached to the latter
diagnostic, not the original error. Sort of worse, if the latter
diagnostic was disabled, the notes are disabled.
Reviewers: rsmith
Differential Revision: https://reviews.llvm.org/D61357
llvm-svn: 359854
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
__builtin_constant_p.
If the operand of __builtin_constant_p is not constant and has
side-effects, then code controlled by a branch on it is unreachable and
we should not emit runtime behavior warnings in such code.
llvm-svn: 359844
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
CUDA 10.1 tools deprecated some command line options.
fatbinary no longer needs --cuda.
Differential Revision: https://reviews.llvm.org/D61470
llvm-svn: 359838
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
If an address_space attribute is defined in a macro, print the macro instead
when diagnosing a warning or error for incompatible pointers with different
address_spaces.
We allow this for all attributes (not just address_space), and for multiple
attributes declared in the same macro.
Differential Revision: https://reviews.llvm.org/D51329
llvm-svn: 359826
 | 
| | 
| 
| 
|  | 
llvm-svn: 359823
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
GCC warns on these cases, but we currently just silently ignore the attribute.
Differential Revision: https://reviews.llvm.org/D61097
llvm-svn: 359814
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Summary:
Fixes PR41677
Consider:
  template <typename LHS, typename RHS> constexpr bool is_same_v = false;
  template <typename T> constexpr bool is_same_v<T, T> = true;
  template constexpr bool is_same_v<int, int>;
Before this change, when emitting debug info for the
`is_same_v<int, int>` global variable, clang would crash because it
would try to use the template parameter list from the partial
specialization to give parameter names to template arguments. This
doesn't work in general, since a partial specialization can have fewer
arguments than the primary template. Therefore, always use the primary
template. Hypothetically we could try to use the parameter names from
the partial specialization when possible, but it's not clear this really
helps debugging in practice.
Reviewers: JDevlieghere, aprantl, ormris, dblaikie
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D61408
llvm-svn: 359809
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
PR36231, [dcl.attr.unused]p3
Reviewers: aaron.ballman
Differential Revision: https://reviews.llvm.org/D61444
llvm-svn: 359800
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
When the expression used to initialise 'this' has a pointer type,
check the address space of the pointee type instead of the pointer
type to decide whether an address space cast is required.
It is the pointee type that carries the address space qualifier.
Fixing PR41674.
Patch by kpet (Kevin Petit)!
Differential Revision: https://reviews.llvm.org/D61319
llvm-svn: 359798
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
Similarly to static variables in OpenCL, static class data
members should be deduced to __global addr space.
Differential Revision: https://reviews.llvm.org/D61304
llvm-svn: 359789
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
This follows up after b7692bc3e9ad2691fc07261904b88fb15f30696b "[UBSan] Fix
isDerivedFromAtOffset on iOS ARM64" fixed the RTTI comparison in
isDerivedFromAtOffset on just one platform and then
a25a2c7c9a7e1e328a5bd8274d2d86b1fadc4692 "Always compare C++ typeinfo (based on
libstdc++ implementation)" extended that fix to more platforms.
But there is another RTTI comparison for -fsanitize=function generated in
clang's CodeGenFunction::EmitCall as just a pointer comparison.  For
SANITIZER_NON_UNIQUE_TYPEINFO platforms this needs to be extended to also do
string comparison.  For that, __ubsan_handle_function_type_mismatch[_abort]
takes the two std::type_info pointers as additional parameters now, checks them
internally for potential equivalence, and returns without reporting failure if
they turn out to be equivalent after all.  (NORETURN needed to be dropped from
the _abort variant for that.)  Also these functions depend on ABI-specific RTTI
now, so needed to be moved from plain UBSAN_SOURCES (ubsan_handlers.h/cc) to
UBSAN_CXXABI_SOURCES (ubsan_handlers_cxx.h/cc), but as -fsanitize=function is
only supported in C++ mode that's not a problem.
Differential Revision: https://reviews.llvm.org/D60760
llvm-svn: 359759
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
explicit function specialization with the MemberSpecializationInfo used
everywhere else.
Not NFC: the ad-hoc pattern tracking was not being serialized /
deserialized properly. That's fixed here.
llvm-svn: 359747
 | 
| | 
| 
| 
| 
| 
| 
|  | 
that don't match any existing declaration. Don't get confused and treat
such declarations as template *specializations*.
llvm-svn: 359746
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
According to alignment section in below ARM64 ABI document, MSVC could increase
alignment of global data based on its total size. Clang doesn't do this. Compile
the same symbol into different alignments by Clang and MSVC could cause link
error because some instruction encodings, like 64-bit LDR/STR with immediate,
require the target to be 8 bytes aligned, and linker could choose code stream
with such LDR/STR instruction from MSVC and 4 bytes aligned data from Clang into
final image, which actually cannot be linked together
(see https://bugs.llvm.org/show_bug.cgi?id=41506 for more details).
https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=vs-2019#alignment
Differential Revision: https://reviews.llvm.org/D61225
llvm-svn: 359744
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
The parser was dealing with unexpected "template" keywords after "using"
keywords too late and putting the parser into the wrong state, which could
lead to a crash down the line.  This change allows the parser to consume the
bad "template" keywords earlier, and continue parsing as if "template" was
never there to begin with for better error recovery.
llvm-svn: 359740
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
-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
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
We correct some typos in `ActOnArraySubscriptExpr` and
`ActOnOMPArraySectionExpr`, so when their result is `ExprError`, we can
end up correcting delayed typos in the same expressions again. In
general it is OK but when `NumTypos` is incorrect, we can hit the
assertion
> Assertion failed: (Entry != DelayedTypos.end() && "Failed to get the state for a TypoExpr!"), function getTypoExprState, file clang/lib/Sema/SemaLookup.cpp, line 5219.
Fix by replacing some subscript `ExprResult` with typo-corrected expressions
instead of keeping the original expressions. Thus if original expressions
contained `TypoExpr`, we'll use corrected expressions instead of trying to
correct them again.
rdar://problem/47403222
Reviewers: rsmith, erik.pilkington, majnemer
Reviewed By: erik.pilkington
Subscribers: jkorous, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D60848
llvm-svn: 359713
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
Fixes PR37175
Differential Revision: https://reviews.llvm.org/D61222
llvm-svn: 359711
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
Fixes PR41483
Differential Revision: https://reviews.llvm.org/D61297
llvm-svn: 359687
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Summary:
This is a follow up to r355253 and a better fix than the first attempt
which was r359257.
We can't install anything from ${CMAKE_CFG_INTDIR}, because this value
is only defined at build time, but we still must make sure to copy the
headers into ${CMAKE_CFG_INTDIR}/lib/clang/$VERSION/include, because the lit
tests look for headers there.  So for this fix we revert to the
old behavior of copying the headers to ${CMAKE_CFG_INTDIR}/lib/clang/$VERSION/include
during the build and then installing them from the source tree.
Reviewers: smeenai, vzakhari, phosek
Reviewed By: smeenai, vzakhari
Subscribers: mgorny, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D61220
llvm-svn: 359654
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Summary:
C guarantees that brace-init with fewer initializers than members in the
aggregate will initialize the rest of the aggregate as-if it were static
initialization. In turn static initialization guarantees that padding is
initialized to zero bits.
Quoth the Standard:
C17 6.7.9 Initialization ❡21
If there are fewer initializers in a brace-enclosed list than there are elements
or members of an aggregate, or fewer characters in a string literal used to
initialize an array of known size than there are elements in the array, the
remainder of the aggregate shall be initialized implicitly the same as objects
that have static storage duration.
C17 6.7.9 Initialization ❡10
If an object that has automatic storage duration is not initialized explicitly,
its value is indeterminate. If an object that has static or thread storage
duration is not initialized explicitly, then:
 * if it has pointer type, it is initialized to a null pointer;
 * if it has arithmetic type, it is initialized to (positive or unsigned) zero;
 * if it is an aggregate, every member is initialized (recursively) according to
   these rules, and any padding is initialized to zero bits;
 * if it is a union, the first named member is initialized (recursively)
   according to these rules, and any padding is initialized to zero bits;
<rdar://problem/50188861>
Reviewers: glider, pcc, kcc, rjmccall, erik.pilkington
Subscribers: jkorous, dexonsmith, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D61280
llvm-svn: 359628
 | 
| | 
| 
| 
| 
| 
|  | 
These extra layers aren't necessary.
llvm-svn: 359623
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Summary: Corresponds to D61030.
Subscribers: jlebar, cfe-commits, llvm-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D61142
llvm-svn: 359616
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
When compiler-rt is selected as the runtime library for Linux targets
use its crtbegin.o/crtend.o implemenetation rather than platform one
if available.
Differential Revision: https://reviews.llvm.org/D59264
llvm-svn: 359603
 | 
| | 
| 
| 
|  | 
llvm-svn: 359594
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Summary:
Changes the signature of the TextGenerator std::function to return an Expected<std::string>
instead of std::string to allow for (non-fatal) failures.  Previously, we
expected that any failures would be expressed with assertions. However, that's
unfriendly to running the code in servers or other places that don't want their
library calls to crash the program.
Correspondingly, updates Transformer's handling of failures in TextGenerators
and the signature of `ChangeConsumer`.
Reviewers: ilya-biryukov
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D61015
llvm-svn: 359574
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
https://bugs.llvm.org/show_bug.cgi?id=41611
Similarly to D61106, the checker ran over an llvm_unreachable for vector types:
struct VectorSizeLong {
  VectorSizeLong() {}
  __attribute__((__vector_size__(16))) long x;
};
void __vector_size__LongTest() {
  VectorSizeLong v;
}
Since, according to my short research,
"The vector_size attribute is only applicable to integral and float scalars,
although arrays, pointers, and function return values are allowed in conjunction
with this construct."
[src: https://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Vector-Extensions.html#Vector-Extensions]
vector types are safe to regard as primitive.
Differential Revision: https://reviews.llvm.org/D61246
llvm-svn: 359539
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Currently we always inline functions that have no branches, i.e. have exactly
three CFG blocks: ENTRY, some code, EXIT. This makes sense because when there
are no branches, it means that there's no exponential complexity introduced
by inlining such function. Such functions also don't trigger various fundamental
problems with our inlining mechanism, such as the problem of inlined
defensive checks.
Sometimes the CFG may contain more blocks, but in practice it still has
linear structure because all directions (except, at most, one) of all branches
turned out to be unreachable. When this happens, still treat the function
as "small". This is useful, in particular, for dealing with C++17 if constexpr.
Differential Revision: https://reviews.llvm.org/D61051
llvm-svn: 359531
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
Don't crash when trying to model a call in which the callee is unknown
in compile time, eg. a pointer-to-member call.
Differential Revision: https://reviews.llvm.org/D61285
llvm-svn: 359530
 |