| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
expressions.
llvm-svn: 316585
|
|
|
|
| |
llvm-svn: 316584
|
|
|
|
|
|
|
|
|
|
|
|
| |
determining whether a RecordDecl is CFError.
CFErrorRef used to be declared with "objc_bridge(NSError)" but is now
declared with "objc_bridge_mutable(NSError)". Look for either when
checking whether a RecordDecl is CFError.
rdar://problem/35034779
llvm-svn: 316531
|
|
|
|
|
|
|
|
|
|
|
|
| |
A helper builtin to facilitate implementing the
std::has_unique_object_representations type trait.
Requested here: https://bugs.llvm.org/show_bug.cgi?id=34942
Also already exists in GCC and MSVC.
Differential Revision: https://reviews.llvm.org/D39064
llvm-svn: 316518
|
|
|
|
|
|
|
|
| |
'-'/'+' prefix
rdar://12040840
llvm-svn: 316458
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
modifiers
With enabled CINDEXTEST_CODE_COMPLETE_PATTERNS env option (which enables
IncludeCodePatterns in completion options) code completion after colon
currently suggests access modifiers with 2 completion chunks which is
incorrect.
Example:
class A : <Cursor>B
{
}
Currently we get 'NotImplemented:{TypedText public}{Colon :} (40)'
but the correct line is just 'NotImplemented:{TypedText public} (40)'
The fix introduces more specific scope that occurs between ':' and '{'
It allows us to determine when we don't need to add ':' as a second
chunk to the public/protected/private access modifiers.
Patch by Ivan Donchevskii!
Differential Revision: https://reviews.llvm.org/D38618
llvm-svn: 316436
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This bug was found via self-build on lld, and worked around
here: https://reviews.llvm.org/rL316180
The issue is that the 'using' causes the lookup to pick up the
first decl. However, when setting inherited default parameters,
we only update 'forward', not 'backward'. SO, only the newest param
list has all the information about the default arguments.
This patch ensures that the list of parameters we look through checks
the newest decl's template parameter list so it doesn't miss a default.
Differential Revision: https://reviews.llvm.org/D39127
llvm-svn: 316405
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allow Obj-C ivars with incomplete array type but only as the last ivar.
Also add a requirement for ivars that contain a flexible array member to
be at the end of class too. It is possible to add in a subclass another
ivar at the end but we'll emit a warning in this case. Also we'll emit a
warning if a variable sized ivar is declared in class extension or in
implementation because subclasses won't know they should avoid adding
new ivars.
In ARC incomplete array objects are treated as __unsafe_unretained so
require them to be marked as such.
Prohibit synthesizing ivars with flexible array members because order of
synthesized ivars is not obvious and tricky to control. Spelling out
ivar explicitly gives control to developers and helps to avoid surprises
with unexpected ivar ordering.
For C and C++ changed diagnostic to tell explicitly a field is not the
last one and point to the next field. It is not as useful as in Obj-C
but it is an improvement and it is consistent with Obj-C. For C for
unions emit more specific err_flexible_array_union instead of generic
err_field_incomplete.
rdar://problem/21054495
Reviewers: rjmccall, theraven
Reviewed By: rjmccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D38773
llvm-svn: 316381
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In some cases the compiler can deduce the length of an array section
as constants. With this information, VLAs can be avoided in place of
a constant sized array or even a scalar value if the length is 1.
Example:
int a[4], b[2];
pragma omp parallel reduction(+: a[1:2], b[1:1])
{ }
For chained array sections, this optimization is restricted to cases
where all array sections except the last have a constant length 1.
This trivially guarantees that there are no holes in the memory region
that needs to be privatized.
Example:
int c[3][4];
pragma omp parallel reduction(+: c[1:1][1:2])
{ }
This relands commit r316229 that I reverted in r316235 because it
failed on some bots. During investigation I found that this was because
Clang and GCC evaluate the two arguments to emplace_back() in
ReductionCodeGen::emitSharedLValue() in a different order, hence
leading to a different order of generated instructions in the final
LLVM IR. Fix this by passing in the arguments from temporary variables
that are evaluated in a defined order.
Differential Revision: https://reviews.llvm.org/D39136
llvm-svn: 316362
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
deduction-guides in line with WG21's p0620r0.
In order to identify the copy deduction candidate, I considered two approaches:
- attempt to determine whether an implicit guide is a copy deduction candidate by checking certain properties of its subsituted parameter during overload-resolution.
- using one of the many bits (WillHaveBody) from FunctionDecl (that CXXDeductionGuideDecl inherits from) that are otherwise irrelevant for deduction guides
After some brittle gymnastics w the first strategy, I settled on the second, although to avoid confusion and to give that bit a better name, i turned it into a member of an anonymous union.
Given this identification 'bit', the tweak to overload resolution was a simple reordering of the deduction guide checks (in SemaOverload.cpp::isBetterOverloadCandidate), in-line with Jason Merrill's p0620r0 drafting which made it into the working paper. Concordant with that, I made sure the copy deduction candidate is always added.
References:
See https://bugs.llvm.org/show_bug.cgi?id=34970
See http://wg21.link/p0620r0
llvm-svn: 316292
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
As Mattias Eriksson has reported in PR35009, in C, for enums, the underlying type should
be used when checking for the tautological comparison, unlike C++, where the enumerator
values define the value range. So if not in CPlusPlus mode, use the enum underlying type.
Also, i have discovered a problem (a crash) when evaluating tautological-ness of the following comparison:
```
enum A { A_a = 0 };
if (a < 0) // expected-warning {{comparison of unsigned enum expression < 0 is always false}}
return 0;
```
This affects both the C and C++, but after the first fix, only C++ code was affected.
That was also fixed, while preserving (i think?) the proper diagnostic output.
And while there, attempt to enhance the test coverage.
Yes, some tests got moved around, sorry about that :)
Fixes PR35009
Reviewers: aaron.ballman, rsmith, rjmccall
Reviewed By: aaron.ballman
Subscribers: Rakete1111, efriedma, materi, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D39122
llvm-svn: 316268
|
|
|
|
|
|
|
|
|
|
| |
This breaks at least two buildbots:
http://lab.llvm.org:8011/builders/clang-cmake-x86_64-avx2-linux/builds/1175
http://lab.llvm.org:8011/builders/clang-atom-d525-fedora-rel/builds/10478
This reverts commit r316229 during local investigation.
llvm-svn: 316235
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In some cases the compiler can deduce the length of an array section
as constants. With this information, VLAs can be avoided in place of
a constant sized array or even a scalar value if the length is 1.
Example:
int a[4], b[2];
pragma omp parallel reduction(+: a[1:2], b[1:1])
{ }
For chained array sections, this optimization is restricted to cases
where all array sections except the last have a constant length 1.
This trivially guarantees that there are no holes in the memory region
that needs to be privatized.
Example:
int c[3][4];
pragma omp parallel reduction(+: c[1:1][1:2])
{ }
Differential Revision: https://reviews.llvm.org/D39136
llvm-svn: 316229
|
|
|
|
|
|
| |
dependent context.
llvm-svn: 316177
|
|
|
|
|
|
|
|
|
| |
instantiation declarations if they are usable from constant expressions.
We are permitted to instantiate in these cases, and required to do so in order
to have an initializer available for use within constant evaluation.
llvm-svn: 316136
|
|
|
|
|
|
| |
enabling double square bracket attributes in C code.
llvm-svn: 316096
|
|
|
|
|
|
| |
enabling double square bracket attributes in C code.
llvm-svn: 316083
|
|
|
|
|
|
|
| |
instantiation, follow lexical parents not semantic ones: we want to find the
module where the pattern was written.
llvm-svn: 316055
|
|
|
|
|
|
| |
This is basically like r288207, just the other way round.
llvm-svn: 316032
|
|
|
|
|
|
|
|
|
|
|
|
| |
As reported here: https://bugs.llvm.org/show_bug.cgi?id=34973
"catch(...)" should catch EVERYTHING, even a rethrow. This
patch changes the order in which things are checked to ensure
that a '...' catch will get a rethrow.
Differential Revision: https://reviews.llvm.org/D39013
llvm-svn: 316030
|
|
|
|
|
|
|
|
|
|
|
| |
Changes behavior introduced in r298369 to only error out on
vector component invalid length access on OpenCL mode.
Differential Revision: https://reviews.llvm.org/D38868
rdar://problem/33568748
llvm-svn: 316016
|
|
|
|
|
|
|
|
|
| |
I ran across an instance where the value was being loaded
out via back, then immediately popped. Since pop_back_val
is more efficient at this (it moves out), replace this
instance.
llvm-svn: 316015
|
|
|
|
|
|
|
|
| |
Use the new helper methods to get the underlying type for NSUInteger,
NSInteger types. This avoids spreading the knowledge of the underlying
types in various sites. For non-LLP64 targets, this has no change.
llvm-svn: 316013
|
|
|
|
|
|
|
|
|
|
|
| |
GCC ignore qualifiers on array types. Since we seem to have this
function primarily for GCC compatibility, we should try to match that
behavior.
This also adds a few more test-cases __builtin_types_compatible_p,
which were inspired by GCC's documentation on the builtin.
llvm-svn: 315951
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The first attempt, rL315614 was reverted because one libcxx
test broke, and i did not know at the time how to deal with it.
Summary:
Currently, clang only diagnoses completely out-of-range comparisons (e.g. `char` and constant `300`),
and comparisons of unsigned and `0`. But gcc also does diagnose the comparisons with the
`std::numeric_limits<>::max()` / `std::numeric_limits<>::min()` so to speak
Finally Fixes https://bugs.llvm.org/show_bug.cgi?id=34147
Continuation of https://reviews.llvm.org/D37565
Reviewers: rjmccall, rsmith, aaron.ballman
Reviewed By: rsmith
Subscribers: rtrieu, jroelofs, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D38101
llvm-svn: 315875
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Convert clang::LangAS to a strongly typed enum
Currently both clang AST address spaces and target specific address spaces
are represented as unsigned which can lead to subtle errors if the wrong
type is passed. It is especially confusing in the CodeGen files as it is
not possible to see what kind of address space should be passed to a
function without looking at the implementation.
I originally made this change for our LLVM fork for the CHERI architecture
where we make extensive use of address spaces to differentiate between
capabilities and pointers. When merging the upstream changes I usually
run into some test failures or runtime crashes because the wrong kind of
address space is passed to a function. By converting the LangAS enum to a
C++11 we can catch these errors at compile time. Additionally, it is now
obvious from the function signature which kind of address space it expects.
I found the following errors while writing this patch:
- ItaniumRecordLayoutBuilder::LayoutField was passing a clang AST address
space to TargetInfo::getPointer{Width,Align}()
- TypePrinter::printAttributedAfter() prints the numeric value of the
clang AST address space instead of the target address space.
However, this code is not used so I kept the current behaviour
- initializeForBlockHeader() in CGBlocks.cpp was passing
LangAS::opencl_generic to TargetInfo::getPointer{Width,Align}()
- CodeGenFunction::EmitBlockLiteral() was passing a AST address space to
TargetInfo::getPointerWidth()
- CGOpenMPRuntimeNVPTX::translateParameter() passed a target address space
to Qualifiers::addAddressSpace()
- CGOpenMPRuntimeNVPTX::getParameterAddress() was using
llvm::Type::getPointerTo() with a AST address space
- clang_getAddressSpace() returns either a LangAS or a target address
space. As this is exposed to C I have kept the current behaviour and
added a comment stating that it is probably not correct.
Other than this the patch should not cause any functional changes.
Reviewers: yaxunl, pcc, bader
Reviewed By: yaxunl, bader
Subscribers: jlebar, jholewinski, nhaehnle, Anastasia, cfe-commits
Differential Revision: https://reviews.llvm.org/D38816
llvm-svn: 315871
|
|
|
|
|
|
| |
use of [[]] attributes in all language modes. This is the initial implementation of WG14 N2165, which is a proposal to add [[]] attributes to C2x, but also allows you to enable these attributes in C++98, or disable them in C++11 or later.
llvm-svn: 315856
|
|
|
|
|
|
|
|
| |
evaluate the initializer."
The warnings in libc++ tests were fixed in the meantime.
llvm-svn: 315811
|
|
|
|
|
|
|
|
| |
evaluate the initializer."
check-libcxx dislikes it.
llvm-svn: 315806
|
|
|
|
|
|
|
|
|
|
| |
If the variable construction can be constant evaluated it doesn't have
side effects, so removing it is always safe. We only try to evaluate
variables that are unused, there should be no impact on compile time.
Differential Revision: https://reviews.llvm.org/D38678
llvm-svn: 315787
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's possible for the code completion consumer to add new decls to the
current scope while lookup happens on it. Avoid this by making a copy
first.
Sadly I wasn't able to get a self-contained test case for this as it
requires code completion + precompiled preamble + the stars aligning to
deserialize at exactly the right time.
llvm-svn: 315772
|
|
|
|
|
|
| |
Fix -Wunused-but-set-variable warning.
llvm-svn: 315688
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently Clang uses default address space (0) to represent private address space for OpenCL
in AST. There are two issues with this:
Multiple address spaces including private address space cannot be diagnosed.
There is no mangling for default address space. For example, if private int* is emitted as
i32 addrspace(5)* in IR. It is supposed to be mangled as PUAS5i but it is mangled as
Pi instead.
This patch attempts to represent OpenCL private address space explicitly in AST. It adds
a new enum LangAS::opencl_private and adds it to the variable types which are implicitly
private:
automatic variables without address space qualifier
function parameter
pointee type without address space qualifier (OpenCL 1.2 and below)
Differential Revision: https://reviews.llvm.org/D35082
llvm-svn: 315668
|
|
|
|
|
|
|
|
|
|
| |
This feature is not (yet) approved by the C++ committee, so this is liable to
be reverted or significantly modified based on committee feedback.
No functionality change intended for existing code (a new type must be defined
in namespace std to take advantage of this feature).
llvm-svn: 315662
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
overriding methods.
This should fix test case Analysis/retain-release.m that was failing on
the reverse iteration bot:
http://lab.llvm.org:8011/builders/reverse-iteration
The test used to fail because the loop in CheckObjCMethodOverrides would
merge attribute ns_returns_retained on methods while checking whether
the overriding methods were compatible. Since OverrideSearch::Overridden
is a SmallPtrSet and the order in which the elements of the set are
visited is non-deterministic, the test would fail when method 'clone' of
the protocol 'F18P' was visited before F18(Cat)'s method 'clone' was
visited.
llvm-svn: 315639
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
template
It seems that all of the other templated cases are handled correctly,
however the function template case was not correctly handled. This
patch recovers from this condition by setting the function to noexcept
after diagnosing. Previously it simply set NoexceptExpr to null,
which caused an Assert when this was evaluated during substitution.
Differential Revision:https://reviews.llvm.org/D38700
llvm-svn: 315638
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts r315614,r315615,r315621,r315622
Breaks http://bb9.pgr.jp/#/builders/20/builds/59
/home/bb9/bootstrap-clang-libcxx-lld-i686-linux/llvm-project/libcxx/test/std/experimental/filesystem/fs.op.funcs/fs.op.last_write_time/last_write_time.pass.cpp:95:17: error: comparison 'long long' > 9223372036854775807 is always false [-Werror,-Wtautological-constant-compare]
if (max_sec > Lim::max()) return false;
~~~~~~~ ^ ~~~~~~~~~~
/home/bb9/bootstrap-clang-libcxx-lld-i686-linux/llvm-project/libcxx/test/std/experimental/filesystem/fs.op.funcs/fs.op.last_write_time/last_write_time.pass.cpp:124:13: error: comparison 'long long' < -9223372036854775808 is always false [-Werror,-Wtautological-constant-compare]
if (sec < Lim::min() || sec > Lim::max()) return false;
~~~ ^ ~~~~~~~~~~
/home/bb9/bootstrap-clang-libcxx-lld-i686-linux/llvm-project/libcxx/test/std/experimental/filesystem/fs.op.funcs/fs.op.last_write_time/last_write_time.pass.cpp:124:33: error: comparison 'long long' > 9223372036854775807 is always false [-Werror,-Wtautological-constant-compare]
if (sec < Lim::min() || sec > Lim::max()) return false;
~~~ ^ ~~~~~~~~~~
3 errors generated.
--
I'm not yet sure what is the proper fix.
llvm-svn: 315631
|
|
|
|
| |
llvm-svn: 315621
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Currently, clang only diagnoses completely out-of-range comparisons (e.g. `char` and constant `300`),
and comparisons of unsigned and `0`. But gcc also does diagnose the comparisons with the
`std::numeric_limits<>::max()` / `std::numeric_limits<>::min()` so to speak
Finally Fixes https://bugs.llvm.org/show_bug.cgi?id=34147
Continuation of https://reviews.llvm.org/D37565
Reviewers: rjmccall, rsmith, aaron.ballman
Reviewed By: rsmith
Subscribers: rtrieu, jroelofs, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D38101
llvm-svn: 315614
|
|
|
|
| |
llvm-svn: 315573
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Treat 'f()' as 'f(void)' rather than a function w/o a prototype.
Reviewers: Anastasia, yaxunl
Reviewed By: Anastasia, yaxunl
Subscribers: cfe-commits, echuraev, chapuni
Differential Revision: https://reviews.llvm.org/D33681
Re-apply revision 306653.
llvm-svn: 315453
|
|
|
|
|
|
|
| |
We want to check whether the using (shadow) declaration itself is visible, not
whether its target is visible.
llvm-svn: 315408
|
|
|
|
| |
llvm-svn: 315402
|
|
|
|
| |
llvm-svn: 315397
|
|
|
|
|
|
| |
the module interface being available.
llvm-svn: 315381
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When declaring an entity in the "purview" of a module, it's never a
redeclaration of an entity in the purview of a default module or in no module
("in the global module"). Don't consider those other declarations as possible
redeclaration targets if they're not visible, and reject any cases where we
pick a prior visible declaration that violates this rule.
This reinstates r315251 and r315256, reverted in r315309 and r315308
respectively, tweaked to avoid triggering a linkage calculation when declaring
implicit special members (this exposed our pre-existing issue with typedef
names for linkage changing the linkage of types whose linkage has already been
computed and cached in more cases). A testcase for that regression has been
added in r315366.
llvm-svn: 315379
|
|
|
|
|
|
|
|
|
|
| |
(PR34849) (take 2)
This is a re-commit of r315025, but making sure to only apply this to
specializations of class template member functions; i.e. not when the function
itself is a template.
llvm-svn: 315330
|
|
|
|
|
|
| |
This reverts commit r315251. See the original commit thread for reason.
llvm-svn: 315309
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ARCReclaimReturnedObject cast.
This is a follow-up to r314370.
Rather than throwing away the enclosing parentheses, this commit walks
down the expression until an ARCReclaimReturnedObject cast is found and
removes just the cast, preserving the syntactic sugar expressions
(parens and casts) that were visited up to that point.
rdar://problem/34705720
Differential Revision: https://reviews.llvm.org/D38659
llvm-svn: 315261
|
|
|
|
|
|
|
|
|
|
| |
When declaring an entity in the "purview" of a module, it's never a
redeclaration of an entity in the purview of a default module or in no module
("in the global module"). Don't consider those other declarations as possible
redeclaration targets if they're not visible, and reject any cases where we
pick a prior visible declaration that violates this rule.
llvm-svn: 315251
|