master -merge latest changes from clang #28
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@335543 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: This adds an option -gsplit-dwarf=<arg>. LLVM can create .dwo files in the given directory during the implicit ThinLTO link stage. Reviewers: tejohnson, dblaikie, pcc Reviewed By: pcc Subscribers: steven_wu, aprantl, JDevlieghere, yunlian, probinson, mehdi_amini, inglorion, cfe-commits Differential Revision: https://reviews.llvm.org/D44788 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@335546 91177308-0d34-0410-b5e6-96231b3b80d8
It's a bit cleaner to use `hasFlag` instead of nested ifs. This just refactors the -moutline/-mno-outline logic to use that. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@335549 91177308-0d34-0410-b5e6-96231b3b80d8
Conservative evaluation of a C++ method call would invalidate the object, as long as the method is not const or the object has mutable fields. When checking for mutable fields, we need to scan the type of the object on which the method is called, which may be more specific than the type of the object on which the method is defined, hence we look up the type from the this-argument expression. If arrow syntax or implicit-this syntax is used, this-argument expression has pointer type, not record type, and lookup accidentally failed for that reason. Obtain object type correctly. Differential Revision: https://reviews.llvm.org/D48460 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@335555 91177308-0d34-0410-b5e6-96231b3b80d8
…ups. ExprWithCleanups wraps full-expressions that require temporary destructors and highlights the moment of time in which these destructors need to be called (i.e., "at the end of the full-expression..."). Such expressions don't necessarily return an object; they may return anything, including a null or undefined value. When the analyzer tries to understand where the null or undefined value came from in order to present better diagnostics to the user, it will now skip any ExprWithCleanups it encounters and look into the expression itself. Differential Revision: https://reviews.llvm.org/D48204 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@335559 91177308-0d34-0410-b5e6-96231b3b80d8
… and implement the mask input argument using an 'and' IR instruction. Additional IR is emitted to convert between scalar and vXi1 type to match the expected software inferface for the builtin that clang exposes. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@335564 91177308-0d34-0410-b5e6-96231b3b80d8
Similarly to CFI on virtual and indirect calls, this implementation tries to use program type information to make the checks as precise as possible. The basic way that it works is as follows, where `C` is the name of the class being defined or the target of a call and the function type is assumed to be `void()`. For virtual calls: - Attach type metadata to the addresses of function pointers in vtables (not the functions themselves) of type `void (B::*)()` for each `B` that is a recursive dynamic base class of `C`, including `C` itself. This type metadata has an annotation that the type is for virtual calls (to distinguish it from the non-virtual case). - At the call site, check that the computed address of the function pointer in the vtable has type `void (C::*)()`. For non-virtual calls: - Attach type metadata to each non-virtual member function whose address can be taken with a member function pointer. The type of a function in class `C` of type `void()` is each of the types `void (B::*)()` where `B` is a most-base class of `C`. A most-base class of `C` is defined as a recursive base class of `C`, including `C` itself, that does not have any bases. - At the call site, check that the function pointer has one of the types `void (B::*)()` where `B` is a most-base class of `C`. Differential Revision: https://reviews.llvm.org/D47567 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@335569 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@335571 91177308-0d34-0410-b5e6-96231b3b80d8
When the return type of an ObjC-style block literals is deduced, pick the candidate type with the strictest nullability annotation applicable to every other candidate. This suppresses a UBSan false-positive in situations where a too-strict nullability would be deduced, despite the fact that the returned value would be implicitly cast to _Nullable. rdar://41317163 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@335572 91177308-0d34-0410-b5e6-96231b3b80d8
Log: http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/11390 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@335577 91177308-0d34-0410-b5e6-96231b3b80d8
Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D48363 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@335595 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: At import of a record describing a template set its type to InjectedClassNameType (instead of RecordType). Reviewers: a.sidorin, martong, r.stahl Reviewed By: a.sidorin, martong, r.stahl Subscribers: a_sidorin, rnkovacs, martong, cfe-commits Differential Revision: https://reviews.llvm.org/D47450 Patch by Balazs Keri! git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@335600 91177308-0d34-0410-b5e6-96231b3b80d8
…rning. NFCI. Split the braces list initialization from the [] map operator to keep MSVC happy. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@335614 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Changes to some clang side tests to go with the summary parsing patch. Depends on D47905. Reviewers: pcc, dexonsmith, mehdi_amini Subscribers: inglorion, eraman, cfe-commits, steven_wu Differential Revision: https://reviews.llvm.org/D47906 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@335618 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: I am not sure anyone has tried to compile an application with sanitizers on Android with `-static-libsan`, and a recent NDK, but it fails with: ``` .../i686-linux-android/bin/ld.gold: error: cannot find -lpthread .../i686-linux-android/bin/ld.gold: error: cannot find -lrt ``` My understanding is that both are included in Bionic and as such are not needed, and actually error out. So remove the addition of those two in `linkSanitizerRuntimeDeps` when dealing with Android, and update the tests. I am unfamiliar with the evolution of the NDK and I am not sure if this has always been the case or if this is somewhat of a recent evolution. I'll let Android people chime in. Reviewers: eugenis, pirama, srhines Reviewed By: eugenis, srhines Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D48570 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@335620 91177308-0d34-0410-b5e6-96231b3b80d8
…t rename." This reverts commit r334550. Try to fix the stage2 build failing on Green Dragon for a while. http://green.lab.llvm.org/green/job/clang-stage2-Rthinlto/11124/console git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@335628 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@335630 91177308-0d34-0410-b5e6-96231b3b80d8
Patch tries to make better analysis of the variables that should be globalized. From now, instead of all parallel directives it will check only distribute parallel .. directives and check only for firstprivte/lastprivate variables if they must be globalized. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@335632 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: The hc.amdgcn.bc and hip.amdgcn.bc are removed in VDI build and no longer needed. Reviewers: yaxunl Reviewed By: yaxunl Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D48455 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@335634 91177308-0d34-0410-b5e6-96231b3b80d8
Apparently we're now hitting an object file section limit on this file with expensive checks enabled. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@335636 91177308-0d34-0410-b5e6-96231b3b80d8
NumTypos guard value ~0U doesn't prevent from creating new delayed typos. When you create new delayed typos during typo correction, value ~0U wraps around to 0. When NumTypos is 0 we can miss some typos and treat an expression as it can be typo-corrected. But if the expression is still invalid after correction, we can get stuck in infinite loop trying to correct it. Fix by not using value ~0U so that NumTypos correctly reflects the number of typos. rdar://problem/38642201 Reviewers: arphaman, majnemer, rsmith Reviewed By: rsmith Subscribers: rsmith, nicholas, cfe-commits Differential Revision: https://reviews.llvm.org/D47341 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@335638 91177308-0d34-0410-b5e6-96231b3b80d8
FreeBSD defaults to mips3 for all MIPS ABIs with GCC as that is the minimum MIPS architecture FreeBSD supports. Use mips3 for MIPS64 and mips2 for MIPS32 to match. Reviewed By: atanasyan Differential Revision: https://reviews.llvm.org/D48499 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@335653 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@335655 91177308-0d34-0410-b5e6-96231b3b80d8
In the current implementation, we run visitors until the fixed point is reached. That is, if a visitor adds another visitor, the currently processed path is destroyed, all diagnostics is discarded, and it is regenerated again, until it's no longer modified. This pattern has a few negative implications: - This loop does not even guarantee to terminate. E.g. just imagine two visitors bouncing a diagnostics around. - Performance-wise, e.g. for sqlite3 all visitors are being re-run at least 10 times for some bugs. We have already seen a few reports where it leads to timeouts. - If we want to add more computationally intense visitors, this will become worse. - From architectural standpoint, the current layout requires copying visitors, which is conceptually wrong, and can be annoying (e.g. no unique_ptr on visitors allowed). The proposed change is a much simpler architecture: the outer loop processes nodes upwards, and whenever the visitor is added it only processes current nodes and above, thus guaranteeing termination. Differential Revision: https://reviews.llvm.org/D47856 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@335666 91177308-0d34-0410-b5e6-96231b3b80d8
…targets Instead of just saying "flag unused", we should tell the user that the outliner isn't (at least officially) supported for some given architecture. This adds a warning that will state something like The 'blah' architecture does not support -moutline; flag ignored when we call -moutline with the 'blah' architecture. Since the outliner is still mostly an AArch64 thing, any architecture other than AArch64 will emit this warning. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@335672 91177308-0d34-0410-b5e6-96231b3b80d8
…erOptions. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@335683 91177308-0d34-0410-b5e6-96231b3b80d8
Depends on r334313, which has been reverted in r335681. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@335684 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@335685 91177308-0d34-0410-b5e6-96231b3b80d8
r335618 added tests that invoke llvm-as, so we should also ensure that running clang tests rebuilds llvm-as. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@335686 91177308-0d34-0410-b5e6-96231b3b80d8
We track when we see a name-shaped expression followed by a '<' token and parse the '<' as a comparison. Then: * if we see a token sequence that cannot possibly be an expression but can be a template argument (in particular, a type-id) that follows either a ',' or the '<', diagnose that the '<' was supposed to start a template argument list, and * if we see '>()', diagnose that the '<' was supposed to start a template argument list. This only changes the diagnostic for error cases, and in practice appears to catch the most common cases where a missing 'template' keyword leads to parse errors within a template. Differential Revision: https://reviews.llvm.org/D48571 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@335687 91177308-0d34-0410-b5e6-96231b3b80d8
The "casts away constness" check doesn't care at all how the different layers of the source and destination type were formed: for example, if the source is a pointer and the destination is a pointer-to-member, the types are still decomposed and their pointee qualifications are still checked. This rule is bizarre and somewhat ridiculous, so as an extension we accept code making use of such reinterpret_casts with a warning outside of SFINAE contexts. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@336738 91177308-0d34-0410-b5e6-96231b3b80d8
…ead of a copy of the intrinsic implementation. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@336739 91177308-0d34-0410-b5e6-96231b3b80d8
…instead of a copy of the intrinsic implementation. This had the same issue I just fixed in r336739. Apparently I copy pasted _mm512_mullo_epi64 when I added _mm512_mullox_epi64. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@336740 91177308-0d34-0410-b5e6-96231b3b80d8
…a type. This allows more qualification conversions, eg. conversion from 'int *(*)[]' -> 'const int *const (*)[]' is now permitted, along with all the consequences of that: more types are similar, more cases are permitted by const_cast, and conversely, fewer "casting away constness" cases are permitted by reinterpret_cast. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@336745 91177308-0d34-0410-b5e6-96231b3b80d8
the bitcast only changed cvr-qualifications within the pointer type. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@336746 91177308-0d34-0410-b5e6-96231b3b80d8
documentation for -fconstexpr-steps. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@336747 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: A forward-declared coroutine_traits should trip an error; we need a complete type. Unfortunately, in debug mode only, we trip an assert when attempting to provide the fully qualified type for the error message. If you try to compile a program with a forward-declared coroutine_traits in debug mode, clang will crash. I've included a test for the behavior and removed the q modifier on the error message. This prevents the crash in debug mode and does not change the behavior for the error message on a forward-declaration of a coroutine_traits type. Test Plan: I've included a test for the forward-declaration. Patch by Tanoy Sinha! Reviewers: modocache, GorNishanov Reviewed By: modocache Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D49099 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@336748 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: The file name was accidentally included when the test file was added. Test Plan: check-clang git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@336750 91177308-0d34-0410-b5e6-96231b3b80d8
…he checker constructor A lot of checkers could be cleaned up in a similar way Differential Revision: https://reviews.llvm.org/D49050 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@336753 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@336755 91177308-0d34-0410-b5e6-96231b3b80d8
To be investigated. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@336756 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Added structural equivalence check for C++ methods. Improved structural equivalence tests. Added related ASTImporter tests. Reviewers: a.sidorin, szepet, xazax.hun, martong, a_sidorin Reviewed By: martong, a_sidorin Subscribers: a_sidorin, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D48628 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@336776 91177308-0d34-0410-b5e6-96231b3b80d8
'-mvirt'/'-mno-virt' enables/disables Virtualization ASE. '-mginv'/'-mno-ginv' enables/disables GINV (Global Invalidate) ASE. Differential revision: https://reviews.llvm.org/D48982 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@336798 91177308-0d34-0410-b5e6-96231b3b80d8
…the requested name Summary: InMemoryFileSystem::status behaves differently than RealFileSystem::status. The Name contained in the Status returned by RealFileSystem::status will be the path as requested by the caller, whereas InMemoryFileSystem::status returns the normalized path. For example, when requested the status for "../src/first.h", RealFileSystem returns a Status with "../src/first.h" as the Name. InMemoryFileSystem returns "/absolute/path/to/src/first.h". The reason for this change is that I want to make a unit test in the clangd testsuite (where we use an InMemoryFileSystem) to reproduce a bug I get with the clangd program (where a RealFileSystem is used). This difference in behavior "hides" the bug in the unit test version. In general, I guess it's good if InMemoryFileSystem works as much as possible like RealFileSystem. Doing so made the FileEntry::RealPathName value (assigned in FileManager::getFile) wrong when using the InMemoryFileSystem. That's because it assumes that vfs::File::getName will always return the real path. I changed to to use FileSystem::getRealPath instead. Subscribers: ilya-biryukov, ioeric, cfe-commits Differential Revision: https://reviews.llvm.org/D48903 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@336807 91177308-0d34-0410-b5e6-96231b3b80d8
…ain file Having `using qualified::name;` for some symbol is an important signal for clangd code completion as the user is more likely to use such symbol. This patch helps to uprank the relevant symbols by saving UsingShadowDecl in the new field of CodeCompletionResult and checking whether the corresponding UsingShadowDecl is located in the main file later in ClangD code completion routine. While the relative importance of such signal is a subject to change in the future, this patch simply bumps DeclProximity score to the value of 1.0 which should be enough for now. The patch was tested using `$ ninja check-clang check-clang-tools` No unexpected failures were noticed after running the relevant testsets. Reviewers: sammccall, ioeric Subscribers: MaskRay, jkorous, cfe-commits Differential Revision: https://reviews.llvm.org/D49012 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@336810 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@336817 91177308-0d34-0410-b5e6-96231b3b80d8
…us with the requested name" This reverts commit r336807. This breaks users of ClangTool::mapVirtualFile. Will try to investigate a fix. See also the discussion on https://reviews.llvm.org/D48903 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@336831 91177308-0d34-0410-b5e6-96231b3b80d8
…erChecker. Previously, the checker only tracked one raw pointer symbol for each container object. But member functions returning a pointer to the object's inner buffer may be called on the object several times. These pointer symbols are now collected in a set inside the program state map and thus all of them is checked for use-after-free problems. Differential Revision: https://reviews.llvm.org/D49057 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@336835 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@336836 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@336840 91177308-0d34-0410-b5e6-96231b3b80d8
Code in `CodeGenModule::SetFunctionAttributes()` could set an empty
attribute `implicit-section-name` on a function that is affected by
`#pragma clang text="section"`. This is incorrect because the attribute
should contain a valid section name. If the function additionally also
used `__attribute__((section("section")))` then this could result in
emitting the function in a section with an empty name.
The patch fixes the issue by removing the problematic code that sets
empty `implicit-section-name` from
`CodeGenModule::SetFunctionAttributes()` because it is sufficient to set
this attribute only from a similar code in `setNonAliasAttributes()`
when the function is emitted.
Differential Revision: https://reviews.llvm.org/D48916
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@336842 91177308-0d34-0410-b5e6-96231b3b80d8
See https://reviews.llvm.org/D47106 for details. Reviewed By: probinson Differential Revision: https://reviews.llvm.org/D47172 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@336844 91177308-0d34-0410-b5e6-96231b3b80d8
with another in template argument deduction. We happened to typically get away with getting this wrong, because the cases where we'd produce a bogus deduction were caught by the final "deduced A is compatible with A" check. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@336852 91177308-0d34-0410-b5e6-96231b3b80d8
string, choose the strictest one instead of the last. Also fix an undefined behavior. Move the pointer update to a later point to avoid adding StringRef::npos to the pointer. rdar://problem/40706280 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@336863 91177308-0d34-0410-b5e6-96231b3b80d8
types. We previously tried to use the "parameter is a reference" logic here, but that doesn't work because it gets P and A backwards. Instead, add a separate implementation of the "deduced A can be less qualified than A" rule. This also exposes that we incorrectly stripped cv-qualifiers from the referent of A if it was a reference. However, if we don't do that, we get the wrong results when P is a reference. In an attempt to match what sanity dictates and what other implementations are doing, we now remove cv-qualifiers from A and P unless both are reference types. I've brought this up on the core reflector too, to try to get the standard fixed. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@336867 91177308-0d34-0410-b5e6-96231b3b80d8
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.