The previous code that was supposed to handle this didn't work
since parsing of inline method definitions is delayed to the end
of the outer class definition. Thus, when HandleTagDeclDefinition()
got called for the inner class, the inline functions in that class
had not been parsed yet.
Richard suggested that the way to do this is by handling inline
method definitions through a new ASTConsumer callback.
I really wanted to call ASTContext::DeclMustBeEmitted() instead of
checking for attributes, but doing that causes us to compute linkage,
and then we fail with "error: unsupported: typedef changes linkage
of anonymous type, but linkage was already computed" on tests like
this: (from SemaCXX/undefined-internal.cpp) :-/
namespace test7 {
typedef struct {
void bar();
void foo() { bar(); }
} A;
}
Differential Revision: http://reviews.llvm.org/D3809
llvm-svn: 209549
Summary:
The limits on the number of fix-it hints and ranges attached to a
diagnostic are arbitrary and don't apply universally to all users of the
DiagnosticsEngine. The way the limits are enforced may lead to diagnostics
generating invalid sets of fixes. I suggest removing the limits, which will also
simplify the implementation.
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D3879
llvm-svn: 209468
Eliminate createMainFileID() / createMainFileIDForMemBuffer() utility
functions. These didn't add much convenience and conflated two distinct
operations.
This change makes things easier to follow by providing a consistent interface
and getting rid of a bunch of cast-to-voids.
llvm-svn: 209266
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
All callers were passing in "a.out" or garbage so a sensible default works fine
here as a cleanup.
This also brings about the possibility of adapting the value based on the
driver's compatibility mode in future.
The setting can still be changed via Driver::DefaultImageName as needed.
llvm-svn: 208926
On reflection, this is better despite the missing command-line handling
bits for remarks. Making this a remark makes it much clearer that
this is purely informational and avoids the negative connotations of a
'warning'.
llvm-svn: 208367
It was set by default on Darwin in r198655. The same usability issues
with DTrace and LLDB apply to FreeBSD, so set it by default there too.
rdar://problem/15758808
http://llvm.org/pr19676
Differential Revision: http://reviews.llvm.org/D3448
llvm-svn: 208310
Use this to fix the leak of DeserializedDeclsDumper and DeserializedDeclsChecker
in FrontendAction (found by LSan), PR19560.
The "delete this" bool is necessary because both PCHGenerator and ASTUnit
return the same object from both getDeserializationListener() and
getASTMutationListener(), so ASTReader can't just have a unique_ptr.
It's also not possible to just let FrontendAction (or CompilerInstance) own
these listeners due to lifetime issues (see comments on PR19560).
Finally, ASTDeserializationListener can't easily be refcounted, since several of
the current listeners are allocated on the stack.
Having this bool isn't ideal, but it's a pattern that's used in other places in
the codebase too, and it seems better than leaking.
llvm-svn: 208277
This addresses an existing FIXME item in the driver. The code model flag was
parsed in the actual tool rather than in the driver. This was problematic since
the value may be invalid. In that case, we would silently treat it as a default
value in non-assert builds, and abort in assert builds. Add a check in the
driver to validate that the value being passed is valid, and if not provide a
proper error message.
llvm-svn: 208275
whether the definition of the template is visible rather than checking whether
the instantiated definition happens to be in an imported module.
llvm-svn: 208150
Ideally, importing Foo.a from Foo.b would "do the right thing", but
until it does, this patch makes it an error rather than allow it to
silently be ignored.
llvm-svn: 207948
Having various possible states of initialization following construction doesn't
add value here.
Also remove the unused size_reserve parameter.
llvm-svn: 207897
The Preprocessor::Initialize() function already offers a clear interface to
achieve this, further reducing the confusing number of states a newly
constructed preprocessor can have.
llvm-svn: 207825
After this patch clang will ignore -fdwarf2-cfi-asm and -ffno-dwarf2-cfi-asm and
always print assembly that uses cfi directives.
In llvm, MC itself supports cfi since the end of 2010 (support started
in r119972, is reported in the 2.9 release notes).
In binutils the support has been around for much longer. It looks like
support started to be added in May 2003. It is available in 2.15
(31-Aug-2011, 2.14 is from 12-Jun-2003).
llvm-svn: 207602
Fixed by moving ProcessWarningOptions from Frontend into Basic. All of
the dependencies for ProcessWarningOptions were already in Basic, so
this was a small change.
llvm-svn: 207549
This patch checks whether the diagnostic options that could lead to
errors (principally -Werror) are consistent between when a module was
built and when it is loaded. If there are new -Werror flags, then the
module is rebuilt. In order to canonicalize the options we do this
check at the level of the constructed DiagnosticsEngine, which contains
the final set of diag to diagnostic level mappings. Currently we only
rebuild with the new diagnostic options, but we intend to refine this in
the future to include the union of the new and old flags, since we know
the old ones did not cause errors. System modules are only rebuilt when
-Wsystem-headers is enabled.
One oddity is that unlike checking language options, we don’t perform
this diagnostic option checking when loading from a precompiled header.
The reason for this is that the compiler cannot rebuild the PCH, so
anything that requires it to be rebuilt effectively leaks into the build
system. And in this case, that would mean the build system
understanding the complex relationship between diagnostic options and
the underlying diagnostic mappings, which is unreasonable. Skipping the
check is safe, because these options do not affect the generated AST.
You simply won’t get new build errors due to changed -Werror options
automatically, which is also true for non-module cases.
llvm-svn: 207477
We don't need the ASTContext for the diagnostics, only the language
options, which we can get from the compiler invocation. It worries me
how many categorically different states the ASTUnit class can be in
depending on how it is being constructed/used.
llvm-svn: 206909
Summary:
This allows callers of Diags.Report() to append a value to the name of
the flag associated with the diagnostic. This is useful in cases like
the -Rpass flag, where we want the diagnostic to show the name of the
pass that matched the pattern. Instead of showing "... [-Rpass]", this
allows us to show "... [-Rpass=passname]".
Reviewers: rsmith
CC: cfe-commits
Differential Revision: http://reviews.llvm.org/D3441
llvm-svn: 206826
Unless they are in submodules that aren't available anyway, due to
requirements not being met. Also, mark children as unavailable when the
parent is.
llvm-svn: 206664
This paves the way to making OnDiskHashTable work with hashes that are
not 32 bits wide and to making OnDiskHashTable work very large hash
tables. The LLVM change to use these types is upcoming.
llvm-svn: 206640
This reverts commit r206413.
This was proposed before, but it's not clear if this is really a good
idea:
http://reviews.llvm.org/D3034
llvm-svn: 206415
Summary:
This patch adds a new flag -Rpass=. The flag indicates the name
of the optimization pass that should emit remarks stating when it
made a transformation to the code.
This implements the design I proposed in:
https://docs.google.com/document/d/1FYUatSjZZO-zmFBxjOiuOzAy9mhHA8hqdvklZv68WuQ/edit?usp=sharing
Other changes:
- Add DiagnosticIDs::isRemark(). Use it in printDiagnosticOptions to
print "-R" instead of "-W" in the diagnostic message.
- In BackendConsumer::OptimizationRemarkHandler, get a SourceLocation
object out of the file name, line and column number. Use that location
in the call to Diags.Report().
- When -Rpass is used without debug info a note is emitted alerting
the user that they need to use -gline-tables-only -gcolumn-info to
get this information.
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3226
llvm-svn: 206401
