merge the latest LLVM master branch changes #21
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…g variables in a block The fixit is actively harmful, as it encourages developers to ignore the warning and to write unsafe code. It is almost impossible to write safe code while capturing autoreleasing variables in the block, as in order to check that the block is never called in the autoreleasing pool the developer has to check the transitive closure of all potential callers of the block. Differential Revision: https://reviews.llvm.org/D46778 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@332288 91177308-0d34-0410-b5e6-96231b3b80d8
If the name after 'template' is an unresolved using declaration (not containing 'typename'), then we don't yet know if it's a valid template-name, so don't reject it prior to instantiation. Instead, treat it as naming a dependent member of the current instantiation. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@332291 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@332294 91177308-0d34-0410-b5e6-96231b3b80d8
Initial support for passing the virtual base pointer offset to CodeViewDebug. https://reviews.llvm.org/D46271 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@332296 91177308-0d34-0410-b5e6-96231b3b80d8
… as well A common pattern is that the code in the block does not write into the variable explicitly, but instead passes it to a helper function which performs the write. Differential Revision: https://reviews.llvm.org/D46772 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@332300 91177308-0d34-0410-b5e6-96231b3b80d8
…cpy()...". Fixed after revert in r331401. Patch by David Carlier! Differential Revision: https://reviews.llvm.org/D45177 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@332303 91177308-0d34-0410-b5e6-96231b3b80d8
…error. After a fatal error Sema::InstantiatingTemplate doesn't allow further instantiation and doesn't push a CodeSynthesisContext. When we tried to synthesize implicit deduction guides from constructors we hit the assertion > Assertion failed: (!CodeSynthesisContexts.empty() && "Cannot perform an instantiation without some context on the " "instantiation stack"), function SubstType, file clang/lib/Sema/SemaTemplateInstantiate.cpp, line 1580. Fix by avoiding deduction guide synthesis if InstantiatingTemplate is invalid. rdar://problem/39051732 Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D46446 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@332307 91177308-0d34-0410-b5e6-96231b3b80d8
Like other conversion warnings, allow float overflow warnings to be disabled in known dead paths of template instantiation. This often occurs when a template template type is a numeric type and the template will check the range of the numeric type before performing the conversion. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@332310 91177308-0d34-0410-b5e6-96231b3b80d8
For example, given:
struct T1 {
struct T2 *p0;
};
-ast-print produced:
struct T1 {
struct T2;
struct T2 *p0;
};
Compiling that produces a warning that the first struct T2 declaration
does not declare anything.
Details:
A tag decl group is one or more decls that share a type specifier that
is a tag decl (that is, a struct/union/class/enum decl). Within
functions, the parser builds such a tag decl group as part of a
DeclStmt. However, in decl contexts, such as file scope or a member
list, the parser does not group together the members of a tag decl
group. Previously, detection of tag decl groups during printing was
implemented but only if the tag decl was unnamed. Otherwise, as in
the above example, the members of the group did not print together and
so sometimes introduced warnings.
This patch extends detection of tag decl groups in decl contexts to
any tag decl that is recorded in the AST as not free-standing.
Reviewed by: rsmith
Differential Revision: https://reviews.llvm.org/D45465
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@332314 91177308-0d34-0410-b5e6-96231b3b80d8
…some of the avx512 truncate builtins. The masking doesn't work right in the backend for the ones that produce byte or word elements without avx512bw. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@332322 91177308-0d34-0410-b5e6-96231b3b80d8
It was failing because on Windows, -ast-print prints __single_inheritance(1) before T1. Adding a triple is a stop-gap fix until it can be fixed properly. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@332335 91177308-0d34-0410-b5e6-96231b3b80d8
During import of a class template, lookup may find a forward declaration and structural match falsely reports equivalency between a forward decl and a definition. The result is that some definitions are not imported if we had imported a forward decl previously. This patch gives a fix. Patch by Gabor Marton! Differential Revision: https://reviews.llvm.org/D46353 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@332338 91177308-0d34-0410-b5e6-96231b3b80d8
When looking at lib/Basic/Targets/OSTargets.h, I noticed that _REENTRANT is defined unconditionally on Solaris, unlike all other targets and what either Studio cc (only define it with -mt) or gcc (only define it with -pthread) do. This patch follows that lead. Differential Revision: https://reviews.llvm.org/D41241 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@332343 91177308-0d34-0410-b5e6-96231b3b80d8
The DEBUG() macro is very generic so it might clash with other projects. The renaming was done as follows: - git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g' - git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM Explicitly avoided changing the strings in the clang-format tests. Differential Revision: https://reviews.llvm.org/D44975 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@332350 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@332370 91177308-0d34-0410-b5e6-96231b3b80d8
In generic data-sharing mode we do not need to globalize variables/parameters of reference/pointer types. They already are placed in the global memory. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@332380 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@332383 91177308-0d34-0410-b5e6-96231b3b80d8
Certain tests in rtti-options.cpp are not really testing anything because they are testing for the absence of -frtti option to the cc1 process. Since the cc1 process does not take -frtti option, these tests are passing tautologically. The RTTI mode is enabled by default in cc1, and -fno-rtti disables it. Therefore the correct way to check for enabling of RTTI is to check for the absence of -fno-rtti to cc1, and the correct way to check for disabling of RTTI is to check for the presence of -fno-rtti to cc1. This patch fixes those tests. Differential Revision: https://reviews.llvm.org/D46836 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@332384 91177308-0d34-0410-b5e6-96231b3b80d8
- Define a function (canPassInRegisters) that determines whether a record can be passed in registers based on language rules and target-specific ABI rules. - Set flag RecordDecl::ParamDestroyedInCallee to true in MSVC mode and remove ASTContext::isParamDestroyedInCallee, which is no longer needed. - Use the same type (unsigned) for RecordDecl's bit-field members. For more background, see the following discussions that took place on cfe-commits. http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180326/223498.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180402/223688.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180409/224754.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180423/226494.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180507/227647.html git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@332397 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@332400 91177308-0d34-0410-b5e6-96231b3b80d8
…very lambda with no explicit return type. We already warned about the lambda, and we don't have a source location for the imagined "auto" anyway. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@332401 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@332405 91177308-0d34-0410-b5e6-96231b3b80d8
Fixes bug reported at: http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180514/228390.html Reviewed by: aaron.ballman Differential Revision: https://reviews.llvm.org/D46894 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@332411 91177308-0d34-0410-b5e6-96231b3b80d8
…orts. Previously plist-html output produced multi-file HTML reports but only single-file Plist reports. Change plist-html output to produce multi-file Plist reports as well. Differential Revision: https://reviews.llvm.org/D46902 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@332417 91177308-0d34-0410-b5e6-96231b3b80d8
It was decided this is the wrong approach to fix this issue. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@332421 91177308-0d34-0410-b5e6-96231b3b80d8
https://bugs.llvm.org/show_bug.cgi?id=37312 rdar://40270582 Differential Revision: https://reviews.llvm.org/D46913 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@332422 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@332425 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch changes the behavior of PenaltyBreakBeforeFirstCallParameter
so that is does not apply after a brace, when Cpp11BracedListStyle is
false.
This way, variable initialization is wrapped more like an initializer
than like a function call, which is more consistent with user
expectations for this braced list style.
With PenaltyBreakBeforeFirstCallParameter=200, this gives the following
code: (with Cpp11BracedListStyle=false)
Before :
const std::unordered_map<std::string, int> Something::MyHashTable =
{ { "aaaaaaaaaaaaaaaaaaaaa", 0 },
{ "bbbbbbbbbbbbbbbbbbbbb", 1 },
{ "ccccccccccccccccccccc", 2 } };
After :
const std::unordered_set<std::string> Something::MyUnorderedSet = {
{ "aaaaaaaaaaaaaaaaaaaaa", 0 },
{ "bbbbbbbbbbbbbbbbbbbbb", 1 },
{ "ccccccccccccccccccccc", 2 }
};
Reviewers: krasimir, djasper, klimek
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D43290
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@332434 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Introduce `PenaltyBreakTemplateDeclaration` to control the penalty, and change `AlwaysBreakTemplateDeclarations` to an enum with 3 modes: * `No` for regular, penalty based, wrapping of template declaration * `MultiLine` for always wrapping before multi-line declarations (e.g. same as legacy behavior when `AlwaysBreakTemplateDeclarations=false`) * `Yes` for always wrapping (e.g. same as legacy behavior when `AlwaysBreakTemplateDeclarations=true`) Reviewers: krasimir, djasper, klimek Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D42684 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@332436 91177308-0d34-0410-b5e6-96231b3b80d8
Although not very well known, diagtool is an incredibly convenient utility for dealing with diagnostics. Particularly useful are the "tree" and "show-enabled" commands: - The former prints the hierarchy of diagnostic (warning) flags and which of them are enabled by default. - The latter can be used to replace an invocation to clang and will print which diagnostics are disabled, warnings or errors. For instance: `diagtool show-enabled -Wall -Werror /tmp/test.c` will print that -Wunused-variable (warn_unused_variable) will be treated as an error. This patch adds them to the install target so it gets shipped with the LLVM release. It also adds a very basic man page and mentions this change in the release notes. Differential revision: https://reviews.llvm.org/D46694 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@332448 91177308-0d34-0410-b5e6-96231b3b80d8
Mostly this fixes the names of all the 128-bit intrinsics to start with _mm_ instead of _mm128_ as is the convention and what the Intel docs say. This also fixes the name of the bitshuffle intrinsics to say epi64 for 128 and 256 bit versions. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333497 91177308-0d34-0410-b5e6-96231b3b80d8
…ypes. Codebases that need to be compatible with the Microsoft ABI can pass this flag to avoid issues caused by the lack of a fixed ABI for incomplete member pointers. Differential Revision: https://reviews.llvm.org/D47503 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333498 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The previous implementation misses an opportunity to apply NRVO (Named Return Value
Optimization) below. That discourages user to write early return code.
```
struct Foo {};
Foo f(bool b) {
if (b)
return Foo();
Foo oo;
return oo;
}
```
That is, we can/should apply RVO for a local variable if:
* It's directly returned by at least one return statement.
* And, all reachable return statements in its scope returns the variable directly.
While, the previous implementation disables the RVO in a scope if there are multiple return
statements that refers different variables.
On the new algorithm, local variables are in NRVO_Candidate state at first, and a return
statement changes it to NRVO_Disabled for all visible variables but the return statement refers.
Then, at the end of the function AST traversal, NRVO is enabled for variables in NRVO_Candidate
state and refers from at least one return statement.
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: xbolva00, Quuxplusone, arthur.j.odwyer, cfe-commits
Differential Revision: https://reviews.llvm.org/D47067
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333500 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333501 91177308-0d34-0410-b5e6-96231b3b80d8
… instead. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333509 91177308-0d34-0410-b5e6-96231b3b80d8
Reviewers: jyknight Reviewed By: jyknight Subscribers: eraman, fedor.sergeev, jrtc27, cfe-commits Differential Revision: https://reviews.llvm.org/D47137 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333510 91177308-0d34-0410-b5e6-96231b3b80d8
These intrinsics are used by MSVC's header files on AArch64 Windows as well as AArch32, so we should support them for both targets. I've factored them out of CodeGenFunction::EmitARMBuiltinExpr into separate functions that EmitAArch64BuiltinExpr can call as well. Reviewers: javed.absar, mstorsjo Reviewed By: mstorsjo Subscribers: kristof.beyls, cfe-commits Differential Revision: https://reviews.llvm.org/D47476 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333513 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333514 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333515 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: When a CXXRecordDecl under ClassTemplateDecl is imported, check the templated record decl for similarity instead of the template. Reviewers: a.sidorin Reviewed By: a.sidorin Subscribers: martong, cfe-commits Differential Revision: https://reviews.llvm.org/D47313 Patch by Balazs Keri! git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333522 91177308-0d34-0410-b5e6-96231b3b80d8
I missed updating the check in r333375 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333529 91177308-0d34-0410-b5e6-96231b3b80d8
…`ArrayBoundCheckerV2.cpp`. Summary: Since the `addTransitionImpl()` has a check about same state transition, there is no need to check it in `ArrayBoundCheckerV2.cpp`. Reviewers: NoQ, xazax.hun, george.karpenkov Reviewed By: NoQ Subscribers: szepet, rnkovacs, a.sidorin, cfe-commits, MTC Differential Revision: https://reviews.llvm.org/D47451 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333531 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r332751 (i.e. reland r332720) after fixing module build. Differential Revision: https://reviews.llvm.org/D47068 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333532 91177308-0d34-0410-b5e6-96231b3b80d8
…clusions."" This reverts commit r333532. Revert for now to fix an internal bot issue. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333534 91177308-0d34-0410-b5e6-96231b3b80d8
… type Summary: Skipping them was clearly not intentional. It's impossible to guarantee correctness if the bodies are skipped. Also adds a test case for r327504, now that it does not produce invalid errors that made the test fail. Reviewers: aaron.ballman, sammccall, rsmith Reviewed By: rsmith Subscribers: rayglover-ibm, rwols, cfe-commits Differential Revision: https://reviews.llvm.org/D44480 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333538 91177308-0d34-0410-b5e6-96231b3b80d8
… for multiline receiver" Summary: This reverts commit db9e5e9 (rC333171). Mentioned change introduced unintended formatting of ObjC code due to split priorities inherited from C/C++, e.g.: ``` fooooooo = [ [obj fooo] aaa:42 aaa:42]; ``` instead of ``` fooooooo = [[obj fooo] aaa:42 aaa:42]; ``` when formatted with ColumnLimit = 30. Reviewers: krasimir Reviewed By: krasimir Subscribers: benhamilton, klimek, cfe-commits Differential Revision: https://reviews.llvm.org/D47527 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333539 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r333500, which causes stage2 compiler crashes. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333547 91177308-0d34-0410-b5e6-96231b3b80d8
…in name Summary: Please take a close look at this CL. I haven't touched much of `UnwrappedLineParser` before, so I may have gotten things wrong. Previously, clang-format would incorrectly format the following: ``` @implementation Foo - (Class)class { } - (void)foo { } @EnD ``` as: ``` @implementation Foo - (Class)class { } - (void)foo { } @EnD ``` The problem is whenever `UnwrappedLineParser::parseStructuralElement()` sees any of the keywords `class`, `struct`, or `enum`, it calls `parseRecord()` to parse them as a C/C++ record. This causes subsequent lines to be parsed incorrectly, which causes them to be indented incorrectly. In Objective-C/Objective-C++, these keywords are valid selector components. This diff fixes the issue by explicitly handling `+` and `-` lines inside `@implementation` / `@interface` / `@protocol` blocks and parsing them as Objective-C methods. Test Plan: New tests added. Ran tests with: make -j16 FormatTests && ./tools/clang/unittests/Format/FormatTests Reviewers: jolesiak, klimek Reviewed By: jolesiak, klimek Subscribers: klimek, cfe-commits, Wizard Differential Revision: https://reviews.llvm.org/D47095 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333553 91177308-0d34-0410-b5e6-96231b3b80d8
This patch replaces all packed (and scalar without rounding mode) fused intrinsics with fmadd/fmaddsub variations. Then fmadd/fmaddsub are lowered to native IR. Patch by tkrupa Reviewers: craig.topper, sroland, spatel, RKSimon Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D47444 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333555 91177308-0d34-0410-b5e6-96231b3b80d8
… use a builtin that returns void. Found by running the intrinsic headers through -pedantic -ansi. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333563 91177308-0d34-0410-b5e6-96231b3b80d8
… by the Intel Intrinsics Guide. We had quite a few for different element sizes of integers sometimes with strange target features attached to them. We only need a single version for each of _m128i, _m256i, and _m512i with the target feature that first introduced those types. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333568 91177308-0d34-0410-b5e6-96231b3b80d8
Conflicts: include/clang/Driver/ToolChain.h lib/Driver/ToolChains/Linux.h
schweitzpgi
pushed a commit
to schweitzpgi/obsolete-flang-driver
that referenced
this pull request
Apr 22, 2019
The assertion prevents it from applying fixes when used along with compilation
databases with relative paths. Added a test that demonstrates the assertion
failure.
An example of the assertion:
input.cpp:11:14: error: expected ';' after top level declarator
typedef int T
^
;
input.cpp:11:14: note: FIX-IT applied suggested code changes
clang-check: clang/tools/clang-check/ClangCheck.cpp:94: virtual std::string (anonymous namespace)::FixItOptions::RewriteFilename(const std::string &, int &): Assertion `llvm::sys::path::is_absolute(filename) && "clang-fixit expects absolute paths only."' failed.
#0 llvm::sys::PrintStackTrace(llvm::raw_ostream&) llvm/lib/Support/Unix/Signals.inc:494:13
flang-compiler#1 llvm::sys::RunSignalHandlers() llvm/lib/Support/Signals.cpp:69:18
flang-compiler#2 SignalHandler(int) llvm/lib/Support/Unix/Signals.inc:357:1
flang-compiler#3 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x110c0)
flang-compiler#4 raise (/lib/x86_64-linux-gnu/libc.so.6+0x32fcf)
flang-compiler#5 abort (/lib/x86_64-linux-gnu/libc.so.6+0x343fa)
flang-compiler#6 (/lib/x86_64-linux-gnu/libc.so.6+0x2be37)
flang-compiler#7 (/lib/x86_64-linux-gnu/libc.so.6+0x2bee2)
flang-compiler#8 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*, std::forward_iterator_tag)
flang-compiler#9 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char*>(char*, char*, std::__false_type)
flang-compiler#10 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*)
flang-compiler#11 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
flang-compiler#12 (anonymous namespace)::FixItOptions::RewriteFilename(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int&) clang/tools/clang-check/ClangCheck.cpp:101:0
flang-compiler#13 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_data() const
flang-compiler#14 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_is_local() const
flang-compiler#15 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_dispose()
flang-compiler#16 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()
flang-compiler#17 clang::FixItRewriter::WriteFixedFiles(std::vector<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >*) clang/lib/Frontend/Rewrite/FixItRewriter.cpp:98:0
flang-compiler#18 std::__shared_ptr<clang::CompilerInvocation, (__gnu_cxx::_Lock_policy)2>::get() const
flang-compiler#19 std::__shared_ptr_access<clang::CompilerInvocation, (__gnu_cxx::_Lock_policy)2, false, false>::_M_get() const
flang-compiler#20 std::__shared_ptr_access<clang::CompilerInvocation, (__gnu_cxx::_Lock_policy)2, false, false>::operator->() const
flang-compiler#21 clang::CompilerInstance::getFrontendOpts() clang/include/clang/Frontend/CompilerInstance.h:290:0
flang-compiler#22 clang::FrontendAction::EndSourceFile() clang/lib/Frontend/FrontendAction.cpp:966:0
flang-compiler#23 __gnu_cxx::__normal_iterator<clang::FrontendInputFile*, std::vector<clang::FrontendInputFile, std::allocator<clang::FrontendInputFile> > >::operator++()
flang-compiler#24 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) clang/lib/Frontend/CompilerInstance.cpp:943:0
flang-compiler#25 clang::tooling::FrontendActionFactory::runInvocation(std::shared_ptr<clang::CompilerInvocation>, clang::FileManager*, std::shared_ptr<clang::PCHContainerOperations>, clang::DiagnosticConsumer*) clang/lib/Tooling/Tooling.cpp:369:33
flang-compiler#26 clang::tooling::ToolInvocation::runInvocation(char const*, clang::driver::Compilation*, std::shared_ptr<clang::CompilerInvocation>, std::shared_ptr<clang::PCHContainerOperations>) clang/lib/Tooling/Tooling.cpp:344:18
flang-compiler#27 clang::tooling::ToolInvocation::run() clang/lib/Tooling/Tooling.cpp:329:10
flang-compiler#28 clang::tooling::ClangTool::run(clang::tooling::ToolAction*) clang/lib/Tooling/Tooling.cpp:518:11
flang-compiler#29 main clang/tools/clang-check/ClangCheck.cpp:187:15
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@357915 91177308-0d34-0410-b5e6-96231b3b80d8
schweitzpgi
pushed a commit
to schweitzpgi/obsolete-flang-driver
that referenced
this pull request
Apr 22, 2019
…heck.
The assertion prevents it from applying fixes when used along with compilation
databases with relative paths. Added a test that demonstrates the assertion
failure.
An example of the assertion:
input.cpp:11:14: error: expected ';' after top level declarator
typedef int T
^
;
input.cpp:11:14: note: FIX-IT applied suggested code changes
clang-check: clang/tools/clang-check/ClangCheck.cpp:94: virtual std::string (anonymous namespace)::FixItOptions::RewriteFilename(const std::string &, int &): Assertion `llvm::sys::path::is_absolute(filename) && "clang-fixit expects absolute paths only."' failed.
#0 llvm::sys::PrintStackTrace(llvm::raw_ostream&) llvm/lib/Support/Unix/Signals.inc:494:13
flang-compiler#1 llvm::sys::RunSignalHandlers() llvm/lib/Support/Signals.cpp:69:18
flang-compiler#2 SignalHandler(int) llvm/lib/Support/Unix/Signals.inc:357:1
flang-compiler#3 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x110c0)
flang-compiler#4 raise (/lib/x86_64-linux-gnu/libc.so.6+0x32fcf)
flang-compiler#5 abort (/lib/x86_64-linux-gnu/libc.so.6+0x343fa)
flang-compiler#6 (/lib/x86_64-linux-gnu/libc.so.6+0x2be37)
flang-compiler#7 (/lib/x86_64-linux-gnu/libc.so.6+0x2bee2)
flang-compiler#8 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*, std::forward_iterator_tag)
flang-compiler#9 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char*>(char*, char*, std::__false_type)
flang-compiler#10 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*)
flang-compiler#11 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
flang-compiler#12 (anonymous namespace)::FixItOptions::RewriteFilename(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int&) clang/tools/clang-check/ClangCheck.cpp:101:0
flang-compiler#13 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_data() const
flang-compiler#14 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_is_local() const
flang-compiler#15 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_dispose()
flang-compiler#16 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()
flang-compiler#17 clang::FixItRewriter::WriteFixedFiles(std::vector<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >*) clang/lib/Frontend/Rewrite/FixItRewriter.cpp:98:0
flang-compiler#18 std::__shared_ptr<clang::CompilerInvocation, (__gnu_cxx::_Lock_policy)2>::get() const
flang-compiler#19 std::__shared_ptr_access<clang::CompilerInvocation, (__gnu_cxx::_Lock_policy)2, false, false>::_M_get() const
flang-compiler#20 std::__shared_ptr_access<clang::CompilerInvocation, (__gnu_cxx::_Lock_policy)2, false, false>::operator->() const
flang-compiler#21 clang::CompilerInstance::getFrontendOpts() clang/include/clang/Frontend/CompilerInstance.h:290:0
flang-compiler#22 clang::FrontendAction::EndSourceFile() clang/lib/Frontend/FrontendAction.cpp:966:0
flang-compiler#23 __gnu_cxx::__normal_iterator<clang::FrontendInputFile*, std::vector<clang::FrontendInputFile, std::allocator<clang::FrontendInputFile> > >::operator++()
flang-compiler#24 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) clang/lib/Frontend/CompilerInstance.cpp:943:0
flang-compiler#25 clang::tooling::FrontendActionFactory::runInvocation(std::shared_ptr<clang::CompilerInvocation>, clang::FileManager*, std::shared_ptr<clang::PCHContainerOperations>, clang::DiagnosticConsumer*) clang/lib/Tooling/Tooling.cpp:369:33
flang-compiler#26 clang::tooling::ToolInvocation::runInvocation(char const*, clang::driver::Compilation*, std::shared_ptr<clang::CompilerInvocation>, std::shared_ptr<clang::PCHContainerOperations>) clang/lib/Tooling/Tooling.cpp:344:18
flang-compiler#27 clang::tooling::ToolInvocation::run() clang/lib/Tooling/Tooling.cpp:329:10
flang-compiler#28 clang::tooling::ClangTool::run(clang::tooling::ToolAction*) clang/lib/Tooling/Tooling.cpp:518:11
flang-compiler#29 main clang/tools/clang-check/ClangCheck.cpp:187:15
........
Breaks windows buildbots
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@357918 91177308-0d34-0410-b5e6-96231b3b80d8
schweitzpgi
pushed a commit
to schweitzpgi/obsolete-flang-driver
that referenced
this pull request
Apr 22, 2019
Re-commit r357915 with a fix for windows.
The assertion prevents it from applying fixes when used along with compilation
databases with relative paths. Added a test that demonstrates the assertion
failure.
An example of the assertion:
input.cpp:11:14: error: expected ';' after top level declarator
typedef int T
^
;
input.cpp:11:14: note: FIX-IT applied suggested code changes
clang-check: clang/tools/clang-check/ClangCheck.cpp:94: virtual std::string (anonymous namespace)::FixItOptions::RewriteFilename(const std::string &, int &): Assertion `llvm::sys::path::is_absolute(filename) && "clang-fixit expects absolute paths only."' failed.
#0 llvm::sys::PrintStackTrace(llvm::raw_ostream&) llvm/lib/Support/Unix/Signals.inc:494:13
flang-compiler#1 llvm::sys::RunSignalHandlers() llvm/lib/Support/Signals.cpp:69:18
flang-compiler#2 SignalHandler(int) llvm/lib/Support/Unix/Signals.inc:357:1
flang-compiler#3 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x110c0)
flang-compiler#4 raise (/lib/x86_64-linux-gnu/libc.so.6+0x32fcf)
flang-compiler#5 abort (/lib/x86_64-linux-gnu/libc.so.6+0x343fa)
flang-compiler#6 (/lib/x86_64-linux-gnu/libc.so.6+0x2be37)
flang-compiler#7 (/lib/x86_64-linux-gnu/libc.so.6+0x2bee2)
flang-compiler#8 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*, std::forward_iterator_tag)
flang-compiler#9 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char*>(char*, char*, std::__false_type)
flang-compiler#10 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*)
flang-compiler#11 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
flang-compiler#12 (anonymous namespace)::FixItOptions::RewriteFilename(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int&) clang/tools/clang-check/ClangCheck.cpp:101:0
flang-compiler#13 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_data() const
flang-compiler#14 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_is_local() const
flang-compiler#15 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_dispose()
flang-compiler#16 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()
flang-compiler#17 clang::FixItRewriter::WriteFixedFiles(std::vector<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >*) clang/lib/Frontend/Rewrite/FixItRewriter.cpp:98:0
flang-compiler#18 std::__shared_ptr<clang::CompilerInvocation, (__gnu_cxx::_Lock_policy)2>::get() const
flang-compiler#19 std::__shared_ptr_access<clang::CompilerInvocation, (__gnu_cxx::_Lock_policy)2, false, false>::_M_get() const
flang-compiler#20 std::__shared_ptr_access<clang::CompilerInvocation, (__gnu_cxx::_Lock_policy)2, false, false>::operator->() const
flang-compiler#21 clang::CompilerInstance::getFrontendOpts() clang/include/clang/Frontend/CompilerInstance.h:290:0
flang-compiler#22 clang::FrontendAction::EndSourceFile() clang/lib/Frontend/FrontendAction.cpp:966:0
flang-compiler#23 __gnu_cxx::__normal_iterator<clang::FrontendInputFile*, std::vector<clang::FrontendInputFile, std::allocator<clang::FrontendInputFile> > >::operator++()
flang-compiler#24 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) clang/lib/Frontend/CompilerInstance.cpp:943:0
flang-compiler#25 clang::tooling::FrontendActionFactory::runInvocation(std::shared_ptr<clang::CompilerInvocation>, clang::FileManager*, std::shared_ptr<clang::PCHContainerOperations>, clang::DiagnosticConsumer*) clang/lib/Tooling/Tooling.cpp:369:33
flang-compiler#26 clang::tooling::ToolInvocation::runInvocation(char const*, clang::driver::Compilation*, std::shared_ptr<clang::CompilerInvocation>, std::shared_ptr<clang::PCHContainerOperations>) clang/lib/Tooling/Tooling.cpp:344:18
flang-compiler#27 clang::tooling::ToolInvocation::run() clang/lib/Tooling/Tooling.cpp:329:10
flang-compiler#28 clang::tooling::ClangTool::run(clang::tooling::ToolAction*) clang/lib/Tooling/Tooling.cpp:518:11
flang-compiler#29 main clang/tools/clang-check/ClangCheck.cpp:187:15
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@357921 91177308-0d34-0410-b5e6-96231b3b80d8
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.