| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
add functions to namespace 'std', also filter out namespaces with '__' anywhere
in the name.
llvm-svn: 167786
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Patch from Brian Brooks!
llvm-svn: 167604
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 166520
|
|
|
|
|
|
| |
namespace.
llvm-svn: 166194
|
|
|
|
|
|
| |
OverloadCandidateSet::clear and don't do it on destruction.
llvm-svn: 165501
|
|
|
|
| |
llvm-svn: 165383
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
longer needed after the unused Context member was removed in r164104.
llvm-svn: 164196
|
|
|
|
|
|
| |
relational operators of enumeration type. From the gcc testsuite.
llvm-svn: 164171
|
|
|
|
| |
llvm-svn: 163846
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
it's likely to lead to a crash later on. Fixes PR12933 /
<rdar://problem/11525335>.
llvm-svn: 163838
|
|
|
|
| |
llvm-svn: 163829
|
|
|
|
| |
llvm-svn: 162586
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 162552
|
|
|
|
|
|
|
| |
These were nops for quite a while and only lead to confusion. ASTMultiPtr
now behaves like a proper dumb array reference.
llvm-svn: 162475
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 162006
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 161036
|
|
|
|
| |
llvm-svn: 160622
|
|
|
|
|
|
| |
number of formal parameters for a variadic function call.
llvm-svn: 160570
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 158985
|
|
|
|
| |
llvm-svn: 158981
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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
|
|
|
|
|
|
| |
types to actually includes the value, rather than saying <uninitialized>.
llvm-svn: 158745
|
|
|
|
| |
llvm-svn: 158733
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
unsigned type is narrowing if the source is non-constant or negative.
llvm-svn: 158377
|
|
|
|
|
|
| |
consider them when enumerating builtin operator candidates.
llvm-svn: 158293
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
which expects exactly one argument, include the name of the argument in
the diagnostic text. Patch by Terry Long!
llvm-svn: 156607
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 156178
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 155282
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 154613
|