Paul Hoad [Mon, 7 Oct 2019 17:03:44 +0000 (17:03 +0000)]
[clang-format] [PR27004] omits leading space for noexcept when formatting operator delete()
Summary:
clang-format is incorrectly thinking the parameter parens are part of a cast operation, this is resulting in there sometimes being not space between the paren and the noexcept (and other keywords like volatile etc..)
The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us.
The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us.
The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us.
The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us.
Hans Wennborg [Mon, 7 Oct 2019 09:30:15 +0000 (09:30 +0000)]
clang-cl: Ignore the new /ZH options
These were added to the MS docs in
https://github.com/MicrosoftDocs/cpp-docs/commit/85b9b6967e58e485251450f7451673f6fc873e88
and are supposedly available in VS 2019 16.4 (though my 2019 Preview,
version 16.4.0-pre.1.0 don't seem to have them.)
Richard Smith [Mon, 7 Oct 2019 02:45:12 +0000 (02:45 +0000)]
Fix behavior of __builtin_bit_cast when the From and To types are the
same.
We were missing the lvalue-to-rvalue conversion entirely in this case,
and in fact still need the full CK_LValueToRValueBitCast conversion to
perform a load with no TBAA.
Richard Smith [Sun, 6 Oct 2019 18:40:59 +0000 (18:40 +0000)]
[Sema] Avoids an assertion failure when an invalid conversion declaration is used
Summary:
When using a user-defined conversion function template with a deduced return type the compiler gives a set of warnings:
```
bug.cc:252:44: error: cannot specify any part of a return type in the declaration of a conversion function; use an alias template to declare a conversion to 'auto (Ts &&...) const'
template <typename... Ts> operator auto()(Ts &&... xs) const;
^~~~~~~~~~~~~~~~~~~
bug.cc:252:29: error: conversion function cannot convert to a function type
template <typename... Ts> operator auto()(Ts &&... xs) const;
^
error: pointer to function type cannot have 'const' qualifier
```
after which it triggers an assertion failure. It seems the last error is incorrect and doesn't have any location information. This patch stops the compilation after the second warning.
Sanjay Patel [Sun, 6 Oct 2019 13:08:08 +0000 (13:08 +0000)]
[InstCombine] don't assume 'inbounds' for bitcast pointer to GEP transform (PR43501)
https://bugs.llvm.org/show_bug.cgi?id=43501
We can't declare a GEP 'inbounds' in general. But we may salvage that information if
we have known dereferenceable bytes on the source pointer.
Paul Hoad [Sat, 5 Oct 2019 09:55:23 +0000 (09:55 +0000)]
[clang-format] SpacesInSquareBrackets should affect lambdas with parameters too
Summary:
This patch makes the `SpacesInSquareBrackets` setting also apply to C++ lambdas with parameters.
Looking through the revision history, it appears support for only array brackets was added, and lambda brackets were ignored. Therefore, I am inclined to think it was simply an omission, rather than a deliberate choice.
See https://bugs.llvm.org/show_bug.cgi?id=17887 and https://reviews.llvm.org/D4944.
Michal Gorny [Fri, 4 Oct 2019 20:28:59 +0000 (20:28 +0000)]
[clang] [cmake] Use add_clang_tool() to install all tools
Switch clang-check, clang-extdef-mapping and clang-offload-bundler
to use add_clang_tool() rather than add_clang_executable() with a custom
install rule. This makes them LLVM_DISTRIBUTION_COMPONENTS-friendly.
Jordan Rose [Fri, 4 Oct 2019 18:17:58 +0000 (18:17 +0000)]
[CMake] Clang: Don't use object libraries with Xcode
Undoes some of the effects of r360946 when using the Xcode CMake
generator---it doesn't handle object libraries correctly at all.
Attempts to still honor BUILD_SHARED_LIBS for Xcode, but I didn't
actually test it. Should have no effect on non-Xcode generators.
The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us.
The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us.
Paul Hoad [Fri, 4 Oct 2019 14:25:20 +0000 (14:25 +0000)]
[clang-format] C++11 braced lists should respect the SpacesInParentheses setting
Summary:
According to the clang-format documentation, "Fundamentally, C++11 braced lists are formatted exactly like function calls would be formatted in their place. If the braced list follows a name (e.g. a type or variable name), clang-format formats as if the `{}` were the parentheses of a function call with that name."
This patch furthers the treatment of C++11 braced list braces as parentheses by respecting the `SpacesInParentheses` setting.
Fix for clang-format incorrectly handles "alternative operators" as described by https://en.cppreference.com/w/cpp/language/operator_alternative
compl = ~
not = !
these are unary operators, and clang-format will remove the space between them and a numeric constant
this incorrectly formats the following code
```
int a compl 5;
int a not 5;
```
into:
```
int a compl5;
int a not5;
```
The code adds FIXME unit tests for "alternative token" representations for {} [] and # as defined by the same link, which would require a more detailed change to the FormatTokenLexer
Simon Tatham [Fri, 4 Oct 2019 13:01:41 +0000 (13:01 +0000)]
[clang] Prevent false positives in arm-mfpu-none codegen test.
A user pointed out to me in private email that this test will fail if
it sees the letter 's' followed by a digit in any part of clang's
assembly output after the function label. That includes the .ident at
the end, which can include a full pathname or hostname or both from
the system clang was built on. So if that path or hostname includes
any text like 's5' then it will cause the test to fail.
Fixed by adding a check for `.fnend`, to limit the scope of the
`CHECK-NOT` to only the actual generated code for the test function.
(Committed without prior review on the basis that it's a simple and
obvious pure test-suite fix and also in a test I contributed myself.)
Raphael Isemann [Fri, 4 Oct 2019 08:26:17 +0000 (08:26 +0000)]
[lldb][modern-type-lookup] No longer import temporary declarations into the persistent AST
Summary:
As we figured out in D67803, importing declarations from a temporary ASTContext that were originally from a persistent ASTContext
causes a bunch of duplicated declarations where we end up having declarations in the target AST that have no associated ASTImporter that
can complete them.
I haven't figured out how/if we can solve this in the current way we do things in LLDB, but in the modern-type-lookup this is solvable
as we have a saner architecture with the ExternalASTMerger. As we can (hopefully) make modern-type-lookup the default mode in the future,
I would say we try fixing this issue here. As we don't use the hack that was reinstated in D67803 during modern-type-lookup, the test case for this
is essentially just printing any kind of container in `std::` as we would otherwise run into the issue that required a hack like D67803.
What this patch is doing in essence is that instead of importing a declaration from a temporary ASTContext, we instead check if the
declaration originally came from a persistent ASTContext (e.g. the debug information) and we directly import from there. The ExternalASTMerger
is already connected with ASTImporters to these different sources, so this patch is essentially just two parts:
1. Mark our temporary ASTContext/ImporterSource as temporary when we import from the expression AST.
2. If the ExternalASTMerger sees we import from the expression AST, instead of trying to import these temporary declarations, check if we
can instead import from the persistent ASTContext that is already connected. This ensures that all records from the persistent source actually
come from the persistent source and are minimally imported in a way that allows them to be completed later on in the target AST.
The next step is to run the ASTImporter for these temporary expressions with the MinimalImport mode disabled, but that's a follow up patch.
This patch fixes most test failures with modern-type-lookup enabled by default (down to 73 failing tests, which includes the 22 import-std-module tests
which need special treatment).
Paul Hoad [Fri, 4 Oct 2019 08:10:22 +0000 (08:10 +0000)]
[clang-format] [PR43338] C# clang format has space issues betweern C# only keywords
Summary:
When formatting C# there can be issues with a lack of spaces between `using (` , `foreach (` and generic types
The C# code
```
public class Foo
{
Dictionary<string,string> foo;
}
```
will be formatted as
```
public class Foo
{
Dictionary<string, string>foo;
^^^^^ missing a space
}
```
This revision also reverts some of {D66662} in order to make this cleaner and resolve an issues seen by @owenpan that the formatting didn't add a space when not in a code block
This also transforms C# foreach commands to be seen as tok::kw_for commands (to ensure foreach gets the same Brace Wrapping behavior as for without littering the code with `if(Style.isCSharp())`
Paul Hoad [Fri, 4 Oct 2019 07:56:49 +0000 (07:56 +0000)]
[clang-format] [PR43333] Fix C# breaking before function name when using Attributes
Summary:
This is a fix for https://bugs.llvm.org/show_bug.cgi?id=43333
This comes with 3 main parts
- C# attributes cause function names on a new line even when AlwaysBreakAfterReturnType is set to None
- Add AlwaysBreakAfterReturnType to None by default in the Microsoft style,
- C# unit tests are not using Microsoft style (which we created to define the default C# style to match a vanilla C# project).
We previously failed to treat an array with an instantiation-dependent
but not value-dependent bound as being an instantiation-dependent type.
We now track the array bound expression as part of a constant array type
if it's an instantiation-dependent expression.
The static analyzer is warning about a potential null dereference, but we should be able to use castAs<FunctionProtoType> directly and if not assert will fire for us.
Also replaces an auto to make the type more obvious.
Alexey Bataev [Thu, 3 Oct 2019 20:49:48 +0000 (20:49 +0000)]
[OPENMP50]Codegen support for scores in context selectors.
If the context selector has associated score and several contexts
selectors matches current context, the function with the highest score
must be selected.
Richard Smith [Thu, 3 Oct 2019 18:55:23 +0000 (18:55 +0000)]
Check for qualified function types after substituting into the operand
of 'typeid'.
This is a rare place where it's valid for a function type to be
substituted but not valid for a qualified function type to be
substituted, so needs a special check.
Paul Hoad [Thu, 3 Oct 2019 18:42:31 +0000 (18:42 +0000)]
[clang-format] Add ability to wrap braces after multi-line control statements
Summary:
Change the BraceWrappingFlags' AfterControlStatement from a bool to an enum with three values:
* "Never": This is the default, and does not do any brace wrapping after control statements.
* "MultiLine": This only wraps braces after multi-line control statements (this really only happens when a ColumnLimit is specified).
* "Always": This always wraps braces after control statements.
The first and last options are backwards-compatible with "false" and "true", respectively.
The new "MultiLine" option is useful for when a wrapped control statement's indentation matches the subsequent block's indentation. It makes it easier to see at a glance where the control statement ends and where the block's code begins. For example:
```
if (
foo
&& bar )
{
baz();
}
```
vs.
```
if (
foo
&& bar ) {
baz();
}
```
Short control statements (1 line) do not wrap the brace to the next line, e.g.
The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us.
The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us.
Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790
[libTooling] Add various Stencil combinators for expressions.
Summary:
This revision adds three new Stencil combinators:
* `expression`, which idiomatically constructs the source for an expression,
including wrapping the expression's source in parentheses if needed.
* `deref`, which constructs an idiomatic dereferencing expression.
* `addressOf`, which constructs an idiomatic address-taking expression.
Summary:
This is a prerequisite to removing `llvm::GlobalObject::setAlignment(unsigned)`.
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790
The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<RecordType> directly and if not assert will fire for us.
Serge Pavlov [Thu, 3 Oct 2019 04:52:46 +0000 (04:52 +0000)]
Fix driver tests when `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR` is `ON`
Some Driver tests relied on the default resource direcory having per-os per-arch
subdirectory layout, and when clang is built with `-DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON`,
those test fail, because clang by default assumes per-target subdirectories.
Explicitly set `-resource-dir` flag to point to a tree with per-os per-arch layout.
Richard Smith [Thu, 3 Oct 2019 01:20:27 +0000 (01:20 +0000)]
PR43519: don't inject a diagnostic when constant-evaulation of a
pointer-to-member call can't determine a callee.
We will have produced a diagnostic already if the callee is known to be
unevaluatable, and diagnosing here rejects valid code during potential
constant expression checking.
Puyan Lotfi [Thu, 3 Oct 2019 01:19:51 +0000 (01:19 +0000)]
Fixing broken builds due to r373538, issues with filepath and hexagon toolchain.
It appears there are some issues with the hexagon toolchain, and also the file
path for the library file. If this doesn't fix the remaining breakages I will
attempt a revert.
Richard Smith [Thu, 3 Oct 2019 00:39:35 +0000 (00:39 +0000)]
For P0784R7: support placement new-expressions in constant evaluation.
For now, we restrict this support to use from within the standard
library implementation, since we're required to make parts of the
standard library that use placement new work, but not permitted to
make uses of placement new from user code work.
will product an ELF binary with visible symbols populated. Visibility attributes
and -fvisibility can be used to control what gets populated.
* Adding ToolChain support for clang Driver IFS Merge Phase
* Implementing a default InterfaceStubs Merge clang Tool, used by ToolChain
* Adds support for the clang Driver to involve llvm-ifs on ifs files.
* Adds -emit-merged-ifs flag, to tell llvm-ifs to emit a merged ifs text file
instead of the final object format (normally ELF)
The static analyzer is warning about potential null dereferences, but we should be able to use castAs<RecordType> directly and if not assert will fire for us.
The static analyzer is warning about potential null dereferences, but we should be able to use cast<>/castAs<> directly and if not assert will fire for us.
Alexey Bataev [Wed, 2 Oct 2019 18:19:02 +0000 (18:19 +0000)]
[OPENMP50]Add parsing/sema analysis for declare variant score.
Context selectors may include optional score clause in format
`score(<expr>):`, where `<expr>` must be a constant integer expression.
Added parsing/sema analysis only.
Simon Pilgrim [Wed, 2 Oct 2019 16:03:36 +0000 (16:03 +0000)]
Type - silence static analyzer getAs<> null dereference warnings. NFCI.
The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us.
The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<VectorType> directly and if not assert will fire for us.
The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us.
The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us.
Sam McCall [Wed, 2 Oct 2019 09:50:40 +0000 (09:50 +0000)]
[ClangFormat] Future-proof Standard option, allow floating or pinning to arbitrary lang version
Summary:
The historical context:
- clang-format was written when C++11 was current,
and the main language-version concern was >> vs > > template-closers.
An option was added to allow selection of the 03/11 behavior, or auto-detection.
- there was no option to choose simply "latest standard" so anyone who didn't
ever want 03 behavior or auto-detection specified Cpp11.
- In r185149 this option started to affect lexer mode.
- no options were added to cover c++14, as parsing/formatting
didn't change that much. The usage of Cpp11 to mean "latest" became
codified e.g. in r206263
- c++17 added some new constructs. These were mostly backwards-compatible and so
not used in old programs, so having no way to turn them off was OK.
- c++20 added some new constructs and keywords (e.g. co_*) that changed the
meaning of existing programs, and people started to complain that
the c++20 parsing couldn't be turned off.
New plan:
- Default ('Auto') behavior remains unchanged: parse as latest, format
template-closers based on input.
- Add new 'Latest' option that more clearly expresses the intent "use
modern features" that many projects have chosen for their .clang-format files.
- Allow pinning to *any* language version, using the same name as clang -std:
c++03, c++11, c++14 etc. These set precise lexer options, and any
clang-format code depending on these can use a >= check.
- For backwards compatibility, `Cpp11` is an alias for `Latest`, not `c++11`.
This matches the historical documented semantics of this option.
This spelling (and `Cpp03`) are deprecated.
Richard Trieu [Wed, 2 Oct 2019 02:32:15 +0000 (02:32 +0000)]
Revert r368237 - Update fix-it hints for std::move warnings.
r368237 attempted to improve fix-its for move warnings, but introduced some
regressions to -Wpessimizing-move. Revert that change and add the missing
test cases to the pessimizing move test to prevent future regressions.
projects / clang / log