HTML diagnostics can be an overwhelming blob of pages of code.
This patch adds a checkbox which filters this list down to only the
lines *relevant* to the counterexample by e.g. skipping branches which
analyzer has assumed to be infeasible at a time.
The resulting amount of output is much smaller, and often fits on one
screen, and also provides a much more readable diagnostics.
Differential Revision: https://reviews.llvm.org/D41378
llvm-svn: 322612
Summary:
noload_lookups() was too lazy: in addition to avoiding external decls, it
avoided populating the lazy lookup structure for internal decls.
This is the right behavior for the existing callsite in ASTDumper, but I think
it's not a very useful default, so we populate it by default.
While here:
- remove an unused test file accidentally added in r322371.
- remove lookups_begin()/lookups_end() in favor of lookups().begin(), which is
more common and more efficient.
Reviewers: ilya-biryukov
Subscribers: cfe-commits, rsmith
Differential Revision: https://reviews.llvm.org/D42077
llvm-svn: 322548
Summary:
Introduce clang_getCursorPrettyPrinted() for pretty printing
declarations. Expose also PrintingPolicy, so the user gets more
fine-grained control of the entities being printed.
The already existing clang_getCursorDisplayName() is pretty limited -
for example, it does not handle return types, parameter names or default
arguments for function declarations. Addressing these issues in
clang_getCursorDisplayName() would mean to duplicate existing code
(e.g. clang::DeclPrinter), so rather expose new API to access the
existing functionality.
Reviewed By: jbcoe
Subscribers: cfe-commits
Tags: #clang
Patch by nik (Nikolai Kosjar)
Differential Revision: https://reviews.llvm.org/D39903
llvm-svn: 322540
The skipped preprocessor ranges are now serialized in the AST PCH file. This fixes, for example, libclang's clang_getSkippedRanges() returning zero ranges after reparsing a translation unit.
Differential Revision: https://reviews.llvm.org/D20124
llvm-svn: 322503
Summary:
This patch adds a FormatStyleSet for storing per-language FormatStyles for the
purposes of formatting code blocks inside the main code.
Reviewers: bkramer
Reviewed By: bkramer
Subscribers: klimek, djasper, bkramer, cfe-commits
Differential Revision: https://reviews.llvm.org/D41487
llvm-svn: 322479
While here, fix up the myriad other ways in which Sema's two "can this handler
catch that exception?" implementations get things wrong and unify them.
llvm-svn: 322431
As @rjmccall suggested in D40023, we can get rid of
ABIInfo::shouldSignExtUnsignedType (used to handle cases like the Mips calling
convention where 32-bit integers are always sign extended regardless of the
sign of the type) by adding a SignExt field to ABIArgInfo. In the common case,
this new field is set automatically by ABIArgInfo::getExtend based on the sign
of the type. For targets that want greater control, they can use
ABIArgInfo::getSignExtend or ABIArgInfo::getZeroExtend when necessary. This
change also cleans up logic in CGCall.cpp.
There is no functional change intended in this patch, and all tests pass
unchanged. As noted in D40023, Mips might want to sign-extend unsigned 32-bit
integer return types. A future patch might modify
MipsABIInfo::classifyReturnType to use MipsABIInfo::extendType.
Differential Revision: https://reviews.llvm.org/D41999
llvm-svn: 322396
getAssociatedStmt() returns the outermost captured statement for the
OpenMP directive. It may return incorrect region in case of combined
constructs. Reworked the code to reduce the number of calls of
getAssociatedStmt() and used getInnermostCapturedStmt() and
getCapturedStmt() functions instead.
In case of firstprivate variables it may lead to an extra allocas
generation for private copies even if the variable is passed by value
into outlined function and could be used directly as private copy.
llvm-svn: 322393
Summary:
Enumerating the contents of a namespace or global scope will omit any
decls that aren't already loaded, instead of deserializing them from the
PCH.
This allows a fast hybrid code completion where symbols from headers are
provided by an external index. (Sema already exposes the information
needed to do a reasonabl job of filtering them).
Clangd plans to implement this hybrid.
This option is just a hint - callers still need to postfilter results if
they want to *avoid* completing decls outside the main file.
Reviewers: bkramer, ilya-biryukov
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D41989
llvm-svn: 322371
Summary:
The STL types `std::pair` and `std::tuple` can both store reference types. However their constructors cannot adequately check if the initialization of reference types is safe. For example:
```
std::tuple<std::tuple<int> const&> t = 42;
// The stored reference is already dangling.
```
Libc++ has a best effort attempts in tuple to diagnose this, but they're not able to handle all valid cases (If I'm not mistaken). For example initialization of a reference from the result of a class's conversion operator. Libc++ would benefit from having a builtin traits which can provide a much better implementation.
This patch introduce the `__reference_binds_to_temporary(T, U)` trait that determines whether a reference of type `T` bound to an expression of type `U` would bind to a materialized temporary object.
Note that the trait simply returns false if `T` is not a reference type instead of reporting it as an error.
```
static_assert(__is_constructible(int const&, long));
static_assert(__reference_binds_to_temporary(int const&, long));
```
Reviewers: majnemer, rsmith
Reviewed By: rsmith
Subscribers: compnerd, cfe-commits
Differential Revision: https://reviews.llvm.org/D29930
llvm-svn: 322334
Summary:
Enable the compile-time flag -fsanitize-memory-use-after-dtor by
default. Note that the run-time option MSAN_OPTIONS=poison_in_dtor=1
still needs to be enabled for destructors to be poisoned.
Reviewers: eugenis, vitalybuka, kcc
Reviewed By: eugenis, vitalybuka
Subscribers: cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D37860
llvm-svn: 322221
Adds option /guard:cf to clang-cl and -cfguard to cc1 to emit function IDs
of functions that have their address taken into a section named .gfids$y for
compatibility with Microsoft's Control Flow Guard feature.
The original patch didn't have the lit.local.cfg file that restricts the new
test to x86, thus the new test was failing on the non-x86 bots.
Differential Revision: https://reviews.llvm.org/D40531
The reverts r322008, which was a revert of r322005.
This reverts commit a05b89f9aca70597dc79fe97bc49b50b51f525ba.
llvm-svn: 322136
Summary:
First, this patch fixes an assert failure when, for example, "omp for"
has num_teams.
Second, this patch prevents duplicate diagnostics when, for example,
"omp for" has uniform.
This patch makes the general assumption (even where it doesn't
necessarily fix an existing bug) that it is worthless to perform sema
for a clause that appears on a directive on which OpenMP does not
permit that clause. However, due to this assumption, this patch
suppresses some diagnostics that were expected in the test suite. I
assert that those diagnostics were likely just distracting to the
user.
Reviewers: ABataev
Reviewed By: ABataev
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D41841
llvm-svn: 322107
Cf-protection is a target independent flag that instructs the back-end to instrument control flow mechanisms like: Branch, Return, etc.
For example in X86 this flag will be used to instrument Indirect Branch Tracking instructions.
Differential Revision: https://reviews.llvm.org/D40478
Change-Id: I5126e766c0e6b84118cae0ee8a20fe78cc373dea
llvm-svn: 322063
Add attribute target multiversioning to the release notes.
Additionally adds multiversioning support to the attribute
documentation for 'target'.
Differential Revision: https://reviews.llvm.org/D41837
llvm-svn: 322043
GCC's attribute 'target', in addition to being an optimization hint,
also allows function multiversioning. We currently have the former
implemented, this is the latter's implementation.
This works by enabling functions with the same name/signature to coexist,
so that they can all be emitted. Multiversion state is stored in the
FunctionDecl itself, and SemaDecl manages the definitions.
Note that it ends up having to permit redefinition of functions so
that they can all be emitted. Additionally, all versions of the function
must be emitted, so this also manages that.
Note that this includes some additional rules that GCC does not, since
defining something as a MultiVersion function after a usage has been made illegal.
The only 'history rewriting' that happens is if a function is emitted before
it has been converted to a multiversion'ed function, at which point its name
needs to be changed.
Function templates and virtual functions are NOT yet supported (not supported
in GCC either).
Additionally, constructors/destructors are disallowed, but the former is
planned.
llvm-svn: 322028
This is not quite NFC: we don't perform the usual arithmetic conversions unless
we have an operand of arithmetic or enumeration type any more. This matches the
standard rule, but actually has no effect other than to marginally improve our
diagnostics for the non-arithmetic, non-enumeration cases (by not performing
integral promotions on one operand if the other is a pointer).
llvm-svn: 322024
The new test fails on the Hexagon bot. Reverting while I investigate.
This reverts https://reviews.llvm.org/rL322005
This reverts commit b7e0026b4385180c378edc658ec91a39566f2942.
llvm-svn: 322008
Adds option /guard:cf to clang-cl and -cfguard to cc1 to emit function IDs
of functions that have their address taken into a section named .gfids$y for
compatibility with Microsoft's Control Flow Guard feature.
Differential Revision: https://reviews.llvm.org/D40531
llvm-svn: 322005
Adds the -fstack-size-section flag to enable the .stack_sizes section. The flag defaults to on for the PS4 triple.
Differential Revision: https://reviews.llvm.org/D40712
llvm-svn: 321992
These just overloads for _Float128. They're supported by GCC 7 and used
by glibc. APFloat support is already there so just add the overloads.
__builtin_copysignf128
__builtin_fabsf128
__builtin_huge_valf128
__builtin_inff128
__builtin_nanf128
__builtin_nansf128
This is the same support that GCC has, according to the documentation,
but limited to _Float128.
llvm-svn: 321948
Attempting to recompute it are doomed to fail because the IDNS of a declaration
is not necessarily preserved across serialization and deserialization (in turn
because whether a friend declaration is visible depends on whether some prior
non-friend declaration exists).
llvm-svn: 321921
Summary:
Depends on https://reviews.llvm.org/D41732.
Utilities such as `opt`, when invoked with arguments that are very
nearly spelled correctly, suggest the correctly spelled options:
```
bin/opt -hel
opt: Unknown command line argument '-hel'. Try: 'bin/opt -help'
opt: Did you mean '-help'?
```
Clang, on the other hand, prior to this commit, does not:
```
bin/clang -hel
clang-6.0: error: unknown argument: '-hel'
```
This commit makes use of the new libLLVMOption API from
https://reviews.llvm.org/D41732 in order to provide correct suggestions:
```
bin/clang -hel
clang-6.0: error: unknown argument: '-hel', did you mean '-help'?
```
Test Plan: `check-clang`
Reviewers: yamaguchi, v.g.vassilev, teemperor, ruiu, bruno
Reviewed By: bruno
Subscribers: bruno, jroelofs, cfe-commits
Differential Revision: https://reviews.llvm.org/D41733
llvm-svn: 321917
Summary:
#pragma STDC FP_CONTRACT handler is only registered in parser so we
should keep the unknown STDC pragma through preprocessor and we also
should not emit warning for unknown STDC pragma during preprocessor.
rdar://problem/35724351
Reviewers: efriedma, rsmith, arphaman
Reviewed By: efriedma
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D41780
llvm-svn: 321909
This is a follow up to r321855, closing the gap between our internal shadow
modules implementation and upstream. It has been tested for longer and
provides a better approach for tracking shadow modules. Mostly NFCI.
rdar://problem/23612102
llvm-svn: 321906
Summary: Tool results are deduplicated by the result key.
Reviewers: hokein
Subscribers: klimek, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D41729
llvm-svn: 321864
As discussed in the mail thread <https://groups.google.com/a/isocpp.org/forum/
#!topic/std-discussion/T64_dW3WKUk> "Calling noexcept function throug non-
noexcept pointer is undefined behavior?", such a call should not be UB.
However, Clang currently warns about it.
This change removes exception specifications from the function types recorded
for -fsanitize=function, both in the functions themselves and at the call sites.
That means that calling a non-noexcept function through a noexcept pointer will
also not be flagged as UB. In the review of this change, that was deemed
acceptable, at least for now. (See the "TODO" in compiler-rt
test/ubsan/TestCases/TypeCheck/Function/function.cpp.)
To remove exception specifications from types, the existing internal
ASTContext::getFunctionTypeWithExceptionSpec was made public, and some places
otherwise unrelated to this change have been adapted to call it, too.
This is the cfe part of a patch covering both cfe and compiler-rt.
Differential Revision: https://reviews.llvm.org/D40720
llvm-svn: 321859
When modules come from module map files explicitly specified by
-fmodule-map-file= arguments, allow those to override/shadow modules
with the same name that are found implicitly by header search. If such a
module is looked up by name (e.g. @import), we will always find the one
from -fmodule-map-file. If we try to use a shadowed module by including
one of its headers report an error.
This enables developers to force use of a specific copy of their module
to be used if there are multiple copies that would otherwise be visible,
for example if they develop modules that are installed in the default
search paths.
Patch originally by Ben Langmuir,
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20151116/143425.html
Based on cfe-dev discussion:
http://lists.llvm.org/pipermail/cfe-dev/2015-November/046164.html
Differential Revision: https://reviews.llvm.org/D31269
rdar://problem/23612102
llvm-svn: 321855
each kind.
Attribute instantiation would previously default to instantiating each kind of
attribute only once. This was overridden by a flag whose intended purpose was
to permit attributes from a prior declaration to be inherited onto a new
declaration even if that new declaration had its own copy of the attribute.
This is the wrong behavior: when instantiating attributes from a template, we
should always instantiate all the attributes that were written on that
template.
This patch renames the flag in the Attr class (and TableGen sources) to more
clearly identify what it's actually for, and removes the usage of the flag from
template instantiation. I also removed the flag from AlignedAttr, which was
only added to work around the incorrect suppression of duplicate attribute
instantiation.
llvm-svn: 321834
This is useful for e.g. highlighting purposes in an IDE.
Note: First version of this patch was reverted due to failing tests in
opencl-types.cl with -target ppc64le-unknown-linux. These tests are
adapted now.
Patch by Nikolai Kosjar.
Differential Revision: https://reviews.llvm.org/D40072
llvm-svn: 321794
When modules come from module map files explicitly specified by
-fmodule-map-file= arguments, allow those to override/shadow modules
with the same name that are found implicitly by header search. If such a
module is looked up by name (e.g. @import), we will always find the one
from -fmodule-map-file. If we try to use a shadowed module by including
one of its headers report an error.
This enables developers to force use of a specific copy of their module
to be used if there are multiple copies that would otherwise be visible,
for example if they develop modules that are installed in the default
search paths.
Patch originally by Ben Langmuir,
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20151116/143425.html
Based on cfe-dev discussion:
http://lists.llvm.org/pipermail/cfe-dev/2015-November/046164.html
Differential Revision: https://reviews.llvm.org/D31269
rdar://problem/23612102
llvm-svn: 321781
a warning
This commit separates out the warn_nsconsumed_attribute_mismatch and
warn_nsreturns_retained_attribute_mismatch diagnostic into a warning and error.
This is needed to avoid a module import regression introduced by r313717 that
turned these errors into warnings and started promoting them only when needed,
which caused an error when importing a module as it had different warning
settings.
rdar://36265651
llvm-svn: 321775
This patch adds support to the attribute tablegen for specifying a [[]] attribute is allowed in C mode. This patch also adds the annotate attribute to the list of double square bracket attributes we support in C mode.
Eventually, I anticipate that this logic will be reversed (you have to opt out of allowing an attribute in C rather than opting in), but I want to see how the design plays out as more attributes are considered.
llvm-svn: 321763
This broke test/Index/opencl-types.cl on several buildbots:
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-lld/builds/3294http://lab.llvm.org:8011/builders/clang-ppc64be-linux-multistage/builds/6498http://lab.llvm.org:8011/builders/clang-ppc64le-linux-multistage/builds/5239
> [libclang] Support querying whether a declaration is invalid
>
> This is useful for e.g. highlighting purposes in an IDE.
>
> Patch by Nikolai Kosjar.
>
> Differential Revision: https://reviews.llvm.org/D40072
Also reverting follow-ups that otherwise caused conflicts for the
revert:
r321700 "Fix line endings."
r321701 "Fix more line endings."
r321698 "[libclang] Fix cursors for functions with trailing return type"
> For the function declaration
>
> auto foo5(Foo) -> Foo;
> the parameter tokens were mapped to cursors representing the
> FunctionDecl:
>
> Keyword: "auto" [1:1 - 1:5] FunctionDecl=test5:1:6
> Identifier: "test5" [1:6 - 1:11] FunctionDecl=test5:1:6
> Punctuation: "(" [1:11 - 1:12] FunctionDecl=test5:1:6
> Identifier: "X" [1:12 - 1:13] FunctionDecl=test5:1:6 // Ops, not a TypeRef
> Punctuation: ")" [1:13 - 1:14] FunctionDecl=test5:1:6
> Punctuation: "->" [1:15 - 1:17] FunctionDecl=test5:1:6
> Identifier: "X" [1:18 - 1:19] TypeRef=struct X:7:8
> Punctuation: ";" [1:19 - 1:20]
>
> Fix this by ensuring that the trailing return type is not visited as
> first.
>
> Patch by Nikolai Kosjar.
>
> Differential Revision: https://reviews.llvm.org/D40561
llvm-svn: 321708
This is useful for e.g. highlighting purposes in an IDE.
Patch by Nikolai Kosjar.
Differential Revision: https://reviews.llvm.org/D40072
llvm-svn: 321697
Summary:
The diagnostic was mostly introduced in D38101 by me, as a reaction to wasting a lot of time, see [[ https://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20171009/206427.html | mail ]].
However, the diagnostic is pretty dumb. While it works with no false-positives,
there are some questionable cases that are diagnosed when one would argue that they should not be.
The common complaint is that it diagnoses the comparisons between an `int` and
`long` when compiling for a 32-bit target as tautological, but not when
compiling for 64-bit targets. The underlying problem is obvious: data model.
In most cases, 64-bit target is `LP64` (`int` is 32-bit, `long` and pointer are
64-bit), and the 32-bit target is `ILP32` (`int`, `long`, and pointer are 32-bit).
I.e. the common pattern is: (pseudocode)
```
#include <limits>
#include <cstdint>
int main() {
using T1 = long;
using T2 = int;
T1 r;
if (r < std::numeric_limits<T2>::min()) {}
if (r > std::numeric_limits<T2>::max()) {}
}
```
As an example, D39149 was trying to fix this diagnostic in libc++, and it was not well-received.
This *could* be "fixed", by changing the diagnostics logic to something like
`if the types of the values being compared are different, but are of the same size, then do diagnose`,
and i even attempted to do so in D39462, but as @rjmccall rightfully commented,
that implementation is incomplete to say the least.
So to stop causing trouble, and avoid contaminating upcoming release, lets do this workaround:
* move these three diags (`warn_unsigned_always_true_comparison`, `warn_unsigned_enum_always_true_comparison`, `warn_tautological_constant_compare`) into it's own `-Wtautological-constant-in-range-compare`
* Disable them by default
* Make them part of `-Wextra`
* Additionally, give `warn_tautological_constant_compare` it's own flag `-Wtautological-type-limit-compare`.
I'm not happy about that name, but i can't come up with anything better.
This way all three of them can be enabled/disabled either altogether, or one-by-one.
Reviewers: aaron.ballman, rsmith, smeenai, rjmccall, rnk, mclow.lists, dim
Reviewed By: aaron.ballman, rsmith, dim
Subscribers: thakis, compnerd, mehdi_amini, dim, hans, cfe-commits, rjmccall
Tags: #clang
Differential Revision: https://reviews.llvm.org/D41512
llvm-svn: 321691
George Karpenkov