- BlockDeclRefExprs always store VarDecls
- BDREs no longer store copy expressions
- BlockDecls now store a list of captured variables, information about
how they're captured, and a copy expression if necessary
With that in hand, change IR generation to use the captures data in
blocks instead of walking the block independently.
Additionally, optimize block layout by emitting fields in descending
alignment order, with a heuristic for filling in words when alignment
of the end of the block header is insufficient for the most aligned
field.
llvm-svn: 125005
failures with relocations.
The code committed is a first cut at compatibility for emitted relocations in
ELF .o.
Why do this? because existing ARM tools like emitting relocs symbols as
explicit relocations, not as section-offset relocs.
Result is that with these changes,
1) relocs are now substantially identical what to gcc outputs.
2) larger apps (including many spec2k tests) compile, cross-link, and pass
Added reminder fixme to tests for future conversion to .s form.
llvm-svn: 124996
overridden via remapping. Thus, when we create a "virtual" file in the
file manager, we still stat() the real file that lives behind it so
that we can provide proper uniquing based on inodes. This helps keep
the file manager much more consistent.
To take advantage of this when reparsing files in libclang, we disable
the use of the stat() cache when reparsing or performing code
completion, since the stat() cache is very likely to be out of date in
this use case.
llvm-svn: 124971
This may not work on build platforms that place the binaries on
special folders ($build_dir/bin/Release/) such as the VS IDE and
XCode. For fixing this it is necessary to add a lit.py configuration
option for saying where the Clang binaries are, and apply to that path
the same magit that is used with the path to the LLVM tools binary
directory. Doing this requires a bit of autoconf work.
llvm-svn: 124969
This is the first step to make the clang_complete vim plugin work with
libclang. Reparsing improves parsing time from 0.8 to 0.25 secs for
one of my LLVM .cpp files.
llvm-svn: 124956
The iterator did never throw an IndexError. It was therefore not possible
to use it in a normal foreach loop as that loop would never stop.
llvm-svn: 124953
This improves the readability of the code and fixes one testsuite bug.
The bug happend, because we only stored the pointer to the diagnostic in the
FixIt iterator, but not the python Diagnostic object. So it could happen that
the FixIt iterator still exists, but the python Diagnostic object is freed.
However, as the python Diagnostic is freed the pointer to the diagnostic is also
freed and the FixIt iterator is referencing a freed pointer.
llvm-svn: 124952
Chris Lattner