| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
ExtWarn/Warnings. Mostly the name of the warning was changed to match the
semantics, but in the PR20356 cases, the warning was about valid code, so the
diagnostic was changed from ExtWarn to Warning instead.
llvm-svn: 213443
|
|
|
|
|
|
| |
declarations that don't start with 'friend' keyword. Add more unittests.
llvm-svn: 213220
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously dllimport variables inside of template arguments relied on
not using the C++11 codepath when -fms-compatibility was set.
While this allowed us to achieve compatibility with MSVC, it did so at
the expense of MingW.
Instead, try to use the DeclRefExpr we dig out of the template argument.
If it has the dllimport attribute, accept it and skip the C++11
null-pointer check.
llvm-svn: 211766
|
|
|
|
| |
llvm-svn: 211764
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a follow-up to David's r211677. For the following code,
we would end up referring to 'foo' in the initializer for 'arr',
and then fail to link, because 'foo' is dllimport and needs to be
accessed through the __imp_?foo.
__declspec(dllimport) extern const char foo[];
const char* f() {
static const char* const arr[] = { foo };
return arr[0];
}
Differential Revision: http://reviews.llvm.org/D4299
llvm-svn: 211736
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The compilation pipeline doesn't actually need to know about the high-level
concept of diagnostic mappings, and hiding the final computed level presents
several simplifications and other potential benefits.
The only exceptions are opportunistic checks to see whether expensive code
paths can be avoided for diagnostics that are guaranteed to be ignored at a
certain SourceLocation.
This commit formalizes that invariant by introducing and using
DiagnosticsEngine::isIgnored() in place of individual level checks throughout
lex, parse and sema.
llvm-svn: 211005
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
'sizeof' is a UnaryExprOrTypeTrait, and it can contain either a type or
an expression. This change threads a RecoveryTSI parameter through the
layers between TransformUnaryExprOrTypeTrait the point at which we look
up the type. If lookup finds a single type result after instantiation,
we now build TypeSourceInfo for it just like a normal transformation
would.
This fixes the last error in the hello world ATL app that I've been
working with, and it now links and runs with clang. Please try it and
file bugs!
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4108
llvm-svn: 210855
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While matching a non-type template argument against a known template
type parameter we now modify the AST's TemplateArgumentLoc to assume the
user wrote typename. Under -fms-compatibility, we downgrade our
diagnostic from an error to an extwarn.
Reviewed by: rsmith
Differential Revision: http://reviews.llvm.org/D4049
llvm-svn: 210607
|
|
|
|
|
|
|
|
| |
results in a template having too many arguments, but all the trailing arguments
are packs, that's OK if we have a partial pack substitution: the trailing pack
expansions may end up empty.
llvm-svn: 210350
|
|
|
|
|
|
| |
redundant ellipsis in parameter pack.
llvm-svn: 210304
|
|
|
|
| |
llvm-svn: 209812
|
|
|
|
|
|
| |
takeAs to getAs.
llvm-svn: 209800
|
|
|
|
| |
llvm-svn: 209613
|
|
|
|
|
|
|
|
|
|
| |
gets explicitly specialized, don't reuse the previous class template
specialization declaration as a new declaration. The benefit here is fairly
marginal, it harms source fidelity, and this is horrible to model if the
specialization was imported from another module (without this change, it
asserts or worse).
llvm-svn: 209552
|
|
|
|
| |
llvm-svn: 208402
|
|
|
|
|
|
|
|
|
| |
a template variable].
A template declaration of a template name can be null in case we have a dependent name or a set of function templates.
Hence use dyn_cast_or_null instead of dyn_cast. Also improve the diagnostic emitted in this case.
llvm-svn: 208313
|
|
|
|
| |
llvm-svn: 207896
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
after we've already instantiated a definition for the function, pass it to the
ASTConsumer again so that it knows the specialization kind has changed and can
update the function's linkage.
This only matters if we instantiate the definition of the function before we
reach the end of the TU; this can happen in at least three different ways:
C++11 constexpr functions, C++14 deduced return types, and functions
instantiated within modules.
llvm-svn: 207152
|
|
|
|
|
|
| |
symbols in non-imported modules.
llvm-svn: 206977
|
|
|
|
| |
llvm-svn: 206452
|
|
|
|
|
|
|
|
| |
definition.
clang\lib\Sema\SemaTemplate.cpp(1826) : error C2064: term does not evaluate to a function taking 1 arguments
llvm-svn: 206451
|
|
|
|
|
|
|
| |
that looks like it might be an explicit specialization, don't recover as an
explicit specialization (bypassing the check that would reject that).
llvm-svn: 206444
|
|
|
|
|
|
| |
template-id after its scope specifier into a single place.
llvm-svn: 206442
|
|
|
|
|
|
|
|
|
|
|
|
| |
at ... )')
For namespaces, this is consistent with mangling and GCC's debug info
behavior. For structs, GCC uses <anonymous struct> but we prefer
consistency between all anonymous entities but don't want to confuse
them with template arguments, etc, so we'll just go with parens in all
cases.
llvm-svn: 205398
|
|
|
|
|
|
| |
param_type_end() with iterator_range param_types(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 204045
|
|
|
|
|
|
| |
class.
llvm-svn: 203640
|
|
|
|
|
|
| |
iterator_range params(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203248
|
|
|
|
|
|
| |
spotting this!
llvm-svn: 201871
|
|
|
|
|
|
|
|
|
|
| |
template parameters, don't look for parameters of outer templates. If a problem
is found in a default template argument, point the diagnostic at the partial
specialization (with a note pointing at the default argument) instead of
pointing it at the default argument and leaving it unclear which partial
specialization os problematic.
llvm-svn: 201031
|
|
|
|
|
|
|
|
|
|
|
|
| |
Properly determine the inheritance model when dealing with nullptr:
- If a nullptr template argument is being checked against
pointer-to-member parameter, nail down an inheritance model.
N.B. We will chose an inheritance model even if we won't ultimately
choose the template to instantiate! Cooky, right?
- Null pointer-to-datamembers have a virtual base table offset of -1,
not zero. Previously, we chose an offset of 0.
llvm-svn: 200920
|
|
|
|
|
|
| |
variable template until we know what the template arguments actually are.
llvm-svn: 200714
|
|
|
|
|
|
|
| |
Otherwise we'd accept them if the LinkageDecl was not the direct
parent DeclContext. PR17968.
llvm-svn: 200641
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A return type is the declared or deduced part of the function type specified in
the declaration.
A result type is the (potentially adjusted) type of the value of an expression
that calls the function.
Rule of thumb:
* Declarations have return types and parameters.
* Expressions have result types and arguments.
llvm-svn: 200082
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix a perennial source of confusion in the clang type system: Declarations and
function prototypes have parameters to which arguments are supplied, so calling
these 'arguments' was a stretch even in C mode, let alone C++ where default
arguments, templates and overloading make the distinction important to get
right.
Readability win across the board, especially in the casting, ADL and
overloading implementations which make a lot more sense at a glance now.
Will keep an eye on the builders and update dependent projects shortly.
No functional change.
llvm-svn: 199686
|
|
|
|
|
|
| |
lookup when declaring a variable template specialization.
llvm-svn: 199438
|
|
|
|
|
|
|
| |
issue 1430. Don't allow a pack expansion to be used as an argument to an alias
template unless the corresponding parameter is a parameter pack.
llvm-svn: 198833
|
|
|
|
|
|
|
|
| |
type-specifier in C++. Some checks will assert in this case otherwise (in
particular, the access specifier may be missing if this happens inside a class
definition, due to a violation of an AST invariant).
llvm-svn: 198721
|
|
|
|
|
|
|
| |
encodes the canonical rules for LLVM's style. I noticed this had drifted
quite a bit when cleaning up LLVM, so wanted to clean up Clang as well.
llvm-svn: 198686
|
|
|
|
|
|
|
|
| |
unneeded typecasts. getScopeRep() already returns a NestedNameSpecifier.
No functional changes intended.
llvm-svn: 198414
|
|
|
|
|
|
|
|
|
|
| |
is specialized by an explicit specialization, start from the first declaration
in case we've got a member of a class template (redeclarations might not number
the template parameters the same way).
Our recover here is still far from ideal.
llvm-svn: 197305
|
|
|
|
|
|
| |
This fixes pr18141.
llvm-svn: 196855
|
|
|
|
|
|
|
|
|
|
|
|
| |
The standard is pretty clear on what it allows inside of template
arguments for non-type template parameters of pointer-to-member.
They must be of the form &qualified-id and cannot come from sources like
constexpr VarDecls or things of that nature.
This fixes PR18192.
llvm-svn: 196852
|
|
|
|
|
|
|
| |
instantiation appears in a non-enclosing namespace (the previous diagnostic
talked about the C++98 rule even in C++11 mode).
llvm-svn: 196642
|
|
|
|
|
|
|
| |
name from the enclosing namespace set if the name is specified as a
qualified-id.
llvm-svn: 196464
|
|
|
|
|
|
|
|
|
| |
nested-name-specifier, rather than crashing. (In fact, reject all
literal-operator-ids that have a non-namespace nested-name-specifier). The
grammar doesn't allow these in some cases, and in other cases does allow them
but instantiation will always fail.
llvm-svn: 196443
|
|
|
|
|
|
| |
to a variable template specialization.
llvm-svn: 196337
|
|
|
|
|
|
| |
simple-template-ids (eg, 'operator+<int>') in weird places.
llvm-svn: 196333
|
|
|
|
|
|
|
|
| |
Before we were considering them only when instantiating templates.
This fixes pr18033.
llvm-svn: 196050
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
There are about 30 removed in this patch, generated by a new FixIt I haven't
got round to submitting yet.
llvm-svn: 195814
|