As described by Richard in https://groups.google.com/a/isocpp.org/d/msg/std-discussion/S1kmj0wF5-g/fb6agEYoL2IJ
we should allow:
template<typename S>
struct A {
template<typename T> static auto default_lambda() {
return [](const T&) { return 42; };
}
template<class U = decltype(default_lambda<S>())>
U func(U u = default_lambda<S>()) { return u; }
};
int run2 = A<double>{}.func()(3.14);
int run3 = A<char>{}.func()('a');
This patch allows the code using the same trickery that was used to allow the code in non-member functions at namespace scope.
Please see http://llvm-reviews.chandlerc.com/D1844 for richard's approval.
llvm-svn: 192166
Summary:
Operator new, new[], delete, and delete[] are all implicitly static when
declared inside a record. CXXMethodDecl already knows this, but we need
to account for that before we pick the calling convention for the
function type.
Fixes PR17371.
Reviewers: rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1761
llvm-svn: 192150
When nested C++11 lambdas are used in NSDMI's - this patch prevents infinite recursion by computing the linkage of any nested lambda by determining the linkage of the outermost enclosing lambda (which might inherit its linkage from its parent).
See http://llvm-reviews.chandlerc.com/D1783 for Doug's approval.
[On a related note, I need this patch so as to pass tests of transformations of nested lambdas returned from member functions]
llvm-svn: 191727
When nested lambdas are used in NSDMI's - this prevents infinite recursion.
See http://llvm-reviews.chandlerc.com/D1783 for Doug's approval regarding the code, and then request for some tests.
[On a related note, I need this patch so as to pass tests of transformations of nested lambdas returned from member functions]
llvm-svn: 191645
putting them in the call operator's DeclContext. This better matches the
language wording and avoids some cases where code gets confused by them for
namespace-scope lambdas and the like.
llvm-svn: 191606
The intent of getTypeOperand() was to yield an unqualified type.
However QualType::getUnqualifiedType() does not strip away qualifiers on
arrays.
N.B. This worked fine when typeid() was applied to an expression
because we would inject as implicit cast to the unqualified array type
in the AST.
llvm-svn: 191487
variable from being the function to being the enclosing namespace scope (in
C++) or the TU (in C). This allows us to fix a selection of related issues
where we would build incorrect redeclaration chains for such declarations, and
fail to notice type mismatches.
Such declarations are put into a new IdentifierNamespace, IDNS_LocalExtern,
which is only found when searching scopes, and not found when searching
DeclContexts. Such a declaration is only made visible in its DeclContext if
there are no non-LocalExtern declarations.
llvm-svn: 191064
Summary:
When selecting a mangling for an anonymous tag type:
- We should first try it's typedef'd name.
- If that doesn't work, we should mangle in the name of the declarator
that specified it as a declaration specifier.
- If that doesn't work, fall back to a static mangling of
<unnamed-type>.
This should make our anonymous type mangling compatible.
This partially fixes PR16994; we would need to have an implementation of
scope numbering to get it right (a separate issue).
Reviewers: rnk, rsmith, rjmccall, cdavis5x
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1540
llvm-svn: 190892
Like any other type, an init list for a vector can have the same type as
the vector itself; handle that case.
<rdar://problem/14990460>
llvm-svn: 190844
Summary:
- lambdas, blocks or captured statements in templates were not
handled which causes codegen crashes.
Differential Revision: http://llvm-reviews.chandlerc.com/D1628
llvm-svn: 190784
Summary:
We should treat a non-dependent template specialization like it wasn't
templated at all.
Reviewers: rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1554
llvm-svn: 190743
GCC ToT doesn't do this & it's worth about 3.2% on Clang's DWO file size
with Clang. Some or all of this may be due to things like r190715 which
could have source fixes/improvements, but it's not clear that's the case
and that doesn't help other source bases.
llvm-svn: 190716
Summary:
Functions named "main", "wmain", "WinMain", "wWinMain", and "DllMain"
are never mangled regardless of linkage, even when compiling for kernel
mode.
Depends on D1655
Reviewers: timurrrr, pcc, rnk, whunt
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1670
llvm-svn: 190675
Summary:
This is a first step to getting extern "C" working properly inside
clang. There are a number of quirks but mangling declarations inside
such a function are a good first step.
Reviewers: timurrrr, pcc, cdavis5x
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1655
llvm-svn: 190671
Summary:
More accurately characterize the nature of array parameters. Doing this
removes false back-reference opportunities. Remove some hacks now that
we characterize these better.
Reviewers: rnk, timurrrr, whunt, cdavis5x
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1626
llvm-svn: 190488
Static locals requiring initialization are not thread safe on Windows.
Unfortunately, it's possible to create static locals that are actually
externally visible with inline functions and templates. As a result, we
have to implement an initialization guard scheme that is compatible with
TUs built by MSVC, which makes thread safety prohibitively difficult.
MSVC's scheme is that every function that requires a guard gets an i32
bitfield. Each static local is assigned a bit that indicates if it has
been initialized, up to 32 bits, at which point a new bitfield is
created. MSVC rejects inline functions with more than 32 static locals,
and the externally visible mangling (?_B) only allows for one guard
variable per function.
On Eli's recommendation, I used MangleNumberingContext to track which
bit each static corresponds to.
Implements PR16888.
Reviewers: rjmccall, eli.friedman
Differential Revision: http://llvm-reviews.chandlerc.com/D1416
llvm-svn: 190427
By removing the possibility of strange partial definitions with no
members that older GCC's produced for the otherwise unreferenced outer
types of referenced inner types, we can simplify debug info generation
and correct this bug. Newer (4.8.1 and ToT) GCC's don't produce this
quirky debug info, and instead produce the full definition for the outer
type (except in the case where that type is dynamic and its vtable is
not emitted in this TU).
During the creation of the context for a type, we may revisit that type
(due to the need to visit template parameters, among other things) and
used to end up visiting it first there. Then when we would reach the
original code attempting to define that type, we would lose debug info
by overwriting its members.
By avoiding the possibility of latent "defined with no members" types,
we can be sure than whenever we already have a type in a cache (either a
definition or declaration), we can just return that. In the case of a
full definition, our work is done. In the case of a partial definition,
we must already be in the process of completing it. And in the case of a
declaration, the completed/vtable/etc callbacks can handle converting it
to a definition.
llvm-svn: 190122
A quirk of AST representation leads to class template static data member
definitions being visited twice during Clang IRGen resulting in
duplicate (benign) initializers.
Discovered while investigating a possibly-related debug info bug tickled
by the duplicate emission of these members & their associated debug
info.
With thanks to Richard Smith for help investigating, understanding, and
helping with the fix.
llvm-svn: 189996
I tried to implement this properly in r189051, but I didn't have enough
test coverage. Richard kindly provided more test cases than I could
possibly imagine and now we should have the correct condition.
llvm-svn: 189898
Faisal Vali