| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously, we were handling only simple integer constants for globals and
the smattering of implicitly-valued expressions handled by Environment for
default arguments. Now, we can use any integer constant expression that
Clang can evaluate, in addition to everything we handled before.
PR15094 / <rdar://problem/12830437>
llvm-svn: 175026
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 175025
|
| |
|
|
|
|
| |
visible, not when they become deserialized <rdar://problem/13203033>.
llvm-svn: 175018
|
| |
|
|
| |
llvm-svn: 175015
|
| |
|
|
|
|
|
|
| |
to make sure we don't crash on release if the index is not valid.
rdar://13089714
llvm-svn: 175010
|
| |
|
|
|
|
|
| |
Still the formatting can be improved, but at least we don't assert any
more. This happened when trying to format lib/Sema/SemaType.cpp.
llvm-svn: 175003
|
| |
|
|
|
|
| |
and instead used a signed integer parameter.
llvm-svn: 174996
|
| |
|
|
| |
llvm-svn: 174986
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MSVC accepts this:
class A {
A::A();
};
Clang accepts regular member functions with extra qualification as an MS
extension, but not constructors. This changes the parser to defer rejecting
qualified constructors so that the same Sema logic can apply to constructors as
regular member functions. This also improves the error message when MS
extensions are disabled (in my opinion). Before it was:
/Users/jason/Desktop/test.cpp:2:8: error: expected member name or ';' after declaration specifiers
A::A();
~~~~ ^
1 error generated.
After:
/Users/jason/Desktop/test.cpp:2:6: error: extra qualification on member 'A'
A::A();
~~~^
1 error generated.
Patch by Jason Haslam.
llvm-svn: 174980
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Before (if only the second line was reformatted):
void f() {}
void g() {}
After:
void f() {}
void g() {}
llvm-svn: 174978
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This redoes how '*' and '&' are classified as pointer / reference markers when
followed by ')', '>', or ','.
Previously, determineStarAmpUsage() marked a single '*' and '&' followed by
')', '>', or ',' as pointer or reference marker. Now, all '*'s and '&'s
preceding ')', '>', or ',' are marked as pointer / reference markers. Fixes
PR14884.
Since only the last '*' in 'int ***' was marked as pointer before (the rest
were unary operators, which don't reach spaceRequiredBetween()),
spaceRequiredBetween() now had to be thought about handing multiple '*'s in
sequence.
Before:
return sizeof(int * *);
Type **A = static_cast<Type * *>(P);
Now:
return sizeof(int**);
Type **A = static_cast<Type **>(P);
While here, also make all methods of AnnotatingParser except parseLine()
private.
Review URL: http://llvm-reviews.chandlerc.com/D384
llvm-svn: 174975
|
| |
|
|
|
|
|
|
|
|
|
|
| |
MarkMemberReferenced instead of marking functions referenced directly. An audit
of callers to MarkFunctionReferenced and DiagnoseUseOfDecl also caused a few
other changes:
* don't mark functions odr-used when considering them for an initialization
sequence. Do mark them referenced though.
* the function nominated by the cleanup attribute should be diagnosed.
* operator new/delete should be diagnosed when building a 'new' expression.
llvm-svn: 174951
|
| |
|
|
|
|
| |
rdar://12046763
llvm-svn: 174946
|
| |
|
|
|
|
|
|
| |
the linkage of functions and variables while merging declarations from modules,
and we don't necessarily have enough of the rest of the AST loaded at that
point to allow us to compute linkage, so serialize it instead.
llvm-svn: 174943
|
| |
|
|
|
|
| |
calling std::terminate(). rdar://11904428
llvm-svn: 174940
|
| |
|
|
| |
llvm-svn: 174939
|
| |
|
|
|
|
| |
expression.
llvm-svn: 174930
|
| |
|
|
|
|
| |
Patch by Joey Gouly!
llvm-svn: 174928
|
| |
|
|
| |
llvm-svn: 174925
|
| |
|
|
|
|
| |
of immediately afterwards.
llvm-svn: 174922
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
move-constructors and move-assignment operators, use memcpy to copy adjacent
POD members.
Previously, classes with one or more Non-POD members would fall back on
element-wise copies for all members, including POD members. This often
generated a lot of IR. Without padding metadata, it wasn't often possible
for the LLVM optimizers to turn the element-wise copies into a memcpy.
This code hasn't yet received any serious tuning. I didn't see any serious
regressions on a self-hosted clang build, or any of the nightly tests, but
I think it's important to get this out in the wild to get more testing.
Insights, feedback and comments welcome.
Many thanks to David Blaikie, Richard Smith, and especially John McCall for
their help and feedback on this work.
llvm-svn: 174919
|
| |
|
|
|
|
| |
declarations if we didn't have a lookup map when the external decls were added.
llvm-svn: 174906
|
| |
|
|
|
|
|
| |
of @throw statement by finding location of the ';'
correctly. // rdar://13186010
llvm-svn: 174898
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
declared in the current translation unit <rdar://problem/13189985>.
These two related tweaks to keep the information associated with a
given identifier correct when the identifier has been given some
top-level information (say, a top-level declaration) and more
information is then loaded from a module. The first ensures that an
identifier that was "interesting" before being loaded from an AST is
considered to be different from its on-disk counterpart. Otherwise, we
lose such changes when writing the current translation unit as a
module.
Second, teach the code that injects AST-loaded names into the
identifier chain for name lookup to keep the most recent declaration,
so that we don't end up confusing our declaration chains by having a
different declaration in there.
llvm-svn: 174895
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
for (id foo in[self getStuffFor : bla]) {
}
Now:
for (id foo in [self getStuffFor:bla]) {
}
"in" is treated as loop keyword if the line starts with "for", and as a
regular identifier else. To check for "in", its IdentifierInfo is handed
through a few layers.
llvm-svn: 174889
|
| |
|
|
|
|
| |
You can run tests with -debug instead now.
llvm-svn: 174880
|
| |
|
|
|
|
|
|
| |
In google style, trailing comments are separated by two spaces. This
patch fixes the counting of these spaces and prevents clang-format from
creating a line with 81 columns.
llvm-svn: 174879
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now correctly formats:
#define A \
\
b;
to
#define A b;
Added the state whether an unwrapped line is a macro to the debug
output.
llvm-svn: 174878
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Before:
operatorvoid*();
operator vector< A< A>>();
After:
operator void *();
operator vector<A<A> >();
llvm-svn: 174863
|
| |
|
|
|
|
|
| |
The more general code for formatting ObjC method exprs does this and more,
it's no longer necessary to special-case this. No behavior change.
llvm-svn: 174843
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
@{
foo:
bar
}
;
Now:
@{ foo : bar };
parseBracedList() already does the right thing from an UnwrappedLineParser
perspective, so check for "@{" in all loops that process constructs that can
contain expressions and call parseBracedList() if found.
llvm-svn: 174840
|
| |
|
|
|
|
|
|
|
|
|
| |
Apple's kernel engineers have been expecting this behavior even though
we've never implemented it before, as far as I can tell. In recent months,
clang has gotten better at using vector instructions to optimize memcpy-like
operations, and that has exposed problems when vector/floating-point
instructions are used in kexts that don't support that. This behavior also
matches what Apple's GCC did for PowerPC targets.
llvm-svn: 174838
|
| |
|
|
| |
llvm-svn: 174837
|