Summary:
This patch implements [dcl.fct.def.coroutine]p8:
> The unqualified-id get_return_object_on_allocation_failure is looked up in the scope of
> class P by class member access lookup (3.4.5). If a declaration is found, ..., and if a
> global allocation function is selected, the ::operator new(size_t, nothrow_t) form shall be used.
> [...]
> The allocation function used in this case must have a non-throwing noexcept-specification.
Reviewers: GorNishanov, rsmith, majnemer, aaron.ballman
Reviewed By: GorNishanov
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D31562
llvm-svn: 300524
Summary:
Certain implicitly generated coroutine statements, such as the calls to 'return_value()' or `return_void()` or `get_return_object_on_allocation_failure()`, cannot be built until the promise type is no longer dependent. This means they are not built until after the coroutine body statement has been transformed.
This patch fixes an issue where these statements would never be built for coroutine templates.
It also fixes a small issue where diagnostics about `get_return_object_on_allocation_failure()` were incorrectly suppressed.
Reviewers: rsmith, majnemer, GorNishanov, aaron.ballman
Reviewed By: GorNishanov
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D31487
llvm-svn: 300504
Summary:
This patch implements [dcl.fct.def.coroutine]p8:
> The unqualified-id get_return_object_on_allocation_failure is looked up in the scope of
> class P by class member access lookup (3.4.5). If a declaration is found, ..., and if a
> global allocation function is selected, the ::operator new(size_t, nothrow_t) form shall be used.
> [...]
> The allocation function used in this case must have a non-throwing noexcept-specification.
Reviewers: GorNishanov, rsmith, majnemer, aaron.ballman
Reviewed By: GorNishanov
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D31562
llvm-svn: 300420
This reverts an attempt to check that types match when matching a
dependently-typed non-type template parameter. (This comes up when matching the
parameters of a template template parameter against the parameters of a
template template argument.)
The matching rules here are murky at best. Our behavior after this revert is
definitely wrong for certain C++17 features (for 'auto' template parameter
types within the parameter list of a template template argument in particular),
but our behavior before this revert is wrong for some pre-existing testcases,
so reverting to our prior behavior seems like our best option.
llvm-svn: 300262
We need to address cases (breaking libc++) such as
template <class _Up> static int __test(...);
template<typename _Tp>
auto v = __test<_Tp>(0);
llvm-svn: 299956
Follow-up to r299363 "Enhance -Wshadow to warn when shadowing typedefs or type
aliases".
Patch by Ahmed Asadi.
Differential Revision: https://reviews.llvm.org/D31235
llvm-svn: 299522
Summary:
Certain implicitly generated coroutine statements, such as the calls to 'return_value()' or `return_void()` or `get_return_object_on_allocation_failure()`, cannot be built until the promise type is no longer dependent. This means they are not built until after the coroutine body statement has been transformed.
This patch fixes an issue where these statements would never be built for coroutine templates.
It also fixes a small issue where diagnostics about `get_return_object_on_allocation_failure()` were incorrectly suppressed.
Reviewers: rsmith, majnemer, GorNishanov, aaron.ballman
Reviewed By: GorNishanov
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D31487
llvm-svn: 299380
GCC has the alloc_align attribute, which is similar to assume_aligned, except the attribute's parameter is the index of the integer parameter that needs aligning to.
Differential Revision: https://reviews.llvm.org/D29599
llvm-svn: 299117
Summary:
If promise_type has get_return_object_on_allocation_failure defined,
check if an allocation function returns nullptr, and if so,
return the result of get_return_object_on_allocation_failure().
Reviewers: rsmith, EricWF
Reviewed By: EricWF
Subscribers: mehdi_amini, cfe-commits
Differential Revision: https://reviews.llvm.org/D31399
llvm-svn: 298891
Summary:
This patch implements parsing of [[clang::suppress(rule, ...)]]
and [[gsl::suppress(rule, ...)]] attributes.
C++ Core Guidelines depend heavily on tool support for
rule enforcement. They also propose a way to suppress
warnings [1] which is by annotating any ancestor in AST
with the C++11 attribute [[gsl::suppress(rule1,...)]].
To have a mechanism to suppress non-C++ Core
Guidelines specific, an additional spelling of [[clang::suppress]]
is defined.
For example, to suppress the warning cppcoreguidelines-slicing,
one could do
```
[[clang::suppress("cppcoreguidelines-slicing")]]
void f() { ... code that does slicing ... }
```
or
```
void g() {
Derived b;
[[clang::suppress("cppcoreguidelines-slicing")]]
Base a{b};
[[clang::suppress("cppcoreguidelines-slicing")]] {
doSomething();
Base a2{b};
}
}
```
This parsing can then be used by clang-tidy, which includes multiple
C++ Core Guidelines rules, to suppress warnings (see
https://reviews.llvm.org/D24888).
For the exact naming of the rule in the attribute, there
are different possibilities, which will be defined in the
corresponding clang-tidy patch.
Currently, clang-tidy supports suppressing of warnings through "//
NOLINT" comments. There are some advantages that the attribute has:
- Suppressing specific warnings instead of all warnings
- Suppressing warnings in a block (namespace, function, compound
statement)
- Code formatting may split a statement into multiple lines,
thus a "// NOLINT" comment may be on the wrong line
I'm looking forward to your comments!
[1] https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#inforce-enforcement
Reviewers: alexfh, aaron.ballman, rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24886
llvm-svn: 298880
for unused values.
This fixes a regression caused by r298676, where constructor calls to
classes with non-trivial dtor were marked as unused if the first
argument is an initializer list. This is inconsistent (as the test
shows) and also warns on a reasonbly common code pattern where people
just call constructors to create and immediately destroy an object.
llvm-svn: 298853
This change fixes a crash on initialization of a reference from ({}) during
template instantiation and incidentally improves diagnostics.
This reverts a prior attempt to handle this in r286721. Instead, we teach the
initialization code that initialization cannot be performed if a source type
is required and the initializer is an initializer list (which is not an
expression and does not have a type), and likewise for function-style cast
expressions.
llvm-svn: 298676
Correct class-template deprecation behavior
Based on the comment in the test, and my reading of the standard, a deprecated warning should be issued in the following case:
template<typename T> [[deprecated]] class Foo{}; Foo<int> f;
This was not the case, because the ClassTemplateSpecializationDecl creation did not also copy the deprecated attribute.
Note: I did NOT audit the complete set of attributes to see WHICH ones should be copied, so instead I simply copy ONLY the deprecated attribute.
Previous DiffRev: https://reviews.llvm.org/D27486, was reverted.
This patch fixes the issues brought up here by the reverter: https://reviews.llvm.org/rL298410
Differential Revision: https://reviews.llvm.org/D31245
llvm-svn: 298634
Summary:
This patch adopts the recent changes that renamed `set_exception(exception_pointer)` to `unhandled_exception()`.
Additionally `unhandled_exception()` is now required, and so an error is emitted when exceptions are enabled but the promise type does not provide the member.
When exceptions are disabled a warning is emitted instead of an error, The warning notes that the `unhandled_exception()` function is required when exceptions are enabled.
Reviewers: rsmith, GorNishanov, aaron.ballman, majnemer
Reviewed By: GorNishanov
Subscribers: mehdi_amini, cfe-commits
Differential Revision: https://reviews.llvm.org/D30859
llvm-svn: 298565
We don't know whether some other instantiation of the template might be able to
reach the annotation, so warning on it has a high chance of false positives.
Patch by Ahmed Asadi!
Differential Revision: https://reviews.llvm.org/D31069
llvm-svn: 298477
The alias was only ever used on darwin and had some issues there,
and isn't used in practice much. Also fixes a problem with -mno-altivec
not turning off -maltivec.
Also add a diagnostic for faltivec/fno-altivec that directs users to use
maltivec options and include the altivec.h file explicitly.
llvm-svn: 298449
Based on the comment in the test, and my reading of the standard, a deprecated warning should be issued in the following case:
template<typename T> [[deprecated]] class Foo{}; Foo<int> f;
This was not the case, because the ClassTemplateSpecializationDecl creation did not also copy the deprecated attribute.
Note: I did NOT audit the complete set of attributes to see WHICH ones should be copied, so instead I simply copy ONLY the deprecated attribute.
Differential Revision: https://reviews.llvm.org/D27486
llvm-svn: 298410
This commit adds support for a new attribute that will be used to
distinguish between extensible and inextensible enums. There are three
main purposes of this attribute:
1. Give better control over when enum-related warnings are issued.
For example, in the code below, clang will not issue a -Wassign-enum
warning if the enum is marked "open":
enum __attribute__((enum_extensibility(closed))) EnumClosed {
B0 = 1, B1 = 10
};
enum __attribute__((enum_extensibility(open))) EnumOpen {
C0 = 1, C1 = 10
};
enum EnumClosed ec = 100; // warning issued
enum EnumOpen eo = 100; // no warning
2. Enable code-completion and debugging tools to offer better
suggestions.
3. Make it easier for swift's clang importer to determine which swift
type an enum should be mapped to.
For more details, see the discussion I started on cfe-dev:
http://lists.llvm.org/pipermail/cfe-dev/2017-February/052748.html
rdar://problem/12764379
rdar://problem/23145650
Differential Revision: https://reviews.llvm.org/D30766
llvm-svn: 298332
This adds -Wbitfield-enum-conversion, which warns on implicit
conversions that happen on bitfield assignment that change the value of
some enumerators.
Values of enum type typically take on a very small range of values, so
they are frequently stored in bitfields. Unfortunately, there is no
convenient way to calculate the minimum number of bits necessary to
store all possible values at compile time, so users usually hard code a
bitwidth that works today and widen it as necessary to pass basic
testing and validation. This is very error-prone, and leads to stale
widths as enums grow. This warning aims to catch such bugs.
This would have found two real bugs in clang and two instances of
questionable code. See r297680 and r297654 for the full description of
the issues.
This warning is currently disabled by default while we investigate its
usefulness outside of LLVM.
The major cause of false positives with this warning is this kind of
enum:
enum E { W, X, Y, Z, SENTINEL_LAST };
The last enumerator is an invalid value used to validate inputs or size
an array. Depending on the prevalance of this style of enum across a
codebase, this warning may be more or less feasible to deploy. It also
has trouble on sentinel values such as ~0U.
Reviewers: rsmith, rtrieu, thakis
Reviewed By: thakis
Subscribers: hfinkel, voskresensky.vladimir, sashab, cfe-commits
Differential Revision: https://reviews.llvm.org/D30923
llvm-svn: 297761
Summary:
Some coroutine diagnostics need to point to the location of the first coroutine keyword in the function, like when diagnosing a `return` inside a coroutine. Previously we did this by storing each *valid* coroutine statement in a list and select the first one to use in diagnostics. However if every coroutine statement is invalid we would have no location to point to.
This patch fixes the storage of the first coroutine statement location, ensuring that it gets stored even when the resulting AST node would be invalid.
This patch also removes the `CoroutineStmts` list in `FunctionScopeInfo` because it was unused.
Reviewers: rsmith, GorNishanov, aaron.ballman
Reviewed By: GorNishanov
Subscribers: mehdi_amini, cfe-commits
Differential Revision: https://reviews.llvm.org/D30776
llvm-svn: 297547
Printing typedefs or type aliases using clang_getTypeSpelling() is missing the
namespace they are defined in. This is in contrast to other types that always
yield the full typename including namespaces.
Patch by Michael Reiher!
Differential Revision: https://reviews.llvm.org/D29944
llvm-svn: 297465
Summary:
A `co_await arg` expression has a dependent type whenever the promise type is still dependent, even if the argument to co_await is not. This is because we cannot attempt the `await_transform(<arg>)` until after we know the promise type.
This patch fixes an assertion in the constructor of `DependentCoawaitExpr` that asserted that `arg` must also be dependent.
Reviewers: rsmith, GorNishanov, aaron.ballman
Reviewed By: GorNishanov
Subscribers: mehdi_amini, cfe-commits
Differential Revision: https://reviews.llvm.org/D30772
llvm-svn: 297358
Summary:
This patch adds passing a coroutine_handle object to await_suspend calls.
It builds the coroutine_handle using coroutine_handle<PromiseType>::from_address(__builtin_coro_frame()).
(a revision of https://reviews.llvm.org/D26316 that for some reason refuses to apply via arc patch)
Reviewers: GorNishanov
Subscribers: mehdi_amini, cfe-commits, EricWF
Differential Revision: https://reviews.llvm.org/D30769
llvm-svn: 297356
Summary:
The changes contained in this patch are:
1. Defines a new AST node `CoawaitDependentExpr` for representing co_await expressions while the promise type is still dependent.
2. Correctly detect and transform the 'co_await' operand to `p.await_transform(<expr>)` when possible.
3. Change the initial/final suspend points to build during the initial parse, so they have the correct operator co_await lookup results.
4. Fix transformation of the CoroutineBodyStmt so that it doesn't re-build the final/initial suspends.
@rsmith: This change is a little big, but it's not trivial for me to split it up. Please let me know if you would prefer this submitted as multiple patches.
Reviewers: rsmith, GorNishanov
Reviewed By: rsmith
Subscribers: ABataev, rsmith, mehdi_amini, cfe-commits
Differential Revision: https://reviews.llvm.org/D26057
llvm-svn: 297093
Previously when a coroutine was building the implicit setup/destroy
constructs it would emit diagostics about failures on the first co_await/co_return/co_yield
it encountered. This was confusing because that construct may not itself be ill-formed.
This patch moves the diagnostics to the function start instead.
llvm-svn: 297089
Summary:
Don't warn about unused lambda captures that involve copying a
value of a type that cannot be trivially copied and destroyed.
Fixes PR31977
Reviewers: rsmith, aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D30327
llvm-svn: 296602
The exisiting warning for inconsistent overrides does not include the destructor
as it was noted in review that it was too noisy. Instead, add to a separate
warning group that is off by default for users who want consistent warnings
between methods and destructors.
llvm-svn: 296572
Essentially, as a base class constructor does not construct virtual bases, such
a constructor for an abstract class does not need the corresponding base class
construction to be valid, and likewise for destructors.
This creates an awkward situation: clang will sometimes generate references to
the complete object and deleting destructors for an abstract class (it puts
them in the construction vtable for a derived class). But we can't generate a
"correct" version of these because we can't generate references to base class
constructors any more (if they're template specializations, say, we might not
have instantiated them and can't assume any other TU will emit a copy).
Fortunately, we don't need to, since no correct program can ever invoke them,
so instead emit symbols that just trap.
We should stop emitting references to these symbols, but still need to emit
definitions for compatibility.
llvm-svn: 296275
Rather than attempting to compare whether the previous and current top of
context stack are "equal" (which fails for a number of reasons, such as the
context stack entries containing pointers to objects on the stack, or reaching
the same "top of stack" entry through two different paths), track the depth of
context stack at which we last emitted a note and invalidate it when we pop the
context stack to less than that depth.
This causes us to emit some missing "in instantiation of" notes and to stop
emitting redundant "in instantiation of" stacks matching the previous stack in
rare cases.
llvm-svn: 295921
This is necessary in order for the evaluation of an _Atomic initializer for
those types to have an associated object, which an initializer for class or
array type needs.
llvm-svn: 295886
We need to look through the PackExpansionType in the parameter type when
deducing, and we need to consider the possibility of deducing arguments for
packs that are not lexically mentioned in the pattern (but are nonetheless
deducible) when figuring out which packs are covered by a pack deduction scope.
llvm-svn: 295790
case where the class template has a parameter pack.
Checking of the template arguments expects an "as-written" template argument
list, which in particular does not have any parameter packs. So flatten the
packs into separate arguments before passing them in.
llvm-svn: 295710
Eric Fiselier