If a class is using the unspecified inheritance model for member
pointers and later we find the class is defined to use single
inheritance, zero out the vbptr offset field of the member pointer when
it is formed.
llvm-svn: 192664
migration to NS_ENUM/NS_OPTIONS macros; when
typedef'ed to NSInteger/NSUInteger preceeds well
before of the enum declaration. // rdar://15201056
llvm-svn: 192645
that looks like a function declaration, except that it's missing a return type,
try typo-correcting it to the relevant constructor name.
In passing, fix a bug where the missing-type-specifier recovery codepath would
drop a preceding scope specifier on the floor, leading to follow-on diagnostics
and incorrect recovery for the auto-in-c++98 hack.
llvm-svn: 192644
We have to reserve at least the width of a pointer for the vfptr. For
classes with small alignment, we weren't reserving enough space, and
were overlapping the first field with the vfptr.
llvm-svn: 192626
This patch fixes the distructor test when checking for vtordisp requirements in
microsoft record layout. A test case is also included.
Addresses:
http://llvm.org/bugs/show_bug.cgi?id=16406#c7
llvm-svn: 192616
This patch fixes PR17019. When doing typo correction, Sema::CorrectTypo uses
correction already seen for the same typo. This causes problems if that
correction is from another scope and cannot be accessed in the current.
llvm-svn: 192594
If the edit distance between the two macros is more than 50%, DefinedMacro may not be header guard or can be header guard of another header file or it might be defining something completely different set by the build environment.
llvm-svn: 192547
function parameter that has array type. Such a parameter will be treated as
a pointer type instead, resulting in a missing begin function error is a
suggestion to dereference the pointer. This provides a different,
more informative diagnostic as well as point to the parameter declaration.
llvm-svn: 192512
This allows the callable_when attribute to be attached to destructors.
Original patch by chris.wailes@gmail.com, reviewed and edited by delesley.
llvm-svn: 192508
Use -no-struct-path-tbaa to turn it off.
This is the same as r191695, which was reverted because it depends on a
commit that has issues.
llvm-svn: 192497
Calling convention attributes can add sugar to methods that we have to
look through. This fixes an assertion failure in the provided test
case.
llvm-svn: 192496
Including following 14 instructions:
4 ld1 insts: load multiple 1-element structure to sequential 1/2/3/4 registers.
ld2/ld3/ld4: load multiple N-element structure to sequential N registers (N=2,3,4).
4 st1 insts: store multiple 1-element structure from sequential 1/2/3/4 registers.
st2/st3/st4: store multiple N-element structure from sequential N registers (N = 2,3,4).
llvm-svn: 192362
Including following 14 instructions:
4 ld1 insts: load multiple 1-element structure to sequential 1/2/3/4 registers.
ld2/ld3/ld4: load multiple N-element structure to sequential N registers (N=2,3,4).
4 st1 insts: store multiple 1-element structure from sequential 1/2/3/4 registers.
st2/st3/st4: store multiple N-element structure from sequential N registers (N = 2,3,4).
E.g. ld1(3 registers version) will load 32-bit elements {A, B, C, D, E, F} sequentially into the three 64-bit vectors list {BA, DC, FE}.
E.g. ld3 will load 32-bit elements {A, B, C, D, E, F} into the three 64-bit vectors list {DA, EB, FC}.
llvm-svn: 192351
marked all variables as "unknown" at the start of a loop. The new version
keeps the initial state of variables unchanged, but issues a warning if the
state at the end of the loop is different from the state at the beginning.
This patch will eventually be replaced with a more precise analysis.
Initial patch by chris.wailes@gmail.com. Reviewed and edited by
delesley@google.com.
llvm-svn: 192314
Follow-up from r192240.
This makes it an error to use callee-cleanup conventions on variadic
functions, except for __fastcall and __stdcall, which we ignore with
a warning for GCC and MSVC compatibility.
Differential Revision: http://llvm-reviews.chandlerc.com/D1870
llvm-svn: 192308
With this patch we produce alias for cases like
template<typename T>
struct foobar {
foobar() {
}
};
template struct foobar<void>;
It is safe to use aliases to weak symbols, as long and the alias itself is also
weak.
llvm-svn: 192300
An invalid decltype expression like 'decltype int' gives:
error: expected '(' after 'decltype'
This makes it so 'sizeof int' gives a similar one:
error: expected parentheses around type name in sizeof expression
llvm-svn: 192258
MSVC and clang with -fms-extensions allow pure virtual methods to be
defined inline after the "= 0" tokens. Clang warns on these because it
is not standard, but incorrectly warns on out-of-line definitions, which
are standard.
With this change, clang will only warn on inline definitions of pure
virtual methods.
Fixes some self-host warnings on out-of-line definitions of pure virtual
destructors.
llvm-svn: 192244
MSVC allows this and silently falls back to __cdecl for variadic functions.
This patch turns Clang's error into a warning in MS mode and adds a test
to make sure we generate correct code.
Differential Revision: http://llvm-reviews.chandlerc.com/D1861
llvm-svn: 192240
properties of block pointer types. Also, remove
strong lifetime attribute from property type
in this migration. This is wip.
// rdar://15082818
llvm-svn: 192226
In the test case one type is coming from a typedef with no default arg, the
other has the default arg. Taking the default arg from the typedef crashes, so
always use the real template paramter declaration. PR17510.
llvm-svn: 192202
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
In r186373, we started merging attributes on typedefs, but this causes
us to try to merge attributes even if the previous declaration was not
a typedef.
Only merge the attributes if the previous decl was also a typedef.
Fixes rdar://problem/15044218
llvm-svn: 192146
An updated version of r191586 with bug fix.
Struct-path aware TBAA generates tags to specify the access path,
while scalar TBAA only generates tags to scalar types.
We should not generate a TBAA tag with null being the first field. When
a TBAA type node is null, the tag should be null too. Make sure we
don't decorate an instruction with a null TBAA tag.
Added a testing case for the bug reported by Richard with -relaxed-aliasing
and -fsanitizer=thread.
llvm-svn: 192145
Fixes <rdar://problem/10679282>.
I'm not completely satisfied with this patch. Sprinkling "diagnostic ignored"
_Pragmas throughout this file is gross, but I couldn't suppress
it for the entire file.
llvm-svn: 192143
extension. The GCC folks have decided to support this even though the standard
committee have not yet approved this feature.
Patch by Hristo Venev!
llvm-svn: 192128
This change doesn't go all the way to making fields redeclarable; instead, it
makes them 'mergeable', which means we can find the canonical declaration, but
not much else (and for a declaration that's not from a module, the canonical
declaration is always that declaration).
llvm-svn: 192092
that a function can be called in. This reduced the total number of annotations
needed and makes writing more complicated behaviour less burdensome.
Patch by chriswails@gmail.com.
llvm-svn: 191983
(assign/unsafe_unretained/weak/retain/strong/copy) in super class
to be overridden by a property with any explicit ownership in the
subclass. // rdar://15014468
llvm-svn: 191971
These IR instructions are undefined when the amount is equal to operand
size, but NEON right shifts support such shifts. Work around that by
emitting a different IR in these cases.
llvm-svn: 191953
It looks like clang always produce code with the ieee comparisons, so it is
safe to ignore this flag (we still error on -mno-ieee-fp).
llvm-svn: 191912
This will emit a warning if a call to clang_analyzer_warnIfReached is
executed, printing REACHABLE. This is a more explicit way to declare
expected reachability than using clang_analyzer_eval or triggering
a bug (divide-by-zero or null dereference), and unlike the former will
work the same in inlined functions and top-level functions. Like the
other debug helpers, it is part of the debug.ExprInspection checker.
Patch by Jared Grubb!
llvm-svn: 191909
This does not yet include capturing (that is next).
Please see test file for examples.
This patch was LGTM'd by Doug:
http://llvm-reviews.chandlerc.com/D1784http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130930/090048.html
When I first committed this patch - a bunch of buildbots were unable to compile the code that VS2010 seemed to compile. Seems like there was a dependency on Sema/Template.h which VS did not seem to need, but I have now added for the other compilers. It still compiles on Visual Studio 2010 - lets hope the buildbots remain quiet (please!)
llvm-svn: 191879
This does not yet include capturing (that is next).
Please see test file for examples.
This patch was LGTM'd by Doug:
http://llvm-reviews.chandlerc.com/D1784
llvm-svn: 191875
This partially addresses PR17435, but it doesn't actually implement the
pragma. If we implement it, we should map levels 1-4 to something like
-Wall and level 0 to something like -w.
llvm-svn: 191833
Also add some tests that there is actually a message and that the bug is
actually a hard error. This actually behaved correctly before, because:
- addTransition() doesn't actually add a transition if the new state is null;
it assumes you want to propagate the predecessor forward and does nothing.
- generateSink() is called in order to emit a bug report.
- If at least one new node has been generated, the predecessor node is /not/
propagated forward.
But now it's spelled out explicitly.
Found by Richard Mazorodze, who's working on a patch that may require this.
llvm-svn: 191805
Replacements were no applied when using a compilation database with paths in the
compilation command relative to the compile directory. This patch makes those
paths abosulte.
llvm-svn: 191776
This attribute allows users to use a modified C or C++ function as an ARM
exception-handling function and, with care, to successfully return control to
user-space after the issue has been dealt with.
rdar://problem/14207019
llvm-svn: 191769
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 we check access for lookup results, make sure we propagate the
result's access to the access control APIs; this can be different from
the natural access of the declaration depending on the path used by the lookup.
PR17394.
llvm-svn: 191726
Currently, IR generation can't handle file-scope compound literals with
non-constant initializers in C++.
Fixes PR17415 (the first crash in the bug).
(We should probably change (T){1,2,3} to use the same codepath as T{1,2,3} in
C++ eventually, given that the semantics of the latter are actually defined by
the standard.)
llvm-svn: 191719
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
The general strategy is to create template versions of the conversion function and static invoker and then during template argument deduction of the conversion function, create the corresponding call-operator and static invoker specializations, and when the conversion function is marked referenced generate the body of the conversion function using the corresponding static-invoker specialization. Similarly, Codegen does something similar - when asked to emit the IR for a specialized static invoker of a generic lambda, it forwards emission to the corresponding call operator.
This patch has been reviewed in person both by Doug and Richard. Richard gave me the LGTM.
A few minor changes:
- per Richard's request i added a simple check to gracefully inform that captures (init, explicit or default) have not been added to generic lambdas just yet (instead of the assertion violation).
- I removed a few lines of code that added the call operators instantiated parameters to the currentinstantiationscope. Not only did it not handle parameter packs, but it is more relevant in the patch for nested lambdas which will follow this one, and fix that problem more comprehensively.
- Doug had commented that the original implementation strategy of using the TypeSourceInfo of the call operator to create the static-invoker was flawed and allowed const as a member qualifier to creep into the type of the static-invoker. I currently kludge around it - but after my initial discussion with Doug, with a follow up session with Richard, I have added a FIXME so that a more elegant solution that involves the use of TrivialTypeSourceInfo call followed by the correct wiring of the template parameters to the functionprototypeloc is forthcoming.
Thanks!
llvm-svn: 191634
Clang uses UTF-16 and UTF-32 for its char16_t's and char32_t's
exclusively. This means that we can define __STDC_UTF_16__ and
__STDC_UTF_32__ unconditionally.
While there, define __STDC_MB_MIGHT_NEQ_WC__ for FreeBSD. FreeBSD's
wchar_t's don't encode characters as ISO-10646; the encoding depends on
the locale used. Because the character set used might not be a superset
of ASCII, we must define __STDC_MB_MIGHT_NEQ_WC__.
llvm-svn: 191631
multi-library path suffix.
The code calculates MIPS toolchain specific multi-lib path suffixes like
mips16/soft-float/el is moved to the separate function
findMultiLibSuffix(). This function called during GCC installation
detection and result is stored for the future using.
The patch reviewed by Rafael Espindola.
http://llvm-reviews.chandlerc.com/D1738
llvm-svn: 191612
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
...rather than trying to figure it out from the call site, and having
people complain that we guessed wrong and that a prototype-less call is
the same as a variadic call on their system. More importantly, fix a
crash when there's no decl at the call site (though we could have just
returned a default value).
<rdar://problem/15037033>
llvm-svn: 191599
This motion appears to have consensus in the C++ committee and is
expected to be voted into the C++14 draft tomorrow during the formal
vote.
No extension warning in C++11 as attributes not specified in the
standard using the standard syntax in C++11 have implementation defined
meaning, and we define the meaning proposed for C++14.
There is one bug exposed as we do not warn on a deprecated template
specialization. I've left a FIXME in the test case and will dig into
that next.
Also, I will add a few more exhaustive test cases of the other features
specified for this attribute in a follow-up commit.
llvm-svn: 191550
Move some tests from typo-correction.cpp to typo-correction-pt2.cpp
because they were running afoul of the hard-coded limit of 20 typos
corrected. Some of the tests after it were still working due to the
limit not applying to cached corrections and in cases where a non-NULL
MemberContext is passed in to Sema::CorrectTypo. Most of the moved tests
still passed after being moved, but the test involving "data_struct" had
only been passing because the test had exceeded that limit so a fix for
it is also included (most of the changes to ParseStmt.cpp are shared with
and originated from another typo correction impovement that was split
into a separate commit).
llvm-svn: 191544
We previously handled one-dimensional arrays but didn't consider the
general case. The fix is simple: keep going through subsequent
dimensions until we get to the base element.
llvm-svn: 191493
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
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
The previous change caused the driver to translate -Wa,-L to the
-msave-temp-labels option for cc1as, but cc1as did not accept that option.
This patch follows the same approach used for similar options (-relax-all,
-noexecstack) in the previous patch.
llvm-svn: 191458
Specifically, the following features are not included in this commit:
- any sort of capturing within generic lambdas
- generic lambdas within template functions and nested
within other generic lambdas
- conversion operator for captureless lambdas
- ensuring all visitors are generic lambda aware
(Although I have gotten some useful feedback on my patches of the above and will be incorporating that as I submit those patches for commit)
As an example of what compiles through this commit:
template <class F1, class F2>
struct overload : F1, F2 {
using F1::operator();
using F2::operator();
overload(F1 f1, F2 f2) : F1(f1), F2(f2) { }
};
auto Recursive = [](auto Self, auto h, auto ... rest) {
return 1 + Self(Self, rest...);
};
auto Base = [](auto Self, auto h) {
return 1;
};
overload<decltype(Base), decltype(Recursive)> O(Base, Recursive);
int num_params = O(O, 5, 3, "abc", 3.14, 'a');
Please see attached tests for more examples.
This patch has been reviewed by Doug and Richard. Minor changes (non-functionality affecting) have been made since both of them formally looked at it, but the changes involve removal of supernumerary return type deduction changes (since they are now redundant, with richard having committed a recent patch to address return type deduction for C++11 lambdas using C++14 semantics).
Some implementation notes:
- Add a new Declarator context => LambdaExprParameterContext to
clang::Declarator to allow the use of 'auto' in declaring generic
lambda parameters
- Add various helpers to CXXRecordDecl to facilitate identifying
and querying a closure class
- LambdaScopeInfo (which maintains the current lambda's Sema state)
was augmented to house the current depth of the template being
parsed (id est the Parser calls Sema::RecordParsingTemplateParameterDepth)
so that SemaType.cpp::ConvertDeclSpecToType may use it to immediately
generate a template-parameter-type when 'auto' is parsed in a generic
lambda parameter context. (i.e we do NOT use AutoType deduced to
a template parameter type - Richard seemed ok with this approach).
We encode that this template type was generated from an auto by simply
adding $auto to the name which can be used for better diagnostics if needed.
- SemaLambda.h was added to hold some common lambda utility
functions (this file is likely to grow ...)
- Teach Sema::ActOnStartOfFunctionDef to check whether it
is being called to instantiate a generic lambda's call
operator, and if so, push an appropriately prepared
LambdaScopeInfo object on the stack.
- various tests were added - but much more will be needed.
There is obviously more work to be done, and both Richard (weakly) and Doug (strongly)
have requested that LambdaExpr be removed form the CXXRecordDecl LambdaDefinitionaData
in a future patch which is forthcoming.
A greatful thanks to all reviewers including Eli Friedman, James Dennett,
and especially the two gracious wizards (Richard Smith and Doug Gregor)
who spent hours providing feedback (in person in Chicago and on the mailing lists).
And yet I am certain that I have allowed unidentified bugs to creep in; bugs, that I will do my best to slay, once identified!
Thanks!
llvm-svn: 191453
I noticed the wrong text was being replaced with the correction while
working on expanding the "namespace-aware" typo correction to include
classes.
llvm-svn: 191450
Unlike with namespaces, searching inside of classes requires also
checking the access to correction candidates (i.e. don't suggest a
correction to a private class member for a correction occurring outside
that class and its methods or friends).
Included is a small (one line) fix for a bug, that was uncovered while
cleaning up the unit tests, where the decls from a TypoCorrection candidate
were preserved in new TypoCorrection candidates that are derived (copied)
from the old TypoCorrection--notably when creating a new candidate by
changing the NestedNameSpecifier associated with the base idenitifer.
llvm-svn: 191449
It is possible that we should say some of these are unsupported, but this is
not any worse than the old behavior of ignoring all unknown -f options.
llvm-svn: 191429
template and defined outside it, don't instantiate it twice when instantiating
the surrounding class template specialization. That would cause us to reject
the code because we think two partial specializations instantiated to produce
the same signature.
llvm-svn: 191418
declared in a typedef declaraton used as super
class of an ObjC class. Curretnly, these protocols
are dropped from the class hierarchy. Test shows that
it is now included. // rdar://15051465
llvm-svn: 191395
Richard Smith