to provide proper overloading, and also prevents mangling conflicts with
template arguments of protocol-qualified type.
This is a non-backward-compatible mangling change, but per discussion with
John, the benefits outweigh this cost.
Fixes <rdar://problem/14074822>.
llvm-svn: 184250
by ensuring DiagnoseUseOfDecl is called both on the found decl and the
decl being used (i.e the specialization in the case of member templates) whenever they are different.
Per the exchange captured in
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130610/081636.html
a more comprehensive fix that allows both decls to be passed into DiagnoseUseOfDecl is (or should be) forthcoming relatively soon.
llvm-svn: 184043
common function. The C++1y contextual implicit conversion rules themselves are
not yet implemented, however.
This also fixes a subtle bug where template instantiation context notes were
dropped for diagnostics coming from conversions for integral constant
expressions -- we were implicitly slicing a SemaDiagnosticBuilder into a
DiagnosticBuilder when producing these diagnostics, and losing their context
notes in the process.
llvm-svn: 182406
- References to ObjC bit-field ivars are bit-field lvalues;
fixes rdar://13794269, which got me started down this.
- Introduce Expr::refersToBitField, switch a couple users to
it where semantically important, and comment the difference
between this and the existing API.
- Discourage Expr::getBitField by making it a bit longer and
less general-sounding.
- Lock down on const_casts of bit-field gl-values until we
hear back from the committee as to whether they're allowed.
llvm-svn: 181252
to use. This makes very little difference right now (other than suppressing
follow-on errors in some cases), but will matter more once we support deduced
return types (we don't want expressions with undeduced return types in the
AST).
llvm-svn: 181107
It was being used correctly, but it is a very dangerous API to have around.
Instead, move the logic from the filtering to when we are deciding if we should
link two decls.
llvm-svn: 179523
We were assuming that any expression used as a converted constant
expression would either not have a folded constant value or would be
an integer, which is not the case for some ill-formed constant
expressions. Because converted constant expressions are only used
where integral values are expected, we can simply treat this as an
error path. If that ever changes, we'll need to widen the interface of
Sema::CheckConvertedConstantExpression() anyway.
llvm-svn: 179068
When two template decls with the same name are used in this diagnostic,
force them to print their qualified names. This changes the bad message of:
candidate template ignored: could not match 'array' against 'array'
to the better message of:
candidate template ignored: could not match 'NS2::array' against 'NS1::array'
llvm-svn: 179056
When Sema::RequireCompleteType() is given a class template
specialization type that then fails to instantiate, it returns
'true'. On subsequent invocations, it can return false. Make sure that
this difference doesn't change the result of
Sema::CompareReferenceRelationship, which is expected to remain stable
while we're checking an initialization sequence.
llvm-svn: 178088
Before this patch we would compute the linkage lazily and cache it. When the
AST was modified in ways that could change the value, we would invalidate the
cache.
That was fairly brittle, since any code could ask for the a linkage before
the correct value was available.
We should change the API to one where the linkage is computed explicitly and
trying to get it when it is not available asserts.
This patch is a first step in that direction. We still compute the linkage
lazily, but instead of invalidating a cache, we assert that the AST
modifications didn't change the result.
llvm-svn: 176999
This would error in C++ mode unless the variable also had a cv
qualifier.
e.g.
__attribute__((address_space(2))) float foo = 1.0f; would error but
__attribute__((address_space(2))) const float foo = 1.0f; would not.
llvm-svn: 176121
Weather we should give C language linkage to functions and variables with
internal linkage probably depends on how much code assumes it. The standard
says they should have no language linkage, but gcc and msvc assign them
C language linkage.
This commit removes the hack that was preventing the mangling on static
functions declare in extern C contexts. It is an experiment to see if we
can implement the rules in the standard.
If it turns out that many users depend on these functions and variables
having C language linkage, we should change isExternC instead and try
to convince the CWG to change the standard.
llvm-svn: 175937
I added hasCLanguageLinkage while fixing some language linkage bugs some
time ago so that I wouldn't have to check all users of isExternC. It turned
out to be a much longer detour than expected, but this patch finally
merges the two again. The isExternC function now implements just the
standard notion of having C language linkage.
llvm-svn: 175119
MarkMemberReferenced instead of marking functions referenced directly. An audit
of callers to MarkFunctionReferenced and DiagnoseUseOfDecl also caused a few
other changes:
* don't mark functions odr-used when considering them for an initialization
sequence. Do mark them referenced though.
* the function nominated by the cleanup attribute should be diagnosed.
* operator new/delete should be diagnosed when building a 'new' expression.
llvm-svn: 174951
have a direct mismatch between some component of the template and some
component of the argument. The diagnostic now says what the mismatch was, but
doesn't yet say which part of the template doesn't match.
llvm-svn: 174039
This patch moves hasCLanguageLinkage to be VarDecl and FunctionDecl methods
so that they can be used from SemaOverload.cpp and then fixes the logic
in Sema::IsOverload.
llvm-svn: 171193
This does limit these typedefs to being sequences, but no current usage
requires them to be contiguous (we could expand this to a more general
iterator pair range concept at some point).
Also, it'd be nice if SmallVector were constructible directly from an ArrayRef
but this is a bit tricky since ArrayRef depends on SmallVectorBaseImpl for the
inverse conversion. (& generalizing over all range-like things, while nice,
would require some nontrivial SFINAE I haven't thought about yet)
llvm-svn: 170482
array from a braced-init-list. There seems to be a core wording wart
here (it suggests we should be testing whether the elements of the init
list are implicitly convertible to the array element type, not whether
there is an implicit conversion sequence) but our prior behavior appears
to be a bug, not a deliberate effort to implement the standard as written.
llvm-svn: 169690
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
and we resolve it to a specific function based on the type which it's used as,
don't forget to mark it as referenced.
Fixes a regression introduced in r167514.
llvm-svn: 167918
I couldn't think of a way to make an operator() invalid without returning
earlier from this function other than making it static, so no new test.
llvm-svn: 167609
function that takes a const Foo&, where Foo is convertible from a large number
of pointer types, we print ALL the overloads, no matter the setting of
-fshow-overloads.
There is potential follow-on work in unifying the "print candidates, but not
too many" logic between OverloadCandidateSet::NoteCandidates and
ImplicitConversionSequence::DiagnoseAmbiguousConversion.
llvm-svn: 167596
instantiate it if it can be instantiated and implicitly define it if it can be
implicitly defined. This matches g++'s approach. Remove some cases from
SemaOverload which were marking functions as referenced when just planning how
overload resolution would proceed; such cases are not actually references.
llvm-svn: 167514
Clang will now honor the FP_CONTRACT pragma and emit LLVM
fmuladd intrinsics for expressions of the form A * B + C (when they occur in a
single statement).
llvm-svn: 164989
function being instantiated. An error recovery codepath was recursively
performing name lookup (and triggering an unbounded stack of template
instantiations which blew out the stack before hitting the depth limit).
Patch by Wei Pan!
llvm-svn: 164586
integral promotions to both its underlying type and to its underlying type's
promoted type. This matters now that boolean conversions aren't permitted in
converted constant expressions (a la DR1407): an enumerator with a fixed
underlying type of bool still can be.
llvm-svn: 163841
The old error message stating that 'begin' was an undeclared identifier
is replaced with a new message explaining that the error is in the range
expression, along with which of the begin() and end() functions was
problematic if relevant.
Additionally, if the range was a pointer type or defines operator*,
attempt to dereference the range, and offer a FixIt if the modified range
works.
llvm-svn: 162248
This is effectively a warning for code that violates core issue 903 & thus will
become standard error in the future, hopefully. It catches strange null
pointers such as: '\0', 1 - 1, const int null = 0; etc...
There's currently a flaw in this warning (& the warning for 'false' as a null
pointer literal as well) where it doesn't trigger on comparisons (ptr == '\0'
for example). Fix to come in a future patch.
Also, due to this only being a warning, not an error, it triggers quite
frequently on gtest code which tests expressions for null-pointer-ness in a
SFINAE context (so it wouldn't be a problem if this was an error as in an
actual implementation of core issue 903). To workaround this for now, the
diagnostic does not fire in unevaluated contexts.
Review by Sean Silva and Richard Smith.
llvm-svn: 161501
Panzer. I've not been able to trigger a failure caused by this, so no test yet.
Also included is a small change from Paul Robinson to only consider the
FailureKind if the overload candidate did actually fail.
llvm-svn: 160470
resulted in it being reverted. A test for that bug was added in r158950.
Original comment:
If an object (such as a std::string) with an appropriate c_str() member function
is passed to a variadic function in a position where a format string indicates
that c_str()'s return type is desired, provide a note suggesting that the user
may have intended to call the c_str() member.
Factor the non-POD-vararg checking out of DefaultVariadicArgumentPromotion and
move it to SemaChecking in order to facilitate this. Factor the call checking
out of function call checking and block call checking, and extend it to cover
constructor calls too.
Patch by Sam Panzer!
llvm-svn: 159159
* Primarily fixed \param commands with names not matching any actual
parameters of the documented functions. In many cases this consists
just of fixing up the parameter name in the \param to match the code,
in some it means deleting obsolete documentation and occasionally it
means documenting the parameter that has replaced the older one that
was documented, which sometimes means some simple reverse-engineering
of the docs from the implementation;
* Fixed \param ParamName [out] to the correct format with [out] before
the parameter name;
* Fixed some \brief summaries.
llvm-svn: 158980
Revert "If an object (such as a std::string) with an appropriate c_str() member function"
This reverts commit 7d96f6106bfbd85b1af06f34fdbf2834aad0e47e.
llvm-svn: 158949
is passed to a variadic function in a position where a format string indicates
that c_str()'s return type is desired, provide a note suggesting that the user
may have intended to call the c_str() member.
Factor the non-POD-vararg checking out of DefaultVariadicArgumentPromotion and
move it to SemaChecking in order to facilitate this. Factor the call checking
out of function call checking and block call checking, and extend it to cover
constructor calls too.
Patch by Sam Panzer!
llvm-svn: 158887
because it expects a reference and receives a non-l-value.
For example, given:
int foo(int &);
template<int x> void b() { foo(x); }
clang will now print "expects an l-value for 1st argument" instead of
"no known conversion from 'int' to 'int &' for 1st argument". The change
in wording (and associated code to detect the case) was prompted by
comment #5 in PR3104, and should be the last bit of work needed for the
bug.
llvm-svn: 158691
* Removed \param comments for parameters that no longer exist;
* Fixed a "\para" typo to "\param";
* Escaped @, # and \ symbols as needed in Doxygen comments;
* Added use of \brief to output short summaries.
llvm-svn: 158498
involving 'restrict', place restrict on the pointer type rather than
on the pointee type. Also make sure that we gather restrict from the
pointer type. Fixes PR12854 and the major part of PR11093.
llvm-svn: 157910
volatile reference to a temporary is not viable. My interpretation is that
DR1152 was a bugfix, not a rule change for C++11, so this is not conditional on
the language mode. This matches g++'s behavior.
llvm-svn: 157370
candidate template ignored: substitution failed [with T = int]: no type named 'type' in 'std::enable_if<false, void>'
Instead, just say:
candidate template ignored: disabled by 'enable_if' [with T = int]
... and point at the enable_if condition which (we assume) failed.
This is applied to all cases where the user writes 'typename enable_if<...>::type' (optionally prefixed with a nested name specifier), and 'enable_if<...>' names a complete class type which does not have a member named 'type', and this results in a candidate function being ignored in a SFINAE context. Thus it catches 'std::enable_if', 'std::__1::enable_if', 'boost::enable_if' and 'llvm::enable_if'.
llvm-svn: 156463
overload candidate, and include its message in any subsequent 'candidate not
viable due to substitution failure' note we may produce.
To keep the note small (since the 'overload resolution failed' diagnostics are
often already very verbose), the text of the SFINAE diagnostic is included as
part of the text of the note, and any notes which were attached to it are
discarded.
There happened to be spare space in OverloadCandidate into which a
PartialDiagnosticAt could be squeezed, and this patch goes to lengths to avoid
unnecessary PartialDiagnostic copies, resulting in no slowdown that I could
measure. (Removal in passing of some PartialDiagnostic copies has resulted in a
slightly smaller clang binary overall.) Even on a torture test, I was unable to
measure a memory increase of above 0.2%.
llvm-svn: 156297
Sema::ConvertToIntegralOrEnumerationType() from PartialDiagnostics to
abstract "diagnoser" classes. Not much of a win here, but we're
-several PartialDiagnostics.
llvm-svn: 156217
off PartialDiagnostic. PartialDiagnostic is rather heavyweight for
something that is in the critical path and is rarely used. So, switch
over to an abstract-class-based callback mechanism that delays most of
the work until a diagnostic is actually produced. Good for ~11k code
size reduction in the compiler and 1% speedup in -fsyntax-only on the
code in <rdar://problem/11004361>.
llvm-svn: 156176
We have a new flavor of exception specification, EST_Uninstantiated. A function
type with this exception specification carries a pointer to a FunctionDecl, and
the exception specification for that FunctionDecl is instantiated (if needed)
and used in the place of the function type's exception specification.
When a function template declaration with a non-trivial exception specification
is instantiated, the specialization's exception specification is set to this
new 'uninstantiated' kind rather than being instantiated immediately.
Expr::CanThrow has migrated onto Sema, so it can instantiate exception specs
on-demand. Also, any odr-use of a function triggers the instantiation of its
exception specification (the exception specification could be needed by IRGen).
In passing, fix two places where a DeclRefExpr was created but the corresponding
function was not actually marked odr-used. We used to get away with this, but
don't any more.
Also fix a bug where instantiating an exception specification which refers to
function parameters resulted in a crash. We still have the same bug in default
arguments, which I'll be looking into next.
This, plus a tiny patch to fix libstdc++'s common_type, is enough for clang to
parse (and, in very limited testing, support) all of libstdc++4.7's standard
headers.
llvm-svn: 154886
types. The second and third conversions in the sequence are based on
the conversion for the underlying type, so that we get sensible
overloading behavior for, e.g., _Atomic(int) vs. _Atomic(float).
As part of this, actually implement the lvalue-to-rvalue conversion
for atomic types. There is probably a pile of code in SemaExpr that
can now be deleted, but I haven't tracked it down yet.
llvm-svn: 154596
for converting an empty list to a scalar, be sure to initialize
the source and destination types so that comparison of conversion
sequences will work in case there are multiple viable candidates.
llvm-svn: 153993
track whether the referenced declaration comes from an enclosing
local context. I'm amenable to suggestions about the exact meaning
of this bit.
llvm-svn: 152491
- getSourceRange().getBegin() is about as awesome a pattern as .copy().size().
I already killed the hot paths so this doesn't seem to impact performance on my
tests-of-the-day, but it is a much more sensible (and shorter) pattern.
llvm-svn: 152419
analysis to make the AST representation testable. They are represented by a
new UserDefinedLiteral AST node, which is a sugared CallExpr. All semantic
properties, including full CodeGen support, are achieved for free by this
representation.
UserDefinedLiterals can never be dependent, so no custom instantiation
behavior is required. They are mangled as if they were direct calls to the
underlying literal operator. This matches g++'s apparent behavior (but not its
actual mangling, which is broken for literal-operator-ids).
User-defined *string* literals are now fully-operational, but the semantic
analysis is quite hacky and needs more work. No other forms of user-defined
literal are created yet, but the AST support for them is present.
This patch committed after midnight because we had already hit the quota for
new kinds of literal yesterday.
llvm-svn: 152211
associated classes, since it can find friend functions declared within them,
but overload resolution does not otherwise require argument types to be
complete.
llvm-svn: 151434
explicit conversion functions to initialize the argument to a
copy/move constructor that itself is the subject of direct
initialization. Since we don't have that much context in overload
resolution, we end up threading more flags :(.
Fixes <rdar://problem/10903741> / PR10456.
llvm-svn: 151409
lambda closure type's function pointer conversion over user-defined
conversion via a lambda closure type's block pointer conversion,
always. This is a preference for more-standard code (since blocks
are an extension) and a nod to efficiency, since function pointers
don't require any memory management. Fixes PR12063.
llvm-svn: 151170
function call (or a comma expression with a function call on its right-hand
side), possibly parenthesized, then the return type is not required to be
complete and a temporary is not bound. Other subexpressions inside a decltype
expression do not get this treatment.
This is implemented by deferring the relevant checks for all calls immediately
within a decltype expression, then, when the expression is fully-parsed,
checking the relevant constraints and stripping off any top-level temporary
binding.
Deferring the completion of the return type exposed a bug in overload
resolution where completion of the argument types was not attempted, which
is also fixed by this change.
llvm-svn: 151117
function, provide a specialized diagnostic that indicates the kind of
special member function (default constructor, copy assignment
operator, etc.) and that it was implicitly deleted. Add a hook where
we can provide more detailed information later.
llvm-svn: 150611
that is referencing the member function, so we can index the referenced function.
Fixes rdar://10762375&10324915 & http://llvm.org/PR11192
llvm-svn: 150033
a typedef of std::pair. This slightly improves type-safety, but mostly
makes code using it clearer to read as well as making it possible to add
methods to the type.
Add such a method for efficiently single-step desugaring a split type.
Add a method to single-step desugaring a locally-unqualified type.
Implement both the SplitQualType and QualType methods in terms of that.
Also, fix a typo ("ObjCGLifetime").
llvm-svn: 150028
value of class type, look for a unique conversion operator converting to
integral or unscoped enumeration type and use that. Implements [expr.const]p5.
Sema::VerifyIntegerConstantExpression now performs the conversion and returns
the converted result. Some important callers of Expr::isIntegralConstantExpr
have been switched over to using it (including all of those required for C++11
conformance); this switch brings a side-benefit of improved diagnostics and, in
several cases, simpler code. However, some language extensions and attributes
have not been moved across and will not perform implicit conversions on
constant expressions of literal class type where an ICE is required.
In passing, fix static_assert to perform a contextual conversion to bool on its
argument.
llvm-svn: 149776
array new expression. This lays some groundwork for the implicit conversion to
integral or unscoped enumeration which C++11 ICEs undergo.
llvm-svn: 149772
The new callback, in addition to limiting which keywords to include in
the pool of typo correction candidates, also filters out non-keyword
candidates that don't refer to (template) functions that accept the
number of arguments that are present for the call being recovered.
llvm-svn: 148962
Fix some review comments.
Add a test for deduction when std::initializer_list isn't available yet.
Fix redundant error messages. This fixes and outstanding FIXME too.
llvm-svn: 148735
values and non-type template arguments of integral and enumeration types.
This change causes some legal C++98 code to no longer compile in C++11 mode, by
enforcing the C++11 rule that narrowing integral conversions are not permitted
in the final implicit conversion sequence for the above cases.
llvm-svn: 148439
No new unit tests yet as there is no behavioral change
(except for slightly more specific filtering in
Sema::ActOnStartOfLambdaDefinition). Tests will be added
as the code paths are traced in greater depth to determine
how to improve the results--there are at least one or two
known bugs that require those improvements. This commit
lays the groundwork for those changes.
llvm-svn: 148382
for it to be used in converted constant expression checking, and fix a couple
of issues:
- Conversion operators implicitly invoked prior to the narrowing conversion
were not being correctly handled when determining whether a constant value
was narrowed.
- For conversions from floating-point to integral types, the diagnostic text
incorrectly always claimed that the source expression was not a constant
expression.
llvm-svn: 148381
Eli Friedman