Use absolute paths for temporary module map files

llvm-svn: 145973

When we treat an #include or #import as a module import, create an
implicit ImportDecl in the translation unit to record the presence of
the import.

llvm-svn: 145727

Introduce the notion of name visibility into modules. For a given
(sub)module, all of the names may be hidden, just the macro names may
be exposed (for example, after the preprocessor has seen the im

Introduce the notion of name visibility into modules. For a given
(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

show more ...

Promote ModuleMap::Module to a namespace-scope class in the Basic
library, since modules cut across all of the libraries. Rename
serialization::Module to serialization::ModuleFile to side-step the
an

Promote ModuleMap::Module to a namespace-scope class in the Basic
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

show more ...

Don't collide loop variable names (to appease GCC)

llvm-svn: 145515

Implement (de-)serialization of the description of a module and its
submodules. This information will eventually be used for name hiding
when dealing with submodules. For now, we only use it to ensur

Implement (de-)serialization of the description of a module and its
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

show more ...

Teach the preprocessor how to handle module import declarations that
involve submodules (e.g., importing std.vector), rather than always
importing the top-level module.

llvm-svn: 145478

When loading a module that involves submodules (e.g., std.vector),
check whether the named submodules themselves are actually
valid, and drill down to the named submodule (although we don't do
anythi

When loading a module that involves submodules (e.g., std.vector),
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

show more ...

Switch the module-loading interfaces and parser from a simple
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.

llv

Switch the module-loading interfaces and parser from a simple
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

show more ...

Switch on-demand module building over to use module maps, always. When
we infer the module map, we'll just print the module map to a
temporary file and generate the module using that.

llvm-svn: 1454

Switch on-demand module building over to use module maps, always. When
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

show more ...

Teach the module import mechanism how to rebuild modules expressed via
module map, rather than assuming that there is an umbrella
header. This allows us to automatically build umbrella-less modules.

Teach the module import mechanism how to rebuild modules expressed via
module map, rather than assuming that there is an umbrella
header. This allows us to automatically build umbrella-less modules.

llvm-svn: 145415

show more ...

Start refactoring to use module maps when rebuilding a module
on-the-fly. No functionality change.

llvm-svn: 145414

When attempting to load a module that is not in the module cache,
return the module itself (in the module map) rather than returning the
umbrella header used to build the module. While doing this, ma

When attempting to load a module that is not in the module cache,
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

show more ...

Make 'LangOptions' in CompilerInvocation a heap-allocated, reference counted object. I discovered that llvm::RefCountedBase<T> has
a bug where the reference count is copied in the copy constructor,

Make 'LangOptions' in CompilerInvocation a heap-allocated, reference counted 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

show more ...

Revert r144703. It was a dumb idea anyway; will add the new bits more
incrementally with a new frontend action.

llvm-svn: 144723

Split GenerateModuleAction into its own action, which will start
differing from GeneratePCHAction fairly soon.

llvm-svn: 144703

Add a -cc1-level option -fmodule-name=<name>, which will be used when
building modules.

llvm-svn: 144680

I predict that HeaderSearch will need the ability to generate
diagnostics in the future. Make it so.

llvm-svn: 144347

rename getHostTriple into getDefaultTargetTriple in clang

llvm-svn: 143503

Start work on SerializedDiagnosticPrinter, a new DiagnosticConsumer that serializes out the diagnostics for a given translation unit to a bit code file. This is a WIP.

The motivation for this new D

Start work on SerializedDiagnosticPrinter, a new DiagnosticConsumer that serializes out the diagnostics for a given translation unit to a bit code file. This is a WIP.

The motivation for this new DiagnosticConsumer is to provide a way for tools invoking the compiler
to get its diagnostics via a libclang interface, rather than textually parsing the compiler output.
This gives us flexibility to change the compiler's textual output, but have a structured data format
for clients to use to get the diagnostics via a stable API.

I have no tests for this, but llvm-bcanalyzer so far shows that the emitted file is well-formed.

More work to follow.

llvm-svn: 143259

show more ...

lib/Frontend/CompilerInstance.cpp: Suppress a "Comparision of unsigned and signed" warning on Cygwin gcc-4.3.4.

llvm-svn: 141488

Whitespace

llvm-svn: 141486

Seriously ugly hack, part 2

llvm-svn: 141181

Seriously ugly hack to try to get the Windows builders back online

llvm-svn: 141180

Introduce a simple file-based locking protocol for on-demand module
creation, so that only a single Clang instance will rebuild a given
module at once (and the others will wait).

We still don't clea

Introduce a simple file-based locking protocol for on-demand module
creation, so that only a single Clang instance will rebuild a given
module at once (and the others will wait).

We still don't clean up the lock files when we crash, which is a
rather unfortunate problem. I'll handle that next, and there is
certainly a *lot* of room for further improvements.

llvm-svn: 141179

show more ...