I made some small changes in smmintrin.h and emmintrin.h intrinsics.
- changed some regular comments '//' into doxygen-style comments '///' where necessary
- removed some trailing spaces in doxygen comments.
I got an OK from Eric Christopher to commit doxygen comments without prior code
review upstream.
llvm-svn: 298371
Summary: I added a new rank to ImplicitConversionRank enum to resolve the function overload ambiguity with vector types. Rank of scalar types conversion is lower than vector splat. So, we can choose which function should we call. See test for more details.
Reviewers: Anastasia, cfe-commits
Reviewed By: Anastasia
Subscribers: bader, yaxunl
Differential Revision: https://reviews.llvm.org/D30816
llvm-svn: 298366
This commit adds support for a new attribute that will be used to
distinguish between extensible and inextensible enums. There are three
main purposes of this attribute:
1. Give better control over when enum-related warnings are issued.
For example, in the code below, clang will not issue a -Wassign-enum
warning if the enum is marked "open":
enum __attribute__((enum_extensibility(closed))) EnumClosed {
B0 = 1, B1 = 10
};
enum __attribute__((enum_extensibility(open))) EnumOpen {
C0 = 1, C1 = 10
};
enum EnumClosed ec = 100; // warning issued
enum EnumOpen eo = 100; // no warning
2. Enable code-completion and debugging tools to offer better
suggestions.
3. Make it easier for swift's clang importer to determine which swift
type an enum should be mapped to.
For more details, see the discussion I started on cfe-dev:
http://lists.llvm.org/pipermail/cfe-dev/2017-February/052748.html
rdar://problem/12764379
rdar://problem/23145650
Differential Revision: https://reviews.llvm.org/D30766
llvm-svn: 298332
Setting dllexport on a declaration has no effect, as we do not emit export
directives for declarations.
Part of the fix for PR32334.
Differential Revision: https://reviews.llvm.org/D31162
llvm-svn: 298330
In doing so, clean up the MD5 interface a little. Most
existing users only care about the lower 8 bytes of an MD5,
but for some users that care about the upper and lower,
there wasn't a good interface. Furthermore, consumers
of the MD5 checksum were required to handle endianness
details on their own, so it seems reasonable to abstract
this into a nicer interface that just gives you the right
value.
Differential Revision: https://reviews.llvm.org/D31105
llvm-svn: 298322
- Fix a variable naming mismatch
- Fix gcc extension pointer arithmetic on void to cast to char *.
- Test that the header (and htmintrin.h) parse.
llvm-svn: 298318
PR32346 suggests that UBSan's docs about the -fsanitize,
-fno-sanitize-recover, and -fsanitize-trap options are not explicit
enough. Try to improve the wording.
llvm-svn: 298310
This reverts commit r298185, effectively reapplying r298165, after fixing the
new unit tests (PR32338). The memory buffer generator doesn't null-terminate
the MemoryBuffer it creates; this version of the commit informs getMemBuffer
about that to avoid the assert.
Original commit message follows:
----
Clang's internal build system for implicit modules uses lock files to
ensure that after a process writes a PCM it will read the same one back
in (without contention from other -cc1 commands). Since PCMs are read
from disk repeatedly while invalidating, building, and importing, the
lock is not released quickly. Furthermore, the LockFileManager is not
robust in every environment. Other -cc1 commands can stall until
timeout (after about eight minutes).
This commit changes the lock file from being necessary for correctness
to a (possibly dubious) performance hack. The remaining benefit is to
reduce duplicate work in competing -cc1 commands which depend on the
same module. Follow-up commits will change the internal build system to
continue after a timeout, and reduce the timeout. Perhaps we should
reconsider blocking at all.
This also fixes a use-after-free, when one part of a compilation
validates a PCM and starts using it, and another tries to swap out the
PCM for something new.
The PCMCache is a new type called MemoryBufferCache, which saves memory
buffers based on their filename. Its ownership is shared by the
CompilerInstance and ModuleManager.
- The ModuleManager stores PCMs there that it loads from disk, never
touching the disk if the cache is hot.
- When modules fail to validate, they're removed from the cache.
- When a CompilerInstance is spawned to build a new module, each
already-loaded PCM is assumed to be valid, and is frozen to avoid
the use-after-free.
- Any newly-built module is written directly to the cache to avoid the
round-trip to the filesystem, making lock files unnecessary for
correctness.
Original patch by Manman Ren; most testcases by Adrian Prantl!
llvm-svn: 298278
The comment about there being three different forms that Ptr represents was stale. Also, the opaque value does not need to be exposed (these functions are unused).
llvm-svn: 298215
Duncan's r298165 introduced the PCMCache mechanism, which guarantees
that locks aren't necessary anymore for correctness but only for
performance, by avoiding building it twice when possible.
Change the logic to avoid an error but actually build the module in case
the timeout happens. Instead of an error, still emit a remark for
debugging purposes.
rdar://problem/30297862
llvm-svn: 298175
Clang's internal build system for implicit modules uses lock files to
ensure that after a process writes a PCM it will read the same one back
in (without contention from other -cc1 commands). Since PCMs are read
from disk repeatedly while invalidating, building, and importing, the
lock is not released quickly. Furthermore, the LockFileManager is not
robust in every environment. Other -cc1 commands can stall until
timeout (after about eight minutes).
This commit changes the lock file from being necessary for correctness
to a (possibly dubious) performance hack. The remaining benefit is to
reduce duplicate work in competing -cc1 commands which depend on the
same module. Follow-up commits will change the internal build system to
continue after a timeout, and reduce the timeout. Perhaps we should
reconsider blocking at all.
This also fixes a use-after-free, when one part of a compilation
validates a PCM and starts using it, and another tries to swap out the
PCM for something new.
The PCMCache is a new type called MemoryBufferCache, which saves memory
buffers based on their filename. Its ownership is shared by the
CompilerInstance and ModuleManager.
- The ModuleManager stores PCMs there that it loads from disk, never
touching the disk if the cache is hot.
- When modules fail to validate, they're removed from the cache.
- When a CompilerInstance is spawned to build a new module, each
already-loaded PCM is assumed to be valid, and is frozen to avoid
the use-after-free.
- Any newly-built module is written directly to the cache to avoid the
round-trip to the filesystem, making lock files unnecessary for
correctness.
Original patch by Manman Ren; most testcases by Adrian Prantl!
llvm-svn: 298165
Summary:
3.4.6 [basic.lookup.udir] paragraph 1:
In a using-directive or namespace-alias-definition, during the lookup for a namespace-name or for a name in a nested-name-specifier, only namespace names are considered.
Reviewers: rsmith, aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D30848
llvm-svn: 298126
clang-cl works best when the user runs vcvarsall to set up
an environment before running, but even this is not enough
on VC 2017 when cross compiling (e.g. using an x64 toolchain
to target x86, or vice versa).
The reason is that although clang-cl itself will have a
valid environment, it will shell out to other tools (such
as link.exe) which may not. Generally we solve this through
adding the appropriate linker flags, but this is not enough
in VC 2017.
The cross-linker and the regular linker both link against
some common DLLs, but these DLLs live in the binary directory
of the native linker. When setting up a cross-compilation
environment through vcvarsall, it will add *both* directories
to %PATH%, so that when cl shells out to any of the associated
tools, those tools will be able to find all of the dependencies
that it links against. If you don't do this, link.exe will
fail to run because the loader won't be able to find all of
the required DLLs that it links against.
To solve this we teach the driver how to spawn a process with
an explicitly specified environment. Then we modify the
PATH before shelling out to subtools and run with the modified
PATH.
Patch by Hamza Sood
Differential Revision: https://reviews.llvm.org/D30991
llvm-svn: 298098
Reapply r289181 but rename the include guard to avoid
conflict with the one from Darwin.
Allow darwin to provide additional definitions and implementation
specifc values for tgmath.h on Apple platforms.
rdar://problem/19019845
llvm-svn: 298013
This enhances the AST to keep track of locations of the names in those ObjC property attributes, and reports them for indexing.
Patch by Nathan Hawes!
https://reviews.llvm.org/D30907
llvm-svn: 297972
The instance method 'self' does not actually return an over-retained object,
so we shouldn't report an error when it's used with 'performSelector'.
rdar://31071620
llvm-svn: 297961
clang-format treats MSVC `__super` keyword like all other keywords adding
a single space after. This change disables this behavior for `__super`.
Patch originally by jutocz (thanks!).
Differential Revision: https://reviews.llvm.org/D30932
llvm-svn: 297936
a) avoid actually compiling anything
b) avoid depositing files in the test directory
c) use a check line to make sure that we're looking for the correct behavior
llvm-svn: 297917
Currently the two flags can not work together.
To illustrate the issue, we can have an one line file a.cl contains only an empty function
cat a.cl
void test(){}
Then use
clang -v -save-temps -x cl -Xclang -cl-std=CL2.0 -Xclang -finclude-default-header -target amdgcn -S -c a.cl
we will get redefinition errors for various things.
The reason is that the -finclude-default-header flag is not meant to be on cc1 command other than the preprocessor.
The fix is modeled after the code just below the change to filter the -finclude-default-header flag out when we are not in the preprocess phase.
Differential Revision: https://reviews.llvm.org/D30743
llvm-svn: 297890
-m(i|tv|watch)os-simulator-version-min is on the command line.
Previously the driver would treat -m(i|tv|watch)os-simulator-version-min
as an alias of -m(i|tv|watch)os-version-min. This no longer works since
we now need to distinguish between the two options (the latter is used
for iOS running in a VM, for example).
This commit stops making the simulator options the aliases of the OS
options and defines a macro to differentiate between the two groups of
options.
rdar://problem/28872911
llvm-svn: 297866
instance of a qualified Class object when that instance method comes from
a protocol that's implemented by NSObject
Instance methods from a root class like NSObject are also class methods because
the metaclass of root class derives from that root class. Therefore, we can
avoid the warning for instances of qualified Class objects that point to classes
that derive from NSObject. Note that we actually don't know if a Class instance
points to a class that derives from NSObject at compile-time, so we have to
make a reasonable assumption that the majority of instances will do so.
rdar://22812517
llvm-svn: 297862
When this test runs on bots that are configured to default
to MSVC, but MSVC isn't actually installed, we can emit a
warning that MSVC is not found. Since MSVC isn't actually
needed for this test to succeed, just disable this warning.
llvm-svn: 297858
2017 changes the way you find an installed copy of
Visual Studio as well as its internal directory layout.
As a result, clang-cl was unable to find VS2017 even
when you had run vcvarsall to set up a toolchain
environment. This patch updates everything for 2017
and cleans up the way we handle a tiered search a la
environment -> installation -> PATH for which copy
of Visual Studio to bind to.
Patch originally by Hamza Sood, with some fixups for landing.
Differential Revision: https://reviews.llvm.org/D30758
llvm-svn: 297851
The way -ffast-math and the various related options to tweak floating-point
handling are handled is inflexible and rather confusing. This patch restructures
things so that we go through the options adjusting our idea of what's enabled as
we go, instead of trying to figure each individual thing out by working
backwards from the end, as this makes the behaviour of each individual option
more clear.
Doing it this way also means we get gcc-compatible behaviour for when the
__FAST_MATH__ and __FINITE_MATH_ONLY__ macros are defined, as they should depend
on the final set of features that are enabled and not just on -ffast-math and
-ffinite-math-only specifically.
Differential Revision: http://reviews.llvm.org/D30582
llvm-svn: 297837
This fixes lookup mismatches that could happen when the module cache
path contained a '/./' component.
<rdar://problem/30413458>
Differential Revision: https://reviews.llvm.org/D30915
llvm-svn: 297790
Since bitcode uses VBR encoding, large numbers are more expensive than
small ones. Instead of emitting a UINT_MAX sentinel after each sequence
of state-change pairs, emit the size of the sequence as a prefix.
This should have no functionality change besides saving bits from the
encoding.
llvm-svn: 297770
This adds -Wbitfield-enum-conversion, which warns on implicit
conversions that happen on bitfield assignment that change the value of
some enumerators.
Values of enum type typically take on a very small range of values, so
they are frequently stored in bitfields. Unfortunately, there is no
convenient way to calculate the minimum number of bits necessary to
store all possible values at compile time, so users usually hard code a
bitwidth that works today and widen it as necessary to pass basic
testing and validation. This is very error-prone, and leads to stale
widths as enums grow. This warning aims to catch such bugs.
This would have found two real bugs in clang and two instances of
questionable code. See r297680 and r297654 for the full description of
the issues.
This warning is currently disabled by default while we investigate its
usefulness outside of LLVM.
The major cause of false positives with this warning is this kind of
enum:
enum E { W, X, Y, Z, SENTINEL_LAST };
The last enumerator is an invalid value used to validate inputs or size
an array. Depending on the prevalance of this style of enum across a
codebase, this warning may be more or less feasible to deploy. It also
has trouble on sentinel values such as ~0U.
Reviewers: rsmith, rtrieu, thakis
Reviewed By: thakis
Subscribers: hfinkel, voskresensky.vladimir, sashab, cfe-commits
Differential Revision: https://reviews.llvm.org/D30923
llvm-svn: 297761
Summary: Fix the test by adding missing -target flags with a 'linux' triple.
Reviewers: rnk, srhines
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D30947
llvm-svn: 297754
Summary:
This patch adds -f[no-]rtlib-add-rpath, which if enabled, embeds the
arch-specific subdirectory in resource directory using -rpath (instead
of doing so only during native compilation).
This patch also re-enables test arch-specific-libdir.c which was
silently unsupported because of the REQUIRES tag 'linux'.
Reviewers: bkramer, rnk, mgorny
Subscribers: srhines, cfe-commits
Differential Revision: https://reviews.llvm.org/D30700
llvm-svn: 297751
This is a follow-up to r297700 (Add a nullability sanitizer).
It addresses some FIXME's re: using nullability-specific diagnostic
handlers from compiler-rt, now that the necessary handlers exist.
check-ubsan test updates to follow.
llvm-svn: 297750
Teach UBSan to detect when a value with the _Nonnull type annotation
assumes a null value. Call expressions, initializers, assignments, and
return statements are all checked.
Because _Nonnull does not affect IRGen, the new checks are disabled by
default. The new driver flags are:
-fsanitize=nullability-arg (_Nonnull violation in call)
-fsanitize=nullability-assign (_Nonnull violation in assignment)
-fsanitize=nullability-return (_Nonnull violation in return stmt)
-fsanitize=nullability (all of the above)
This patch builds on top of UBSan's existing support for detecting
violations of the nonnull attributes ('nonnull' and 'returns_nonnull'),
and relies on the compiler-rt support for those checks. Eventually we
will need to update the diagnostic messages in compiler-rt (there are
FIXME's for this, which will be addressed in a follow-up).
One point of note is that the nullability-return check is only allowed
to kick in if all arguments to the function satisfy their nullability
preconditions. This makes it necessary to emit some null checks in the
function body itself.
Testing: check-clang and check-ubsan. I also built some Apple ObjC
frameworks with an asserts-enabled compiler, and verified that we get
valid reports.
Differential Revision: https://reviews.llvm.org/D30762
llvm-svn: 297700
This prevents unwanted fallout from r296664. Specifically in proto formatting,
this changed:
optional Aaaaaaaa aaaaaaaa = 12 [
(aaa) = aaaa,
(bbbbbbbbbbbbbbbbbbbbbbbbbb) = {
aaaaaaaaaaaaaaaaa: true,
aaaaaaaaaaaaaaaa: true
}
];
Into:
optional Aaaaaaaa aaaaaaaa = 12 [
(aaa) = aaaa,
(bbbbbbbbbbbbbbbbbbbbbbbbbb) =
{aaaaaaaaaaaaaaaaa: true, aaaaaaaaaaaaaaaa: true}
];
Which is considered less readable. Generally, it seems preferable to
format such dict literals as blocks rather than contract them to one
line.
llvm-svn: 297696
Modified the tests to accept any iteration order, to run only on Unix, and added
additional error reporting to investigate SystemZ bot issue.
The VFS directory iterator and recursive directory iterator behave differently
from the LLVM counterparts. Once the VFS iterators hit a broken symlink they
immediately abort. The LLVM counterparts don't stat entries unless they have to
descend into the next directory, which allows to recover from this issue by
clearing the error code and skipping to the next entry.
This change adds similar behavior to the VFS iterators. There should be no
change in current behavior in the current CLANG source base, because all
clients have loop exit conditions that also check the error code.
This fixes rdar://problem/30934619.
Differential Revision: https://reviews.llvm.org/D30768
llvm-svn: 297693
All of these were found by a new warning that I am prototyping,
-Wbitfield-enum-conversion.
Stmt::ExprBits::ObjectKind - This was not wide enough to represent
OK_ObjSubscript, so this was a real, true positive bug.
ObjCDeclSpec::objCDeclQualifier - On Windows, setting DQ_CSNullability
would cause the bitfield to become negative because enum types are
always implicitly 'int' there. This would probably never be noticed
because this is a flag-style enum, so we only ever test one bit at a
time. Switching to 'unsigned' also makes this type pack smaller on
Windows.
FunctionDecl::SClass - Technically, we only need two bits for all valid
function storage classes. Functions can never have automatic or register
storage class. This seems a bit too clever, and we have a bit to spare,
so widening the bitfield seems like the best way to pacify the warning.
You could classify this as a false positive, but widening the bitfield
defends us from invalid ASTs.
llvm-svn: 297680
We can't actually pretend that 0 is valid for address space 0.
r295877 added a workaround to stop allocating user objects
there, so we can use 0 as the invalid pointer.
Some of the tests seemed to be using private as the non-0 null
test address space, so add copies using local to make sure
this is still stressed.
llvm-svn: 297659
Change ASTFileSignature from a random 32-bit number to the hash of the
PCM content.
- Move definition ASTFileSignature to Basic/Module.h so Module and
ASTSourceDescriptor can use it.
- Change the signature from uint64_t to std::array<uint32_t,5>.
- Stop using (saving/reading) the size and modification time of PCM
files when there is a valid SIGNATURE.
- Add UNHASHED_CONTROL_BLOCK, and use it to store the SIGNATURE record
and other records that shouldn't affect the hash. Because implicit
modules reuses the same file for multiple levels of -Werror, this
includes DIAGNOSTIC_OPTIONS and DIAG_PRAGMA_MAPPINGS.
This helps to solve a PCH + implicit Modules dependency issue: PCH files
are handled by the external build system, whereas implicit modules are
handled by internal compiler build system. This prevents invalidating a
PCH when the compiler overwrites a PCM file with the same content
(modulo the diagnostic differences).
Design and original patch by Manman Ren!
llvm-svn: 297655
The only valid values for scale immediate of scatter/gather builtins are 1, 2, 4, or 8. This patch enforces this in the frontend otherwise we generate invalid instruction encodings in the backend.
Differential Revision: https://reviews.llvm.org/D30875
llvm-svn: 297642
Given that we have already explicitly stated in the qualifier that the
expression is __unaligned, it makes little sense to diagnose that the address
of the packed member may not be aligned.
Differential Revision: https://reviews.llvm.org/D30884
llvm-svn: 297620
It looks like on some host-triples the result of a valist related expr can be
a LazyCompoundVal. Handle that case in the check.
Patch by Abramo Bagnara!
llvm-svn: 297619
This commit adds support for a new -iframeworkwithsysroot compiler option which
allows the user to specify a framework path that can be prefixed with the
sysroot. This option is similar to the -iwithsysroot option that exists to
supplement -isystem.
rdar://21316352
Differential Revision: https://reviews.llvm.org/D30183
llvm-svn: 297614
Summary:
@see is special among JSDoc tags in that it is commonly followed by URLs. The JSDoc spec suggests that users should wrap URLs in an additional {@link url...} tag (@see http://usejsdoc.org/tags-see.html), but this is very commonly violated, with @see being followed by a "naked" URL.
This change special cases all JSDoc lines that contain an @see not to be wrapped to account for that.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D30883
llvm-svn: 297607
Summary:
Previously clang-format would not break after any !. However in TypeScript, ! can be used as a post fix operator for non-nullability:
x.foo()!.bar()!;
With this change, clang-format will wrap after the ! if it is likely a post-fix non null operator.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D30705
llvm-svn: 297606
Summary:
`interface` and `type` are pseudo keywords and cause automatic semicolon
insertion when followed by a line break:
interface // gets parsed as a long variable access to "interface"
VeryLongInterfaceName {
}
With this change, clang-format not longer wraps after `interface` or `type`.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D30874
llvm-svn: 297605
x86 has undef SSE/AVX intrinsics that should represent a bogus register operand.
This is not the same as LLVM's undef value which can take on multiple bit patterns.
There are better solutions / follow-ups to this discussed here:
https://bugs.llvm.org/show_bug.cgi?id=32176
...but this should prevent miscompiles with a one-line code change.
Differential Revision: https://reviews.llvm.org/D30834
llvm-svn: 297588
Summary:
Some coroutine diagnostics need to point to the location of the first coroutine keyword in the function, like when diagnosing a `return` inside a coroutine. Previously we did this by storing each *valid* coroutine statement in a list and select the first one to use in diagnostics. However if every coroutine statement is invalid we would have no location to point to.
This patch fixes the storage of the first coroutine statement location, ensuring that it gets stored even when the resulting AST node would be invalid.
This patch also removes the `CoroutineStmts` list in `FunctionScopeInfo` because it was unused.
Reviewers: rsmith, GorNishanov, aaron.ballman
Reviewed By: GorNishanov
Subscribers: mehdi_amini, cfe-commits
Differential Revision: https://reviews.llvm.org/D30776
llvm-svn: 297547
Summary:
Create only one OpaqueValue for await_ready/await_suspend/await_resume.
Store OpaqueValue used in the CoroutineSuspendExpr node, so that CodeGen does not have to hunt looking for it.
Reviewers: rsmith, EricWF, aaron.ballman
Reviewed By: EricWF
Subscribers: mehdi_amini, cfe-commits
Differential Revision: https://reviews.llvm.org/D30775
llvm-svn: 297541
Modified the tests to accept any iteration order.
The VFS directory iterator and recursive directory iterator behave differently
from the LLVM counterparts. Once the VFS iterators hit a broken symlink they
immediately abort. The LLVM counterparts allow to recover from this issue by
clearing the error code and skipping to the next entry.
This change adds the same functionality to the VFS iterators. There should be
no change in current behavior in the current CLANG source base, because all
clients have loop exit conditions that also check the error code.
This fixes rdar://problem/30934619.
Differential Revision: https://reviews.llvm.org/D30768
llvm-svn: 297528
The VFS directory iterator and recursive directory iterator behave differently
from the LLVM counterparts. Once the VFS iterators hit a broken symlink they
immediately abort. The LLVM counterparts allow to recover from this issue by
clearing the error code and skipping to the next entry.
This change adds the same functionality to the VFS iterators. There should be
no change in current behavior in the current CLANG source base, because all
clients have loop exit conditions that also check the error code.
This fixes rdar://problem/30934619.
Differential Revision: https://reviews.llvm.org/D30768
llvm-svn: 297510
Removes immediate range checks for these instructions, since they have GPR
rt as their input operand.
Patch by Stefan Maksimovic.
Differential Revision: https://reviews.llvm.org/D30693
llvm-svn: 297485
1. Reimplemented conditional operator so that it checks
compatibility of unqualified pointees of the 2nd and
the 3rd operands (C99, OpenCL v2.0 6.5.15).
Define QualTypes compatibility for OpenCL as following:
- corresponding types are compatible (C99 6.7.3)
- CVR-qualifiers are equal (C99 6.7.3)
- address spaces are equal (implementation defined)
2. Added generic address space to Itanium mangling.
Review: D30037
Patch by Dmitry Borisenkov!
llvm-svn: 297468
Printing typedefs or type aliases using clang_getTypeSpelling() is missing the
namespace they are defined in. This is in contrast to other types that always
yield the full typename including namespaces.
Patch by Michael Reiher!
Differential Revision: https://reviews.llvm.org/D29944
llvm-svn: 297465
We have several reports of false positives coming from libc++. For example,
there are reports of false positives in std::regex, std::wcout, and also
a bunch of issues are reported in https://reviews.llvm.org/D30593. In many
cases, the analyzer trips over the complex libc++ code invariants. Let's turn
off the reports coming from these headers until we can re-evalate the support.
We can turn this back on once we individually suppress all known false
positives and perform deeper evaluation on large codebases that use libc++.
We'd also need to commit to doing these evaluations regularly as libc++
headers change.
Differential Revision: https://reviews.llvm.org/D30798
llvm-svn: 297429
It's possible to load out-of-range values from bitfields backed by a
boolean or an enum. Check for UB loads from bitfields.
This is the motivating example:
struct S {
BOOL b : 1; // Signed ObjC BOOL.
};
S s;
s.b = 1; // This is actually stored as -1.
if (s.b == 1) // Evaluates to false, -1 != 1.
...
Changes since the original commit:
- Single-bit bools are a special case (see CGF::EmitFromMemory), and we
can't avoid dealing with them when loading from a bitfield. Don't try to
insert a check in this case.
Differential Revision: https://reviews.llvm.org/D30423
llvm-svn: 297389
Summary:
A `co_await arg` expression has a dependent type whenever the promise type is still dependent, even if the argument to co_await is not. This is because we cannot attempt the `await_transform(<arg>)` until after we know the promise type.
This patch fixes an assertion in the constructor of `DependentCoawaitExpr` that asserted that `arg` must also be dependent.
Reviewers: rsmith, GorNishanov, aaron.ballman
Reviewed By: GorNishanov
Subscribers: mehdi_amini, cfe-commits
Differential Revision: https://reviews.llvm.org/D30772
llvm-svn: 297358
Summary:
This patch adds passing a coroutine_handle object to await_suspend calls.
It builds the coroutine_handle using coroutine_handle<PromiseType>::from_address(__builtin_coro_frame()).
(a revision of https://reviews.llvm.org/D26316 that for some reason refuses to apply via arc patch)
Reviewers: GorNishanov
Subscribers: mehdi_amini, cfe-commits, EricWF
Differential Revision: https://reviews.llvm.org/D30769
llvm-svn: 297356
Some of the magic functions take arguments of arbitrary type. However,
for semantic correctness, the compiler still requires a declaration
of these functions with the correct type. Since C does not have
argument-type-overloaded function, this made those functions hard to
use in C code. Improve this situation by allowing arbitrary suffixes
in the affected magic functions' names, thus allowing the user to
create different declarations for different types.
A patch by Keno Fischer!
Differential Revision: https://reviews.llvm.org/D30589
llvm-svn: 297325
Add a bug visitor to the taint checker to make it easy to distinguish where
the tainted value originated. This is especially useful when the original
taint source is obscured by complex data flow.
A patch by Vlad Tsyrklevich!
Differential Revision: https://reviews.llvm.org/D30289
llvm-svn: 297324
- Mips is architecture, not a toolchain
- Might help eliminate the confusion in the future by not having header files with the same name
Differential Revision: https://reviews.llvm.org/D30753
llvm-svn: 297312
It's possible to load out-of-range values from bitfields backed by a
boolean or an enum. Check for UB loads from bitfields.
This is the motivating example:
struct S {
BOOL b : 1; // Signed ObjC BOOL.
};
S s;
s.b = 1; // This is actually stored as -1.
if (s.b == 1) // Evaluates to false, -1 != 1.
...
Differential Revision: https://reviews.llvm.org/D30423
llvm-svn: 297298
This patch honors the unaligned type qualifier (currently available through he
keyword __unaligned and -fms-extensions) in CodeGen. In the current form the
patch affects declarations and expressions. It does not affect fields of
classes.
Differential Revision: https://reviews.llvm.org/D30166
llvm-svn: 297276
Summary:
This patch makes ContinuationIndenter call breakProtrudingToken only if
NoLineBreak and NoLineBreakInOperand is false.
Previously, clang-format required two runs to converge on the following example with 24 columns:
Note that the second operand shouldn't be splitted according to NoLineBreakInOperand, but the
token breaker doesn't take that into account:
```
func(a, "long long long long", c);
```
After first run:
```
func(a, "long long "
"long long",
c);
```
After second run, where NoLineBreakInOperand is taken into account:
```
func(a,
"long long "
"long long",
c);
```
With the patch, clang-format now obtains in one run:
```
func(a,
"long long long"
"long",
c);
```
which is a better token split overall.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D30575
llvm-svn: 297274
Summary:
This patch enables comment reflowing of lines not matching the comment pragma regex
in multiline comments containing comment pragma lines. Previously, these comments
were dumped without being reindented to the result.
Reviewers: djasper, mprobst
Reviewed By: mprobst
Subscribers: klimek, mprobst, cfe-commits
Differential Revision: https://reviews.llvm.org/D30697
llvm-svn: 297261
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
Summary:
This is a revised version of D28796. Included test is changed to
resolve the target compatibility issue reported (rL293032).
Reviewers: inglorion, dblaikie, echristo, aprantl, probinson
Reviewed By: inglorion
Subscribers: mehdi_amini, cfe-commits
Differential Revision: https://reviews.llvm.org/D30663
llvm-svn: 297194
This test broke with an LLVM instcombine patch (r297166).
I changed the RUN line to only run -mem2reg (to save time checking this large chunk of tests)
and updated the checks using the script attached to D17999:
https://reviews.llvm.org/D17999
The goal is to make this test immune to optimizer changes. If there's something in these
tests that was checking for an IR optimization, that should be tested in LLVM, not Clang.
llvm-svn: 297189
This patch makes the valist check more robust to the different AST variants on
different platforms and also fixes a FIXME.
Differential Revision: https://reviews.llvm.org/D30157
llvm-svn: 297153
Summary:
This patch adds support for namespaces ending in semicolon to the namespace comment fixer.
source:
```
namespace A {
int i;
int j;
};
```
clang-format before:
```
namespace A {
int i;
int j;
} // namespace A;
```
clang-format after:
```
namespace A {
int i;
int j;
}; // namespace A
```
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D30688
llvm-svn: 297140
Summary:
I've included a unit test with a function template containing a variable
of incomplete type. Clang compiles this without errors (the standard
does not require a diagnostic in this case). Without the fix, this case
triggers the crash.
Reviewers: klimek
Reviewed By: klimek
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D30636
llvm-svn: 297129
Summary:
The changes contained in this patch are:
1. Defines a new AST node `CoawaitDependentExpr` for representing co_await expressions while the promise type is still dependent.
2. Correctly detect and transform the 'co_await' operand to `p.await_transform(<expr>)` when possible.
3. Change the initial/final suspend points to build during the initial parse, so they have the correct operator co_await lookup results.
4. Fix transformation of the CoroutineBodyStmt so that it doesn't re-build the final/initial suspends.
@rsmith: This change is a little big, but it's not trivial for me to split it up. Please let me know if you would prefer this submitted as multiple patches.
Reviewers: rsmith, GorNishanov
Reviewed By: rsmith
Subscribers: ABataev, rsmith, mehdi_amini, cfe-commits
Differential Revision: https://reviews.llvm.org/D26057
llvm-svn: 297093
Previously when a coroutine was building the implicit setup/destroy
constructs it would emit diagostics about failures on the first co_await/co_return/co_yield
it encountered. This was confusing because that construct may not itself be ill-formed.
This patch moves the diagnostics to the function start instead.
llvm-svn: 297089
Summary:
Because of the existence branches out of GNU statement expressions, it
is possible that emitting cleanups for a full expression may cause the
new insertion point to not be dominated by the result of the inner
expression. Consider this example:
struct Foo { Foo(); ~Foo(); int x; };
int g(Foo, int);
int f(bool cond) {
int n = g(Foo(), ({ if (cond) return 0; 42; }));
return n;
}
Before this change, result of the call to 'g' did not dominate its use
in the store to 'n'. The early return exit from the statement expression
branches to a shared cleanup block, which ends in a switch between the
fallthrough destination (the assignment to 'n') or the function exit
block.
This change solves the problem by spilling and reloading expression
evaluation results when any of the active cleanups have branches.
I audited the other call sites of enterFullExpression, and they don't
appear to keep and Values live across the site of the cleanup, except in
ARC code. I wasn't able to create a test case for ARC that exhibits this
problem, though.
Reviewers: rjmccall, rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D30590
llvm-svn: 297084
Summary:
Added co_return statement emission.
Tweaked coro-alloc.cpp test to use co_return to trigger coroutine processing instead of co_await, since this change starts emitting the body of the coroutine and await expression handling has not been upstreamed yet.
Reviewers: rsmith, majnemer, EricWF, aaron.ballman
Reviewed By: rsmith
Subscribers: majnemer, llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D29979
llvm-svn: 297076
GNUMode shouldn't be a benign language option because it influences the
resulting AST when checking for the existence of GNUMode-specific macro
"linux" (e.g. by having code inside #ifdef linux). This patch marks it as a
normal language option so it gets correctly passed to the compiler invocation
for the used modules.
The added test case illustrated this because it compiles without modules, but
fails when using modules.
Patch by Raphael Isemann (D30496)!
llvm-svn: 297030
Summary:
Until now, NamespaceEndCommentFixer was adding missing comments for every run,
which results in multiple end comments for:
```
namespace {
int i;
int j;
}
#if A
int a = 1;
#else
int a = 2;
#endif
```
result before:
```
namespace {
int i;
int j;
}// namespace // namespace
#if A
int a = 1;
#else
int a = 2;
#endif
```
result after:
```
namespace {
int i;
int j;
}// namespace
#if A
int a = 1;
#else
int a = 2;
#endif
```
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D30659
llvm-svn: 297028
block copy/destroy routines
This is a preparation commit for work on merging unique block copy/destroy
helper functions.
rdar://22950898
Differential Revision: https://reviews.llvm.org/D30345
llvm-svn: 297023
that return record or vector types
The performSelector family of methods from Foundation use objc_msgSend to
dispatch the selector invocations to objects. However, method calls to methods
that return record types might have to use the objc_msgSend_stret as the return
value won't find into the register. This is also supported by this sentence from
performSelector documentation: "The method should not have a significant return
value and should take a single argument of type id, or no arguments". This
commit adds a new warning that warns when a selector which corresponds to a
method that returns a record type is passed into performSelector.
rdar://12056271
Differential Revision: https://reviews.llvm.org/D30174
llvm-svn: 297019
Summary:
Functions with the "xray_log_args" attribute will tell LLVM to emit a special
XRay sled for compiler-rt to copy any call arguments to your logging handler.
Reviewers: dberris
Reviewed By: dberris
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D29704
llvm-svn: 296999
UBSan's nonnull argument check applies when a parameter has the
"nonnull" attribute. The check currently works for FunctionDecls, but
not for ObjCMethodDecls. This patch extends the check to work for ObjC.
Differential Revision: https://reviews.llvm.org/D30599
llvm-svn: 296996
easily extend the aggregate-builder API. Stupid missing language
features.
Also add APIs for constructing a relative reference and computing
the offset of a position from the start of the initializer.
llvm-svn: 296979
Report the typedef as reference, and desugar it to report the underlying class as an
implicit 'base' reference.
Reporting the underlying base class for 'base' relations matches the ObjC handling and
leads to a simpler model.
llvm-svn: 296975
If the QualType is null, calling ASTContext::getCanonicalType on it will lead
to an assert. This was found while testing a new use for Stmt::Profile, so
there is no test case for this.
llvm-svn: 296956
Now print diagnostics for static, virtual, inline, volatile, and const
differences in methods. Also use DeclarationName instead of IdentifierInfo
for additional robustness in diagnostic printing.
llvm-svn: 296932
Summary: This fails on Windows due to dependence on path separators.
Reviewers: rnk, srhines
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30595
llvm-svn: 296929
Summary:
This change adds an arch-specific subdirectory in <ResourceDir>/lib/<OS>
to the linker search path. This path also gets added as '-rpath' for
native compilation if a runtime is linked in as a shared object. This
allows arch-specific libraries to be installed alongside clang.
Reviewers: danalbert, cbergstrom, javed.absar
Subscribers: srhines
Differential Revision: https://reviews.llvm.org/D30015
llvm-svn: 296927
* ExprEngine assumes that OpenMP statements should never appear in CFG.
However, current CFG doesn't know anything about OpenMP and passes
such statements as CFG nodes causing "UNREACHABLE executed!" crashes.
Since there is no OpenMP implementation in ExprEngine or CFG,
we stop the analysis on OpenMP statements to avoid crashes.
This fixes PR31835.
Differential Revision: https://reviews.llvm.org/D30565
llvm-svn: 296884
As is the case on platforms like Mips, X86 and SystemZ, the -fomit-frame-pointer
should be enabled by default on PPC when optimizing at -O1 and above. This
brings the behaviour of LLVM on PPC in line with GCC.
Committing on behalf of Hiroshi Inoue.
Differential Revision: https://reviews.llvm.org/D29750
llvm-svn: 296861
Previously, VC++ has always set _MSC_VER to a four-digit value with the two least significant digits set to zero. Visual Studio 2017, however, sets _MSC_VER=1910, and we expect to update the least significant digit as we release major updates for VS 2017. This patch fixes the msc-version.c test to handle non-zero values in the two least significant digits of _MSC_VER.
llvm-svn: 296843
When we are deciding whether we are creating a PCH or a module, we would
check if the ModuleMgr had any elements to switch into PCH mode.
However, when creating a module, the size may be 1. This would result
in us going down the wrong path.
This was found by cross-compiling the swift standard library. Use the
PCH chain length instead to identify the PCH mode.
Unfortunately, I have not yet been able to create a simple test case for
this, but have verified that this fixes the swift standard library
construction.
Thanks to Adrian Prantl for help and discussions with this change!
llvm-svn: 296769
Summary:
This patch makes the namespace comment fixer use the number of unwrapped lines
that a namespace spans to detect it that namespace is short, thus not needing
end comments to be added.
This is needed to ensure clang-format is idempotent. Previously, a short namespace
was detected by the original source code lines. This has the effect of requiring two
runs for this example:
```
namespace { class A; }
```
after first run:
```
namespace {
class A;
}
```
after second run:
```
namespace {
class A;
} // namespace
```
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D30528
llvm-svn: 296736
Many things were wrong:
- We didn't always allow wrapping after "as", which can be necessary.
- We used to Undestand the identifier after "as" as a start of a name.
- We didn't properly parse the structure of the expression with "as"
having the precedence of relational operators
llvm-svn: 296659
This is a stopgap fix for PR31863, a regression introduced in r276159.
Consider this snippet:
struct FVector;
struct FVector {};
struct FBox {
FVector Min;
FBox(int);
};
namespace {
FBox InvalidBoundingBox(0);
}
While parsing the DECL_VAR for 'struct FBox', clang recursively read all the
dep decls until it finds the DECL_CXX_RECORD forward declaration for 'struct
FVector'. Then, it resumes all the way up back to DECL_VAR handling in
`ReadDeclRecord`, where it checks if `isConsumerInterestedIn` for the decl.
One of the condition for `isConsumerInterestedIn` to return false is if the
VarDecl is imported from a module `D->getImportedOwningModule()`, because it
will get emitted when we import the relevant module. However, before checking
if it comes from a module, clang checks if `Ctx.DeclMustBeEmitted(D)`, which
triggers the emission of 'struct FBox'. Since one of its fields is still
incomplete, it crashes.
Instead, check if `D->getImportedOwningModule()` is true before calling
`Ctx.DeclMustBeEmitted(D)`.
Differential Revision: https://reviews.llvm.org/D29753
rdar://problem/30173654
llvm-svn: 296656
and the nature of a declaration
This commit adds an external_source_symbol attribute to Clang. This attribute
specifies that a declaration originates from an external source and describes
the nature of that source. This attribute will be used to improve IDE features
like 'jump-to-definition' for mixed-language projects or project that use
auto-generated code.
rdar://30423368
Differential Revision: https://reviews.llvm.org/D29819
llvm-svn: 296649
In the following code involving GNU statement-expression extension:
struct S {
~S();
};
void foo() {
const S &x = ({ return; S(); });
}
function 'foo()' returns before reference x is initialized. We shouldn't call
the destructor for the temporary object lifetime-extended by 'x' in this case,
because the object never gets constructed in the first place.
The real problem is probably in the CFG somewhere, so this is a quick-and-dirty
hotfix rather than the perfect solution.
A patch by Artem Dergachev!
rdar://problem/30759076
Differential Revision: https://reviews.llvm.org/D30499
llvm-svn: 296646
Summary:
This patch enables namespace end comments under a new flag FixNamespaceComments,
which is enabled for the LLVM and Google styles.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D30405
llvm-svn: 296632
Summary:
An AtomicChange is used to create and group a set of source edits, e.g.
replacements or header insertions. Edits in an AtomicChange should be related,
e.g. replacements for the same type reference and the corresponding header
insertion/deletion.
An AtomicChange is uniquely identified by a key position and will either be
fully applied or not applied at all. The key position should be the location
of the key syntactical element that is being changed, e.g. the call to a
refactored method.
Next step: add a tool that applies AtomicChange.
Reviewers: klimek, djasper
Reviewed By: klimek
Subscribers: alexshap, cfe-commits, djasper, mgorny
Differential Revision: https://reviews.llvm.org/D27054
llvm-svn: 296616
Those blocks are used if C++ code is SWIG-wrapped (see swig.org) and
usually do not contain C++ code. Also cleanup the implementation of for #if 0
and #if false a bit.
llvm-svn: 296605
Summary:
Don't warn about unused lambda captures that involve copying a
value of a type that cannot be trivially copied and destroyed.
Fixes PR31977
Reviewers: rsmith, aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D30327
llvm-svn: 296602
potential capture list.
Fix Sema::getCurLambda() to return the innermost lambda scope when there
is a block enclosed in the lambda. Previously, the method would return a
nullptr in such cases, which would prevent a variable captured by the
enclosed block to be added to the lambda scope's potential capture list.
rdar://problem/28412462
Differential Revision: https://reviews.llvm.org/D25556
llvm-svn: 296584
The exisiting warning for inconsistent overrides does not include the destructor
as it was noted in review that it was too noisy. Instead, add to a separate
warning group that is off by default for users who want consistent warnings
between methods and destructors.
llvm-svn: 296572
Fix a crash in the ObjCPropertyChecker when analyzing a 'copy' property of an
NSMutable* type in a protocol.
rdar://problem/30766684
Differential Revision: https://reviews.llvm.org/D30482
llvm-svn: 296562
Summary:
Also limits the blacklisting to only apply when the tag is actually
followed by a parameter in curly braces.
/** @mods {long.type.must.not.wrap} */
vs
/** @const this is a long description that may wrap. */
Reviewers: djasper
Subscribers: klimek, krasimir, cfe-commits
Differential Revision: https://reviews.llvm.org/D30452
llvm-svn: 296467
The option -mexecute-only is translated into the backend option
-arm-execute-only. But this option only makes sense for the compiler and
the assembler does not recognize it. This patch stops clang from passing
this option to the assembler.
Change-Id: I4f4cb1162c13cfd50a0a36702a4ecab1bc0324ba
Review: https://reviews.llvm.org/D30414
llvm-svn: 296454
The begining command "rm" will return 1 when there is not such file to
delete.
This patch is to remove it, as it's not needed for the test.
llvm-svn: 296453
Second attempt after http://llvm.org/viewvc/llvm-project?rev=296166&view=rev
In the first attempt, Code (the memory buffer backing the input file) was reset
before overwriteChangedFiles() was called, but overwriteChangedFiles() still
reads from it. This time, load the whole input file into memory instead of
using mmap when formatting in-place.
(Since the test is identical to what was in the repo before chapuni's revert,
svn diff doesn't show it – see the above link for the test.)
https://reviews.llvm.org/D30385
llvm-svn: 296408
When clang emits an inheriting C++ constructor it may inline code
during the CodeGen phase. This patch ensures that any debug info in
this inlined code gets a proper inlined location. Otherwise we can end
up with invalid debug info metadata, since all inlined local variables
and function arguments would be reparented into the call site.
Analogous to ApplyInlineLocation this patch introduces a
ApplyInlineDebugLocation scoped helper to facilitate entering an
inlined scope and cleaning up afterwards.
This fixes one of the issues discovered in PR32042.
rdar://problem/30679307
llvm-svn: 296388
Ekaterina Romanova