| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
C++ does not allow shadowing template parameters, but previously we
allowed it under -fms-extensions. Now this behavior is controlled by
-fms-compatibility, and we emit a -Wmicrosoft-template warning when it
happens.
Fixes PR43265
Reviewers: thakis, hans
Subscribers: amccarth, rsmith, STL_MSFT, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67463
llvm-svn: 371753
|
|
|
|
|
|
|
| |
This is more or less a complete rewrite of r347627, and it fixes PR38460
I added a reduced test case to DelayedTemplateParsing.cpp.
llvm-svn: 347713
|
|
|
|
|
|
|
|
|
|
|
| |
It broke the Windows self-host:
http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/1799/steps/stage%202%20build/logs/stdio
I can build
lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/MachinePostDominators.cpp.obj to
repro.
llvm-svn: 347630
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Only push the outermost record as a DeclContext when parsing a function
body. See the comments in Sema::getContainingDC about the way the parser
pushes contexts. This is intended to match the behavior the parser
normally displays where it parses all method bodies from all nested
classes at the end of the outermost class, when all nested classes are
complete.
Fixes PR38460.
llvm-svn: 347627
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang currently crashes on
class C {
C() = default;
C() = delete;
};
My cunning plan for fixing this was to change the `if (!FnD)` in
Parser::ParseCXXInlineMethodDef() to `if (!FnD || FnD->isInvalidDecl)` – but
alas, the second constructor decl wasn't marked as invalid. This lets
Sema::MergeFunctionDecl() return true on function redeclarations, which leads
to them being marked invalid.
This also improves error messages when functions are redeclared.
llvm-svn: 226365
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Based on a patch and test by Stephan Tolksdorf! Refactoring and fixing adjacent
brokenness by me.
llvm-svn: 203733
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit r191484 treated constexpr function templates as normal function
templates with respect to delaying their parsing. However, this is
unnecessarily restrictive because there is no compatibility concern with
constexpr, MSVC doesn't support it.
Instead, simply disable delayed template parsing for constexpr function
templates. This largely reverts the changes made in r191484 but keeps
it's unit test.
This fixes PR17661.
llvm-svn: 193274
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Functions declared as constexpr must have their parsing delayed in
-fdelayed-template-parsing mode so as not to upset later template
instantiation.
N.B. My reading of the standard makes it seem like delayed template
parsing is at odds with constexpr. We may want to make refinements in
other places in clang to make constexpr play nicer with this feature.
This fixes PR17334.
llvm-svn: 191484
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sema::MergeFunctionDecl attempts merging two decls even if the old decl
is invalid. This can lead to interesting circumstances where we
successfully merge the decls but the result makes no sense.
Take the following for example:
template <typename T>
int main(void);
int main(void);
Sema will not consider these to be overloads of the same name because
main can't be overloaded, which means that this must be a redeclaration.
In this case the templated decl is compatible with the non-templated
decl allowing the Sema::CheckFunctionDeclaration machinery to move on
and do bizarre things like setting the previous decl of a non-templated
decl to a templated decl!
The way I see it, we should just bail from MergeFunctionDecl if the old
decl is invalid.
This fixes PR16531.
llvm-svn: 185779
|
|
|
|
|
|
| |
parsing. Fixes <rdar://problem/11700604>.
llvm-svn: 159380
|
|
|
|
|
|
|
|
|
|
| |
templated function; (Not just the template parameter scope as previously). Also enter the scope stack in the correct order.
Otherwise this breaks some invariant during name lookup especially when dealing with shadowed declaration
Fix PR11931.
llvm-svn: 151140
|
|
|
|
|
|
| |
class scope.
llvm-svn: 144980
|
|
|
|
|
|
|
|
|
|
| |
reentering the delayed function context correctly. The problem was that all template params were reintroduced inside the same scope. So if we had a situation where we had 2 template params with the same name at different scope then clang would generate an error about ambiguous name.
The solution is to create a new ParseScope(Scope::TemplateParamScope) for each template scope that we want to reenter. (from the outmost to the innermost scope)
This fixes some errors when parsing MFC code with clang.
llvm-svn: 140344
|
|
|
|
|
|
|
|
| |
update.
Despite the diff, nothing but line endings changed here.
llvm-svn: 130121
|
|
|
|
|
|
| |
-flate-template-parsing mode.
llvm-svn: 130030
|
|
function definitions are parsed at the end of the translation unit only if it is required by an actual instantiation. As such all the symbols of the TU are available during name lookup.
Using this flag is necessary for compatibility with Microsoft template code.
This also provides some parsing speed improvement.
llvm-svn: 130022
|