| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
This is required to use them in TableGen.
llvm-svn: 173924
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
People use the C preprocessor for things other than C files. Some of them
have Unicode characters. We shouldn't warn about Unicode characters
appearing outside of identifiers in this case.
There's not currently a way for the preprocessor to tell if it's in -E mode,
so I added a new flag, derived from the PreprocessorOutputOptions. This is
only used by the Unicode warnings for now, but could conceivably be used by
other warnings or even behavioral differences later.
<rdar://problem/13107323>
llvm-svn: 173881
|
|
|
|
| |
llvm-svn: 173871
|
|
|
|
| |
llvm-svn: 173866
|
|
|
|
|
|
|
|
| |
- The only group where it makes sense for the "ExternC" bit is System, so this
simplifies having to have the extra isCXXAware (or ImplicitExternC, depending
on what code you talk to) bit caried around.
llvm-svn: 173859
|
|
|
|
|
|
|
|
|
| |
- This slightly decouples the path handling, since before the group sometimes
dominated the "use sysroot" bit, but it was still passed in via the API.
- No functionality change.
llvm-svn: 173855
|
|
|
|
| |
llvm-svn: 173854
|
|
|
|
| |
llvm-svn: 173853
|
|
|
|
|
|
|
|
|
|
|
| |
implementation; this is much more inline with the original implementation
(i.e., pre-ubsan) and does not require run-time library support.
The trapping implementation can be invoked using either '-fcatch-undefined-behavior'
or '-fsanitize=undefined-trap -fsanitize-undefined-trap-on-error', with the latter
being preferred. Eventually, the -fcatch-undefined-behavior' flag will be removed.
llvm-svn: 173848
|
|
|
|
|
|
|
|
| |
-fno-modules-global-index -cc1 option to allow one to disable the
index for performance testing purposes, but with a 10% win in
-fsyntax-only time, there is no reason a user would do this.
llvm-svn: 173707
|
|
|
|
|
|
|
|
|
|
| |
The -E output from clang did not produce the correct indentation on the first line.
This is because MoveToLine returned false, and when this happens,
the regular process for producing initial indentation is skipped.
Thanks to Eli for suggesting a way to simplify this to a one-line change.
llvm-svn: 173657
|
|
|
|
| |
llvm-svn: 173412
|
|
|
|
| |
llvm-svn: 173411
|
|
|
|
|
|
|
| |
GCC docs.
- Found by inspection.
llvm-svn: 173410
|
|
|
|
| |
llvm-svn: 173409
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AST reader.
The global module index tracks all of the identifiers known to a set
of module files. Lookup of those identifiers looks first in the global
module index, which returns the set of module files in which that
identifier can be found. The AST reader only needs to look into those
module files and any module files not known to the global index (e.g.,
because they were (re)built after the global index), reducing the
number of on-disk hash tables to visit. For an example source I'm
looking at, we go from 237844 total identifier lookups into on-disk
hash tables down to 126817.
Unfortunately, this does not translate into a performance advantage.
At best, it's a wash once the global module index has been built, but
that's ignore the cost of building the global module index (which
is itself fairly large). Profiles show that the global module index
code is far less efficient than it should be; optimizing it might give
enough of an advantage to justify its continued inclusion.
llvm-svn: 173405
|
|
|
|
|
|
|
| |
"-fmodules-global-index" and expand its behavior to include both the
use and generation of the global module index.
llvm-svn: 173404
|
|
|
|
|
|
|
|
|
| |
The idea is to eventually place all analyzer options under
"analyzer-config". In addition, this lays the ground for introduction of
a high-level analyzer mode option, which will influence the
default setting for IPAMode.
llvm-svn: 173385
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The global module index is a "global" index for all of the module
files within a particular subdirectory in the module cache, which
keeps track of all of the "interesting" identifiers and selectors
known in each of the module files. One can perform a fast lookup in
the index to determine which module files will have more information
about entities with a particular name/selector. This information can
help eliminate redundant lookups into module files (a serious
performance problem) and help with creating auto-import/auto-include
Fix-Its.
The global module index is created or updated at the end of a
translation unit that has triggered a (re)build of a module by
scraping all of the .pcm files out of the module cache subdirectory,
so it catches everything. As with module rebuilds, we use the file
system's atomicity to synchronize.
llvm-svn: 173301
|
|
|
|
| |
llvm-svn: 173277
|
|
|
|
|
|
|
|
| |
operations (as opposed to storage only half/fp16).
Also add some semantic checks for OpenCL half types.
llvm-svn: 173254
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Fix a typo, s/BeginSourceAction/BeginSourceFile/, so that the documentation
for FrontendAction::BeginSourceFileAction links correctly to BeginSourceFile;
* Add some basic \file documentation for FrontendAction.h;
* More use of "\brief" instead of repeating the name of the entity being
documented;
* Stop using Doxygen-style "///" comments in FrontendAction.cpp, as they were
polluting the documentation for BeginSourceFile;
* Drop incorrect "\see" markup that broke Doxygen's formatting;
* Other minor documentation fixes.
llvm-svn: 173213
|
|
|
|
|
|
| |
inline assembly can be enable with -fasm-blocks or -fms-extensions alone.
llvm-svn: 173186
|
|
|
|
|
|
|
|
|
|
| |
crash if Precompilepreamble
is set to true because there is no FileManager at that point.
Patch by Hurcan Solter!
llvm-svn: 173071
|
|
|
|
|
|
| |
AddressSanitizer use bottom of the address space for the shadow memory. On Linux it can be used with -fPIE/-pie to improve performance.
llvm-svn: 172974
|
|
|
|
|
|
|
| |
Also, it was the only reason that `argc` and `argv` were being passed
into createDiagnostics, so remove those parameters and clean up callers.
llvm-svn: 172945
|
|
|
|
|
|
|
|
|
|
| |
This looks like it was copied from SetUpBuildDumpLog, which dumps to the
file `DiagOpts->DumpBuildInformation`. There is another member
`DiagOpts->DiagnosticLogFile` which appears to be unused. The fact that
this feature doesn't even print to the output file specified on the
command line makes me think that it should be ripped out.
llvm-svn: 172944
|
|
|
|
| |
llvm-svn: 172808
|
|
|
|
|
|
| |
users can explicitly enable/disable modules autolinking.
llvm-svn: 172592
|
|
|
|
| |
llvm-svn: 172509
|
|
|
|
|
|
|
|
|
|
| |
driver needs to process the
warning options to setup diagnostic state, but should not be emitting warnings as these would be
rudndant with what the frontend emits.
rdar://13001556
llvm-svn: 172497
|
|
|
|
|
|
| |
callers, removing unneeded const_cast
llvm-svn: 172372
|
|
|
|
|
|
| |
brought into 'clang' namespace by clang/Basic/LLVM.h
llvm-svn: 172323
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
which a particular declaration resides. Use this information to
customize the "definition of 'blah' must be imported from another
module" diagnostic with the module the user actually has to
import. Additionally, recover by importing that module, so we don't
complain about other names in that module.
Still TODO: coming up with decent Fix-Its for these cases, and expand
this recovery approach for other name lookup failures.
llvm-svn: 172290
|
|
|
|
|
|
|
|
| |
ASTUnit
came from loading a PCH/module.
llvm-svn: 172259
|
|
|
|
| |
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
|