| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Fixes PR41792: Clang assertion failure on templated friend member function
Differential Revision: https://reviews.llvm.org/D69481
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
template name is not visible to unqualified lookup.
In order to support this without a severe degradation in our ability to
diagnose typos in template names, this change significantly restructures
the way we handle template-id-shaped syntax for which lookup of the
template name finds nothing.
Instead of eagerly diagnosing an undeclared template name, we now form a
placeholder template-name representing a name that is known to not find
any templates. When the parser sees such a name, it attempts to
disambiguate whether we have a less-than comparison or a template-id.
Any diagnostics or typo-correction for the name are delayed until its
point of use.
The upshot should be a small improvement of our diagostic quality
overall: we now take more syntactic context into account when trying to
resolve an undeclared identifier on the left hand side of a '<'. In
fact, this works well enough that the backwards-compatible portion (for
an undeclared identifier rather than a lookup that finds functions but
no function templates) is enabled in all language modes.
llvm-svn: 360308
|
|
|
|
|
|
|
|
|
|
|
|
| |
triggers instantiation of constexpr functions.
We mostly implemented this since Clang 6, but missed the template
instantiation case.
We do not implement the '&cast-expression' special case. It appears to
be a mistake / oversight. I've mailed CWG to see if we can remove it.
llvm-svn: 343064
|
|
|
|
|
|
|
|
|
| |
More generally, this permits a template to be specialized in any scope in which
it could be defined, so this also supersedes DR44 and DR374 (the latter of
which we previously only implemented in C++11 mode onwards due to unclarity as
to whether it was a DR).
llvm-svn: 327705
|
|
|
|
|
|
|
|
|
| |
diagnostics.
We were previouly assuming that every type template was a class template, which
is not true any more.
llvm-svn: 291988
|
|
|
|
|
|
|
| |
template arguments as written rather than the canonical template arguments,
so we print more user-friendly names for template parameters.
llvm-svn: 290483
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Much to my surprise, '-disable-llvm-optzns' which I thought was the
magical flag I wanted to get at the raw LLVM IR coming out of Clang
deosn't do that. It still runs some passes over the IR. I don't want
that, I really want the *raw* IR coming out of Clang and I strongly
suspect everyone else using it is in the same camp.
There is actually a flag that does what I want that I didn't know about
called '-disable-llvm-passes'. I suspect many others don't know about it
either. It both does what I want and is much simpler.
This removes the confusing version and makes that spelling of the flag
an alias for '-disable-llvm-passes'. I've also moved everything in Clang
to use the 'passes' spelling as it seems both more accurate (*all* LLVM
passes are disabled, not just optimizations) and much easier to remember
and spell correctly.
This is part of simplifying how Clang drives LLVM to make it cleaner to
wire up to the new pass manager.
Differential Revision: https://reviews.llvm.org/D28047
llvm-svn: 290392
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Other compilers accept invalid code here that we reject, and we need a
better error message to try to convince users that the code is really
incorrect. Consider:
class Foo {
typedef MyIterHelper<Foo> iterator;
friend class iterator;
};
Previously our wording was "elaborated type refers to a typedef".
"elaborated type" isn't widely known terminology, so the new diagnostic
says "typedef 'iterator' cannot be referenced with class specifier".
Reviewers: rsmith
Differential Revision: https://reviews.llvm.org/D25216
llvm-svn: 289259
|
|
|
|
|
|
| |
C++ language standard is not C++98.
llvm-svn: 280309
|
|
|
|
|
|
|
|
|
| |
explicit specialization to a warning for C++98 mode (this is a defect report
resolution, so per our informal policy it should apply in C++98), and turn
the warning on by default for C++11 and later. In all cases where it fires, the
right thing to do is to remove the pointless explicit instantiation.
llvm-svn: 280308
|
|
|
|
|
|
|
| |
variable weak discardable linkage and partially-ordered initialization, and is
implied for constexpr static data members.)
llvm-svn: 273754
|
|
|
|
|
|
| |
24 tests have been updated for C++11 compatibility.
llvm-svn: 266387
|
|
|
|
|
|
|
| |
13 tests have been updated for C++11 compatibility.
Differential Revision: http://reviews.llvm.org/D19068
llvm-svn: 266239
|
|
|
|
|
|
|
| |
Added expected diagnostics new to C++11.
Expanded RUN line to: default, C++98/03 and C++11.
llvm-svn: 253371
|
|
|
|
|
|
| |
Changes diagnostic options, language standard options, diagnostic identifiers, diagnostic wording to use c++14 instead of c++1y. It also modifies related test cases to use the updated diagnostic wording.
llvm-svn: 215982
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-frewrite-includes. [PR20321]"
We've decided to make the core rewriter class and PP rewriters mandatory.
They're only a few hundred lines of code in total and not worth supporting as a
distinct build configuration, especially since doing so disables key compiler
features.
This reverts commit r213150.
Revert "clang/test: Introduce the feature "rewriter" for --enable-clang-rewriter."
This reverts commit r213148.
Revert "Move clang/test/Frontend/rewrite-*.c to clang/test/Frontend/Rewriter/"
This reverts commit r213146.
llvm-svn: 213159
|
|
|
|
| |
llvm-svn: 213148
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
A reference temporary should inherit the linkage of the variable it
initializes. Otherwise, we may hit cases where a reference temporary
wouldn't have the same value in all translation units.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3515
llvm-svn: 207451
|
|
|
|
|
|
| |
lookup when declaring a variable template specialization.
llvm-svn: 199438
|
|
|
|
|
|
|
| |
instantiation appears in a non-enclosing namespace (the previous diagnostic
talked about the C++98 rule even in C++11 mode).
llvm-svn: 196642
|
|
|
|
|
|
|
|
|
|
|
| |
We would fail to instantiate them when the surrounding function was
instantiated. Instantiate the class and add it's members to the list of
pending instantiations, they should be resolved when we are finished
with the function's body.
This fixes PR9685.
llvm-svn: 195827
|
|
|
|
|
|
| |
argument list, but could be instantiated with argument list of <>.
llvm-svn: 190913
|
|
|
|
| |
llvm-svn: 189919
|
|
|
|
|
|
| |
variable
llvm-svn: 188350
|
|
|
|
|
|
| |
fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention...
llvm-svn: 187762
|
|
|
|
| |
llvm-svn: 184577
|
|
|
|
| |
llvm-svn: 184559
|
|
|
|
|
|
| |
(FixIts yet to be tested.)
llvm-svn: 184503
|
|
|
|
|
|
|
|
|
| |
C++1y, so stop adding the 'const' there. Provide a compatibility warning for
code relying on this in C++11, with a fix-it hint. Update our lazily-written
tests to add the const, except for those ones which were testing our
implementation of this rule.
llvm-svn: 179969
|
|
|
|
| |
llvm-svn: 172697
|
|
|
|
|
|
| |
we know whether it is static.
llvm-svn: 172376
|
|
|
|
|
|
| |
VerifyDiagnosticConsumer, make the necessary adjustment to 580 test-cases which will henceforth require this new directive.
llvm-svn: 166280
|
|
|
|
|
|
|
|
|
| |
are otherwise too short to try to correct.
The TODOs added to two of the tests are for existing deficiencies in the
typo correction code that could be exposed by using longer identifiers.
llvm-svn: 158109
|
|
|
|
|
|
|
|
|
|
|
| |
Moves the bool bail-out down a little in SemaChecking - so now
-Wnull-conversion and -Wliteral-conversion can fire when the target type is
bool.
Also improve the wording/details in the -Wliteral-conversion warning to match
the -Wconstant-conversion.
llvm-svn: 156826
|
|
|
|
| |
llvm-svn: 156513
|
|
|
|
|
|
|
|
|
|
| |
so that we actually accumulate all the delayed diagnostics. Do
this so that we can restore those diagnostics to good standing
if it turns out that we were wrong to suppress, e.g. if the
tag specifier is actually an elaborated type specifier and not
a declaration.
llvm-svn: 156291
|
|
|
|
|
|
| |
in the wrong namespace scope. Patch by Jonathan Sauer!
llvm-svn: 154656
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This diagnostic seems to be production ready, it's just an oversight that it
wasn't turned on by default.
The test changes are a bit of a mixed bag. Some tests that seemed like they
clearly didn't need to use this behavior have been modified not to use it.
Others that I couldn't be sure about, I added the necessary expected-warnings
to.
It's possible the diagnostic message could be improved to make it clearer that
this warning can be suppressed by using a value that won't lose precision when
converted to the target type (but can still be a floating point literal, such
as "bool b = 1.0;").
llvm-svn: 154068
|
|
|
|
|
|
|
| |
class template's definition, and for explicit specializations of such enum
members.
llvm-svn: 153304
|
|
|
|
|
|
|
|
| |
scoped enumeration members. Later uses of an enumeration temploid as a nested
name specifier should cause its instantiation. Plus some groundwork for
explicit specialization of member enumerations of class templates.
llvm-svn: 152750
|
|
|
|
|
|
| |
specialization.
llvm-svn: 147798
|
|
|
|
|
|
|
| |
'is an extension'. The former is inappropriate and confusing when building with
-Werror/-pedantic-errors.
llvm-svn: 147357
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Explicit instantiations following specializations are no-ops and hence have
no PointOfInstantiation. That was done correctly in most cases, but for a
specialization -> instantiation decl -> instantiation definition chain, the
definition didn't realize that it was a no-op. Fix that.
Also, when printing diagnostics for these no-ops, get the diag location from
the decl name location.
Add many test cases, one of them not yet passing (but it failed the same way
before this change). Fixes http://llvm.org/pr11558 and more.
llvm-svn: 147225
|
|
|
|
| |
llvm-svn: 146988
|
|
|
|
|
|
|
| |
valid C++98/03 code. However, add these warnings to -Wall, for those
who obviously already like clean code.
llvm-svn: 142903
|
|
|
|
|
|
| |
gcc's behaviour), and a -Wc++98-compat-pedantic warning for C++11.
llvm-svn: 142597
|
|
|
|
| |
llvm-svn: 141982
|
|
|
|
|
|
| |
-std=c++0x. Patch by Ahmed Charles!
llvm-svn: 141900
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
arithmetic into a couple of common routines. Use these to make the
messages more consistent in the various contexts, especially in terms of
consistently diagnosing binary operators with invalid types on both the
left- and right-hand side. Also, improve the grammar and wording of the
messages some, handling both two pointers and two (different) types.
The wording of function pointer arithmetic diagnostics still strikes me
as poorly phrased, and I worry this makes them slightly more awkward if
more consistent. I'm hoping to fix that with a follow-on patch and test
case that will also make them more helpful when a typedef or template
type parameter makes the type completely opaque.
Suggestions on better wording are very welcome, thanks to Richard Smith
for some initial help on that front.
llvm-svn: 133906
|
|
|
|
|
|
|
|
| |
specializations within an explicit instantiation to default to off
(enabled by -pedantic). Nobody else seem to implement C++
[temp.explicit]p3. Fixes PR10093.
llvm-svn: 132704
|