| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If function parameters have default values, and that of the second
parameter is parsed with errors, function declaration would have
a parameter without default value that follows a parameter with
that. Such declaration breaks logic of selecting overloaded
function. As a solution, put opaque object as default value in such case.
This patch fixes PR20055.
Differential Revision: http://reviews.llvm.org/D4378
llvm-svn: 213594
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
I don't think other implicit members like copy assignment and move
assignment require this treatment, because they should already be
operating on a constructed object.
Fixes PR20351.
llvm-svn: 213346
|
|
|
|
|
|
|
|
|
|
|
|
| |
-- a constructor list initialization that unpacked an initializer list into
constructor arguments and
-- a list initialization that created as std::initializer_list and passed it
as the first argument to a constructor
in the AST. Use this flag while instantiating templates to provide the right
semantics for the resulting initialization.
llvm-svn: 213224
|
|
|
|
|
|
| |
declarations that don't start with 'friend' keyword. Add more unittests.
llvm-svn: 213220
|
|
|
|
|
|
|
|
|
| |
We would silently accept volatile ~S() when the user probably intended
to write virtual ~S().
This fixes PR20238.
llvm-svn: 212555
|
|
|
|
|
|
|
|
|
|
| |
This source range is useful for all kinds of diagnostic QOI and refactoring
work, so let's make it more discoverable.
This commit also makes use of the new function to enhance various diagnostics
relating to return types and resolves an old FIXME.
llvm-svn: 212154
|
|
|
|
| |
llvm-svn: 211764
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
specialization bases (PR11170)
Consider the following code:
template <typename T> class Base {};
class __declspec(dllexport) class Derived : public Base<int> {}
When the base of an exported or imported class is a class template
specialization, MSVC will propagate the dll attribute to the base.
In the example code, Base<int> becomes a dllexported class.
This commit makes Clang do the proopagation when the base hasn't been
instantiated yet, and warns about it being unsupported otherwise.
This is different from MSVC, which allows changing a specialization
back and forth between dllimport and dllexport and seems to let the
last one win. Changing the dll attribute after instantiation would be
hard for us, and doesn't seem to come up in practice, so I think this
is a reasonable limitation to have.
MinGW doesn't do this kind of propagation.
Differential Revision: http://reviews.llvm.org/D4264
llvm-svn: 211725
|
|
|
|
| |
llvm-svn: 211394
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When adding the implicit compound statement (required for Codegen?), the
end location was previously overridden by the start location, probably
based on the assumptions:
* The location of the compound statement should be the member's location
* The compound statement if present is the last element of a FunctionDecl
This patch changes the location of the compound statement to the
member's end location.
Code review: http://reviews.llvm.org/D4175
llvm-svn: 211344
|
|
|
|
|
|
|
|
| |
This makes us handle static locals in exported/imported functions correctly.
Differential Revision: http://reviews.llvm.org/D4136
llvm-svn: 211173
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CRTP-like patterns involve a class which inherits from another class
using itself as a template parameter.
However, the base class itself may try to create a pointer-to-member
which involves the derived class. This is problematic because we
may not have finished parsing the most derived classes' base specifiers
yet.
It turns out that MSVC simply uses the unspecified inheritance model
instead of doing anything fancy.
This fixes PR19987.
llvm-svn: 210886
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we would do the access check from the context of
MarkVTableUsed.
Also update this test to C++11, since that is typically used with the MS
C++ ABI.
Fixes PR20005.
llvm-svn: 210850
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Current MSVC versions don't have move assignment operators, so we
can't rely on them being available in the dll. If we have the
definition, we can just use that directly. This breaks pointer
equality, but should work fine otherwise.
When there is an MSVC version that supports move assignment,
we can key this off the -fmsc-ver option.
http://reviews.llvm.org/D4105
llvm-svn: 210715
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We would previously end up with an error when instantiating the
following template:
template <typename> struct __declspec(dllimport) S {
void foo() = delete;
};
S<int> s;
error: attribute 'dllimport' cannot be applied to a deleted function
llvm-svn: 210550
|
|
|
|
|
|
|
| |
will never be true in a well-defined context. The checking for null pointers
has been moved into the caller logic so it does not rely on undefined behavior.
llvm-svn: 210498
|
|
|
|
| |
llvm-svn: 210328
|
|
|
|
|
|
|
| |
function parameter. One of our existing test cases was XFAILed because
of this. This fixes the issue and un-XFAILs the test.
llvm-svn: 210026
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D3973
llvm-svn: 209954
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements the central part of support for dllimport/dllexport on
classes: allowing the attribute on class declarations, inheriting it
to class members, and forcing emission of exported members. It's based
on Nico Rieck's patch from http://reviews.llvm.org/D1099.
This patch doesn't propagate dllexport to bases that are template
specializations, which is an interesting problem. It also doesn't
look at the rules when redeclaring classes with different attributes,
I'd like to do that separately.
Differential Revision: http://reviews.llvm.org/D3877
llvm-svn: 209908
|
|
|
|
| |
llvm-svn: 209827
|
|
|
|
| |
llvm-svn: 209812
|
|
|
|
|
|
| |
takeAs to getAs.
llvm-svn: 209800
|
|
|
|
|
|
|
|
|
| |
These note diags have the same message and can be unified further but for now
let's just bring them together.
Incidental change: Display a source range in the final attr diagnostic.
llvm-svn: 209728
|
|
|
|
| |
llvm-svn: 209613
|
|
|
|
| |
llvm-svn: 209511
|
|
|
|
| |
llvm-svn: 209285
|
|
|
|
| |
llvm-svn: 209224
|
|
|
|
|
|
|
|
| |
Also correct argument/parameter terminology.
No change in functionality.
llvm-svn: 208498
|
|
|
|
|
|
|
|
|
| |
The base class is the culprit/risk here - a sealed/final derived class
with virtual functions and a non-virtual dtor can't accidentally be
polymorphically destroyed (if the base class's dtor is protected - which
also suppresses this warning).
llvm-svn: 208449
|
|
|
|
| |
llvm-svn: 207962
|
|
|
|
|
|
|
|
| |
apply the NRVO candidate flag to all possible NRVO candidates here, and remove the flags in computeNRVO or upon template instantiation. A variable now has NRVO applied if and only if every return statement in that scope returns that variable. This is nearly optimal.
Performs NRVO roughly 7% more often in a bootstrap build of clang. Patch co-authored by Richard Smith.
llvm-svn: 207890
|
|
|
|
|
|
|
|
|
|
|
| |
class template member classes (PR19613)
Also improve this code in general by implementing suggestions
from Richard.
Differential Revision: http://reviews.llvm.org/D3555?id=9020
llvm-svn: 207822
|
|
|
|
|
|
|
| |
correction to direct base class members, and recover properly after we apply
such a correction.
llvm-svn: 207731
|
|
|
|
| |
llvm-svn: 207681
|
|
|
|
|
|
| |
base classes.
llvm-svn: 207680
|
|
|
|
|
|
| |
non-member declaration. Patch by Dinesh Dwivedi!
llvm-svn: 207677
|
|
|
|
|
|
| |
symbols in non-imported modules.
llvm-svn: 206977
|
|
|
|
|
|
|
|
| |
statements, don't diagnose; the return type might end up being 'void'.
Patch by Rahul Jain! Tiny tweaks by me.
llvm-svn: 206929
|
|
|
|
|
|
| |
imported from another module, emit an update record, rather than using the broken decl rewriting mechanism. If multiple modules do this, merge the definitions together, much as we would if they were separate declarations.
llvm-svn: 206680
|
|
|
|
|
|
| |
template-id after its scope specifier into a single place.
llvm-svn: 206442
|
|
|
|
|
|
| |
if the member is already 'const'. Don't assert in that case.
llvm-svn: 206205
|
|
|
|
|
|
|
|
|
|
|
| |
declaration is not visible. Previously we didn't find hidden friend names in
this redeclaration lookup, because we forgot to treat it as a redeclaration
lookup. Conversely, we did find some local extern names, but those don't
actually conflict with a namespace-scope using declaration, because the only
conflicts we can get are scope conflicts, not conflicts due to the entities
being members of the same namespace.
llvm-svn: 206011
|
|
|
|
|
|
| |
to suggest a different syntax to get the same effect.
llvm-svn: 205467
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Declaring a function as inline after it has been defined is in violation
of [dcl.fct.spec]p4. The program would get a strong definition instead
of getting a function with linkonce_odr linkage.
Reviewers: rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3220
llvm-svn: 205129
|
|
|
|
|
|
|
|
| |
This commit also adds an additional test case for the global destructor warning.
Reviewed in http://llvm-reviews.chandlerc.com/D3205
llvm-svn: 204954
|
|
|
|
|
|
| |
Fixes PR19253.
llvm-svn: 204825
|
|
|
|
|
|
| |
resolved, emit an update record.
llvm-svn: 204403
|