| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
linkonce_odr. Emit construction vtables as internal in this case, since the ABI
does not guarantee that they will be availble externally.
llvm-svn: 175330
|
|
|
|
|
|
|
|
|
|
|
| |
until recursive loading is finished.
Otherwise we may end up with a template trying to deserialize a template
parameter that is in the process of getting loaded.
rdar://13135282
llvm-svn: 175329
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for distinguishing type vs. value visibility.
The changes to the visibility of explicit specializations
are intentional. The change to the "ugly" test case is
a consequence of a sensible implementation, and I am happy
to argue that this is better behavior. Other changes may
or may not be intended; it is quite difficult to divine
intent from some of the code I altered.
I've left behind a comment which I hope explains the
philosophy behind visibility computation.
llvm-svn: 175326
|
|
|
|
|
|
|
| |
The back-end will use these values to reconfigure code generation for different
features.
llvm-svn: 175308
|
|
|
|
|
|
|
| |
an ivar of type pointer to a typedef'ed object.
// rdar://13190095
llvm-svn: 175298
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current heuristic assumes that there can't be binary operators in
builder-type calls (excluding assigments). However, it also excluded
< and > in general, which is wrong. Now they are only excluded if they
are template parameters.
Before:
return aaaaaaaaaaaaaaaaa->aaaaa().aaaaaaaaaaaaa()i
.aaaaaa() < aaaaaaaaaaaaaaaaaaa->aaaaa().aaaaaaaaaaaaa().aaaaaa();
After:
return aaaaaaaaaaaaaaaaa->aaaaa().aaaaaaaaaaaaa().aaaaaa() <
aaaaaaaaaaaaaaaaaaa->aaaaa().aaaaaaaaaaaaa().aaaaaa();
llvm-svn: 175291
|
|
|
|
| |
llvm-svn: 175289
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
ostream &operator
<<(ostream &out, some::ns::SomeReallyLongType WithSomeReallyLongValue);
After:
ostream &operator<<(ostream &out,
some::ns::SomeReallyLongType WithSomeReallyLongValue);
llvm-svn: 175286
|
|
|
|
|
|
|
|
| |
while trying to do error recovery.
rdar://13207886
llvm-svn: 175282
|
|
|
|
|
|
|
| |
we don't do the scope checks otherwise we are going to hit assertion checks
since a label may not have been actually added.
llvm-svn: 175281
|
|
|
|
|
|
|
|
|
| |
This got lost and was untested as the same effect is achieved by
avoiding bin packing, which is active in Google style by default.
However, moving forward, we want more control over the bin packing
option(s) and thus, this flag should work as expected.
llvm-svn: 175277
|
|
|
|
|
|
|
| |
cast<ObjCObjectPointerType> doesn't look through sugar, getAs does.
Fixes PR15257.
llvm-svn: 175272
|
|
|
|
|
|
| |
microsoft; also fix vdtor calls for the ARM ABI
llvm-svn: 175271
|
|
|
|
| |
llvm-svn: 175265
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is almost always more readable.
Before:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
? aaaaaaaaaaaaaaaaaaaaaaaaaaa : aaaaaaaaaaaaaaaaaaaaaaaaaaa;
After:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
? aaaaaaaaaaaaaaaaaaaaaaaaaaa
: aaaaaaaaaaaaaaaaaaaaaaaaaaa;
llvm-svn: 175262
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This just adds a very simple check that if a DerivedToBase CastExpr is
operating on a value with known C++ object type, and that type is not the
base type specified in the AST, then the cast is invalid and we should
return UnknownVal.
In the future, perhaps we can have a checker that specifies that this is
illegal, but we still shouldn't assert even if the user turns that checker
off.
PR14872
llvm-svn: 175239
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
...after a host of optimizations related to the use of LazyCompoundVals
(our implementation of aggregate binds).
Originally applied in r173951.
Reverted in r174069 because it was causing hangs.
Re-applied in r174212.
Reverted in r174265 because it was /still/ causing hangs.
If this needs to be reverted again it will be punted to far in the future.
llvm-svn: 175234
|
|
|
|
|
|
|
| |
This means we don't have to recompute them all later for every
removeDeadSymbols check.
llvm-svn: 175233
|
|
|
|
|
|
|
|
| |
Previously, we were scanning the current store. Now, we properly scan the
store that the LazyCompoundVal came from, which may have very different
live symbols.
llvm-svn: 175232
|
|
|
|
|
|
| |
This is optimization only; no behavioral change.
llvm-svn: 175231
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, whenever we had a LazyCompoundVal, we crawled through the
entire store snapshot looking for bindings within the LCV's region. Now, we
just ask for the subregion bindings of the lazy region and only visit those.
This is an optimization (so no test case), but it may allow us to clean up
more dead bindings than we were previously.
llvm-svn: 175230
|
|
|
|
|
|
|
|
|
|
|
| |
This is going to be used in the next commit.
While I'm here, tighten up assumptions about symbolic offset
BindingKeys, and make offset calculation explicitly handle all
MemRegion kinds.
No functionality change.
llvm-svn: 175228
|
|
|
|
|
|
|
|
| |
declarations to synthesize their ivars in similar
determinstic order so they are laid out in
a determinstic order. // rdar://13192366
llvm-svn: 175214
|
|
|
|
|
|
|
|
| |
a property, the -Wdirect-ivar-access should not warn when
accessing the property's synthesized instance variable.
// rdar://13142820
llvm-svn: 175195
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In C++, constants captured by lambdas (and blocks) are not actually stored
in the closure object, since they can be expanded at compile time. In this
case, they will have no binding when we go to look them up. Previously,
RegionStore thought they were uninitialized stack variables; now, it checks
to see if they are a constant we know how to evaluate, using the same logic
as r175026.
This particular code path is only for scalar variables. Constant arrays and
structs are still unfortunately unhandled; we'll need a stronger solution
for those.
This may have a small performance impact, but only for truly-undefined
local variables, captures in a non-inlined block, and non-constant globals.
Even then, in the non-constant case we're only doing a quick type check.
<rdar://problem/13105553>
llvm-svn: 175194
|
|
|
|
|
|
|
|
| |
before checking for its attributes.
rdar://13192395
llvm-svn: 175184
|
|
|
|
| |
llvm-svn: 175166
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
aaaaaaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa()
.aaaaaaaaaaaaaaaaa());
After:
aaaaaaaaaaaaaaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa().aaaaaaaaaaaaaaaaa());
Not sure which of the formattings above is better, but we should not pick
one by accident.
llvm-svn: 175165
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This gives a clearer separation of the context, e.g. in GMOCK
statements.
Before:
EXPECT_CALL(SomeObject,
SomeFunction(Parameter)).WillRepeatedly(Return(SomeValue));
After:
EXPECT_CALL(SomeObject, SomeFunction(Parameter))
.WillRepeatedly(Return(SomeValue));
Minor format cleanups.
llvm-svn: 175162
|
|
|
|
| |
llvm-svn: 175161
|
|
|
|
| |
llvm-svn: 175160
|
|
|
|
| |
llvm-svn: 175159
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So far, clang-format has always assumed the whitespace belonging to the
subsequent token. This has the negative side-effect that when
clang-format formats a line, it does not remove its trailing whitespace,
as it belongs to the next token.
Thus, this patch fixes most of llvm.org/PR15062.
We are not zapping a file's trailing whitespace so far, as this does not
belong to any token we see during formatting. We need to fix this in a
subsequent patch.
llvm-svn: 175152
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The formatter can now format:
void aaaaaaaaaaaaaaaaaa(int level,
double *min_x,
double *max_x,
double *min_y,
double *max_y,
double *min_z,
double *max_z, ) {
}
Although this is invalid code, it frequently happens during development and
clang-format should be nicer :-).
llvm-svn: 175151
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes llvm.org/PR15179.
Before:
class ColorChooserMac : public content::ColorChooser,
public content::WebContentsObserver {
};
After:
class ColorChooserMac : public content::ColorChooser,
public content::WebContentsObserver {
};
llvm-svn: 175147
|
|
|
|
| |
llvm-svn: 175143
|
|
|
|
|
|
|
| |
The code generation stuff is going to set attributes on the functions it
generates. To do that it needs the target options. Pass them through.
llvm-svn: 175141
|
|
|
|
|
|
|
| |
static functions in extern "C" contexts are mangled. Should fix the
bootstrap.
llvm-svn: 175132
|
|
|
|
|
|
|
|
|
|
| |
I added hasCLanguageLinkage while fixing some language linkage bugs some
time ago so that I wouldn't have to check all users of isExternC. It turned
out to be a much longer detour than expected, but this patch finally
merges the two again. The isExternC function now implements just the
standard notion of having C language linkage.
llvm-svn: 175119
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
some cases where functions with no language linkage were being treated as having
C language linkage. In particular, don't warn in
extern "C" {
static NonPod foo();
}
Since getLanguageLinkage checks the language linkage, the linkage computation
cannot use the language linkage. Break the loop by checking just the context
in the linkage computation.
llvm-svn: 175117
|
|
|
|
|
|
|
| |
instantiation in order to permit devirtualization later in codegen, skip over
pure functions since those can't be devirtualization targets.
llvm-svn: 175116
|
|
|
|
|
|
|
|
| |
in the course of property synthesis deterministic (ordered
by their type size), instead of having hashtable order
(as it is currently). // rdar://13192366
llvm-svn: 175100
|
|
|
|
|
|
|
| |
base-to-derived casts have undefined behavior if the object is not actually an
instance of the derived type.
llvm-svn: 175078
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This has so far been disabled for Google style, but should be done
before breaking at nested name specifiers or in template parameters.
Before (in Google style):
template <typename T>
aaaaaaaa::aaaaa::aaaaaa<T, aaaaaaaaaaaaaaaaaaaaaaaaa> aaaaaaaaaaaaaaaaaaaaaaaa<
T>::aaaaaaa() {}
After:
template <typename T>
aaaaaaaa::aaaaa::aaaaaa<T, aaaaaaaaaaaaaaaaaaaaaaaaa>
aaaaaaaaaaaaaaaaaaaaaaaa<T>::aaaaaaa() {}
llvm-svn: 175074
|
|
|
|
|
|
|
| |
Due to an error in one of the expressions, we used to not align comments
although it would have been possible.
llvm-svn: 175068
|
|
|
|
|
|
| |
Fix some comments.
llvm-svn: 175052
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- clear ownership: the SpecificBumpPtrAllocator owns all StateNodes
- this allows us to simplify the memoization data structure into a
std::set (FIXME: figure out whether we want to use a hash based
data structure).
- introduces StateNode as recursive data structure, instead of using
Edge and the Seen-map combined to drill through the graph
- using a count to stabilize the penalty instead of relying on the
container
- pulled out a method to forward-apply states in the end
This leads to a ~40% runtime decrease on Nico's benchmark.
Main FiXME is that the parameter lists of some function get too long.
I'd vote for either pulling the Queue etc into the Formatter proper,
or creating an inner class just for the search algorithm.
llvm-svn: 175051
|
|
|
|
| |
llvm-svn: 175045
|
|
|
|
|
|
| |
No functionality change. Also add another cast test.
llvm-svn: 175029
|
|
|
|
|
|
| |
Not all casts are correctly detected yet, but it helps in some cases.
llvm-svn: 175028
|