| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
with -Wconversion. // rdar://16502418
llvm-svn: 205646
|
|
|
|
|
|
| |
involving capabilities, the semantics for attributes now looks through the types of the constituent parts of a capability expression instead of at the aggregate expression type.
llvm-svn: 205629
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
better. This warning will now trigger on the following conditionals:
bool b;
int i;
if (b > 1) {} // always false
if (0 <= (i > 5)) {} // always true
if (-1 > b) {} // always false
Patch by Per Viberg.
llvm-svn: 205608
|
|
|
|
|
|
|
| |
as there is no way to attach this attribute to the
block literal. // rdar://16274746
llvm-svn: 205580
|
|
|
|
|
|
|
| |
(which indicates vector expression is a string of hex
values) instead of crashing in code gen. // rdar://16492792
llvm-svn: 205557
|
|
|
|
| |
llvm-svn: 205521
|
|
|
|
|
|
|
|
|
|
|
|
| |
at ... )')
For namespaces, this is consistent with mangling and GCC's debug info
behavior. For structs, GCC uses <anonymous struct> but we prefer
consistency between all anonymous entities but don't want to confuse
them with template arguments, etc, so we'll just go with parens in all
cases.
llvm-svn: 205398
|
|
|
|
|
|
|
|
|
| |
While investigating some debug info issues, Eric and I came across a
particular template case where the location of a decl was quite
different from the range of the same decl. It might've been rather
helpful if the dumper had actually showed us this.
llvm-svn: 205396
|
|
|
|
|
|
| |
Instead of using terminology such as "lock", "unlock" and "locked", the new terminology is "acquire", "release" and "held". Additionally, the capability attribute's name argument is now reported as part of the diagnostic, instead of hard coding as "mutex."
llvm-svn: 205359
|
|
|
|
|
|
|
|
| |
argument parsing code.
This removes a diagnostic that is no longer required (the semantic engine now properly handles attribute syntax so __declspec and __attribute__ spellings no longer get mismatched). This caused several testcases to need updating for a slightly different wording.
llvm-svn: 205234
|
|
|
|
| |
llvm-svn: 205198
|
|
|
|
|
|
|
| |
A redeclaration may not add dllimport or dllexport attributes. dllexport is
sticky and can be omitted on redeclarations while dllimport cannot.
llvm-svn: 205197
|
|
|
|
|
|
|
|
|
|
|
| |
This adds Clang support for the ARM64 backend. There are definitely
still some rough edges, so please bring up any issues you see with
this patch.
As with the LLVM commit though, we think it'll be more useful for
merging with AArch64 from within the tree.
llvm-svn: 205100
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
intentionally marked dead via if((0)).
Taking a hint from -Wparentheses, use an extra '()' as a sigil that
a dead condition is intentionally dead. For example:
if ((0)) { dead }
When this sigil is found, do not emit a dead code warning. When the
analysis sees:
if (0)
it suggests inserting '()' as a Fix-It.
llvm-svn: 205069
|
|
|
|
|
|
|
| |
This produces valid IR now that llvm rejects aliases to weak aliases and warns
the user that the resolution is not changed if the weak alias is overridden.
llvm-svn: 204935
|
|
|
|
| |
llvm-svn: 204872
|
|
|
|
|
|
|
|
|
|
| |
The main difference between __va_start and __builtin_va_start is that
the address of the va_list has already been taken, and the va_list is
always a char*.
__va_end and __va_arg are not needed.
llvm-svn: 204821
|
|
|
|
|
|
| |
as a structure declaration. This allows for C code to use Boolean expressions on a capability as part of another attribute. Eg) __attribute__((requires_capability(!SomeCapability)))
llvm-svn: 204657
|
|
|
|
|
|
| |
Proper redeclaration warnings for dllimport are not implemented yet.
llvm-svn: 204577
|
|
|
|
|
|
|
| |
dllimport implies a definition which means the 'extern' keyword is optional
when declaring imported variables.
llvm-svn: 204576
|
|
|
|
|
|
| |
release_generic_capability functions are now functionally distinct for capability analysis. The unlock_function attribute maps directly to release_generic_capability.
llvm-svn: 204469
|
|
|
|
| |
llvm-svn: 204413
|
|
|
|
|
|
|
|
| |
unlock_function attributes with the acquire_capability and release_capability attributes. The old spellings will continue to work, but the underlying semantic attributes have been replaced.
Downgraded the capability diagnostics from error to warning to match the desired behavior, and updated the existing test cases.
llvm-svn: 204350
|
|
|
|
|
|
|
|
|
|
|
|
| |
Amends r204300 to not try to test fixing a wchar_t* to "%ls", which we don't
do correctly anyway. In C mode, wchar_t is just a typedef for a normal
primitive integer type, not a distinct type like it is in C++. To make this
work correctly, we'll need to look for the wchar_t typedef, not just the
builtin type.
Should fix the buildbots.
llvm-svn: 204349
|
|
|
|
|
|
| |
win32.
llvm-svn: 204334
|
|
|
|
|
|
| |
Patch by Zach Davis!
llvm-svn: 204300
|
|
|
|
|
|
|
|
| |
parameters
Patch by Joe Ranieri.
llvm-svn: 204235
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since "half" is an OpenCL keyword and clang accepts __fp16 as an extension for
other languages, error messages and metadata (and hence debug info) should refer
to the half-precision floating point as "__fp16" instead of "half" when
compiling for non-OpenCL languages. This patch creates a new printing policy for
half in a similar manner to what is done for bool and wchar_t.
Differential Revision: http://llvm-reviews.chandlerc.com/D2952
llvm-svn: 204164
|
|
|
|
|
|
|
|
|
|
| |
doesn't turn off all unreachable code warnings.
Also relax unreachable 'break' and 'return' to not check for being
preceded by a call to 'noreturn'. That turns out to not be so
interesting in practice.
llvm-svn: 204000
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Recent work on -Wunreachable-code has focused on suppressing uninteresting
unreachable code that center around "configuration values", but
there are still some set of cases that are sometimes interesting
or uninteresting depending on the codebase. For example, a dead
"break" statement may not be interesting for a particular codebase,
potentially because it is auto-generated or simply because code
is written defensively.
To address these workflow differences, -Wunreachable-code is now
broken into several diagnostic groups:
-Wunreachable-code: intended to be a reasonable "default" for
most users.
and then other groups that turn on more aggressive checking:
-Wunreachable-code-break: warn about dead break statements
-Wunreachable-code-trivial-return: warn about dead return statements
that return "trivial" values (e.g., return 0). Other return
statements that return non-trivial values are still reported
under -Wunreachable-code (this is an area subject to more refinement).
-Wunreachable-code-aggressive: supergroup that enables all these
groups.
The goal is to eventually make -Wunreachable-code good enough to
either be in -Wall or on-by-default, thus finessing these warnings
into different groups helps achieve maximum signal for more users.
TODO: the tests need to be updated to reflect this extra control
via diagnostic flags.
llvm-svn: 203994
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Someone could write:
if (0) {
__c11_atomic_load(ptr, memory_order_release);
}
or the equivalent, which is perfectly valid, so we shouldn't outright reject
invalid orderings on purely static grounds.
rdar://problem/16242991
llvm-svn: 203564
|
|
|
|
|
|
|
|
|
| |
This is a conservative check, because it's valid for the expression to be
non-constant, and in cases like that we just don't know whether it's valid.
rdar://problem/16242991
llvm-svn: 203561
|
|
|
|
|
|
|
| |
-Wunused-comparison. Also, newly warn on unused result from overloaded
relational comparisons, now also in -Wunused-comparison.
llvm-svn: 203535
|
|
|
|
|
|
| |
'noreturn' function.
llvm-svn: 203333
|
|
|
|
| |
llvm-svn: 203302
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-Wunreachable-code.
I had forgotten that the same reachability code is used by both -Wreturn-type
and -Wunreachable-code, so the heuristics applied to the latter were indirectly
impacting the former.
To address this, the reachability code is more refactored so that whiled
the logic at its core is shared, the intention of the clients are better
captured and segregated in helper APIs.
Fixes PR19074, and also some false positives reported offline to me
by Nick Lewycky.
llvm-svn: 203209
|
|
|
|
|
|
| |
and '||' branches involving configuration values.
llvm-svn: 203194
|
|
|
|
|
|
| |
literal types.
llvm-svn: 203193
|
|
|
|
|
|
|
|
| |
getTypeSize (which rounds up sizes) in order to issue diagnostics
when casting to mismatched vector sizes; instead of crashing in IRGen.
// rdar:// 16196902. Reviewed offline by John McCall.
llvm-svn: 203175
|
|
|
|
| |
llvm-svn: 203147
|
|
|
|
|
|
| |
which includes those with all cases covered but with no 'default:'.
llvm-svn: 203094
|
|
|
|
|
|
|
|
|
|
| |
condition.
Sometimes do..while() is used to create a scope that can be left early.
In such cases, the unreachable 'while()' test is not usually interesting
unless it actually does something that is observable.
llvm-svn: 203051
|
|
|
|
|
|
|
|
|
|
| |
condition.
Sometimes do..while() is used to create a scope that can be left early.
In such cases, the unreachable 'while()' test is not usually interesting
unless it actually does something that is observable.
llvm-svn: 203036
|
|
|
|
|
|
|
|
| |
Previously we only pruned dead returns preceded by a call to a
'noreturn' function. After looking at the results of the LLVM codebase,
there are many others that should be pruned as well.
llvm-svn: 203029
|
|
|
|
| |
llvm-svn: 203027
|
|
|
|
|
|
| |
heuristic
llvm-svn: 203026
|
|
|
|
|
|
| |
comparison operators.
llvm-svn: 203016
|
|
|
|
|
|
|
|
| |
is being annotated. There are currently only two supported names: mutex and role. Adding functionality to check for the capability name and diagnose when it's unexpected.
Note that for backwards compatibility, an unnamed capability will default to being a "mutex." This allows the deprecated lockable attribute to continue to function.
llvm-svn: 203012
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
value".
Some unreachable code is only "sometimes unreachable" because it
is guarded by a configuration value that is determined at compile
time and is always constant. Sometimes those represent real bugs,
but often they do not. This patch causes the reachability analysis
to cover such branches even if they are technically unreachable
in the CFG itself. There are some conservative heuristics at
play here to determine a "configuration value"; these are intended
to be refined over time.
llvm-svn: 202912
|
|
|
|
| |
llvm-svn: 202866
|