Use functions with prototypes when appropriate; NFC

A significant number of our tests in C accidentally use functions
without prototypes. This patch converts the function signatures to have
a protot

Use functions with prototypes when appropriate; NFC

A significant number of our tests in C accidentally use functions
without prototypes. This patch converts the function signatures to have
a prototype for the situations where the test is not specific to K&R C
declarations. e.g.,

void func();

becomes

void func(void);

This is the seventh batch of tests being updated (there are a
significant number of other tests left to be updated).

show more ...

Improve diagnostics for missing import / #include of module.

Fix a few bugs where we would fail to properly determine header to
module correspondence when determining whether to suggest a #include o

Improve diagnostics for missing import / #include of module.

Fix a few bugs where we would fail to properly determine header to
module correspondence when determining whether to suggest a #include or
import, and suggest a #include more often in language modes where there
is no import syntax. Generally, if the target is in a header with
include guards or #pragma once, we should suggest either #including or
importing that header, and not importing a module that happens to
textually include it.

In passing, improve the notes we attach to the corresponding
diagnostics: calling an entity that we couldn't see "previous" is
confusing.

show more ...

[modules] Simplify -cc1 interface for enabling implicit module maps.

We used to have a flag to enable module maps, and two more flags to enable
implicit module maps. This is all redundant; we don't

[modules] Simplify -cc1 interface for enabling implicit module maps.

We used to have a flag to enable module maps, and two more flags to enable
implicit module maps. This is all redundant; we don't need any flag for
enabling module maps in the abstract, and we don't usually have -fno- flags for
-cc1. We now have just a single flag, -fimplicit-module-maps, that enables
implicitly searching the file system for module map files and loading them.

The driver interface is unchanged for now. We should probably rename
-fmodule-maps to -fimplicit-module-maps at some point.

llvm-svn: 239789

show more ...

During typo correction, check for an exact match in an unimported module. If we
find one, then report the error as a missing import instead of as a typo.

llvm-svn: 188821

Extended VerifyDiagnosticConsumer to also verify source file for diagnostic.

VerifyDiagnosticConsumer previously would not check that the diagnostic and
its matching directive referenced the same so

Extended VerifyDiagnosticConsumer to also verify source file for diagnostic.

VerifyDiagnosticConsumer previously would not check that the diagnostic and
its matching directive referenced the same source file. Common practice was
to create directives that referenced other files but only by line number,
and this led to problems such as when the file containing the directive
didn't have enough lines to match the location of the diagnostic in the
other file, leading to bizarre file formatting and other oddities.

This patch causes VerifyDiagnosticConsumer to match source files as well as
line numbers. Therefore, a new syntax is made available for directives, for
example:

// expected-error@file:line {{diagnostic message}}

This extends the @line feature where "file" is the file where the diagnostic
is generated. The @line syntax is still available and uses the current file
for the diagnostic. "file" can be specified either as a relative or absolute
path - although the latter has less usefulness, I think! The #include search
paths will be used to locate the file and if it is not found an error will be
generated.

The new check is not optional: if the directive is in a different file to the
diagnostic, the file must be specified. Therefore, a number of test-cases
have been updated with regard to this.

This closes out PR15613.

llvm-svn: 179677

show more ...

Rename -fmodule-cache-path <blah> to -fmodules-cache-path=<blah> for consistency.

llvm-svn: 174645

Use @import rather than @__experimental_modules_import, since the
latter is rather a mess to type.

llvm-svn: 169919

Sanitize the names of modules determined based on the names of headers
or directories, to make sure that they are identifiers that are not
keywords in any dialect. Fixes <rdar://problem/12489495>.

l

Sanitize the names of modules determined based on the names of headers
or directories, to make sure that they are identifiers that are not
keywords in any dialect. Fixes <rdar://problem/12489495>.

llvm-svn: 165821

show more ...

Change @import to @__experimental_modules_import. We are not ready to commit to a particular syntax for modules,
and don't have time to push it forward in the near future.

llvm-svn: 151841

Eliminate the uglified keyword __import_module__ for importing
modules. This leaves us without an explicit syntax for importing
modules in C/C++, because such a syntax needs to be discussed
first. In

Eliminate the uglified keyword __import_module__ for importing
modules. This leaves us without an explicit syntax for importing
modules in C/C++, because such a syntax needs to be discussed
first. In Objective-C/Objective-C++, the @import syntax is used to
import modules.

Note that, under -fmodules, C/C++ programs can import modules via the
#include mechanism when a module map is in place for that header. This
allows us to work with modules in C/C++ without committing to a syntax.

llvm-svn: 147467

show more ...

Rename the command-line option for mapping #include/#import over to
module imports from -fauto-module-import to -fmodules. The new name
will eventually be used to enable modules, and the #include/#im

Rename the command-line option for mapping #include/#import over to
module imports from -fauto-module-import to -fmodules. The new name
will eventually be used to enable modules, and the #include/#import
mapping is a crucial part of the feature.

llvm-svn: 147447

show more ...

Modify how the -verify flag works. Currently, the verification string and
diagnostic message are compared. If either is a substring of the other, then
no error is given. This gives rise to an unex

Modify how the -verify flag works. Currently, the verification string and
diagnostic message are compared. If either is a substring of the other, then
no error is given. This gives rise to an unexpected case:

// expect-error{{candidate function has different number of parameters}}

will match the following error messages from Clang:

candidate function has different number of parameters (expected 1 but has 2)
candidate function has different number of parameters

It will also match these other error messages:

candidate function
function has different number of parameters
number of parameters

This patch will change so that the verification string must be a substring of
the diagnostic message before accepting. Also, all the failing tests from this
change have been corrected. Some stats from this cleanup:

87 - removed extra spaces around verification strings
70 - wording updates to diagnostics
40 - extra leading or trailing characters (typos, unmatched parens or quotes)
35 - diagnostic level was included (error:, warning:, or note:)
18 - flag name put in the warning (-Wprotocol)

llvm-svn: 146619

show more ...

Implement umbrella directories for modules, which are similar to
umbrella headers in the sense that all of the headers within that
directory (and eventually its subdirectories) are considered to be
p

Implement umbrella directories for modules, which are similar to
umbrella headers in the sense that all of the headers within that
directory (and eventually its subdirectories) are considered to be
part of the module with that umbrella directory. However, unlike
umbrella headers, which are expected to include all of the headers
within their subdirectories, Clang will automatically include all of
the headers it finds in the named subdirectory.

The intent here is to allow a module map to trivially turn a
subdirectory into a module, where the module's structure can mimic the
directory structure.

llvm-svn: 146165

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 ...

A module with an umbrella header assumes that all of the headers in
the umbrella header's directory and its subdirectories are part of the
module (that's why it's an umbrella). Make sure that these h

A module with an umbrella header assumes that all of the headers in
the umbrella header's directory and its subdirectories are part of the
module (that's why it's an umbrella). Make sure that these headers are
considered to be part of the module for lookup purposes.

llvm-svn: 144859

show more ...

Implement (de-)serialization of the buffer contents for an overridden
file in the source manager. This allows us to properly create and use
modules described by module map files without umbrella head

Implement (de-)serialization of the buffer contents for an overridden
file in the source manager. This allows us to properly create and use
modules described by module map files without umbrella headers (or
with incompletely umbrella headers). More generally, we can actually
build a PCH file that makes use of file -> buffer remappings, which
could be useful in libclang in the future.

llvm-svn: 144830

show more ...

When building a module from a module map that isn't simply an umbrella
header, create our own in-memory buffer to parse all of the
appropriate headers, and use that to build the module. This isn't
en

When building a module from a module map that isn't simply an umbrella
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

show more ...

Add support for building a module from a module map to the -cc1
interface. This is currently limited to modules with umbrella
headers.

llvm-svn: 144736

When searching for a module, speculatively load module maps to see if
the module is described in one of the module maps in a search path or
in a subdirectory off the search path that has the same nam

When searching for a module, speculatively load module maps to see if
the module is described in one of the module maps in a search path or
in a subdirectory off the search path that has the same name as the
module we're looking for.

llvm-svn: 144433

show more ...

Teach the search for modules to consider modules described by a module
map, so long as they have an umbrella header. This makes it possible
to introduce a module map + umbrella header for a given set

Teach the search for modules to consider modules described by a module
map, so long as they have an umbrella header. This makes it possible
to introduce a module map + umbrella header for a given set of
headers, to turn it into a module.

There are two major deficiencies here: first, we don't go hunting for
module map files when we just see a module import (so we won't know
about the modules described therein). Second, we don't yet have a way
to build modules that don't have umbrella headers, or have incomplete
umbrella headers.

llvm-svn: 144424

show more ...

Wire up the mapping from header files mentioned in module maps over to
the corresponding (top-level) modules. This isn't actually useful yet,
because we don't yet have a way to build modules out of m

Wire up the mapping from header files mentioned in module maps over to
the corresponding (top-level) modules. This isn't actually useful yet,
because we don't yet have a way to build modules out of module maps.

llvm-svn: 144410

show more ...

Introduce basic support for parsing module map files.

Module map files provide a way to map between headers and modules, so
that we can layer a module system on top of existing headers without
chang

Introduce basic support for parsing module map files.

Module map files provide a way to map between headers and modules, so
that we can layer a module system on top of existing headers without
changing those headers at all.

This commit introduces the module map file parser and the module map
that it generates, and wires up the module map file parser so that
we'll automatically find module map files as part of header
search. Note that we don't yet use the information stored in the
module map.

llvm-svn: 144402

show more ...