| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
offsetof handling code. Also use a range-based for loop. NFC
llvm-svn: 250989
|
| |
|
|
|
|
| |
loop. NFC
llvm-svn: 250988
|
| |
|
|
|
|
| |
size. While there use std::copy intead of a manual loop.
llvm-svn: 250987
|
| |
|
|
|
|
| |
co_await modifier on range-based for loop, co_return statement.
llvm-svn: 250985
|
| |
|
|
|
|
| |
the implementation is incomplete.
llvm-svn: 250982
|
| |
|
|
|
|
|
| |
Add -fcoroutines flag (just for -cc1 for now) to enable the feature. Early
indications are that this will be part of -std=c++1z.
llvm-svn: 250980
|
| |
|
|
|
|
|
|
| |
size when it really expects a StringRef and a normally optional bool argument.
The pointer was being implicitly converted to a StringRef and the size was being passed into the bool. Since the bool has a default value normally, no one noticed that the wrong number of arguments was given.
llvm-svn: 250977
|
| |
|
|
| |
llvm-svn: 250976
|
| |
|
|
|
|
|
|
| |
than taking a pointer and element count that it modifies. This paves the way to directly convert the small vector into an ArrayRef without needing to explicitly pass the modified size. No functional change intended.
While there also use a range-based for loop and use append instead of insert to copy elements into the empty SmallVector."
llvm-svn: 250971
|
| |
|
|
|
|
| |
that uses back().
llvm-svn: 250970
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When removing out-of-date modules we might have left behind a VisitOrder
that contains pointers to freed ModuleFiles. This was very rarely seen,
because it only happens when modules go out of date and the VisitOrder
happens to have the right size to not be recomputed.
Thanks ASan!
rdar://23181512
llvm-svn: 250963
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is almost entirely a matter of just flipping a switch. 99% of
the runtime support is available all the way back to when it was
implemented in the non-fragile runtime, i.e. in Lion. However,
fragile runtimes do not recognize ARC-style ivar layout strings,
which means that accessing __strong or __weak ivars reflectively
(e.g. via object_setIvar) will end up accessing the ivar as if it
were __unsafe_unretained. Therefore, when using reflective
technologies like KVC, be sure that your paths always refer to a
property.
rdar://23209307
llvm-svn: 250955
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ELF symbol visibilities are:
- internal: Not visibile across DSOs, cannot pass address across DSOs
- hidden: Not visibile across DSOs, can be called indirectly
- default: Usually visible across DSOs, possibly interposable
- protected: Visible across DSOs, not interposable
LLVM only supports the latter 3 visibilities. Internal visibility is in
theory useful, as it allows you to assume that the caller is maintaining
a PIC register for you in %ebx, or in some other pre-arranged location.
As far as LLVM is concerned, this isn't worth the trouble. Using hidden
visibility is always correct, so we can just do that.
Resolves PR9183.
llvm-svn: 250954
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Since r249754 MemorySanitizer should work equally well for PIE and
non-PIE executables on Linux/x86_64.
Beware, with this change -fsanitize=memory no longer adds implicit
-fPIE -pie compiler/linker flags on Linux/x86_64.
This is a re-land of r250941, limited to Linux/x86_64 + a very minor
refactoring in SanitizerArgs.
llvm-svn: 250949
|
| |
|
|
|
|
| |
It actually does require PIE on some targets.
llvm-svn: 250944
|
| |
|
|
|
|
|
|
|
|
| |
Since r249754 MemorySanitizer should work equally well for PIE and
non-PIE executables.
Beware, with this change -fsanitize=memory no longer adds implicit
-fPIE -pie compiler/linker flags, unless the target defaults to PIE.
llvm-svn: 250941
|
| |
|
|
|
|
| |
No functionality change is intended.
llvm-svn: 250935
|
| |
|
|
| |
llvm-svn: 250932
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Specifically, handle under-aligned object references (by explicitly
ignoring them, because this just isn't representable in the format;
yes, this means that GC silently ignores such references), descend
into anonymous structs and unions, stop classifying fields of
pointer-to-strong/weak type as strong/weak in ARC mode, and emit
skips to cover the entirety of block layouts in GC mode. As a
cleanup, extract this code into a helper class, avoid a number of
unnecessary copies and layout queries, generate skips implicitly
instead of explicitly tracking them, and clarify the bitmap-creation
logic.
llvm-svn: 250919
|
| |
|
|
| |
llvm-svn: 250918
|
| |
|
|
| |
llvm-svn: 250917
|
| |
|
|
|
|
|
| |
a value loaded from a __weak variable into a call to
objc_copyWeak or objc_moveWeak.
llvm-svn: 250916
|
| |
|
|
|
|
|
|
|
|
| |
clang accepts both #include and #import for includes (the latter having an
implicit header guard). Let clang-format interleave both types if
--sort-includes is passed. #import is used frequently in Objective-C code.
http://reviews.llvm.org/D13853
llvm-svn: 250909
|
| |
|
|
|
|
| |
ArrayRef. NFC
llvm-svn: 250903
|
| |
|
|
|
|
| |
eventually creating a StringRef. NFC
llvm-svn: 250902
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Putting DynTypedNode in the ParentMap bloats its memory foot print.
Before the void* key had 8 bytes, now we're at 40 bytes per key which
can mean multiple gigabytes increase for large ASTs and this count
doesn't even include all the added TypeLoc nodes. Revert until I come
up with a better data structure.
This reverts commit r250831.
llvm-svn: 250889
|
| |
|
|
|
|
|
|
|
| |
The logic for parsing FP capabilities to set __ARM_FP was mistakenly removing
the Half-Precision capability when handling fp-only-sp resulting in a value
of 0x4. Section 6.5.1 of ACLE states that for such FP architectures the value
should be 0x6
llvm-svn: 250888
|
| |
|
|
|
|
|
|
|
|
|
| |
headers. If those headers end up being textually included twice into the same
module, we get ambiguity errors.
Work around this by downgrading the ambiguity error to a warning if multiple
identical internal-linkage functions appear in an overload set, and just pick
one of those functions as the lookup result.
llvm-svn: 250884
|
| |
|
|
| |
llvm-svn: 250881
|
| |
|
|
| |
llvm-svn: 250880
|
| |
|
|
|
|
| |
positive and casting to unsigned. Since we know the string starts with a digit it couldn't be negative anyway. NFCI
llvm-svn: 250879
|
| |
|
|
| |
llvm-svn: 250878
|
| |
|
|
| |
llvm-svn: 250876
|
| |
|
|
|
|
|
|
|
|
|
| |
This time, I went with the first approach from
http://reviews.llvm.org/D6700, where clang actually attempts to form an
implicit member reference from an UnresolvedLookupExpr. We know that
there are only two possible outcomes at this point, a DeclRefExpr of the
FieldDecl or an error, but its safer to reuse the existing machinery for
this.
llvm-svn: 250856
|
| |
|
|
|
|
|
|
|
|
|
| |
as an extension
Microsoft's ATL headers make use of this MSVC extension, add support for
it and issue a diagnostic under -Wmicrosoft-exception-spec.
This fixes PR25265.
llvm-svn: 250854
|
| |
|
|
|
|
| |
Fixes PR25262
llvm-svn: 250844
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang will now accept this valid C++11 code:
struct A { int field; };
struct B : A {
using A::field;
enum { TheSize = sizeof(field) };
};
Previously we would classify the 'field' reference as something other
than a field, and then forget to apply the C++11 rule to allow
non-static data member references in unevaluated contexts.
This usually arises in class templates that want to reference fields of
a dependent base in an unevaluated context outside of an instance
method. Such contexts do not allow references to 'this', so the only way
to access the field is with a using decl and an implicit member
reference.
llvm-svn: 250839
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Firstly this changes the type of parent map to be keyed on DynTypedNode to
simplify the following changes. This comes with a DenseMapInfo for
DynTypedNode, which is a bit incomplete still and will probably only work
for parentmap right now.
Then the RecursiveASTVisitor in ASTContext is updated and finally
ASTMatchers hasParent and hasAncestor learn about the new functionality.
Now ParentMap is only missing TemplateArgumentLocs and CXXCtorInitializers.
Differential Revision: http://reviews.llvm.org/D13897
llvm-svn: 250831
|
| |
|
|
|
|
|
|
|
|
| |
Summary: It breaks the build for the ASTMatchers
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D13893
llvm-svn: 250827
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Replace empty bodies of default constructors and destructors with '= default'.
Reviewers: bkramer, klimek
Subscribers: klimek, alexfh, cfe-commits
Differential Revision: http://reviews.llvm.org/D13890
llvm-svn: 250822
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
According to the Intel documentation, the mask operand of a maskload and
maskstore intrinsics is always a vector of packed integer/long integer values.
This patch introduces the following two changes:
1. It fixes the avx maskload/store intrinsic definitions in avxintrin.h.
2. It changes BuiltinsX86.def to match the correct gcc definitions for avx
maskload/store (see D13861 for more details).
Differential Revision: http://reviews.llvm.org/D13861
llvm-svn: 250816
|
| |
|
|
| |
llvm-svn: 250804
|
| |
|
|
|
|
| |
Partially reverts r250418.
llvm-svn: 250803
|
| |
|
|
|
|
|
| |
Currently debug info for types used in explicit cast only is not emitted. It happened after a patch for better alignment handling. This patch fixes this bug.
Differential Revision: http://reviews.llvm.org/D13582
llvm-svn: 250795
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
static methods"
This reverts commit r250592.
It has issues around unevaluated contexts, like this:
template <class T> struct A { T i; };
template <class T>
struct B : A<T> {
using A<T>::i;
typedef decltype(i) U;
};
template struct B<int>;
llvm-svn: 250774
|
| |
|
|
| |
llvm-svn: 250764
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
static data members
Out-of-line definitions of static data members which have an inline
initializer must get GVA_DiscardableODR linkage instead of
GVA_StrongExternal linkage.
MSVC 2013's behavior is different with respect to this and would cause
link errors if one TU provided a definition while another did not.
MSVC 2015 fixed this bug, making this OK. Note that the 2015 behavior
is always compatible with 2013: it never produces a strong definition.
This essentially reverts r237787.
llvm-svn: 250757
|
| |
|
|
| |
llvm-svn: 250691
|
| |
|
|
|
|
|
|
|
| |
The Intel MCU psABI requires floating-point values to be passed in-reg.
This makes the x86-32 ABI code respect "-mfloat-abi soft" and generate float inreg arguments.
Differential Revision: http://reviews.llvm.org/D13554
llvm-svn: 250689
|
| |
|
|
| |
llvm-svn: 250687
|