| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
module, at least have the decency to complain about it.
llvm-svn: 146002
|
|
|
|
| |
llvm-svn: 145983
|
|
|
|
| |
llvm-svn: 145973
|
|
|
|
|
|
|
|
| |
explicit submodules or umbrella headers from submodules. Instead,
build the entire module at once, and let the name-hiding mechanisms
hide the contents of explicit submodules at load time.
llvm-svn: 145940
|
|
|
|
|
|
| |
realignment, even with locals with alignment exceeding the ABI guarantee.
llvm-svn: 145909
|
|
|
|
|
|
| |
backend options are gone.
llvm-svn: 145868
|
|
|
|
|
|
|
| |
implicit ImportDecl in the translation unit to record the presence of
the import.
llvm-svn: 145727
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(sub)module, all of the names may be hidden, just the macro names may
be exposed (for example, after the preprocessor has seen the import of
the module but the parser has not), or all of the names may be
exposed. Importing a module makes its names, and the names in any of
its non-explicit submodules, visible to name lookup (transitively).
This commit only introduces the notion of name visible and marks
modules and submodules as visible when they are imported. The actual
name-hiding logic in the AST reader will follow (along with test cases).
llvm-svn: 145586
|
|
|
|
|
|
|
|
|
| |
library, since modules cut across all of the libraries. Rename
serialization::Module to serialization::ModuleFile to side-step the
annoying naming conflict. Prune a bunch of ModuleMap.h includes that
are no longer needed (most files only needed the Module type).
llvm-svn: 145538
|
|
|
|
| |
llvm-svn: 145515
|
|
|
|
|
|
|
|
|
| |
submodules. This information will eventually be used for name hiding
when dealing with submodules. For now, we only use it to ensure that
the module "key" returned when loading a module will always be a
module (rather than occasionally being a FileEntry).
llvm-svn: 145497
|
|
|
|
|
|
| |
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
|