The testcase in PR16060 points out that while template arguments can
show that a type is not externally visible, the standards still says
they have external linkage.
In terms of our implementation, it means that we should merge just the
isExternallyVisible bit, not the formal linkage.
llvm-svn: 182962
references. What's more, they use this language extension in their
ATL header files (which come as part of MFC and the Win32 SDK). This patch implements support for the Microsoft extension, and addresses PR13737.
llvm-svn: 182936
This change is motivated from user feedback that some APIs use
void* as an opaque "context" object that may not really be a pointer.
Such users want an ability to turn off the warning for casts
to void* while preserving the warning for other cases.
Implements <rdar://problem/14016721>.
llvm-svn: 182884
MSVC's class data is always comdat, so clang's should always be
linkonce_odr in LLVM IR.
Reviewers: pcc
Differential Revision: http://llvm-reviews.chandlerc.com/D838
llvm-svn: 182865
newFrontendActionFactory() took a pointer to a callback to call when a source
file was done being processed by an action. This revision updates the callback
to include an ante-processing callback as well.
Callback-providing class renamed and callback functions themselves renamed.
Functions are no longer pure-virtual so users aren't forced to implement both
callbacks if one isn't needed.
llvm-svn: 182864
With option enabled (e.g. in Google-style):
template <typename T>
void f() {}
With option disabled:
template <typename T> void f() {}
Enabling this for Google-style and Chromium-style, not sure which other
styles would prefer that.
llvm-svn: 182849
This gives slightly better precision, specifically, in cases where a non-typed region represents the array
or when the type is a non-array type, which can happen when an array is a result of a reinterpret_cast.
llvm-svn: 182810
Before this patch the linkage cache was only used by the entry level function
(getLinkage). The function that does the actual computation (getLVForDecl),
never looked at it.
This means that we would not reuse an entry in the cache when getLVForDecl did
a recursive call. This patch fixes that by adding another computation enum
value for when we don't care about the linkage at all and having getLVForDecl
check the cache in that case.
When running "clang -cc1" over SemaExpr.ii this brings the number of linkage
computations from 93749 to 58426. When running "clang -cc1 -emit-llvm -O3" it
goes from 198708 to 161444.
For SemaExpr.ii at least linkage computation is a small enough percentage of
the work that the time difference was in the noise.
When asserts are enabled this patch also causes clang to check the linkage
cache even on recursive calls.
llvm-svn: 182799
This option is used to select a dynamic loader prefix to be used
at runtime. Currently this is implemented for the Linux toolchain.
Differential Revision: http://llvm-reviews.chandlerc.com/D851
llvm-svn: 182744
If -fsanitize=leak is specified, link the program with the
LeakSanitizer runtime. Ignore this option when -fsanitize=address is specified,
because AddressSanitizer has this functionality built in.
llvm-svn: 182729
John noticed that the fix for pr15930 (r181981) didn't handle indirect
uses of local types. For example, a pointer to local struct, or a
function that returns it.
One way to implement this would be to recursively look for local
types. This would look a lot like the linkage computation itself for
types.
To avoid code duplication and utilize the existing linkage cache, this
patch just makes the computation of "type with no linkage but
externally visible because it is from an inline function" part of the
linkage computation itself.
llvm-svn: 182711
Before:
vector<int> x { 1, 2, 3 };
After:
vector<int> x{ 1, 2, 3 };
Also add a style option to remove the spaces inside braced lists,
so that the above becomes:
std::vector<int> v{1, 2, 3};
llvm-svn: 182570
*that* easy...
Try a bit harder to disambiguate. This is mostly straightforward, but for
=-style initializers, we actually need to know where an expression ends:
[foo = bar baz]
is a message send, whereas
[foo = bar + baz]
is a lambda-introducer. Handle this by parsing the expression eagerly, and
replacing it with an annotation token. By chance, we use the *exact same*
parsing rules in both cases (except that we need to assume we're inside a
message send for the parse, to turn off various forms of inapplicable
error recovery).
llvm-svn: 182432
common function. The C++1y contextual implicit conversion rules themselves are
not yet implemented, however.
This also fixes a subtle bug where template instantiation context notes were
dropped for diagnostics coming from conversions for integral constant
expressions -- we were implicitly slicing a SemaDiagnosticBuilder into a
DiagnosticBuilder when producing these diagnostics, and losing their context
notes in the process.
llvm-svn: 182406
With this patch, clang-format will try to keep the cursor at the
original code position in editor integrations (implemented for emacs and
vim). This means, after formatting, clang-format will try to keep the
cursor on the same character of the same token.
llvm-svn: 182373
attach, rather than merging all comments on the declaration chain. This gives a
more faithful dump, and has the side benefit of unbreaking uses of dump() from
within AST deserialization (where the redeclaration chain may not be sane).
llvm-svn: 182350
protocols that declare the same property of incompatible
types, issue a warning when class implementation synthesizes
the property. // rdar://13075400
llvm-svn: 182316
selectany only applies to externally visible global variables. It has
the effect of making the data weak_odr.
The MSDN docs suggest that unused definitions can only be dropped at
linktime, so Clang uses weak instead of linkonce. MSVC optimizes away
references to constant selectany data, so it must assume that there is
only one definition, hence weak_odr.
Reviewers: espindola
Differential Revision: http://llvm-reviews.chandlerc.com/D814
llvm-svn: 182266
Ted and I spent a long time discussing this today and found out that neither
the existing code nor the new code was doing what either of us thought it
was, which is never good. The good news is we found a much simpler way to
fix the motivating test case (an ObjCSubscriptExpr).
This reverts r182083, but pieces of it will come back in subsequent commits.
llvm-svn: 182185
assert_exclusive_lock and assert_shared_lock. These attributes are used to
mark functions that dynamically check (i.e. assert) that a lock is held.
llvm-svn: 182170
This optimizes some spurious edges resulting from PseudoObjectExprs.
This required far more changes than I anticipated. The current
ParentMap does not record any hierarchy information between
a PseudoObjectExpr and its *semantic* expressions that may be
wrapped in OpaqueValueExprs, which are the expressions actually
laid out in the CFG. This means the arrow pruning logic could
not map from an expression to its containing PseudoObjectExprs.
To solve this, this patch adds a variant of ParentMap that
returns the "semantic" parentage of expressions (essentially
as they are viewed by the CFG). This alternate ParentMap is then
used by the arrow reducing logic to identify edges into pseudo
object expressions, and then eliminate them.
llvm-svn: 182083
instantiate the inherited constructor template and mark that as the constructor
which the instantiated specialization is inheriting. This fixes a
crash-on-valid when trying to compute the exception specification of a
specialization of the inheriting constructor.
llvm-svn: 182072
The analyzer can't see the reference count for shared_ptr, so it doesn't
know whether a given destruction is going to delete the referenced object.
This leads to spurious leak and use-after-free warnings.
For now, just ban destructors named '~shared_ptr', which catches
std::shared_ptr, std::tr1::shared_ptr, and boost::shared_ptr.
PR15987
llvm-svn: 182071
Benjamin Kramer