This expands NRVO propagation for more cases:
Parse analysis improvement:
* Lambdas and Blocks with dependent return type can have their variables
marked as NRVO Candidates.
Variable instantiation improvements:
* Fixes crash when instantiating NRVO variables in Blocks.
* Functions, Lambdas, and Blocks which have auto return type have their
variables' NRVO status propagated. For Blocks with non-auto return type,
as a limitation, this propagation does not consider the actual return
type.
This also implements exclusion of VarDecls which are references to
dependent types.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Reviewed By: Quuxplusone
Differential Revision: https://reviews.llvm.org/D99696
the function the block is passed to isn't a block pointer type
This patch fixes a bug where a block passed to a function taking a
parameter that doesn't have a block pointer type (e.g., id or reference
to a block pointer) was marked as noescape.
This partially fixes PR50043.
rdar://77030453
Differential Revision: https://reviews.llvm.org/D101097
Clang used to emit a bad -Wbridge-cast diagnostic on the cast in the attached
test. This was because, after 09abecef7, struct __CFString was not added to
lookup, so the objc_bridge attribute wasn't getting duplicated onto the most
recent declaration, causing us to fail to find it in getObjCBridgeAttr. This
patch fixes this by instead walking through the redeclarations to find an
appropriate bridge attribute. rdar://72823399
Differential revision: https://reviews.llvm.org/D99661
The swift_async_name attribute provides a name for a function/method that can be used
to call the async overload of this method from Swift. This name specified in this attribute
assumes that the last parameter in the function/method its applied to is removed when
Swift invokes it, as the the Swift's await/async transformation implicitly constructs the callback.
Differential Revision: https://reviews.llvm.org/D92355
The function `TryListConversion` didn't properly validate the following
part of the standard:
Otherwise, if the parameter type is a character array [... ]
and the initializer list has a single element that is an
appropriately-typed string literal (8.5.2 [dcl.init.string]), the
implicit conversion sequence is the identity conversion.
This caused the following call to `f()` to be ambiguous.
void f(int(&&)[1]);
void f(unsigned(&&)[1]);
void g(unsigned i) {
f({i});
}
This issue only occurs when the initializer list had one element.
Differential Revision: https://reviews.llvm.org/D87561
objc_super is special and needs LookupPredefedObjCSuperType() called before performing builtin type comparisons.
This fixes an error when compiling macOS headers. A test is added.
Differential Revision: https://reviews.llvm.org/D87917
Reland https://reviews.llvm.org/D76696
All known crashes have been fixed, another attemption.
We have rolled out this to all internal users for a while, didn't see
big issues, we consider it is stable enough.
Reviewed By: sammccall
Subscribers: rsmith, hubert.reinterpretcast, ebevhan, jkorous, arphaman, kadircet, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D78350
trivial.
We previously took a shortcut by assuming that if a subobject had a
trivial copy assignment operator (with a few side-conditions), we would
always invoke it, and could avoid going through overload resolution.
That turns out to not be correct in the presenve of ref-qualifiers (and
also won't be the case for copy-assignments with requires-clauses
either). Use the same logic for lazy declaration of copy-assignments
that we use for all other special member functions.
Previously committed as c57f8a3a20. This
now also includes an extension of LLDB's workaround for handling special
members without the help of Sema to cover copy assignments.
trivial.
We previously took a shortcut by assuming that if a subobject had a
trivial copy assignment operator (with a few side-conditions), we would
always invoke it, and could avoid going through overload resolution.
That turns out to not be correct in the presenve of ref-qualifiers (and
also won't be the case for copy-assignments with requires-clauses
either). Use the same logic for lazy declaration of copy-assignments
that we use for all other special member functions.
Summary:
This patch contains 2 separate changes:
1) the initializer of a variable should play no part in decl "invalid" bit;
2) preserve the invalid initializer via recovery exprs;
With 1), we will regress the diagnostics (one big regression is that we loose
the "selected 'begin' function with iterator type" diagnostic in for-range stmt;
but with 2) together, we don't have regressions (the new diagnostics seems to be
improved).
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D78116
Summary:
This patch would cause clang emit more diagnostics, but it is much better than https://reviews.llvm.org/D76831
```cpp
struct A {
A(int);
~A() = delete;
};
void k() {
A a;
}
```
before the patch:
/tmp/t3.cpp:24:5: error: no matching constructor for initialization of 'A'
A a;
^
/tmp/t3.cpp:20:3: note: candidate constructor not viable: requires 1 argument, but 0 were provided
A(int);
^
/tmp/t3.cpp:19:8: note: candidate constructor (the implicit copy constructor) not viable: requires 1 argument, but 0 were provided
struct A {
After the patch:
/tmp/t3.cpp:24:5: error: no matching constructor for initialization of 'A'
A a;
^
/tmp/t3.cpp:20:3: note: candidate constructor not viable: requires 1 argument, but 0 were provided
A(int);
^
/tmp/t3.cpp:19:8: note: candidate constructor (the implicit copy constructor) not viable: requires 1 argument, but 0 were provided
struct A {
^
/tmp/t3.cpp:24:5: error: attempt to use a deleted function
A a;
^
/tmp/t3.cpp:21:3: note: '~A' has been explicitly marked deleted here
~A() = delete;
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D77395
Summary: 5ade17e broke __is_pointer for Objective-C pointer types. This patch fixes the builtin and re-applies the change to type_traits.
Tags: #clang, #libc
Differential Revision: https://reviews.llvm.org/D77519
Compute and propagate conversion kind to diagnostics helper in C++
to provide more specific diagnostics about incorrect implicit
conversions in assignments, initializations, params, etc...
Duplicated some diagnostics as errors because C++ is more strict.
Tags: #clang
Differential Revision: https://reviews.llvm.org/D74116
type computation, in preparation for P0388R4, which adds another few
cases here.
We now properly handle forming multi-level composite pointer types
involving nested Objective-C pointer types (as is consistent with
including them as part of the notion of 'similar types' on which this
rule is based). We no longer lose non-CVR qualifiers on nested pointer
types.
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 de21704ba9,
reverted in commit d8018233d1, with
workarounds for some overload resolution ordering problems introduced by
CWG2352.
This reverts commit de21704ba9.
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.
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.
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.
pointer types.
For example, in Objective-C mode, the initialization of 'x' in:
```
@implementation MyType
+ (void)someClassMethod {
MyType *x = self;
}
@end
```
is correctly diagnosed with an incompatible-pointer-types warning, but
in Objective-C++ mode, it is not diagnosed at all -- even though
incompatible pointer conversions generally become an error in C++.
This patch fixes that oversight, allowing implicit conversions
involving Class only to/from unqualified-id, and between qualified and
unqualified Class, where the protocols are compatible.
Note that this does change some behaviors in Objective-C, as well, as
shown by the modified tests.
Of particular note is that assignment from from 'Class<MyProtocol>' to
'id<MyProtocol>' now warns. (Despite appearances, those are not
compatible types. 'Class<MyProtocol>' is not expected to have instance
methods defined by 'MyProtocol', while 'id<MyProtocol>' is.)
Differential Revision: https://reviews.llvm.org/D67983
llvm-svn: 375125
This is especially important for Objective-C++, which is entirely
missing this testing at the moment.
This annotates with "FIXME" the cases which I change in the next
patch -- I primarily wanted to document the current state of things so
that the effect of the code change is made clear.
Differential Revision: https://reviews.llvm.org/D67982
llvm-svn: 375124
initializers.
This has some interesting interactions with our existing extensions to
support C99 designated initializers as an extension in C++. Those are
resolved as follows:
* We continue to permit the full breadth of C99 designated initializers
in C++, with the exception that we disallow a partial overwrite of an
initializer with a non-trivially-destructible type. (Full overwrite
is OK, because we won't run the first initializer at all.)
* The C99 extensions are disallowed in SFINAE contexts and during
overload resolution, where they could change the meaning of valid
programs.
* C++20 disallows reordering of initializers. We only check for that for
the simple cases that the C++20 rules permit (designators of the form
'.field_name =' and continue to allow reordering in other cases).
It would be nice to improve this behavior in future.
* All C99 designated initializer extensions produce a warning by
default in C++20 mode. People are going to learn the C++ rules based
on what Clang diagnoses, so it's important we diagnose these properly
by default.
* In C++ <= 17, we apply the C++20 rules rather than the C99 rules, and
so still diagnose C99 extensions as described above. We continue to
accept designated C++20-compatible initializers in C++ <= 17 silently
by default (but naturally still reject under -pedantic-errors).
This is not a complete implementation of P0329R4. In particular, that
paper introduces new non-C99-compatible syntax { .field { init } }, and
we do not support that yet.
This is based on a previous patch by Don Hinton, though I've made
substantial changes when addressing the above interactions.
Differential Revision: https://reviews.llvm.org/D59754
llvm-svn: 370544
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
retaining block and all of the enclosing blocks are non-escaping.
If the block implicitly retaining self doesn't escape, there is no risk
of creating retain cycles, so clang shouldn't diagnose it and force
users to add self-> to silence the diagnostic.
Also, fix a bug where clang was failing to diagnose an implicitly
retained self inside a c++ lambda nested inside a block.
rdar://problem/25059955
Differential Revision: https://reviews.llvm.org/D60736
llvm-svn: 358624
Summary:
SExprBuilder::translateDeclRefExpr was only looking at FunctionDecl and not also looking at ObjCMethodDecl. It should consider both because the attributes can be used on Objective-C as well.
<rdar://problem/48941331>
Reviewers: dexonsmith, erik.pilkington
Subscribers: jkorous, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59523
llvm-svn: 356940
Before this commit, we emit unavailable errors for calls to functions during
overload resolution, and for references to all other declarations in
DiagnoseUseOfDecl. The early checks during overload resolution aren't as good as
the DiagnoseAvailabilityOfDecl based checks, as they error on the code from
PR40991. This commit fixes this by removing the early checking.
llvm.org/PR40991
rdar://48564179
Differential revision: https://reviews.llvm.org/D59394
llvm-svn: 356599
expression inside the parentheses is a valid UTF-8 string literal.
Previously clang emitted an expression like @("abc") as a message send
to stringWithUTF8String. This commit makes clang emit the boxed
expression as a compile-time constant instead.
This commit also has the effect of silencing the nullable-to-nonnull
conversion warning clang started emitting after r317727, which
originally motivated this commit (see https://oleb.net/2018/@keypath).
rdar://problem/42684601
Differential Revision: https://reviews.llvm.org/D58729
llvm-svn: 355662
ownership qualifications in C++ unions under ARC.
An ObjC pointer member with non-trivial ownership qualifications causes
all of the defaulted special functions of the enclosing union to be
defined as deleted, except when the member has an in-class initializer,
the default constructor isn't defined as deleted.
rdar://problem/34213306
Differential Revision: https://reviews.llvm.org/D57438
llvm-svn: 352949
before adding a delayed diagnostic to DelayedDiagnostics.
This fixes an assertion failure in Sema::DelayedDiagnostics::add that
was caused by the changes made in r141037.
rdar://problem/42782323
llvm-svn: 351911
from those that aren't.
This patch changes the way __block variables that aren't captured by
escaping blocks are handled:
- Since non-escaping blocks on the stack never get copied to the heap
(see https://reviews.llvm.org/D49303), Sema shouldn't error out when
the type of a non-escaping __block variable doesn't have an accessible
copy constructor.
- IRGen doesn't have to use the specialized byref structure (see
https://clang.llvm.org/docs/Block-ABI-Apple.html#id8) for a
non-escaping __block variable anymore. Instead IRGen can emit the
variable as a normal variable and copy the reference to the block
literal. Byref copy/dispose helpers aren't needed either.
This reapplies r343518 after fixing a use-after-free bug in function
Sema::ActOnBlockStmtExpr where the BlockScopeInfo was dereferenced after
it was popped and deleted.
rdar://problem/39352313
Differential Revision: https://reviews.llvm.org/D51564
llvm-svn: 343542
from those that aren't.
This patch changes the way __block variables that aren't captured by
escaping blocks are handled:
- Since non-escaping blocks on the stack never get copied to the heap
(see https://reviews.llvm.org/D49303), Sema shouldn't error out when
the type of a non-escaping __block variable doesn't have an accessible
copy constructor.
- IRGen doesn't have to use the specialized byref structure (see
https://clang.llvm.org/docs/Block-ABI-Apple.html#id8) for a
non-escaping __block variable anymore. Instead IRGen can emit the
variable as a normal variable and copy the reference to the block
literal. Byref copy/dispose helpers aren't needed either.
This reapplies r341754, which was reverted in r341757 because it broke a
couple of bots. r341754 was calling markEscapingByrefs after the call to
PopFunctionScopeInfo, which caused the popped function scope to be
cleared out when the following code was compiled, for example:
$ cat test.m
struct A {
id data[10];
};
void foo() {
__block A v;
^{ (void)v; };
}
This commit calls markEscapingByrefs before calling PopFunctionScopeInfo
to prevent that from happening.
rdar://problem/39352313
Differential Revision: https://reviews.llvm.org/D51564
llvm-svn: 343518
Matheus Izvekov