| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
member functions
Summary:
Before this change, we couldn't capture the `this` pointer that's
implicitly the first argument of class member functions. There are some
interesting things we can do with capturing even just this single
argument for zero-argument member functions.
Reviewers: rnk, pelikan
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D34052
llvm-svn: 305544
|
|
|
|
|
|
|
|
|
|
| |
This commit is a follow up to r302797 which added support for dependent
completions after the '.' and '->' operators. This commit adds support for
dependent completions after the '::' operator.
Differential Revision: https://reviews.llvm.org/D34173
llvm-svn: 305511
|
|
|
|
|
|
|
|
|
|
|
|
| |
input expression
Reviewers: GorNishanov, rsmith
Reviewed By: GorNishanov
Differential Revision: https://reviews.llvm.org/D34216
llvm-svn: 305498
|
|
|
|
|
|
| |
It broke clang-x86_64-linux-selfhost-modules-2 and some other buildbots.
llvm-svn: 305381
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While a function body is being parsed, the function declaration is not considered
as a definition because it does not have a body yet. In some cases it leads to
incorrect interpretation, the case is presented in
https://bugs.llvm.org/show_bug.cgi?id=14785:
```
template<typename T> struct Somewhat {
void internal() const {}
friend void operator+(int const &, Somewhat<T> const &) {}
};
void operator+(int const &, Somewhat<char> const &x) { x.internal(); }
```
When statement `x.internal()` in the body of global `operator+` is parsed, the type
of `x` must be completed, so the instantiation of `Somewhat<char>` is started. It
instantiates the declaration of `operator+` defined inline, and makes a check for
redefinition. The check does not detect another definition because the declaration
of `operator+` is still not defining as does not have a body yet.
To solves this problem the function `isThisDeclarationADefinition` considers
a function declaration as a definition if it has flag `WillHaveBody` set.
This change fixes PR14785.
Differential Revision: https://reviews.llvm.org/D30375
llvm-svn: 305379
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Currently we build the co_await expressions on the wrong implicit statements of the implicit ranged for; Specifically we build the co_await expression wrapping the range declaration, but it should wrap the begin expression.
This patch fixes co_await on range for.
Reviewers: rsmith, GorNishanov
Reviewed By: GorNishanov
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D34021
llvm-svn: 305363
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Clang emits unused-lambda-capture warning for captures in generic lambdas even though they are actually used.
Fixes PR31815.
Reviewers: malcolm.parsons, aaron.ballman, rsmith
Reviewed By: malcolm.parsons
Subscribers: ahatanak, cfe-commits
Differential Revision: https://reviews.llvm.org/D33526
llvm-svn: 305315
|
|
|
|
|
|
|
|
|
| |
full-exprs."
This reverts commit r305239 because it broke the buildbots (the
diag-flags.cpp test is failing).
llvm-svn: 305287
|
|
|
|
|
|
| |
This patch also exposed pre-existing bugs in clang, see PR32864 and PR33140#c3 .
llvm-svn: 305239
|
|
|
|
|
|
|
|
| |
Fixes PR32172
Differential revision: https://reviews.llvm.org/D34096
llvm-svn: 305195
|
|
|
|
|
|
|
|
| |
Fixes PR25156.
Patch by Don Hinton!
llvm-svn: 305169
|
|
|
|
|
|
| |
Breaks -Werror builders.
llvm-svn: 305148
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This way, the behavior of that warning flag
more closely resembles that of GCC.
Do note that there is at least one false-negative (see FIXME in tests).
Fixes PR4802.
Testing:
```
ninja check-clang-sema check-clang-semacxx
```
Reviewers: dblaikie, majnemer, rnk
Reviewed By: dblaikie, rnk
Subscribers: cfe-commits, alexfh, rnk
Differential Revision: https://reviews.llvm.org/D33102
llvm-svn: 305147
|
|
|
|
|
|
|
|
| |
Patch by Taiju Tsuiki!
Differential Revision: https://reviews.llvm.org/D33875
llvm-svn: 305126
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
n the current local-submodule-visibility mode, as soon as we discover a virtual
destructor, we declare on demand a global delete operator. However, this causes
that this delete operator is owned by the submodule which contains said virtual
destructor. This means that other modules no longer can see the global delete
operator which is hidden inside another submodule and fail to compile.
This patch unhides those global allocation function once they're created to
prevent this issue.
Patch by Raphael Isemann (D33366)!
llvm-svn: 305118
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
If the first parameter of the function is the ImplicitParamDecl, codegen
automatically marks it as an implicit argument with `this` or `self`
pointer. Added internal kind of the ImplicitParamDecl to separate
'this', 'self', 'vtt' and other implicit parameters from other kind of
parameters.
Reviewers: rjmccall, aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33735
llvm-svn: 305075
|
|
|
|
|
|
| |
As promised in r304996.
llvm-svn: 305013
|
|
|
|
| |
llvm-svn: 304997
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The only use in-tree I can find for BuiltinTypes.ResultTy is a single
store to it. We otherwise just recompute what it should be later on (and
sometimes do things like argument conversions in the process of
recomputing it).
Since it's impossible to test if the value stored there is sane, and we
don't use it anyway, we should probably just drop the field.
I'll do a follow-up patch to rename BuiltinTypes.ParamTypes ->
BuiltinParamTypes in a bit. Wanted to keep this patch relatively
minimal.
Thanks to Petr Kudryavtsev for bringing this up!
llvm-svn: 304996
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A function declared in a friend declaration may have declarations prior
to the containing class definition. If such declaration defines default
argument, the friend function declaration inherits them. This behavior
causes problems if the class where the friend is declared is a template:
during the class instantiation the friend function looks like if it had
default arguments, so error is triggered.
With this change friend functions declared in class templates do not
inherit default arguments. Actual set of them will be defined at the
point where the containing class is instantiated.
This change fixes PR12724.
Differential Revision: https://reviews.llvm.org/D30393
llvm-svn: 304965
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang makes check for function redefinition after it merged the new
declaration with the existing one. As a result, it produces poor
diagnostics in the case of a friend function defined inline, as in
the code:
```
void func() {}
class C { friend void func() {} };
```
Error message in this case states that `inline declaration of 'func'
follows non-inline definition`, which is misleading, as `func` does
not have explicit `inline` specifier.
With this changes compiler reports function redefinition if the new
function is a friend defined inline and it does not have explicit
`inline` specifier.
Differential Revision: https://reviews.llvm.org/D26065
llvm-svn: 304964
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bitwise complement applied to vector of floats described with
attribute `ext_vector_type` is not diagnosed as error. Attempt to
compile such construct causes assertion violation in Instruction.cpp.
With this change the complement is treated similar to the case of
vector type described with attribute `vector_size`.
Differential Revision: https://reviews.llvm.org/D33732
llvm-svn: 304963
|
|
|
|
| |
llvm-svn: 304960
|
|
|
|
|
|
|
| |
the injected-class-name of a specialization that uses a partial / explicit
specialization.
llvm-svn: 304957
|
|
|
|
|
|
|
|
|
|
| |
sure that non-template functions don't end up in the candidate set.
Fixes PR14211.
Patch by Don Hinton!
llvm-svn: 304951
|
|
|
|
|
|
|
|
| |
This is not required by the standard (yet), but there seems to be reasonable
support for this being a defect according to CWG discussion, and libstdc++ 7.1
relies on it working.
llvm-svn: 304946
|
|
|
|
| |
llvm-svn: 304892
|
|
|
|
| |
llvm-svn: 304872
|
|
|
|
| |
llvm-svn: 304870
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
RecursiveASTVisitor was not properly recursing through a
SubstTemplateTypeParmTypes, resulting in crashes in pack expansion where we
couldn't always find an unexpanded pack within a pack expansion.
We also have an issue where substitution of deduced template arguments for an
implicit deduction guide creates the "impossible" case of naming a
non-dependent member of the current instantiation, but within a specialization
that is actually instantiated from a different (partial/explicit)
specialization of the template. We resolve this by declaring that constructors
that do so can only be used to deduce specializations of the primary template.
I'm running this past CWG to see if people agree this is the right thing to do.
llvm-svn: 304862
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
template is valid with or without it (with different meanings).
If we see "dependent.x<...", and what follows the '<' is a valid expression,
we must parse the '<' as a comparison rather than a template angle bracket.
When we later come to instantiate, if we find that the LHS of the '<' actually
names an overload set containing function templates, produce a diagnostic
suggesting that the 'template' keyword was missed rather than producing a
mysterious diagnostic saying that the function must be called (and pointing
at what looks to already be a function call!).
llvm-svn: 304852
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: rsmith, craig.topper, efriedma
Reviewed By: efriedma
Subscribers: efriedma, cfe-commits
Tags: #clang-c
Differential Revision: https://reviews.llvm.org/D33926
llvm-svn: 304823
|
|
|
|
|
|
|
| |
This fixes missing lambda-captures for variables referenced only inside a
static_assert (!), among other things.
llvm-svn: 304760
|
|
|
|
|
|
|
|
|
|
|
|
| |
replaced by visible decls.
Make sure that all paths through checkCorrectionVisibility set the
RequiresImport flag appropriately, so we don't end up using a stale value.
Patch by Jorge Gorbe!
Differential Revision: https://reviews.llvm.org/D30963
llvm-svn: 304745
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch provides a means to specify section-names for global variables,
functions and static variables, using #pragma directives.
This feature is only defined to work sensibly for ELF targets.
One can specify section names as:
#pragma clang section bss="myBSS" data="myData" rodata="myRodata" text="myText"
One can "unspecify" a section name with empty string e.g.
#pragma clang section bss="" data="" text="" rodata=""
Reviewers: Roger Ferrer, Jonathan Roelofs, Reid Kleckner
Differential Revision: https://reviews.llvm.org/D33412
llvm-svn: 304705
|
|
|
|
| |
llvm-svn: 304651
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We were not handling correctly rebuilding of parameter and were not creating copies for them.
Now we will always rebuild parameter moves in TreeTransform's TransformCoroutineBodyStmt.
Reviewers: rsmith, GorNishanov
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33797
llvm-svn: 304620
|
|
|
|
|
|
|
|
|
|
|
|
| |
template partial specialization.
In passing, fix the deduction-crash.cpp test to actually run all the tests. Due
to a typo, the last third of the file was being skipped by the parser and some
of the tests were not actually testing anything as a result. Switch from
FileCheck to -verify to make the problem more obvious and prevent this
happening again.
llvm-svn: 304604
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Improve OpenCL type checking by rejecting function pointer types.
Reviewers: Anastasia, yaxunl
Reviewed By: Anastasia
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33821
llvm-svn: 304575
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The warning for unchanged loop variables outputted a diagnostic that was
dependent on iteration order from a pointer set, which is not always
deterministic. Switch to a set vector, which allows fast querying and
preserves ordering.
Also make other minor changes in this area.
Use more range-based for-loops.
Remove limitation on SourceRanges that no logner exists.
llvm-svn: 304519
|
|
|
|
|
|
|
|
|
|
|
| |
Print "this block declaration is not a prototype" for non-prototype
declarations of blocks instead of "this function declaration ...".
rdar://problem/32461723
Differential Revision: https://reviews.llvm.org/D33739
llvm-svn: 304507
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This hooks up the detailed diagnostics of why constant initialization was
not possible if require_constant_initialization reports an error.
I have updated the test to account for the new notes.
Reviewed By: EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24371
llvm-svn: 304451
|
|
|
|
| |
llvm-svn: 304445
|
|
|
|
|
|
| |
IgnoreNarrowingConversion should never return nullptr, but I've added an assert just in case.
llvm-svn: 304444
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rationale: OpenCL kernels are called via an explicit runtime API
with arguments set with clSetKernelArg(), not as normal sub-functions.
Return SPIR_KERNEL by default as the kernel calling convention to ensure
the fingerprint is fixed such way that each OpenCL argument gets one
matching argument in the produced kernel function argument list to enable
feasible implementation of clSetKernelArg() with aggregates etc. In case
we would use the default C calling conv here, clSetKernelArg() might
break depending on the target-specific conventions; different targets
might split structs passed as values to multiple function arguments etc.
https://reviews.llvm.org/D33639
llvm-svn: 304389
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unlike the GCC-compatible __has_trivial_destructor trait, this one computes the
right answer rather than performing the quirky set of checks described in GCC's
documentation (https://gcc.gnu.org/onlinedocs/gcc/Type-Traits.html).
MSVC also has a __has_trivial_destructor trait which is the same as its (and
now Clang's) __is_trivially_destructible trait; we might want to consider
changing the behavior of __has_trivial_destructor if we're targeting an MSVC
platform, but I'm not doing so for now.
While implementing this I found that we were incorrectly rejecting
__is_destructible queries on arrays of unknown bound of incomplete types; that
too is fixed, and I've added similar tests for other traits for good measure.
llvm-svn: 304376
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
@rsmith Does this correctly address the issues mentioned in https://reviews.llvm.org/D33625#inline-292971 ?
Reviewers: rsmith, EricWF
Reviewed By: EricWF
Subscribers: cfe-commits, rsmith
Differential Revision: https://reviews.llvm.org/D33636
llvm-svn: 304373
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: @rsmith Is there a better place to put this test?
Reviewers: GorNishanov, rsmith
Reviewed By: GorNishanov
Subscribers: cfe-commits, rsmith
Differential Revision: https://reviews.llvm.org/D33660
llvm-svn: 304331
|
|
|
|
|
|
|
|
|
| |
These diagnostics can't be disabled, and can't actually catch any bugs.
rdar://32427296
Differential revision: https://reviews.llvm.org/D33661
llvm-svn: 304306
|
|
|
|
|
|
|
|
| |
According to OpenMP 5.0 at least one 'map' or 'use_device_ptr' clause
must be specified for 'target data' construct. Patch adds support for
this feature.
llvm-svn: 304216
|