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
Rafael Espindola