| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 172035
|
| |
|
|
|
|
|
|
| |
-P" mode. <rdar://problem/12774044>
llvm-svn: 171944
|
| |
|
|
| |
llvm-svn: 171478
|
| |
|
|
|
|
|
|
| |
reflect the migration in r171366.
Re-sort the #include lines to reflect the new paths.
llvm-svn: 171369
|
| |
|
|
| |
llvm-svn: 171367
|
| |
|
|
| |
llvm-svn: 171264
|
| |
|
|
| |
llvm-svn: 171020
|
| |
|
|
|
|
|
|
| |
DiagnosticRenderer::emitMacroExpansions(). [-Wdocumentation]
/// \param MacroSkipEnd The depth to stop skipping macro expansions.
llvm-svn: 171012
|
| |
|
|
|
|
|
|
|
|
|
| |
to the
code-completion results, the SourceManager state may be slightly
different when code-completing.
And we don't even care for diagnostics when code-completing, anyway.
llvm-svn: 170979
|
| |
|
|
| |
llvm-svn: 170905
|
| |
|
|
| |
llvm-svn: 170903
|
| |
|
|
| |
llvm-svn: 170487
|
| |
|
|
|
|
| |
needs to be robust
llvm-svn: 170466
|
| |
|
|
|
|
|
|
| |
diagnostic ranges).
I'm not really happy with this fix, but I'm confident it's correct.
llvm-svn: 170397
|
| |
|
|
|
|
| |
workloads.
llvm-svn: 170143
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This still isn't quite right, but it fixes a crash.
I factored out findCommonParent because we need it on the result of
getImmediateExpansionRange: for a function macro, the beginning
and end of an expansion range can come out of different
macros/macro arguments, which means the resulting range is a complete
mess to handle consistently.
I also made some changes to how findCommonParent works; it works somewhat
better in some cases, and somewhat worse in others, but I think overall
it's a better balance. I'm coming to the conclusion that mapDiagnosticRanges
isn't using the right algorithm, though: chasing the caret is fundamentally
more complicated than any algorithm which only considers one FileID for the
caret can handle because each SourceLocation doesn't really have a single parent.
We need to follow the same path of choosing expansion locations and spelling
locations which the caret used to come up with the correct range
in the general case.
Fixes <rdar://problem/12847524>.
llvm-svn: 170049
|
| |
|
|
|
|
|
|
|
|
| |
a file or directory, allowing just a stat call if a file descriptor
is not needed.
Doing just 'stat' is faster than 'open/fstat/close'.
This has the effect of cutting down system time for validating the input files of a PCH.
llvm-svn: 169831
|
| |
|
|
|
|
|
|
| |
fed into the diagnostic formatting machinery again.
Fixes PR14543.
llvm-svn: 169677
|
| |
|
|
|
|
|
|
|
| |
should enable
the AsmBlocks language extension as well.
rdar://12808010
llvm-svn: 169448
|
| |
|
|
|
|
|
|
| |
option. MS-style inline asm can now be enabled by either -fasm-blocks or
-fms-extensions.
rdar://12808010
llvm-svn: 169445
|
| |
|
|
|
|
|
| |
-fasm-blocks flag, not the -fms-extensions flag.
rdar://12808010
llvm-svn: 169422
|
| |
|
|
|
|
|
| |
the LHS of a token paste. Use "expanded from here" instead when we're not sure
it's actually a macro.
llvm-svn: 169373
|
| |
|
|
| |
llvm-svn: 169367
|
| |
|
|
|
|
|
|
| |
diagnostic from the emission of macro backtraces. Incidentally, we now get the
displayed source location for a diagnostic and the location for the caret from
the same place, rather than computing them separately. No functionality change.
llvm-svn: 169357
|
| |
|
|
| |
llvm-svn: 169351
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
|
| |
|
|
|
|
|
|
|
| |
PreprocessingRecord and into its own class, PPConditionalDirectiveRecord.
Decoupling allows a client to use the functionality of PPConditionalDirectiveRecord
without needing a PreprocessingRecord.
llvm-svn: 169229
|
| |
|
|
|
|
| |
flag usable for ASan. Blacklisting can be used to disable sanitizer checks for particular file/function/object.
llvm-svn: 169144
|
| |
|
|
| |
llvm-svn: 169114
|
| |
|
|
|
|
|
|
| |
private members so the anonymous class doesn't leak out.
No functionality change.
llvm-svn: 169099
|
| |
|
|
|
|
|
|
|
|
| |
state so that all of the various clones end up rendering their
diagnostics into the same serialized-diagnostics file. This is
important when we actually want failures during module build to be
reported back to the translation unit that tried to import the
not-yet-built or out-of-date module. <rdar://problem/12565727>
llvm-svn: 169057
|
| |
|
|
| |
llvm-svn: 169045
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
module, provide a module import stack similar to what we would get for
an include stack, e.g.,
In module 'DependsOnModule' imported from build-fail-notes.m:4:
In module 'Module' imported from DependsOnModule.framework/Headers/DependsOnModule.h:1:
Inputs/Module.framework/Headers/Module.h:15:12: note: previous definition is here
@interface Module
<rdar://problem/12696425>
llvm-svn: 169042
|
| |
|
|
|
|
|
|
|
| |
building module 'Foo' imported from..." notes (the same we we provide
"In file included from..." notes) in the diagnostic, so that we know
how this module got included in the first place. This is part of
<rdar://problem/12696425>.
llvm-svn: 169021
|
| |
|
|
|
|
|
| |
the beginning and end of the range are in different macro arguments.
PR14399.
llvm-svn: 168984
|
| |
|
|
|
|
|
|
|
|
|
|
| |
import of that module elsewhere, don't try to build the module again:
it won't work, and the experience is quite dreadful. We track this
information somewhat globally, shared among all of the related
CompilerInvocations used to build modules on-the-fly, so that a
particular Clang instance will only try to build a given module once.
Fixes <rdar://problem/12552849>.
llvm-svn: 168961
|
| |
|
|
|
|
|
| |
'getPointerWidth(0) >= 64' test to be a method on TargetInfo, ready to be
properly cleaned up.
llvm-svn: 168856
|
| |
|
|
|
|
| |
is not used in any #ifdef.
llvm-svn: 168703
|
| |
|
|
|
|
| |
- This ensures we see the right buffer size for the file.
llvm-svn: 168636
|
| |
|
|
| |
llvm-svn: 168510
|
| |
|
|
|
|
| |
Patch by Philip Craig.
llvm-svn: 168420
|
| |
|
|
|
|
| |
it as a pointer.
llvm-svn: 168136
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
CachedCompletionAllocator
to the CodeCompletionTUInfo that is going to be used to get the results.
Previously we would use ASTUnit's CodeCompletionTUInfo which has its own allocator
that will go away when we reparse. That could result in a use-after-free bug when
getting the parent context name from a CodeCompletionString.
Addresses rdar://12568377.
llvm-svn: 168133
|
| |
|
|
|
|
|
|
| |
- This diverges from gcc, and confuses tools (like dtrace) which track # line
markers as a way to determine which content is in the context of the main
file.
llvm-svn: 168128
|
| |
|
|
|
|
|
|
| |
to a cc1 -fencode-extended-block-signature and pass it
to cc1 and recognize this option to produce extended block
type signature. // rdar://12109031
llvm-svn: 168063
|
| |
|
|
|
|
| |
instead of messing with virtual files.
llvm-svn: 168062
|
| |
|
|
|
|
| |
as the include location of the main file of an imported module.
llvm-svn: 168061
|
| |
|
|
| |
llvm-svn: 168041
|
| |
|
|
|
|
|
| |
more sense anyway - it determines how expressions are codegen'd. It also ensures
that -ffp-contract=fast has the intended effect when compiling LLVM IR.
llvm-svn: 168027
|
| |
|
|
|
|
|
|
|
| |
working with preprocessed testcases. This causes source locations in
diagnostics to point at the spelling location instead of the presumed location,
while still keeping the semantic effects of the line directives (entering and
leaving system-header mode, primarily).
llvm-svn: 168004
|