| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
this is wasteful, blah blah, but this is a test utility only. It turns
out that without doing this, libxml2 will always leak a bunch of the XML
data, and that is causing failures with LSan. This is also quite a bit
simpler and I don't think it is slow enough to really be a show stopper.
If someone yells about the runtime of c-index-test, we can do other
things to try to mitigate it, but the current strategy wasn't working
well.
llvm-svn: 207882
|
|
|
|
|
|
| |
This bumps CINDEX_VERSION_MINOR up (to 26).
llvm-svn: 207767
|
|
|
|
|
|
| |
PR19583
llvm-svn: 207484
|
|
|
|
|
|
| |
This exposed a leak, fix that.
llvm-svn: 207396
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's possible that the "comment AST" may be replaced or split out in the
midterm, any anyway this makes the headers easier to read.
Developers don't currently need to include "clang-c/Documentation.h" explicitly
and there's no macro to test for availability yet.
The raw comment and brief comment accessors have been kept in Index.h though
brief support may also move here as a separate proposal.
This is not a deprecation, just a gentle separation of concerns as we look to
simplify the built-in representation of comment nodes and support external
comment processors.
llvm-svn: 207392
|
|
|
|
| |
llvm-svn: 207340
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The change was landed without review or test cases.
It trivially broke almost any stable application checking for Severity >=
CXDiagnostic_Error or indeed any other kind of severity comparison upon
encountering a 'remark'.
Mapped to CXDiagnostic_Warning until a workable solution is proposed to the
list that preserves API stability.
(It's also not clear why the rest of r202475 wasn't simply implemented as a
modifier to the existing 'warning' level.)
llvm-svn: 207319
|
|
|
|
| |
llvm-svn: 207081
|
|
|
|
|
|
|
|
| |
A CursorPlatformAvailability can have several "unavailable" attributes, don't
leak all but the first. I'm not sure if there can be several "deprecate"ds too,
but add the same logic there to keep the two code paths looking the same.
llvm-svn: 207076
|
|
|
|
|
|
| |
The result of clang_getCursorSpelling() needs to be clang_getCursorSpelling()ed.
llvm-svn: 207073
|
|
|
|
|
|
| |
Patch by Yuri Gorshenin.
llvm-svn: 206970
|
|
|
|
|
|
|
|
|
| |
We don't need the ASTContext for the diagnostics, only the language
options, which we can get from the compiler invocation. It worries me
how many categorically different states the ASTUnit class can be in
depending on how it is being constructed/used.
llvm-svn: 206909
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D3272
llvm-svn: 206891
|
|
|
|
| |
llvm-svn: 206752
|
|
|
|
|
|
|
|
|
| |
Update clang to use the InstrProfReader from LLVM to read
instrumentation based profile data. This also switches us from the
naive text format to the binary format, since that's what's
implemented in the reader.
llvm-svn: 206658
|
|
|
|
|
|
|
|
| |
This reverts r172072. clang-format used to use DiagnosticEngine to output
errors: http://llvm.org/viewvc/llvm-project?view=revision&revision=172071. Now
it doesn't, so this code is obsolete.
llvm-svn: 206479
|
|
|
|
|
|
|
|
| |
The YAMLParser has its own escaped string representation, and does not
handle octal escape sequences. When writing the virtual file system to a
YAML file, use yaml::escape().
llvm-svn: 206443
|
|
|
|
|
|
|
| |
This allows code indexing, etc. to use the VFS in the same way as the
compiler.
llvm-svn: 206309
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 206111
|
|
|
|
|
|
|
|
|
| |
The idea is to give visibility to more type kinds, especially for getting
a better grasp of what appears as unexposed type kind with libclang.
Differential Revision: http://reviews.llvm.org/D3325
llvm-svn: 205921
|
|
|
|
| |
llvm-svn: 205842
|
|
|
|
|
|
|
|
| |
member function or member function template is declared 'const'
Patch by Kevin Funk with testcase updates by me.
llvm-svn: 205714
|
|
|
|
|
|
|
|
|
|
|
|
| |
Code review feedback from Eric Christopher on r204261.
I didn't want to go into too much detail (the revision history should
provide the full stuff) - but I can add more if that's preferred.
Also moved this up to right by the construction of the MCAsmInfo so
there's less chance that other things might sneak in in between.
llvm-svn: 205267
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For those playing at home this produced some fairly subtle behavior. The
sections created in InitMCObjectFileInfo were created without compressed
debug info (a mistake, but not necessarily /broken). Since these
sections were almost always referenced by the existing MCSection object,
this almost worked.
This got weird when we got to handling the relocations for a section.
See ELFObjectWriter::WriteSection where we compute the true section for
a relocation section by simply stripping the ".rela" prefix and then
looking up that section - doing so hit the compression codepath, looked
up .zdebug_blah and found a newly constructed empty section... thus,
things got weird.
This is untestable without a cross-project test (let me know if people
would prefer that to no testing).
llvm-svn: 205261
|
|
|
|
| |
llvm-svn: 205189
|
|
|
|
| |
llvm-svn: 205164
|
|
|
|
|
|
| |
unless the macro comes from a system header
llvm-svn: 205064
|
|
|
|
|
|
| |
Also, while I'm here, support -nocompress-debug-sections too.
llvm-svn: 204959
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These don't seem to have any real point. Let's start with
IndexingContext. I can't come up with any conceivable reason to have
many hundereds of thousands of these alive in an address space which
would make the 4x difference in allocated (but unused) memory for the
string scratch buffer a significant memory usage problem.
The EditedSource one is somewhat more surprising. This is an 8x increase
in the memory allocated (but not used) per editted source file. However,
for this to realistically be a problem, you would need to have over half
a million editted source files in a single address space, and even that
would only really have problems on 32-bit Windows where you really only
have 2gb of virtual address space. And what's more important, the fix to
this if it is actually an issue shouldn't be to shrink the allocator's
size, it is to pass a single allocator into *many* edited source file
objects and let them share the memory.
These were the only two uses of custom sized BumpPtrAllocators
(excluding ones in the JIT using a custom allocation strategy) in all of
LLVM, Clang, LLD, LLDB, or Polly. I don't think we actually need this
complexity in the primary BumpPtrAllocator at all and am planning to
remove it.
llvm-svn: 204910
|
|
|
|
| |
llvm-svn: 204428
|
|
|
|
|
|
| |
Third time's the charm. Patch by Brennan Shacklett!
llvm-svn: 204362
|
|
|
|
|
|
|
|
|
| |
Because neither ' ' nor '-' is alphanumeric, \b won't match between them!
Since in this case we know our output is coming from a -### invocation,
we should always have spaces on both sides of the flag we're trying to match,
"-cc1".
llvm-svn: 204356
|
|
|
|
|
|
| |
While there convert to range-based for loops. No functionality change.
llvm-svn: 204338
|
|
|
|
|
|
|
|
|
|
| |
exposes the VFS option
to set the case-sensitivity for lookups.
rdar://16374696
llvm-svn: 204303
|
|
|
|
|
|
| |
PR19191
llvm-svn: 204253
|
|
|
|
|
|
| |
class.
llvm-svn: 204002
|
|
|
|
|
|
| |
iterator_range decls(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203947
|
|
|
|
|
|
| |
varlist_begin() and varlist_end() with iterator_range varlists(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203937
|
|
|
|
|
|
| |
ivar_end() with iterator_range ivars(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203932
|
|
|
|
| |
llvm-svn: 203887
|
|
|
|
|
|
| |
iterator_range shadows(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203825
|
|
|
|
|
|
| |
iterator_range inits(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203819
|
|
|
|
|
|
| |
iterator_range bases(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203803
|
|
|
|
|
|
|
|
|
| |
I've clearly done something wrong with how to get this to link
correctly. Reverting for now.
This reverts commit r203711.
llvm-svn: 203712
|
|
|
|
|
|
|
|
| |
This updates CodeGenPGO to use the ProfileDataReader introduced to
llvm in r203703 and the new API for writing out the profile introduced
to compiler-rt in r203710.
llvm-svn: 203711
|
|
|
|
|
|
| |
This is a follow-up to r203624 to address Anton's comment.
llvm-svn: 203668
|
|
|
|
| |
llvm-svn: 203665
|
|
|
|
|
|
|
|
|
| |
Windows
This narrows the impact of r188833 after Dimitry pointed out that it's good to be
able to tell the difference between 'cc' and 'CC'.
llvm-svn: 203624
|
|
|
|
|
|
| |
This will allow using an early return statement in a subsequent change.
llvm-svn: 203501
|
|
|
|
| |
llvm-svn: 203473
|