Commit Graph

14 Commits

Author SHA1 Message Date
Richard Smith 053f6c6c9e If a declaration is loaded, and then a module import adds a redeclaration, then
ensure that querying the first declaration for its most recent declaration
checks for redeclarations from the imported module.

This works as follows:
 * The 'most recent' pointer on a canonical declaration grows a pointer to the
   external AST source and a generation number (space- and time-optimized for
   the case where there is no external source).
 * Each time the 'most recent' pointer is queried, if it has an external source,
   we check whether it's up to date, and update it if not.
 * The ancillary data stored on the canonical declaration is allocated lazily
   to avoid filling it in for declarations that end up being non-canonical.
   We'll still perform a redundant (ASTContext) allocation if someone asks for
   the most recent declaration from a decl before setPreviousDecl is called,
   but such cases are probably all bugs, and are now easy to find.

Some finessing is still in order here -- in particular, we use a very general
mechanism for handling the DefinitionData pointer on CXXRecordData, and a more
targeted approach would be more compact.

Also, the MayHaveOutOfDateDef mechanism should now be expunged, since it was
addressing only a corner of the full problem space here. That's not covered
by this patch.

Early performance benchmarks show that this makes no measurable difference to 
Clang performance without modules enabled (and fixes a major correctness issue
with modules enabled). I'll revert if a full performance comparison shows any
problems.

llvm-svn: 209046
2014-05-16 23:01:30 +00:00
Richard Smith 4abe0a8d82 C++ modules: fix a bug where loading a declaration with some name would prevent
name lookup from lazily deserializing the other declarations with the same
name, by tracking a bit to indicate whether a name in a DeclContext might have
additional external results. This also allows lazier reconciling of the lookup
table if a module import adds decls to a pre-existing DC.

However, this exposes a pre-existing bug, which causes a regression in
test/Modules/decldef.mm: if we have a reference to a declaration, and a
later-imported module adds a redeclaration, nothing causes us to load that
redeclaration when we use or emit the reference (which can manifest as a
reference to an undefined inline function, a use of an incomplete type, and so
on). decldef.mm has been extended with an additional testcase which fails with
or without this change.

llvm-svn: 190293
2013-09-09 07:34:56 +00:00
Richard Smith e156254d4c 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
2013-08-20 20:35:18 +00:00
Andy Gibbs fcc699aee8 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
2013-04-17 08:06:46 +00:00
Douglas Gregor 7dab26b87c Ensure that type definitions present in just-loaded modules are
visible.

The basic problem here is that a given translation unit can use
forward declarations to form pointers to a given type, say,

  class X;
  X *x;

and then import a module that includes a definition of X:

  import XDef;

We will then fail when attempting to access a member of X, e.g., 

  x->method()

because the AST reader did not know to look for a default of a class
named X within the new module.

This implementation is a bit of a C-centric hack, because the only
definitions that can have this property are enums, structs, unions,
Objective-C classes, and Objective-C protocols, and all of those are
either visible at the top-level or can't be defined later. Hence, we
can use the out-of-date-ness of the name and the identifier-update
mechanism to force the update.

In C++, we will not be so lucky, and will need a more advanced
solution, because the definitions could be in namespaces defined in
two different modules, e.g.,

  // module 1
  namespace N { struct X; }

  // module 2
  namespace N { struct X { /* ... */ }; }

One possible implementation here is for C++ to extend the information
associated with each identifier table to include the declaration IDs
of any definitions associated with that name, regardless of
context. We would have to eagerly load those definitions.

llvm-svn: 174794
2013-02-09 01:35:03 +00:00
Douglas Gregor 35b04d6fd2 Rename -fmodule-cache-path <blah> to -fmodules-cache-path=<blah> for consistency.
llvm-svn: 174645
2013-02-07 19:01:24 +00:00
Douglas Gregor c147b0bc31 Provide Decl::getOwningModule(), which determines the (sub)module in
which a particular declaration resides. Use this information to
customize the "definition of 'blah' must be imported from another
module" diagnostic with the module the user actually has to
import. Additionally, recover by importing that module, so we don't
complain about other names in that module.

Still TODO: coming up with decent Fix-Its for these cases, and expand
this recovery approach for other name lookup failures.

llvm-svn: 172290
2013-01-12 01:29:50 +00:00
Douglas Gregor c50d4924eb Use @import rather than @__experimental_modules_import, since the
latter is rather a mess to type.

llvm-svn: 169919
2012-12-11 22:11:52 +00:00
Ted Kremenek c1e4dd0e8e 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
2012-03-01 22:07:04 +00:00
Douglas Gregor 0bf886d41a Under -fmodules, accept #public <macroname> and #private <macroname>
to make a macro public (the default for headers) or private,
respectively.

llvm-svn: 147455
2012-01-03 18:24:14 +00:00
Douglas Gregor 22d0974b40 Introduce a non-uglified syntax for module imports in Objective-C:
@import identifier [. identifier]* ;

llvm-svn: 147452
2012-01-03 18:04:46 +00:00
Douglas Gregor 5dbf4eb66b Diagnose cases where the definition of a particular type is required,
is known (to Clang), but is not visible because the module has not yet
been imported.

llvm-svn: 147436
2012-01-02 17:18:37 +00:00
Douglas Gregor 95ab186240 When name lookup finds a module-private Objective-C class declaration,
check whether any previous declarations of the class were visible.

llvm-svn: 146680
2011-12-15 20:36:27 +00:00
Douglas Gregor 4a814568b2 When name lookup comes across a declaration that is in a module that
is not visible, look for any previous declarations of that entity that
might be visible.

llvm-svn: 146563
2011-12-14 16:03:29 +00:00