Commit Graph

1081 Commits

Author SHA1 Message Date
George Burgess IV add6ab5084 Use the member function location in enable_if diagnostics.
Before:
<stdin>:3:3: error: no matching member function for call to 'bar'
  Foo().bar();
  ^

After:
<stdin>:3:9: error: no matching member function for call to 'bar'
  Foo().bar();
        ^

llvm-svn: 287154
2016-11-16 21:31:25 +00:00
George Burgess IV 0d546534d3 [Sema] Range-ify for loop, add period to comment. NFC.
llvm-svn: 286506
2016-11-10 21:47:12 +00:00
Richard Smith 9095e5bf7e p0012: Teach resolving address of overloaded function with dependent exception
specification to resolve the exception specification as part of the type check,
in C++1z onwards. This is not actually part of P0012 / CWG1330 rules for when
an exception specification is "needed", but is necessary for sanity.

llvm-svn: 285663
2016-11-01 01:31:23 +00:00
George Burgess IV d66d37cbd9 Make a function static. NFC.
llvm-svn: 285458
2016-10-28 21:42:06 +00:00
Richard Smith 1be59c5106 [c++1z] P0012R1: Implement a few remaining pieces: downgrade diagnostic for
mismatched dynamic exception specifications in expressions from an error to a
warning, since this is no longer ill-formed in C++1z.

Allow reference binding of a reference-to-non-noexcept function to a noexcept
function lvalue. As defect resolutions, also allow a conditional between
noexcept and non-noexcept function lvalues to produce a non-noexcept function
lvalue (rather than decaying to a function pointer), and allow function
template argument deduction to deduce a reference to non-noexcept function when
binding to a noexcept function type.

llvm-svn: 284905
2016-10-22 01:32:19 +00:00
Richard Smith ce76629905 Remove unnecessary distinction between Ref_Compatible and
Ref_Compatible_With_Added_Qualification. We always treated these two values the
same way.

llvm-svn: 284895
2016-10-21 23:01:55 +00:00
Richard Smith 5e9746f520 DR583, DR1512: Implement a rewrite to C++'s 'composite pointer type' rules.
This has two significant effects:

1) Direct relational comparisons between null pointer constants (0 and nullopt)
   and pointers are now ill-formed. This was always the case for C, and it
   appears that C++ only ever permitted by accident. For instance, cases like
     nullptr < &a
   are now rejected.

2) Comparisons and conditional operators between differently-cv-qualified
   pointer types now work, and produce a composite type that both source
   pointer types can convert to (when possible). For instance, comparison
   between 'int **' and 'const int **' is now valid, and uses an intermediate
   type of 'const int *const *'.

Clang previously supported #2 as an extension.

We do not accept the cases in #1 as an extension. I've tested a fair amount of
code to check that this doesn't break it, but if it turns out that someone is
relying on this, we can easily add it back as an extension.

This is a re-commit of r284800.

llvm-svn: 284890
2016-10-21 22:00:42 +00:00
Renato Golin 41189656ed Revert "DR583, DR1512: Implement a rewrite to C++'s 'composite pointer type' rules."
This reverts commit r284800, as it failed all ARM/AArch64 bots.

llvm-svn: 284811
2016-10-21 08:03:49 +00:00
Richard Smith 0c1c53e3fa DR583, DR1512: Implement a rewrite to C++'s 'composite pointer type' rules.
This has two significant effects:

1) Direct relational comparisons between null pointer constants (0 and nullopt)
   and pointers are now ill-formed. This was always the case for C, and it
   appears that C++ only ever permitted by accident. For instance, cases like
     nullptr < &a
   are now rejected.

2) Comparisons and conditional operators between differently-cv-qualified
   pointer types now work, and produce a composite type that both source
   pointer types can convert to (when possible). For instance, comparison
   between 'int **' and 'const int **' is now valid, and uses an intermediate
   type of 'const int *const *'.

Clang previously supported #2 as an extension.

We do not accept the cases in #1 as an extension. I've tested a fair amount of
code to check that this doesn't break it, but if it turns out that someone is
relying on this, we can easily add it back as an extension.

llvm-svn: 284800
2016-10-21 02:36:37 +00:00
Richard Smith eb7ef2e1ca Re-commit r284753, reverted in r284778, with a fix for PR30749.
Original commit message:

[c++1z] Teach composite pointer type computation how to compute the composite
pointer type of two function pointers with different noexcept specifications.
While I'm here, also teach it how to merge dynamic exception specifications.

llvm-svn: 284785
2016-10-20 21:53:09 +00:00
Hans Wennborg 2b81f42a76 Revert r284753 "[c++1z] Teach composite pointer type computation how to compute the composite"
It caused PR30749.

llvm-svn: 284778
2016-10-20 20:54:32 +00:00
Richard Smith 9c37e66c31 [c++1z] Teach composite pointer type computation how to compute the composite
pointer type of two function pointers with different noexcept specifications.
While I'm here, also teach it how to merge dynamic exception specifications.

llvm-svn: 284753
2016-10-20 17:57:33 +00:00
Richard Smith 6f42740707 Fix crash on noreturn conversion in unprototyped function type. Thanks to Keith
Walker for spotting the bug.

llvm-svn: 284673
2016-10-20 00:01:36 +00:00
Richard Smith 5f4b388442 Resolve exception specifications when selecting an overloaded operator.
llvm-svn: 284556
2016-10-19 00:14:23 +00:00
Richard Smith 84a0b6dba1 DR1330: instantiate exception-specifications when "needed". We previously did
not instantiate exception specifications of functions if they were only used in
unevaluated contexts (other than 'noexcept' expressions).

In C++17 onwards, this becomes essential since the exception specification is
now part of the function's type.

Note that this means that constructs like the following no longer work:

  struct A {
    static T f() noexcept(...);
    decltype(f()) *p;
  };

... because the decltype expression now needs the exception specification of
'f', which has not yet been parsed.

llvm-svn: 284549
2016-10-18 23:39:12 +00:00
Richard Smith 3c4f8d2e96 P0012R1: Make exception specifications be part of the type system. This
implements the bulk of the change (modifying the type system to include
exception specifications), but not all the details just yet.

llvm-svn: 284337
2016-10-16 17:54:23 +00:00
Richard Smith b2f0f05742 Re-commit r283722, reverted in r283750, with a fix for a CUDA-specific use of
past-the-end iterator.

Original commit message:

P0035R4: Semantic analysis and code generation for C++17 overaligned
allocation.

llvm-svn: 283789
2016-10-10 18:54:32 +00:00
Daniel Jasper e9abe64816 Revert "P0035R4: Semantic analysis and code generation for C++17 overaligned allocation."
This reverts commit r283722. Breaks:
  Clang.SemaCUDA.device-var-init.cu
  Clang.CodeGenCUDA.device-var-init.cu

http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-expensive/884/

llvm-svn: 283750
2016-10-10 14:13:55 +00:00
Richard Smith 189e52fcdf P0035R4: Semantic analysis and code generation for C++17 overaligned
allocation.

llvm-svn: 283722
2016-10-10 06:42:31 +00:00
Richard Smith e15a370084 PR25890: Fix incoherent error handling in PerformImplicitConversion and
CheckSingleAssignmentConstraints. These no longer produce ExprError() when they
have not emitted an error, and reliably inform the caller when they *have*
emitted an error.

This fixes some serious issues where we would fail to emit any diagnostic for
invalid code and then attempt to emit code for an invalid AST, and conversely
some issues where we would emit two diagnostics for the same problem.

llvm-svn: 283508
2016-10-06 23:12:58 +00:00
Justin Lebar 53b000afc2 [CUDA] Clean up some comments in Sema::IsOverload. NFC
llvm-svn: 283121
2016-10-03 16:48:27 +00:00
Justin Lebar e060feb7b1 [CUDA] Disallow overloading destructors.
Summary:
We'd attempted to allow this, but turns out we were doing a very bad
job.  :)

Making this work properly would be a giant change in clang.  For
example, we'd need to make CXXRecordDecl::getDestructor()
context-sensitive, because the destructor you end up with depends on
where you're calling it from.

For now (and hopefully for ever), just disallow overloading of
destructors in CUDA.

Reviewers: rsmith

Subscribers: cfe-commits, tra

Differential Revision: https://reviews.llvm.org/D24571

llvm-svn: 283120
2016-10-03 16:48:23 +00:00
George Burgess IV fbad5b2f1b [Sema] Compare bad conversions in overload resolution.
r280553 introduced an issue where we'd emit ambiguity errors for code
like:

```
void foo(int *, int);
void foo(unsigned int *, unsigned int);

void callFoo() {
  unsigned int i;
  foo(&i, 0); // ambiguous: int->unsigned int is worse than int->int,
              // but unsigned int*->unsigned int* is better than
              // int*->int*.
}
```

This patch fixes this issue by changing how we handle ill-formed (but
valid) implicit conversions. Candidates with said conversions now always
rank worse than candidates without them, and two candidates are
considered to be equally bad if they both have these conversions for
the same argument.

Additionally, this fixes a case in C++11 where we'd complain about an
ambiguity in a case like:

```
void f(char *, int);
void f(const char *, unsigned);
void g() { f("abc", 0); }
```

...Since conversion to char* from a string literal is considered
ill-formed in C++11 (and deprecated in C++03), but we accept it as an
extension.

llvm-svn: 280847
2016-09-07 20:03:19 +00:00
Ismail Pazarbasi 4a00774e59 Try contextually converting condition of constexpr if to Boolean value
Summary:
C++1z 6.4.1/p2:
 If the if statement is of the form if constexpr, the value of the
 condition shall be a contextually converted constant expression of type
 bool [...]
C++1z 5.20/p4:
 [...] A contextually converted constant expression of type bool is an
 expression, contextually converted to bool (Clause4), where the
 converted expression is a constant expression and the conversion
 sequence contains only the conversions above. [...]

Contextually converting result of an expression `e` to a Boolean value
requires `bool t(e)` to be well-formed.

An explicit conversion function is only considered as a user-defined
conversion for direct-initialization, which is essentially what
//contextually converted to bool// requires.

Also, fixes PR28470.

Reviewers: rsmith

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D24158

llvm-svn: 280838
2016-09-07 18:24:54 +00:00
George Burgess IV 6098fd1989 [Sema] Fix how we set implicit conversion kinds.
We have invariants we like to guarantee for the
`ImplicitConversionKind`s in a `StandardConversionSequence`. These
weren't being upheld in code that r280553 touched, so Richard suggested
that we should fix that. See D24113.

I'm not entirely sure how to go about testing this, so no test case is
included. Suggestions welcome.

llvm-svn: 280562
2016-09-03 00:28:25 +00:00
George Burgess IV 2099b54102 [Sema] Relax overloading restrictions in C.
This patch allows us to perform incompatible pointer conversions when
resolving overloads in C. So, the following code will no longer fail to
compile (though it will still emit warnings, assuming the user hasn't
opted out of them):

```
void foo(char *) __attribute__((overloadable));
void foo(int) __attribute__((overloadable));

void callFoo() {
  unsigned char bar[128];
  foo(bar); // selects the char* overload.
}
```

These conversions are ranked below all others, so:

  A. Any other viable conversion will win out
  B. If we had another incompatible pointer conversion in the example
     above (e.g. `void foo(int *)`), we would complain about
     an ambiguity.

Differential Revision: https://reviews.llvm.org/D24113

llvm-svn: 280553
2016-09-02 22:59:57 +00:00
Aaron Ballman 8b871d96d7 Based on post-commit feedback over IRC with dblaikie, ideally, we should have a SmallVector constructor that accepts anything which can supply a range via ADL begin()/end() calls so that we can construct the SmallVector directly from anything range-like.
Since that doesn't exist right now, use a local variable instead of calling getAssocExprs() twice; NFC.

llvm-svn: 280520
2016-09-02 18:31:31 +00:00
Aaron Ballman ff7bd8bacd Allow a C11 generic selection expression to select a function with the overloadable attribute as the result expression without crashing. This fixes PR30201.
llvm-svn: 280483
2016-09-02 13:45:40 +00:00
Justin Lebar 18e2d82297 [CUDA] Raise an error if a wrong-side call is codegen'ed.
Summary:
Some function calls in CUDA are allowed to appear in
semantically-correct programs but are an error if they're ever
codegen'ed.  Specifically, a host+device function may call a host
function, but it's an error if such a function is ever codegen'ed in
device mode (and vice versa).

Previously, clang made no attempt to catch these errors.  For the most
part, they would be caught by ptxas, and reported as "call to unknown
function 'foo'".

Now we catch these errors and report them the same as we report other
illegal calls (e.g. a call from a host function to a device function).

This has a small change in error-message behavior for calls that were
previously disallowed (e.g. calls from a host to a device function).
Previously, we'd catch disallowed calls fairly early, before doing
additional semantic checking e.g. of the call's arguments.  Now we catch
these illegal calls at the very end of our semantic checks, so we'll
only emit a "illegal CUDA call" error if the call is otherwise
well-formed.

Reviewers: tra, rnk

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D23242

llvm-svn: 278759
2016-08-15 23:00:49 +00:00
George Burgess IV 458b3f3a11 [Sema] Fix the wording of a comment. NFC.
llvm-svn: 278472
2016-08-12 04:19:35 +00:00
George Burgess IV 53b938da5a [Sema] Fix a crash on variadic enable_if functions.
Currently, when trying to evaluate an enable_if condition, we try to
evaluate all arguments a user passes to a function. Given that we can't
use variadic arguments from said condition anyway, not converting them
is a reasonable thing to do. So, this patch makes us ignore any varargs
when attempting to check an enable_if condition.

We'd crash because, in order to convert an argument, we need its
ParmVarDecl. Variadic arguments don't have ParmVarDecls.

llvm-svn: 278471
2016-08-12 04:12:31 +00:00
Justin Lebar 7d078bddbd [CUDA] Print a "previous-decl" note when calling an illegal member fn.
Summary:
When we emit err_ref_bad_target, we should emit a "'method' declared
here" note.  We already do so in most places, just not in
BuildCallToMemberFunction.

Reviewers: tra

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D23240

llvm-svn: 278195
2016-08-10 01:09:18 +00:00
Justin Lebar b008003aa3 [CUDA] Rename CheckCUDATarget to IsAllowedCUDACall. NFC
Summary:
I want to reuse "CheckCUDAFoo" in a later patch.  Also, I think
IsAllowedCUDACall gets the point across more clearly.

Reviewers: tra

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D23238

llvm-svn: 278193
2016-08-10 01:09:11 +00:00
Justin Lebar 66a2ab9175 [CUDA] Minor comment nits.
llvm-svn: 278183
2016-08-10 00:40:43 +00:00
George Burgess IV 21081364f8 [Sema] Replace mem_fn with lambdas. NFC.
I'm told that some optimizers like lambdas a lot more than mem_fn.
Given that the readability difference is basically nil, and we seem to
use lambdas basically everywhere else, it seems sensible to just use
lambdas.

llvm-svn: 276577
2016-07-24 23:12:40 +00:00
Dmitry Polukhin ba57f02720 Deprecated (legacy) string literal conversion to 'char *' causes strange overloading resolution
It's a patch for PR28050. Seems like overloading resolution wipes out
the first standard conversion sequence (before user-defined conversion)
in case of deprecated string literal conversion.

Differential revision: https://reviews.llvm.org/D21228

Patch by Alexander Makarov

llvm-svn: 275970
2016-07-19 11:29:16 +00:00
Justin Lebar d35f706cc2 [CUDA] Don't assume that destructors can't be overloaded.
Summary:
You can overload a destructor in CUDA, and SemaOverload needs to be
tweaked not to crash when it sees an explicit call to an overloaded
destructor.

Reviewers: rsmith

Subscribers: cfe-commits, tra

Differential Revision: http://reviews.llvm.org/D21912

llvm-svn: 275231
2016-07-12 23:23:01 +00:00
David Majnemer 02d57cc92c [MS ABI] Pick an inheritance model if we resolve an overload set
We didn't assign an inheritance model for 'Foo' if the event an
exrepssion like '&Foo::Bar' occured if 'Bar' could resolve to multiple
functions.

Once the overload set is resolved to a particular member, we enforce a
specific inheritance model.

This fixes PR28360.

llvm-svn: 274202
2016-06-30 03:02:03 +00:00
Richard Smith 5179eb7821 P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991:
Replace inheriting constructors implementation with new approach, voted into
C++ last year as a DR against C++11.

Instead of synthesizing a set of derived class constructors for each inherited
base class constructor, we make the constructors of the base class visible to
constructor lookup in the derived class, using the normal rules for
using-declarations.

For constructors, UsingShadowDecl now has a ConstructorUsingShadowDecl derived
class that tracks the requisite additional information. We create shadow
constructors (not found by name lookup) in the derived class to model the
actual initialization, and have a new expression node,
CXXInheritedCtorInitExpr, to model the initialization of a base class from such
a constructor. (This initialization is special because it performs real perfect
forwarding of arguments.)

In cases where argument forwarding is not possible (for inalloca calls,
variadic calls, and calls with callee parameter cleanup), the shadow inheriting
constructor is not emitted and instead we directly emit the initialization code
into the caller of the inherited constructor.

Note that this new model is not perfectly compatible with the old model in some
corner cases. In particular:
 * if B inherits a private constructor from A, and C uses that constructor to
   construct a B, then we previously required that A befriends B and B
   befriends C, but the new rules require A to befriend C directly, and
 * if a derived class has its own constructors (and so its implicit default
   constructor is suppressed), it may still inherit a default constructor from
   a base class

llvm-svn: 274049
2016-06-28 19:03:57 +00:00
David Majnemer a3debed239 Use even more ArrayRefs
No functional change is intended, just a small refactoring.

llvm-svn: 273650
2016-06-24 05:33:44 +00:00
George Burgess IV beca4a3338 [Sema] Teach CheckPlaceholderExpr about unaddressable functions.
Given the following C++:

```
void foo();
void foo() __attribute__((enable_if(false, "")));

bool bar() {
  auto P = foo;
  return P == foo;
}
```

We'll currently happily (and correctly) resolve `foo` to the `foo`
overload without `enable_if` when assigning to `P`. However, we'll
complain about an ambiguous overload on the `P == foo` line, because
`Sema::CheckPlaceholderExpr` doesn't recognize that there's only one
`foo` that could possibly work here.

This patch teaches `Sema::CheckPlaceholderExpr` how to properly deal
with such cases.

Grepping for other callers of things like
`Sema::ResolveAndFixSingleFunctionTemplateSpecialization`, it *looks*
like this is the last place that needed to be fixed up. If I'm wrong,
I'll see if there's something we can do that beats what amounts to
whack-a-mole with bugs.

llvm-svn: 272080
2016-06-08 00:34:22 +00:00
Richard Smith c2bebe9aca Preserve the FoundDecl when performing overload resolution for constructors.
This is in preparation for C++ P0136R1, which switches the model for inheriting
constructors over from synthesizing a constructor to finding base class
constructors (via using shadow decls) when looking for derived class
constructors.

llvm-svn: 269231
2016-05-11 20:37:46 +00:00
Andrey Bokhanko 45d413260e [MSVC] Implementation of __unaligned as a proper type qualifier
This patch implements __unaligned (MS extension) as a proper type qualifier
(before that, it was implemented as an ignored attribute).

It also fixes PR27367 and PR27666.

Differential Revision: http://reviews.llvm.org/D20103

llvm-svn: 269220
2016-05-11 18:38:21 +00:00
George Burgess IV e8f10cc0b9 [Sema] Fix value-dependent enable_if bug.
This patch fixes a bug where we would assume all value-dependent
enable_if conditions give successful results.

Instead, we consider value-dependent enable_if conditions to always
fail. While this isn't ideal, this is the best we can realistically do
without changing both enable_if's semantics and large parts of Sema
(specifically, all of the parts that don't expect type dependence to
come out of nowhere, and that may interact with overload resolution).

Differential Revision: http://reviews.llvm.org/D20130

llvm-svn: 269154
2016-05-11 01:38:27 +00:00
George Burgess IV 3dc1669133 [Sema] Fix an overload resolution bug with enable_if.
Currently, if clang::isBetterOverloadCandidate encounters an enable_if
attribute on either candidate that it's inspecting, it will ignore all
lower priority attributes (e.g. pass_object_size). This is problematic
in cases like:

```
void foo(char *c) __attribute__((enable_if(1, "")));
void foo(char *c __attribute__((pass_object_size(0))))
    __attribute__((enable_if(1, "")));
```

...Because we would ignore the pass_object_size attribute in the second
`foo`, and consider any call to `foo` to be ambiguous.

This patch makes overload resolution consult further tiebreakers (e.g.
pass_object_size) if two candidates have equally good enable_if
attributes.

llvm-svn: 269005
2016-05-10 01:59:34 +00:00
Nemanja Ivanovic bb1ea2d613 Enable support for __float128 in Clang and enable it on pertinent platforms
This patch corresponds to reviews:
http://reviews.llvm.org/D15120
http://reviews.llvm.org/D19125

It adds support for the __float128 keyword, literals and target feature to
enable it. Based on the latter of the two aforementioned reviews, this feature
is enabled on Linux on i386/X86 as well as SystemZ.
This is also the second attempt in commiting this feature. The first attempt
did not enable it on required platforms which caused failures when compiling
type_traits with -std=gnu++11.

If you see failures with compiling this header on your platform after this
commit, it is likely that your platform needs to have this feature enabled.

llvm-svn: 268898
2016-05-09 08:52:33 +00:00
Nico Weber 2801d32c07 Revert r268727, it caused PR27666.
llvm-svn: 268736
2016-05-06 14:34:29 +00:00
Andrey Bokhanko ba0d7540e3 [MSVC] Implementation of __unaligned as a proper type qualifier
This patch implements __unaligned (MS extension) as a proper type qualifier
(before that, it was implemented as an ignored attribute).

It also fixes PR27367.

Differential Revision: http://reviews.llvm.org/D19654

llvm-svn: 268727
2016-05-06 11:47:55 +00:00
George Burgess IV f23ce3609b [Sema] Specify the underlying type for an enum. NFC.
llvm-svn: 268113
2016-04-29 21:32:53 +00:00
Serge Pavlov 7dcc97e7ac Warn if function or variable cannot be implicitly instantiated
With this patch compiler emits warning if it tries to make implicit instantiation
of a template but cannot find the template definition. The warning can be suppressed
by explicit instantiation declaration or by command line options
-Wundefined-var-template and -Wundefined-func-template. The implementation follows
the discussion of http://reviews.llvm.org/D12326.

Differential Revision: http://reviews.llvm.org/D16396

llvm-svn: 266719
2016-04-19 06:19:52 +00:00