| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
This is a small optimization on linux, but should help more on windows
where msvc only outputs one destructor if there would be two identical ones.
llvm-svn: 194046
|
| |
|
|
| |
llvm-svn: 194042
|
| |
|
|
|
|
|
| |
"Missing call to Super" in the overriding method and
not in the method itself. // rdar://15385981.
llvm-svn: 194031
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change fixes Richard's testcase for r193815. Now we include non-explicit
submodules into the list of exports.
The test failed previously because:
- recursive_visibility_a1.inner is not imported (only recursive_visibility_a1 is),
- thus the 'inner' submodule is not showing up in any of the import lists,
- and because of this getExportedModules() is not returning the
correct module set -- it only considers modules that are imported.
The fix is to make Module::getExportedModules() include non-explicit submodules
into the list of exports.
llvm-svn: 194018
|
| |
|
|
| |
llvm-svn: 194005
|
| |
|
|
|
|
| |
The analyzer cannot reason about the internal invariances of the data structure (radar://15194597).
llvm-svn: 194004
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Similar C code isn't caught as it seems to hit a different code path.
Also, as the check is only done for record pointers, cases involving
an overloaded operator-> are not handled either. Note that the reason
this check is done in the parser instead of Sema is not related to
having enough knowledge about the current state as it is about being
able to fix up the parser's state to be able to recover and traverse the
correct code paths.
llvm-svn: 194002
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this patch we produce alias for cases like
template<typename T>
struct foobar {
foobar() {
}
};
template struct foobar<void>;
We just have to be careful to produce the same aliases in every TU because
of comdats.
llvm-svn: 194000
|
| |
|
|
| |
llvm-svn: 193997
|
| |
|
|
| |
llvm-svn: 193995
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
A while ago EmitForStmt was changed to explicitly evaluate the
condition expression and create a branch instead of using
EmitBranchOnBool, so that the condition expression could be used for
some cleanup logic. The cleanup stuff has since been reorganized, and
this is no longer necessary.
In EmitCXXForRange, the evaluated condition was never used for
anything else. The logic was presumably modeled on EmitForStmt.
llvm-svn: 193994
|
| |
|
|
|
|
|
|
| |
An initialization somehow found its way in between a comment and the
block of code the comment is about. Moving the initialization makes
this less confusing.
llvm-svn: 193993
|
| |
|
|
|
|
| |
ClangAttrTypeArg is required here.
llvm-svn: 193991
|
| |
|
|
| |
llvm-svn: 193990
|
| |
|
|
|
|
| |
coded into the parser. Instead, they are automatically listed through tablegen.
llvm-svn: 193989
|
| |
|
|
|
|
| |
PR17796.
llvm-svn: 193986
|
| |
|
|
| |
llvm-svn: 193985
|
| |
|
|
|
|
|
| |
the same virtual base class multiple times (and the move assignment is used,
and the move assignment for the virtual base is not trivial).
llvm-svn: 193977
|
| |
|
|
| |
llvm-svn: 193973
|
| |
|
|
| |
llvm-svn: 193970
|
| |
|
|
|
|
|
|
|
|
|
| |
would be deleted are still declared, but are ignored by overload resolution.
Also, don't delete such members if a subobject has no corresponding move
operation and a non-trivial copy. This causes us to implicitly declare move
operations in more cases, but risks move-assigning virtual bases multiple
times in some circumstances (a warning for that is to follow).
llvm-svn: 193969
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the sole distinction between two declarations is that one has a
__restrict qualifier then we should not consider it to be an overload.
Instead, we will consider it as an incompatible redeclaration which is
similar to how MSVC, ICC and GCC would handle it.
This fixes PR17786.
N.B. We must not mangle in __restrict into method qualifiers becase we
don't allow overloading between such declarations anymore. To do
otherwise would be a violation of the Itanium ABI.
llvm-svn: 193964
|
| |
|
|
|
|
|
|
| |
r102230 added an 'echo' making this a no-op.
Also fixes FAIL on native Windows with no shell/GnuWin32.
llvm-svn: 193938
|
| |
|
|
| |
llvm-svn: 193936
|
| |
|
|
|
|
|
|
| |
rdar://13973577
Patch by Fariborz Jahanian.
llvm-svn: 193935
|
| |
|
|
| |
llvm-svn: 193934
|
| |
|
|
| |
llvm-svn: 193924
|
| |
|
|
|
|
|
|
|
|
|
| |
Flexible array members inherently index off of the end of their parent
type.
We shouldn't allow this type to be used as a base, virtual or otherwise,
because indexing off the end may find us inside of another base or the
derived types members.
llvm-svn: 193923
|
| |
|
|
| |
llvm-svn: 193922
|
| |
|
|
| |
llvm-svn: 193921
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
members
Flexible array members only work out if they are the last field of a
record, however virtual bases would give us many situations where the
flexible array member would overlap with the virtual base fields.
It is unlikely in the extreme that this behavior was intended by the
user so raise a diagnostic instead of accepting. This is will not
reject conforming code because flexible array members are an extension
in C++ mode.
llvm-svn: 193920
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The determination of which diagnostics would be issued for certain
anonymous unions started to get a little ridiculous. Clean this up by
inverting the condition-tree's logic from dialect -> issue to
issue -> diagnostic.
As part of this cleanup, move ext_c99_flexible_array_member from
DiagnosticParseKinds.td to DiagnosticSemaKinds.td because it's driven by
Sema, not Parse.
Also, the liberty was taken to edit ext_c99_flexible_array_member to
match other, similar, diagnostics.
llvm-svn: 193919
|
| |
|
|
|
|
|
| |
The declaration of a flexible array member was correctly diagnosed as an
extension in C89 mode but not in C++.
llvm-svn: 193918
|
| |
|
|
| |
llvm-svn: 193917
|
| |
|
|
| |
llvm-svn: 193916
|
| |
|
|
|
|
|
| |
- Don't seek "entry:" It dosen't appear with -Asserts.
- Take care that Codegen'ed Instruction(s) wouldn't have name(s) in -Asserts.
llvm-svn: 193908
|
| |
|
|
|
|
|
| |
specializations. Also switch to -Wuninitialized for a test case that depended
on a warning firing in template specializations.
llvm-svn: 193906
|
| |
|
|
| |
llvm-svn: 193902
|
| |
|
|
|
|
|
| |
long in linux 64 is 64 bits but is always 32 bits on windows. The lit test was modified
to use long long instead of long and check for 64-bit mangling.
llvm-svn: 193901
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Differential Revision: http://llvm-reviews.chandlerc.com/D2090
Clang was "improperly" over-aligning arrays with sizes are not a multiple of
their alignment.
This behavior was removed in microsoft 32 bit mode.
In addition, after examination of ASTContext::getTypeInfoImpl, a redundant code block in
MicrosoftRecordLayoutBuilder::getAdjustedFieldInfo was deleted.
llvm-svn: 193898
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Differential Revision: http://llvm-reviews.chandlerc.com/D2082
Adds a lang_c LinkageSpecDecl to lazily generated builtins. This enforces correct
behavior for builtins in a variety of cases without special treatment elsewhere within
the compiler (special treatment is removed by the patch). It also allows for C++
overloads of builtin functions, which Microsoft uses in their headers e.g.
_InterlockedExchangeAdd is an extern C builtin for the long type but an inline wrapper
for int type.
llvm-svn: 193896
|
| |
|
|
|
|
| |
... in case someone decides to -I/usr/include <rdar://problem/15235948>.
llvm-svn: 193893
|
| |
|
|
|
|
| |
warning in template specializations.
llvm-svn: 193890
|
| |
|
|
|
|
|
|
|
|
|
| |
-fobjc-subscripting-legacy-runtime which is off
by default and on only when using ObjectiveC
legacy runtime. Use this flag to allow
array and dictionary subscripting and disallow
objectiveC pointer arithmatic in ObjectiveC
legacy runtime. // rdar://15363492
llvm-svn: 193889
|
| |
|
|
| |
llvm-svn: 193888
|
| |
|
|
| |
llvm-svn: 193887
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The thread, memory, dataflow and function sanitizers are now diagnosed if
enabled explicitly on an unsupported platform. Unsupported sanitizers which
are enabled implicitly (as part of a larger group) are silently disabled. As a
side effect, this makes SanitizerArgs parsing toolchain-dependent (and thus
essentially reverts r188058), and moves SanitizerArgs ownership to ToolChain.
Differential Revision: http://llvm-reviews.chandlerc.com/D1990
llvm-svn: 193875
|
| |
|
|
| |
llvm-svn: 193858
|
| |
|
|
| |
llvm-svn: 193857
|
| |
|
|
| |
llvm-svn: 193850
|