|  | Commit message (Collapse) | Author | Age | Files | Lines | 
|---|
| | 
| 
| 
| 
| 
| 
| 
| 
| | The original revert was done in r326869, since reverting r326602 broke
the test added by this.
The new test should be less dependent on r326602.
llvm-svn: 326872 | 
| | 
| 
| 
| | llvm-svn: 326869 | 
| | 
| 
| 
| 
| 
| 
| 
| | send to ObjC objects.
Differential Revision: https://reviews.llvm.org/D44170
llvm-svn: 326868 | 
| | 
| 
| 
| 
| 
| 
| 
| | This is already used throughout the entire system, so make it a default.
Differential Revision: https://reviews.llvm.org/D44065
llvm-svn: 326867 | 
| | 
| 
| 
| | llvm-svn: 326862 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | When a sanitizer incompatible with one of the default sanitizers
is explicitly enabled, automatically disable all the conflicting
default sanitizers.
Differential Revision: https://reviews.llvm.org/D44064
llvm-svn: 326860 | 
| | 
| 
| 
| 
| 
| | warnings; other minor fixes (NFC).
llvm-svn: 326856 | 
| | 
| 
| 
| 
| 
| 
| 
| | EmitLifetimeStart returns a non-null `size` pointer if it actually
emits a lifetime.start. Later in this function, we use `tempSize`'s
nullness to determine whether or not we should emit a lifetime.end.
llvm-svn: 326844 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Provide two new CMake cache variables -- CLANG_DEFAULT_STD_C
and CLANG_DEFAULT_STD_CXX -- that can be used to override the default
C/ObjC and C++/ObjC++ standards appropriately. They can be set to one of
the identifiers from LangStandards.def, or left unset (the default) to
respect the current platform default.
This option is mostly intended for compiler vendors that may wish
to adjust the defaults their compilers are using. For example, Gentoo
planned to use it to set clang and gcc to matching standards, so that
we could maintain as much compatibility between different compilers
as possible.
The code relies on explicit identifiers rather than the string aliases
for simplicity. This saves us from the necessity of parsing aliases at
build-time or adding additional processing at runtime. For the latter
case, it also adds trivial value check -- if incorrect value is passed,
the code simply fails to compile through referencing an undefined
constant.
If the variable is used to redefine the default standard, the explicit
value overrides the special case for PS4. It is done this way mostly
following other kinds of variables where 'platform defaults' are
redefined.
Differential Revision: https://reviews.llvm.org/D34365
llvm-svn: 326836 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | variables.
If the task has reduction construct and this construct for some variable
requires unique threadprivate storage, we may generate different names
for variables used in taskgroup task_reduction clause and in task
  in_reduction clause. Patch fixes this problem.
llvm-svn: 326827 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Summary:
Previously, clang-format would detect the following as an
Objective-C for-in statement:
  for (int x = in.value(); ...) {}
because the logic only decided a for-loop was definitely *not*
an Objective-C for-in loop after it saw a semicolon or a colon.
To fix this, I delayed the decision of whether this was a for-in
statement until after we found the matching right-paren, at which
point we know if we've seen a semicolon or not.
Test Plan: New tests added. Ran tests with:
  make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: krasimir, jolesiak
Reviewed By: jolesiak
Subscribers: djasper, cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D43904
llvm-svn: 326815 | 
| | 
| 
| 
| | llvm-svn: 326807 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Summary:
Code that used to be formatted as `if (! + object) {` is now formatted as `if (!+object) {`
(we have a particular object in our codebase where unary `operator+` is overloaded to return the underlying value, which in this case is a `bool`)
We still preserve the TypeScript behavior where `!` is a trailing non-null operator. (This is already tested by an existing unit test in `FormatTestJS.cpp`)
It doesn't appear like handling of consecutive unary operators are tested in general, so I added another test for completeness
Patch contributed by @kevinl!
Reviewers: krasimir
Reviewed By: krasimir
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D43312
llvm-svn: 326792 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | dereference on dest-buffer or src-buffer.
Summary: `CheckBufferAccess()` calls `CheckNonNull()`, so there are some calls to `CheckNonNull()` that are useless.
Reviewers: dcoughlin, NoQ, xazax.hun, cfe-commits, george.karpenkov
Reviewed By: NoQ
Subscribers: szepet, rnkovacs, MTC, a.sidorin
Differential Revision: https://reviews.llvm.org/D44075
llvm-svn: 326782 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | operand with type bool.
Summary:
There is a problem with analyzer that a wrong value is given when modeling the increment operator of the operand with type bool. After `rL307604` is applied, a unsigned overflow may occur.
Example:
```
void func() {
  bool b = true;
  // unsigned overflow occur, 2 -> 0 U1b
  b++;
}
``` 
The use of an operand of type bool with the ++ operators is deprecated but valid untill C++17. And if the operand of the increment operator is of type bool, it is set to true.
This patch includes two parts:
  - If the operand of the increment operator is of type bool or type _Bool, set to true.
  - Modify `BasicValueFactory::getTruthValue()`, use `getIntWidth()` instead `getTypeSize()` and use `unsigned` instead `signed`.
Reviewers: alexshap, NoQ, dcoughlin, george.karpenkov
Reviewed By: NoQ
Subscribers: xazax.hun, szepet, a.sidorin, cfe-commits, MTC
Differential Revision: https://reviews.llvm.org/D43741
llvm-svn: 326776 | 
| | 
| 
| 
| | llvm-svn: 326767 | 
| | 
| 
| 
| | llvm-svn: 326766 | 
| | 
| 
| 
| 
| 
| | warnings; other minor fixes (NFC).
llvm-svn: 326757 | 
| | 
| 
| 
| | llvm-svn: 326755 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | performance anti-pattern
rdar://37312818
NB: The checker does not care about the ordering of callbacks, see the
relevant FIXME in tests.
Differential Revision: https://reviews.llvm.org/D44059
llvm-svn: 326746 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Starting with the Fall Creators Update, Windows 10 Desktop can run on
machines that are powered by aarch64 processors.
Microsoft call the aarch64 architecture "arm64". This patch maps
ArchType::aarch64 to "arm64" to allow the MSVC toolchain driver to find
the aarch64 / arm64 cross-compiler.
Patch by Chris January
Differential Revision: https://reviews.llvm.org/D44087
llvm-svn: 326744 | 
| | 
| 
| 
| | llvm-svn: 326741 | 
| | 
| 
| 
| 
| 
| | Differential Revision: https://reviews.llvm.org/D43911
llvm-svn: 326725 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Summary:
GenericTaintChecker can't recognize stdin in some cases. The reason is that `if (PtrTy->getPointeeType() == C.getASTContext().getFILEType()` does not hold when stdin is encountered.
My platform is ubuntu16.04 64bit, gcc 5.4.0, glibc 2.23. The definition of stdin is as follows:
```
__BEGIN_NAMESPACE_STD
/* The opaque type of streams.  This is the definition used elsewhere.  */
typedef struct _IO_FILE FILE;
___END_NAMESPACE_STD
  ...
/* The opaque type of streams.  This is the definition used elsewhere.  */
typedef struct _IO_FILE __FILE;   
  ...
/* Standard streams.  */
extern struct _IO_FILE *stdin;      /* Standard input stream.  */
extern struct _IO_FILE *stdout;     /* Standard output stream.  */
extern struct _IO_FILE *stderr;     /* Standard error output stream.  */
```
The type of stdin is as follows AST:
```
ElaboratedType 0xc911170'struct _IO_FILE'sugar
`-RecordType 0xc911150'struct _IO_FILE'
 `-CXXRecord 0xc923ff0'_IO_FILE'
```
`C.getASTContext().GetFILEType()` is as follows AST:
```
TypedefType 0xc932710 'FILE' sugar
|-Typedef 0xc9111c0 'FILE'
`-ElaboratedType 0xc911170 'struct _IO_FILE' sugar
  `-RecordType 0xc911150 'struct _IO_FILE'
      `-CXXRecord 0xc923ff0 '_IO_FILE'
```
So I think it's better to use `getCanonicalType()`.
Reviewers: zaks.anna, NoQ, george.karpenkov, a.sidorin
Reviewed By: zaks.anna, a.sidorin
Subscribers: a.sidorin, cfe-commits, xazax.hun, szepet, MTC
Differential Revision: https://reviews.llvm.org/D39159
llvm-svn: 326709 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Summary:
The _get_ssp intrinsic can be used to retrieve the
shadow stack pointer, independent of the current arch -- in
contract with the rdsspd and the rdsspq intrinsics.
Also, this intrinsic returns zero on CPUs which don't
support CET. The rdssp[d|q] instruction is decoded as nop,
essentially just returning the input operand, which is zero.
Example result of compilation:
```
xorl    %eax, %eax
movl    %eax, %ecx
rdsspq  %rcx         # NOP when CET is not supported
movq    %rcx, %rax   # return zero
```
Reviewers: craig.topper
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D43814
llvm-svn: 326689 | 
| | 
| 
| 
| 
| 
| | Fixed a trivial formatting and indent.
llvm-svn: 326685 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Previously, we passed "#" to --autocomplete to indicate to enable cc1
flags. For example, when -cc1 or -Xclang was passed to bash, bash
executed `clang --autocomplete=#-<flag they want to complete>`.
However, this was not a good implementation because it depends -Xclang
and -cc1 parsing to shell. So I changed this to pass all flags shell
has, so that Clang can handle them internally.
I had to change many testcases because API spec changed quite a lot.
Reviewers: teemperor, v.g.vassilev
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D39342
llvm-svn: 326684 | 
| | 
| 
| 
| 
| 
| | These attributes were only customized because of the need to check for attribute mutual exclusion, but we now have the handleSimpleAttributeWithExclusions() helper function to handle these scenarios.
llvm-svn: 326675 | 
| | 
| 
| 
| 
| 
| 
| 
| | checking logic.
This changes the diagnostic wording somewhat, but otherwise intends no functional change to the attribute.
llvm-svn: 326665 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Summary:
Basic support of Sanitiser to follow-up ubsan support in compiler-rt.
Needs to use lld instead of base ld to be fully workable.
Patch by: David CARLIER
Reviewers: krytarowski, vitalybuka, kettenis
Reviewed By: vitalybuka
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D43961
llvm-svn: 326648 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Summary:
- Like other *BSD, conditioning certain flags to pass
- To prepare future OpenBSD sanitisers.
Patch by: David CARLIER
Reviewers: dlj, krytarowski, vitalybuka
Reviewed By: vitalybuka
Subscribers: krytarowski, cfe-commits
Differential Revision: https://reviews.llvm.org/D43818
llvm-svn: 326645 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Summary:
Currently only calls to mcount were suppressed with
no_instrument_function attribute.
Linux kernel requires that calls to fentry should also not be
generated.
This is an extended fix for PR PR33515.
Reviewers: hfinkel, rengolin, srhines, rnk, rsmith, rjmccall, hans
Reviewed By: rjmccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D43995
llvm-svn: 326639 | 
| | 
| 
| 
| 
| 
| | warnings; other minor fixes (NFC).
llvm-svn: 326633 | 
| | 
| 
| 
| | llvm-svn: 326624 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | initialization in if-expression
```
if (NSNumber* x = ...)
```
is a reasonable pattern in objc++, we should not warn on it.
rdar://35152234
Differential Revision: https://reviews.llvm.org/D44044
llvm-svn: 326619 | 
| | 
| 
| 
| | llvm-svn: 326607 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | The patch fixes a number of bugs related to parameter indexing in
attributes:
* Parameter indices in some attributes (argument_with_type_tag,
  pointer_with_type_tag, nonnull, ownership_takes, ownership_holds,
  and ownership_returns) are specified in source as one-origin
  including any C++ implicit this parameter, were stored as
  zero-origin excluding any this parameter, and were erroneously
  printing (-ast-print) and confusingly dumping (-ast-dump) as the
  stored values.
* For alloc_size, the C++ implicit this parameter was not subtracted
  correctly in Sema, leading to assert failures or to silent failures
  of __builtin_object_size to compute a value.
* For argument_with_type_tag, pointer_with_type_tag, and
  ownership_returns, the C++ implicit this parameter was not added
  back to parameter indices in some diagnostics.
This patch fixes the above bugs and aims to prevent similar bugs in
the future by introducing careful mechanisms for handling parameter
indices in attributes.  ParamIdx stores a parameter index and is
designed to hide the stored encoding while providing accessors that
require each use (such as printing) to make explicit the encoding that
is needed.  Attribute declarations declare parameter index arguments
as [Variadic]ParamIdxArgument, which are exposed as ParamIdx[*].  This
patch rewrites all attribute arguments that are processed by
checkFunctionOrMethodParameterIndex in SemaDeclAttr.cpp to be declared
as [Variadic]ParamIdxArgument.  The only exception is xray_log_args's
argument, which is encoded as a count not an index.
Differential Revision: https://reviews.llvm.org/D43248
llvm-svn: 326602 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | Patch fixes the problem with the functions marked as `declare simd`. If
the canonical declaration does not have associated `declare simd`
construct, we may not generate required code even if other
redeclarations are marked as `declare simd`.
llvm-svn: 326594 | 
| | 
| 
| 
| 
| 
| 
| 
| | In CUDA mode all local variables are actually thread
local|threadprivate, not private, and, thus, they cannot be shared
between threads|lanes.
llvm-svn: 326590 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Patch by: krisb
Reviewers: teemperor
Reviewed By: teemperor
Subscribers: klimek, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D43809
llvm-svn: 326566 | 
| | 
| 
| 
| 
| 
| 
| 
| | These paths aren't used and don't make sense on Fuchsia.
Differential Revision: https://reviews.llvm.org/D43992
llvm-svn: 326542 | 
| | 
| 
| 
| | llvm-svn: 326531 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | This makes it easier to debug crashes and hangs in block functions since
users can easily find out where the block is called from. The option
doesn't disable tail-calls from non-escaping blocks since non-escaping
blocks are not as hard to debug as escaping blocks.
rdar://problem/35758207
Differential Revision: https://reviews.llvm.org/D43841
llvm-svn: 326530 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | This shouldn't change any results for now, but is more consistent with
how we set dllimport/dllexport and will make future changes easier.
Since clang produces IR as it parses, it can find out mid file that
something is dllimport. When that happens we have to drop
dso_local. This is not a problem right now because
CodeGenModule::setDSOLocal is called from relatively few places at
the moment.
llvm-svn: 326527 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | https://bugs.llvm.org/show_bug.cgi?id=36381
rdar://37543426
Turns out, the type passed for the lambda capture was incorrect.
One more argument to abandon the getSVal overload which does not require the
type information.
Differential Revision: https://reviews.llvm.org/D43925
llvm-svn: 326520 | 
| | 
| 
| 
| 
| 
| | warnings; other minor fixes (NFC).
llvm-svn: 326519 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Summary: Add exception handling option to clang.
Reviewers: dschuff
Subscribers: jfb, sbc100, jgravelle-google, sunfish, cfe-commits
Differential Revision: https://reviews.llvm.org/D43681
llvm-svn: 326517 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | (Re-applying r326501.)
When parsing comments, for example, for -Wdocumentation, slightly different
behaviour occurs when -fparse-all-comments is specified. However, these
differences are subtle:
1. All comments are saved during parsing, regardless of whether they are doc
   comments or not.
2. "Maybe-doc" comments, like <, !, etc, are saved as such, instead of marking
   them as ordinary comments. The maybe-doc type of comment is never saved
   otherwise. (Warning on these is the impetus of -Wdocumentation.)
3. All comments are treated as doc comments in ASTContext, even if they are ordinary.
This change moves the logic for checking CommentOptions.ParseAllComments closer
to where it has an effect. The overall logic is unchanged, but checks of the
ParseAllComments flag are now done where the effect will be clearer.
Subscribers: cfe-commits
llvm-svn: 326512 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Original change:
[NFC] Move CommentOpts checks to the call sites that depend on it.
When parsing comments, for example, for -Wdocumentation, slightly different
behaviour occurs when -fparse-all-comments is specified. However, these
differences are subtle:
1. All comments are saved during parsing, regardless of whether they are doc comments or not.
2. "Maybe-doc" comments, like //<, //!, etc, are saved as such, instead of marking them as ordinary comments. The maybe-doc type of comment is never saved otherwise. (Warning on these is the impetus of -Wdocumentation.)
3. All comments are treated as doc comments in ASTContext, even if they are ordinary.
This change moves the logic for checking CommentOptions.ParseAllComments closer
to where it has an effect. The overall logic is unchanged, but checks of the
ParseAllComments flag are now done where the effect will be clearer.
llvm-svn: 326508 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | When parsing comments, for example, for -Wdocumentation, slightly different
behaviour occurs when -fparse-all-comments is specified. However, these
differences are subtle:
 1. All comments are saved during parsing, regardless of whether they are doc
    comments or not.
 2. "Maybe-doc" comments, like //<, //!, etc, are saved as such, instead of
    marking them as ordinary comments. The maybe-doc type of comment is never
    saved otherwise. (Warning on these is the impetus of -Wdocumentation.)
 3. All comments are treated as doc comments in ASTContext, even if they are
    ordinary.
This change moves the logic for checking CommentOptions.ParseAllComments closer
to where it has an effect. The overall logic is unchanged, but checks of the
ParseAllComments flag are now done where the effect will be clearer.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D43663
llvm-svn: 326501 |