Better controls the inlining of functions when the caller function has MinSize attribute.
Basically, when the caller function has this attribute, we do not "force" the inlining
of callee functions carrying the InlineHint attribute (i.e., functions defined with
inline keyword)
llvm-svn: 170065
Also add an MIBundleBuilder constructor that takes an existing bundle.
Together these functions make it possible to add instructions to
existing bundles.
llvm-svn: 170063
This is a Band-Aid fix to a false positive, where we complain about not
initializing self to [super init], where self is not coming from the
init method, but is coming from the caller to init.
The proper solution would be to associate the self and it's state with
the enclosing init.
llvm-svn: 170059
This still isn't quite right, but it fixes a crash.
I factored out findCommonParent because we need it on the result of
getImmediateExpansionRange: for a function macro, the beginning
and end of an expansion range can come out of different
macros/macro arguments, which means the resulting range is a complete
mess to handle consistently.
I also made some changes to how findCommonParent works; it works somewhat
better in some cases, and somewhat worse in others, but I think overall
it's a better balance. I'm coming to the conclusion that mapDiagnosticRanges
isn't using the right algorithm, though: chasing the caret is fundamentally
more complicated than any algorithm which only considers one FileID for the
caret can handle because each SourceLocation doesn't really have a single parent.
We need to follow the same path of choosing expansion locations and spelling
locations which the caret used to come up with the correct range
in the general case.
Fixes <rdar://problem/12847524>.
llvm-svn: 170049
Converts:
LanguageExtensions
LibASTMatchers
LibTooling
PCHInternals
ThreadSanitizer
Tooling
Patch by Mykhailo Pustovit!
(with minor edits by Dmitri Gribenko and Sean Silva)
llvm-svn: 170048
I don't think this will be visible just yet on <clang.llvm.org/docs/>
since I don't think that the necessary server-side setup has taken
place.
Don't shoot me over the theme. I don't want to duplicate LLVM's theme
into the clang repo at the moment, so I just used one of Sphinx's
default themes.
llvm-svn: 170042
has inconsistent ownership with the backing ivar, point the error location to the
ivar.
Pointing to the ivar (instead of the @synthesize) is better since this is where a fix is needed.
Also provide the location of @synthesize via a note.
This also fixes the problem where an auto-synthesized property would emit an error without
any location.
llvm-svn: 170039
should only occur on invalid input. Instruction matching errors aren't
unexpected, so we can't rely on the AsmParsers HadError variable directly.
rdar://12840278
llvm-svn: 170037
My variadics patch, r169588, changed these calls to typically be
bitcasts rather than calls to a supposedly variadic function.
This totally subverted a hack where we intentionally dropped
excess arguments from such calls in order to appease the inliner
and a "warning" from the optimizer. This patch extends the hack
to also work with bitcasts, as well as teaching it to rewrite
invokes.
llvm-svn: 170034