| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
consistency.
llvm-svn: 174645
|
|
|
|
|
|
|
|
|
|
|
|
| |
bogus with a PCH
that redefined a macro without undef'ing it first.
Proper reconstruction of the macro info history from modules will properly fix this in subsequent commits.
rdar://13016031
llvm-svn: 173281
|
|
|
|
|
|
| |
latter is rather a mess to type.
llvm-svn: 169919
|
|
|
|
|
|
| |
#undef only occurs if that submodule is imported.
llvm-svn: 165773
|
|
|
|
|
|
|
| |
only with modules, when two disjoint modules #define the same
identifier to different token sequences.
llvm-svn: 165746
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
macro history.
When deserializing macro history, we arrange history such that the
macros that have definitions (that haven't been #undef'd) and are
visible come at the beginning of the list, which is what the
preprocessor and other clients of Preprocessor::getMacroInfo()
expect. If additional macro definitions become visible later, they'll
be moved toward the front of the list. Note that it's possible to have
ambiguities, but we don't diagnose them yet.
There is a partially-implemented design decision here that, if a
particular identifier has been defined or #undef'd within the
translation unit, that definition (or #undef) hides any macro
definitions that come from imported modules. There's still a little
work to do to ensure that the right #undef'ing happens.
Additionally, we'll need to scope the update records for #undefs, so
they only kick in when the submodule containing that update record
becomes visible.
llvm-svn: 165682
|
|
|
|
|
|
|
|
|
|
| |
specific module (__building_module(modulename)) and to get the name of
the current module as an identifier (__MODULE__).
Used to help headers behave differently when they're being included as
part of building a module. Oh, the irony.
llvm-svn: 164605
|
|
|
|
|
|
|
|
| |
commit to a particular syntax for modules,
and don't have time to push it forward in the near future.
llvm-svn: 151841
|
|
|
|
| |
llvm-svn: 147469
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
to make a macro public (the default for headers) or private,
respectively.
llvm-svn: 147455
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
source file (e.g., a header). Immediately steal this useful option
name for building modules from a module map file.
llvm-svn: 145444
|
|
|
|
| |
llvm-svn: 144779
|
|
|
|
|
|
|
| |
public. Add a __private_macro__ directive to hide a macro, similar to
the __module_private__ declaration specifier.
llvm-svn: 142188
|
|
|
|
| |
llvm-svn: 139750
|
|
|
|
|
|
| |
non-exported macro, for real this time
llvm-svn: 139745
|
|
|
|
| |
llvm-svn: 139734
|
|
|
|
|
|
| |
non-exported macro
llvm-svn: 139728
|
|
|
|
|
|
|
|
|
| |
target triple to separate modules built under different
conditions. The hash is used to create a subdirectory in the module
cache path where other invocations of the compiler (with the same
version, language options, etc.) can find the precompiled modules.
llvm-svn: 139662
|
|
|
|
|
|
|
|
| |
where the compiler will look for module files. Eliminates the
egregious hack where we looked into the header search paths for
modules.
llvm-svn: 139538
|
|
include guards don't show up as macro definitions in every translation
unit that imports a module. Macro definitions can, however, be
exported with the intentionally-ugly #__export_macro__
directive. Implement this feature by not even bothering to serialize
non-exported macros to a module, because clients of that module need
not (should not) know that these macros even exist.
llvm-svn: 138943
|