| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
writer. No functionality change.
llvm-svn: 145479
|
| |
|
|
|
|
|
| |
involve submodules (e.g., importing std.vector), rather than always
importing the top-level module.
llvm-svn: 145478
|
| |
|
|
|
|
|
|
|
| |
check whether the named submodules themselves are actually
valid, and drill down to the named submodule (although we don't do
anything with it yet). Perform typo correction on the submodule names
when possible.
llvm-svn: 145477
|
| |
|
|
|
|
|
| |
top-level module name to a module path (e.g., std.vector). We're still
missing a number of pieces for this actually to do something.
llvm-svn: 145462
|
| |
|
|
|
|
|
| |
source file (e.g., a header). Immediately steal this useful option
name for building modules from a module map file.
llvm-svn: 145444
|
| |
|
|
|
|
|
| |
we infer the module map, we'll just print the module map to a
temporary file and generate the module using that.
llvm-svn: 145436
|
| |
|
|
|
|
|
| |
module map, rather than assuming that there is an umbrella
header. This allows us to automatically build umbrella-less modules.
llvm-svn: 145415
|
| |
|
|
|
|
| |
on-the-fly. No functionality change.
llvm-svn: 145414
|
| |
|
|
| |
llvm-svn: 145412
|
| |
|
|
| |
llvm-svn: 145396
|
| |
|
|
|
|
|
|
| |
Ruben Van Boxem.
(We should probably start doing some sort of autodetection like we do on Linux at some point.)
llvm-svn: 145326
|
| |
|
|
|
|
|
|
| |
return the module itself (in the module map) rather than returning the
umbrella header used to build the module. While doing this, make sure
that we're inferring modules for frameworks to build that module.
llvm-svn: 145310
|
| |
|
|
| |
llvm-svn: 145290
|
| |
|
|
|
|
|
|
| |
after
indexing, honor all the TU options.
llvm-svn: 145229
|
| |
|
|
| |
llvm-svn: 145228
|
| |
|
|
|
|
| |
and linux.
llvm-svn: 145142
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
file region
inside an objc container that "contains" other file-level declarations.
When getting the array of file-level declarations that overlap with a file region,
we failed to report that the region overlaps with an objc container, if
the container had other file-level declarations declared lexically inside it.
Fix this by marking such declarations as "isTopLevelDeclInObjCContainer" in the AST
and handling them appropriately.
llvm-svn: 145109
|
| |
|
|
|
|
| |
LangOpts.AddressSanitizer instead of CodeGenOpts.AddressSanitizer
llvm-svn: 145054
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
semantics and defaults as the corresponding g++ arguments. The historical g++
argument -ftemplate-depth-N is kept for compatibility, but modern g++ versions
no longer document that option.
Add -cc1 argument -fconstexpr-depth N to implement the corresponding
functionality.
The -ftemplate-depth=N part of this fixes PR9890.
llvm-svn: 145045
|
| |
|
|
|
|
| |
generate any reasonable depfile if a header is missing.
llvm-svn: 145019
|
| |
|
|
|
|
| |
baseclass CompilerInvocationBase with a custom copy constructor. This ensures that whenever the CompilerInvocation object's copy constructor is used we always clone the LangOptions object.
llvm-svn: 144973
|
| |
|
|
|
|
| |
parsing or false to abort parsing.
llvm-svn: 144943
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
object. I discovered that llvm::RefCountedBase<T> has
a bug where the reference count is copied in the copy constructor, which means that there were cases when the CompilerInvocation
objects created by ASTUnit were actually leaked. When I fixed that bug locally, it showed that a whole bunch of code assumed
that the LangOptions object that was part of CompilerInvocation was still alive. By making it heap-allocated and reference counted,
we can keep it around after the CompilerInvocation object goes away.
As part of this change, change CompilerInvocation:getLangOptions() to return a pointer, acting as another clue that this
object may outlive the CompilerInvocation object.
This commit doesn't fix the CompilerInvocation leak itself. That will come when I commit the fix to llvm::RefCountedBase<T> to
mainline LLVM.
llvm-svn: 144930
|
| |
|
|
|
|
| |
out two IntrusiveRefCnt pointers after we have assigned their respective values into fields of ASTUnit.
llvm-svn: 144929
|
| |
|
|
| |
llvm-svn: 144800
|
| |
|
|
|
|
|
|
| |
header, create our own in-memory buffer to parse all of the
appropriate headers, and use that to build the module. This isn't
end-to-end testable yet; that's coming next.
llvm-svn: 144797
|
| |
|
|
| |
llvm-svn: 144766
|
| |
|
|
|
|
| |
and remove stray fprintf.
llvm-svn: 144742
|
| |
|
|
|
|
|
| |
interface. This is currently limited to modules with umbrella
headers.
llvm-svn: 144736
|
| |
|
|
|
|
| |
incrementally with a new frontend action.
llvm-svn: 144723
|
| |
|
|
|
|
| |
differing from GeneratePCHAction fairly soon.
llvm-svn: 144703
|
| |
|
|
|
|
| |
building modules.
llvm-svn: 144680
|
| |
|
|
| |
llvm-svn: 144672
|
| |
|
|
|
|
|
|
|
|
|
| |
only be emitting
warnings/errors for unknown warning options. getDiagnosticsInGroup returns false if the
diagnostics is found and true otherwise. Thus, if we're reporting and we have a valid
diagnostic, we were actually setting the flag and causing mayhem.
rdar://10444207
llvm-svn: 144670
|
| |
|
|
|
|
|
|
| |
don't display either.
Also add a maximum edit distance threshold, so we don't correct "-Wx" to "-W#pragma-messages".
llvm-svn: 144644
|
| |
|
|
| |
llvm-svn: 144604
|
| |
|
|
|
|
|
| |
$ clang -Wololo t.c
warning: unknown warning option '-Wololo'; did you mean '-Wall'? [-Wunknown-warning-option]
llvm-svn: 144591
|
| |
|
|
|
|
| |
diagnostics in the future. Make it so.
llvm-svn: 144347
|
| |
|
|
| |
llvm-svn: 144277
|
| |
|
|
|
|
|
|
| |
via the libclang API.
I've tested it on simple cases and it works. Test cases to follow as well as a few tweaks.
llvm-svn: 144269
|
| |
|
|
| |
llvm-svn: 144115
|
| |
|
|
|
|
| |
function template instantiations. Fixes <rdar://problem/10398005> / PR11312.
llvm-svn: 143984
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We don't actually need a separate flag for non-sysrooted paths as the
driver has to manage the sysroot anyways. The driver is not infrequently
adding paths to the header search based on their existence on the
filesystem. For that, it has to add the sysroot anyways, we should pass
it on down to CC1 already joined. More importantly, the driver cannot in
all cases distinguish between sysrooted paths and paths that are
relative to the Clang binary's installation directory. Essentially, we
always need to ignore the system root for these internal header search
options. It turns out in most of the places we were already providing
the system root in the driver, and then another one in CC1 so this fixes
several bugs.
llvm-svn: 143917
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the first (and diff-noisiest) step to making Linux header searching
tremendously more principled and less brittle. Note that this step
should have essentially no functional impact. We still search the exact
same set of paths in the exact same order. The only change here is where
the code implementing such a search lives.
This has one obvious negative impact -- we now pass a ludicrous number
of flags to the CC1 layer. That should go away as I re-base this logic
on the logic to detect a GCC installation. I want to do this in two
phases so the bots can tell me if this step alone breaks something, and
so that the diffs of the refactoring make more sense.
llvm-svn: 143822
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
actually manage the builtin header file includes as well as the system
ones.
This one is actually debatable whether it belongs in the driver or not,
as the builtin includes are really an internal bit of implementation
goop for Clang. However, they must be included at *exactly* the right
point in the sequence of header files, which makes it essentially
impossible to have this be managed by the Frontend and the rest by the
Driver. I have terrible ideas that would "work", but I think they're
worse than putting this in the driver and making the Frontend library
even more ignorant of the environment and system on which it is being
run.
Also fix the fact that we weren't properly respecting the flags which
suppress standard system include directories.
Note that this still leaves all of the Clang tests which run CC1
directly and include builtin header files broken on Windows. I'm working
on a followup patch to address that.
llvm-svn: 143801
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
encode the *exact* semantics which the header search paths internally
built by the Frontend layer have had, which is both non-user-provided,
and at times adding the implicit extern "C" bit to the directory entry.
There are lots of CC1 options that are very close, but none do quite
this, and they are all already overloaded for other purposes. In some
senses this makes the command lines more clean as it clearly indicates
which flags are exclusively used to implement internal detection of
"standard" header search paths.
Lots of the implementation of this is really crufty, due to the
surrounding cruft. It doesn't seem worth investing lots of time cleaning
this up as it isn't new, and hopefully *lots* of this code will melt
away as header search inside of the frontend becomes increasingly
trivial.
llvm-svn: 143798
|
| |
|
|
| |
llvm-svn: 143776
|
| |
|
|
| |
llvm-svn: 143765
|
| |
|
|
|
|
| |
diagnostics block.
llvm-svn: 143764
|
| |
|
|
|
|
| |
blocks. The goal is to remove BLOCK_STRINGS so that the bitcode file can potentially be streamed.
llvm-svn: 143763
|