summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaOverload.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Generalize the consumed-parameter array on FunctionProtoTypeJohn McCall2016-03-011-3/+2
| | | | | | | | | to allow arbitrary data to be associated with a parameter. Also, fix a bug where we apparently haven't been serializing this information for the last N years. llvm-svn: 262278
* Minor cleanup of Sema::CheckEnableIf. NFC.George Burgess IV2016-02-241-23/+16
| | | | llvm-svn: 261798
* [CUDA] do not allow attribute-based overloading for __global__ functions.Artem Belevich2016-02-241-1/+4
| | | | | | | | __global__ functions are present on both host and device side, so providing __host__ or __device__ overloads is not going to do anything useful. llvm-svn: 261778
* Remove use of builtin comma operator.Richard Trieu2016-02-181-2/+4
| | | | | | Cleanup for upcoming Clang warning -Wcomma. No functionality change intended. llvm-svn: 261271
* [CUDA] Tweak attribute-based overload resolution to match nvcc behavior.Artem Belevich2016-02-121-3/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | This is an artefact of split-mode CUDA compilation that we need to mimic. HD functions are sometimes allowed to call H or D functions. Due to split compilation mode device-side compilation will not see host-only function and thus they will not be considered at all. For clang both H and D variants will become function overloads visible to compiler. Normally target attribute is considered only if C++ rules can not determine which function is better. However in this case we need to ignore functions that would not be present during current compilation phase before we apply normal overload resolution rules. Changes: * introduced another level of call preference to better describe possible call combinations. * removed WrongSide functions from consideration if the set contains SameSide function. * disabled H->D, D->H and G->H calls. These combinations are not allowed by CUDA and we were reluctantly allowing them to work around device-side calls to math functions in std namespace. We no longer need it after r258880. Differential Revision: http://reviews.llvm.org/D16870 llvm-svn: 260697
* Make ParentMap work with explicit specializations of function templates.Nico Weber2016-02-081-1/+0
| | | | | | | | | | | | | | | | | For an explicit specialization, we first build a FunctionDecl, and then we call SubstDecl() on it to build a second FunctionDecl, which has the first FunctionDecl as canonical decl. The address of an explicit specialization of function template used to be the canonical decl of the FunctionDecl. This is different from all the other DeduceTemplateArguments() calls in SemaOverload, and since the canonical decl isn't visited by ParentMap while the redecl is, it also made ParentMap assert when computing the parent of a address-of-explicit-specialization-fun-template. To fix, remove the getCanonicalDecl() call. No behavior difference for clang, but it fixes an assert in ParentMap (which is e.g. used by libTooling). llvm-svn: 260159
* Annotate dump() methods with LLVM_DUMP_METHOD, addressing Richard Smith ↵Yaron Keren2016-01-291-1/+1
| | | | | | r259192 post commit comment. llvm-svn: 259232
* Make -Wdelete-non-virtual-dtor warn on explicit `a->~A()` dtor calls too.Nico Weber2016-01-151-0/+11
| | | | | | | | | | | | | | | | | | | | | | | -Wdelete-non-virtual-dtor warns if A is a type with virtual functions but without virtual dtor has its constructor called via `delete a`. This makes the warning also fire if the dtor is called via `a->~A()`. This would've found a security bug in Chromium at compile time. Fixes PR26137. To fix the warning, add a virtual destructor, make the class final, or remove its other virtual methods. If you want to silence the warning, there's also a fixit that shows how: test.cc:12:3: warning: destructor called on 'B' ... [-Wdelete-non-virtual-dtor] b->~B(); ^ test.cc:12:6: note: qualify call to silence this warning b->~B(); ^ B:: http://reviews.llvm.org/D16206 llvm-svn: 257939
* [Sema] Suppress diags in overload resolution.George Burgess IV2016-01-131-9/+16
| | | | | | | | | | We were emitting diagnostics from our shiny new C-only overload resolution mode. This patch attempts to silence all such diagnostics. This fixes PR26085. Differential Revision: http://reviews.llvm.org/D16159 llvm-svn: 257710
* [Bugfix] Fix ICE on constexpr vector splat.George Burgess IV2016-01-131-0/+1
| | | | | | | | | | | | | In {CG,}ExprConstant.cpp, we weren't treating vector splats properly. This patch makes us treat splats more properly. Additionally, this patch adds a new cast kind which allows a bool->int cast to result in -1 or 0, instead of 1 or 0 (for true and false, respectively), so we can sanely model OpenCL bool->int casts in the AST. Differential Revision: http://reviews.llvm.org/D14877 llvm-svn: 257559
* [Sema] Teach overload resolution about unaddressable functions.George Burgess IV2016-01-071-1/+25
| | | | | | | | | | | | Given an expression like `(&Foo)();`, we perform overload resolution as if we are calling `Foo` directly. This causes problems if `Foo` is a function that can't have its address taken. This patch teaches overload resolution to ignore functions that can't have their address taken in such cases. Differential Revision: http://reviews.llvm.org/D15590 llvm-svn: 257016
* Improve diagnostic for the case where a function template candidate is rejectedRichard Smith2015-12-311-4/+52
| | | | | | | | by overload resolution because deduction succeeds, but the substituted parameter type for some parameter (with deduced type) doesn't exactly match the corresponding adjusted argument type. llvm-svn: 256657
* [TrailingObjects] Convert ASTTemplateKWAndArgsInfo and ↵James Y Knight2015-12-241-2/+2
| | | | | | | | | | | | | | | | | | | ASTTemplateArgumentListInfo. Doing so required separating them so that the former doesn't inherit from the latter anymore. Investigating that, it became clear that the inheritance wasn't actually providing real value in any case. So also: - Remove a bunch of redundant functions (getExplicitTemplateArgs, getOptionalExplicitTemplateArgs) on various Expr subclasses which depended on the inheritance relationship. - Switched external callers to use pre-existing accessors that return the data they're actually interested in (getTemplateArgs, getNumTemplateArgs, etc). - Switched internal callers to use pre-existing getTemplateKWAndArgsInfo. llvm-svn: 256359
* Split RequireCompleteType into a function that actually requires that the typeRichard Smith2015-12-181-12/+13
| | | | | | | | | | | | | | | | | | | is complete (with an error produced if not) and a function that merely queries whether the type is complete. Either way we'll trigger instantiation if necessary, but only the former will diagnose and recover from missing module imports. The intent of this change is to prevent a class of bugs where code would call RequireCompleteType(..., 0) and then ignore the result. With modules, we must check the return value and use it to determine whether the definition of the type is visible. This also fixes a debug info quality issue: calls to isCompleteType do not trigger the emission of debug information for a type in limited-debug-info mode. This allows us to avoid emitting debug information for type definitions in more cases where we believe it is safe to do so. llvm-svn: 256049
* [modules] Don't try to use the definition of a class ifRichard Smith2015-12-181-6/+3
| | | | | | | RequireCompleteType(..., 0) says we're not permitted to do so. The definition might not be visible, even though we know what it is. llvm-svn: 256045
* Wire a SourceLocation into IsDerivedFrom and move the RequireCompleteType callRichard Smith2015-12-181-59/+61
| | | | | | | | for the derived class into it. This is mostly just a cleanup, but could in principle be a bugfix if there is some codepath that reaches here and didn't previously require a complete type (I couldn't find any such codepath, though). llvm-svn: 256037
* [Sema] Use UnaryOperatorKind and BinaryOperatorKind in parameter lists ↵Craig Topper2015-12-101-9/+4
| | | | | | instead of just unsigned. Removes a few explicit casts. NFC llvm-svn: 255232
* Add tests for `&enable_if_function` diagnostics.George Burgess IV2015-12-031-1/+0
| | | | | | | | The introduction of pass_object_size fixed a few bugs related to taking the address of a function with enable_if attributes. This patch adds tests for the cases that were fixed. llvm-svn: 254646
* Add the `pass_object_size` attribute to clang.George Burgess IV2015-12-021-40/+152
| | | | | | | | | | | | | `pass_object_size` is our way of enabling `__builtin_object_size` to produce high quality results without requiring inlining to happen everywhere. A link to the design doc for this attribute is available at the Differential review link below. Differential Revision: http://reviews.llvm.org/D13263 llvm-svn: 254554
* [modules] Follow the C++ standard's rule for linkage of enumerators: they haveRichard Smith2015-11-131-10/+43
| | | | | | | | | the linkage of the enumeration. For enumerators of unnamed enumerations, extend the -Wmodules-ambiguous-internal-linkage extension to allow selecting an arbitrary enumerator (but only if they all have the same value, otherwise it's ambiguous). llvm-svn: 253010
* [modules] Generalize the workaround for multiple ambiguous definitions ofRichard Smith2015-11-041-26/+39
| | | | | | | | | | | | | internal linkage entities in different modules from r250884 to apply to all names, not just function names. This is really awkward: we don't want to merge internal-linkage symbols from separate modules, because they might not actually be defining the same entity. But we don't want to reject programs that use such an ambiguous symbol if those internal-linkage symbols are in fact equivalent. For now, we're resolving the ambiguity by picking one of the equivalent definitions as an extension. llvm-svn: 252063
* [MSVC Compat] Permit conversions from pointer-to-function to ↵David Majnemer2015-10-311-1/+9
| | | | | | | | | | | pointer-to-object iff -fms-compatibility We permit implicit conversion from pointer-to-function to pointer-to-object when -fms-extensions is specified. This is rather unfortunate, move this into -fms-compatibility and only permit it within system headers unless -Wno-error=microsoft-cast is specified. llvm-svn: 251738
* [coroutines] Creation of promise object, lookup of operator co_await, buildingRichard Smith2015-10-271-12/+8
| | | | | | of await_* calls, and AST representation for same. llvm-svn: 251387
* [coroutines] Add overloaded unary 'operator co_await'.Richard Smith2015-10-221-0/+1
| | | | llvm-svn: 250991
* [modules] libstdc++ defines some static inline functions in its internalRichard Smith2015-10-211-0/+36
| | | | | | | | | | | headers. If those headers end up being textually included twice into the same module, we get ambiguity errors. Work around this by downgrading the ambiguity error to a warning if multiple identical internal-linkage functions appear in an overload set, and just pick one of those functions as the lookup result. llvm-svn: 250884
* [Sema] Fix address-of + enable_if overloading logicGeorge Burgess IV2015-10-161-57/+93
| | | | | | | | | | | | | | | | | Previously, our logic when taking the address of an overloaded function would not consider enable_if attributes, so long as all of the enable_if conditions on a given candidate were true. So, two functions with identical signatures (one with enable_if attributes, the other without), would be considered equally good overloads. If we were calling the function instead of taking its address, then the function with enable_if attributes would be preferred. This patch makes us prefer the candidate with enable_if regardless of if we're calling or taking the address of an overloaded function. Differential Revision: http://reviews.llvm.org/D13795 llvm-svn: 250486
* [Sema] Make `&function_with_enable_if_attrs` an errorGeorge Burgess IV2015-10-121-13/+44
| | | | | | | | | | | | | | | | | | This fixes a bug where one can take the address of a conditionally enabled function to drop its enable_if guards. For example: int foo(int a) __attribute__((enable_if(a > 0, ""))); int (*p)(int) = &foo; int result = p(-1); // compilation succeeds; calls foo(-1) Overloading logic has been updated to reflect this change, as well. Functions with enable_if attributes that are always true are still allowed to have their address taken. Differential Revision: http://reviews.llvm.org/D13607 llvm-svn: 250090
* [Sema] Don't emit multiple diags for one errorGeorge Burgess IV2015-10-121-5/+13
| | | | | | | | | Fixed a bug where we'd emit multiple diagnostics if there was a problem taking the address of an overloaded template function. Differential Revision: http://reviews.llvm.org/D13664 llvm-svn: 250078
* [Sema] Allow C conversions in C overload logicGeorge Burgess IV2015-10-111-15/+36
| | | | | | | | | | C allows for some implicit conversions that C++ does not, e.g. void* -> char*. This patch teaches clang that these conversions are okay when dealing with overloads in C. Differential Revision: http://reviews.llvm.org/D13604 llvm-svn: 249995
* SourceRanges are small and trivially copyable, don't them by reference.Craig Topper2015-10-041-1/+1
| | | | llvm-svn: 249259
* Make incomplete type errors better with enable_ifGeorge Burgess IV2015-09-251-10/+15
| | | | | | | | | | | | This patch fixes the order in which we evaluate the different ways that a function call could be disallowed. Now, if you call a non-overloaded function with an incomplete type and failing enable_if, we'll prioritize reporting the more obvious error (use of incomplete type) over reporting the failing enable_if. Thanks to Ettore Speziale for the patch! llvm-svn: 248595
* Remove wrong implication that value-dependent implies instantiation-dependent,Richard Smith2015-09-231-0/+2
| | | | | | | | | and fix the only code that was depending on this so that it sets all the relevant flags appropriately. No functionality change intended. llvm-svn: 248430
* [CUDA] Allow function overloads in CUDA based on host/device attributes.Artem Belevich2015-09-221-1/+35
| | | | | | | | | | | | | | | | | | | The patch makes it possible to parse CUDA files that contain host/device functions with identical signatures, but different attributes without having to physically split source into host-only and device-only parts. This change is needed in order to parse CUDA header files that have a lot of name clashes with standard include files. Gory details are in design doc here: https://goo.gl/EXnymm Feel free to leave comments there or in this review thread. This feature is controlled with CC1 option -fcuda-target-overloads and is disabled by default. Differential Revision: http://reviews.llvm.org/D12453 llvm-svn: 248295
* [modules] A using-declaration doesn't introduce a new entity, just a new nameRichard Smith2015-09-151-0/+5
| | | | | | | for an existing entity, and as such a using-declaration doesn't need to conflict with a hidden entity (nor vice versa). llvm-svn: 247654
* [MS ABI] Make member pointers return true for isIncompleteTypeDavid Majnemer2015-09-101-4/+0
| | | | | | | The type of a member pointer is incomplete if it has no inheritance model. This lets us reuse more general logic already embedded in clang. llvm-svn: 247346
* Add a new frontend warning for referencing members from the handler of a ↵Aaron Ballman2015-09-011-3/+3
| | | | | | | | constructor or destructor function-try-block, which is UB in C++. This corresponds to the CERT secure coding rule ERR53-CPP. llvm-svn: 246548
* Make sure that we evaluate __attribute__((enable_if)) on a method with no ↵Nick Lewycky2015-08-251-1/+34
| | | | | | overloads. Patch by Ettore Speziale! llvm-svn: 245985
* Clarify the error message when the reason the conversion is not viable is ↵Nick Lewycky2015-08-251-1/+1
| | | | | | because the returned value does not match the function return type. llvm-svn: 245979
* Fix typo - symetric -> symmetric.Eric Christopher2015-08-211-3/+3
| | | | llvm-svn: 245706
* [Sema] Don't emit "pure virtual" warning for fully qualified calls.Davide Italiano2015-07-141-2/+8
| | | | | | | | | | -fapple-kext is an exception because calls will still go through the vtable in that mode. Add a note to make the user aware of that. PR: 23215 Differential Revision: http://reviews.llvm.org/D10935 llvm-svn: 242246
* Implement the Objective-C __kindof type qualifier.Douglas Gregor2015-07-071-17/+1
| | | | | | | | | | The __kindof type qualifier can be applied to Objective-C object (pointer) types to indicate id-like behavior, which includes implicit "downcasting" of __kindof types to subclasses and id-like message-send behavior. __kindof types provide better type bounds for substitutions into unspecified generic types, which preserves more type information. llvm-svn: 241548
* Revert r240270 ("Fixed/added namespace ending comments using clang-tidy").Alexander Kornienko2015-06-221-6/+6
| | | | llvm-svn: 240353
* Fixed/added namespace ending comments using clang-tidy. NFCAlexander Kornienko2015-06-221-6/+6
| | | | | | | | | | | | The patch is generated using this command: $ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \ -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \ work/llvm/tools/clang To reduce churn, not touching namespaces spanning less than 10 lines. llvm-svn: 240270
* Diagnose unsafe uses of nil and __nonnull pointers.Douglas Gregor2015-06-191-1/+1
| | | | | | | | | | | | | | | | | | | This generalizes the checking of null arguments to also work with values of pointer-to-function, reference-to-function, and block pointer type, using the nullability information within the underling function prototype to extend non-null checking, and diagnoses returns of 'nil' within a function with a __nonnull return type. Note that we don't warn about nil returns from Objective-C methods, because it's common for Objective-C methods to mimic the nil-swallowing behavior of the receiver by checking ostensibly non-null parameters and returning nil from otherwise non-null methods in that case. It also diagnoses (via a separate flag) conversions from nullable to nonnull pointers. It's a separate flag because this warning can be noisy. llvm-svn: 240153
* [ms] Don't try to delay lookup for failures in SFINAE context (PR23823)Hans Wennborg2015-06-121-1/+2
| | | | | | | | | | | | | The underlying problem in PR23823 already existed before my recent change in r239558, but that change made it worse (failing not only for undeclared symbols, but also failed overload resolution). This makes Clang not try to delay the lookup in SFINAE context. I assume no current code is relying on SFINAE working with lookups that need to be delayed, because that never seems to have worked. Differential Revision: http://reviews.llvm.org/D10417 llvm-svn: 239639
* [ms] Do lookup in dependent base classes also when overload resolution fails ↵Hans Wennborg2015-06-111-22/+28
| | | | | | | | | | | | | | | | | | | (PR23810) This patch does two things in order to enable compilation of the problematic code in PR23810: 1. In Sema::buildOverloadedCallSet, it postpones lookup for MS mode when no viable candidate is found in the overload set. Previously, lookup would only be postponed here if the overload set was empty. 2. Make BuildRecoveryCallExpr call Sema::DiagnoseEmptyLookup under more circumstances. There is a comment in DiagnoseTwoPhaseLookup that says "Don't diagnose names we find in classes; we get much better diagnostics for these from DiagnoseEmptyLookup." The problem was that DiagnoseEmptyLookup might not get called later, and we failed to recover. Differential Revision: http://reviews.llvm.org/D10369 llvm-svn: 239558
* Fix a few line endings. NFC.Yunzhong Gao2015-05-011-11/+11
| | | | llvm-svn: 236301
* [SemaCXX patch] Patch to fix a crash when a 'delete' constructorFariborz Jahanian2015-04-141-4/+5
| | | | | | | is being accessed. Reviewed by Richard Smith. rdar://20281011 llvm-svn: 234912
* A conversion from a scoped enumeration bitfield to an integral type is anRichard Smith2015-03-281-2/+4
| | | | | | | | integral promotion only if it converts to the underlying type or its promoted type, not if it converts to the promoted type that the bitfield would have it if were of the underlying type. llvm-svn: 233457
* Reformatting, NFCRichard Smith2015-03-261-6/+6
| | | | llvm-svn: 233234
OpenPOWER on IntegriCloud