Bump ajv from 6.8.1 to 6.12.6 in /clang-tools-extra/clangd/clients/clangd-vscode#4
Open
dependabot[bot] wants to merge 289 commits intocahpfrom
Conversation
------------------------------------------------------------------------
r367062 | yhs | 2019-07-25 23:47:27 +0200 (Thu, 25 Jul 2019) | 30 lines
[BPF] fix typedef issue for offset relocation
Currently, the CO-RE offset relocation does not work
if any struct/union member or array element is a typedef.
For example,
typedef const int arr_t[7];
struct input {
arr_t a;
};
func(...) {
struct input *in = ...;
... __builtin_preserve_access_index(&in->a[1]) ...
}
The BPF backend calculated default offset is 0 while
4 is the correct answer. Similar issues exist for struct/union
typedef's.
When getting struct/union member or array element type,
we should trace down to the type by skipping typedef
and qualifiers const/volatile as this is what clang did
to generate getelementptr instructions.
(const/volatile member type qualifiers are already
ignored by clang.)
This patch fixed this issue, for each access index,
skipping typedef and const/volatile/restrict BTF types.
Signed-off-by: Yonghong Song <yhs@fb.com>
Differential Revision: https://reviews.llvm.org/D65259
------------------------------------------------------------------------
llvm-svn: 367211
llvm-svn: 367212
------------------------------------------------------------------------
r367215 | hans | 2019-07-29 11:49:04 +0200 (Mon, 29 Jul 2019) | 66 lines
Mark test/MC/RISCV/rv{32,64}i-aliases-invalid.s unsupported also on Windows
Because they fail there too.
FAIL: LLVM :: MC/RISCV/rv32i-aliases-invalid.s (24397 of 32659)
******************** TEST 'LLVM :: MC/RISCV/rv32i-aliases-invalid.s' FAILED ********************
Script:
--
: 'RUN: at line 2'; not c:\src\llvm.monorepo\build.release2\bin\llvm-mc.exe C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv32i-aliases-invalid.s -triple=riscv32 -riscv-no-aliases 2>&1 | c:\src\llvm.monorepo\build.release2\bin\filecheck.exe C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv32i-aliases-invalid.s
: 'RUN: at line 3'; not c:\src\llvm.monorepo\build.release2\bin\llvm-mc.exe C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv32i-aliases-invalid.s -triple=riscv32 2>&1 | c:\src\llvm.monorepo\build.release2\bin\filecheck.exe C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv32i-aliases-invalid.s
--
Exit Code: 1
Command Output (stdout):
--
$ ":" "RUN: at line 2"
$ "not" "c:\src\llvm.monorepo\build.release2\bin\llvm-mc.exe" "C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv32i-aliases-invalid.s" "-triple=riscv32" "-riscv-no-aliases"
$ "c:\src\llvm.monorepo\build.release2\bin\filecheck.exe" "C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv32i-aliases-invalid.s"
C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv32i-aliases-invalid.s:10:21: error: CHECK: expected string not found in input
li t4, foo # CHECK: :[[@line]]:8: error: immediate must be an integer in the range [-2147483648, 4294967295]
^
<stdin>:5:1: note: scanning from here
li x0, -2147483649 # CHECK: :[[@line]]:8: error: immediate must be an integer in the range [-2147483648, 4294967295]
^
<stdin>:5:1: note: with "@line" equal to "10"
li x0, -2147483649 # CHECK: :[[@line]]:8: error: immediate must be an integer in the range [-2147483648, 4294967295]
^
<stdin>:5:38: note: possible intended match here
li x0, -2147483649 # CHECK: :[[@line]]:8: error: immediate must be an integer in the range [-2147483648, 4294967295]
^
error: command failed with exit status: 1
--
--
********************
Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70
FAIL: LLVM :: MC/RISCV/rv64i-aliases-invalid.s (24416 of 32659)
******************** TEST 'LLVM :: MC/RISCV/rv64i-aliases-invalid.s' FAILED ********************
Script:
--
: 'RUN: at line 2'; not c:\src\llvm.monorepo\build.release2\bin\llvm-mc.exe C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv64i-aliases-invalid.s -triple=riscv64 -riscv-no-aliases 2>&1 | c:\src\llvm.monorepo\build.release2\bin\filecheck.exe C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv64i-aliases-invalid.s
: 'RUN: at line 3'; not c:\src\llvm.monorepo\build.release2\bin\llvm-mc.exe C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv64i-aliases-invalid.s -triple=riscv64 2>&1 | c:\src\llvm.monorepo\build.release2\bin\filecheck.exe C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv64i-aliases-invalid.s
--
Exit Code: 1
Command Output (stdout):
--
$ ":" "RUN: at line 2"
$ "not" "c:\src\llvm.monorepo\build.release2\bin\llvm-mc.exe" "C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv64i-aliases-invalid.s" "-triple=riscv64" "-riscv-no-aliases"
$ "c:\src\llvm.monorepo\build.release2\bin\filecheck.exe" "C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv64i-aliases-invalid.s"
C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv64i-aliases-invalid.s:6:21: error: CHECK: expected string not found in input
li t4, foo # CHECK: :[[@line]]:8: error: operand must be a constant 64-bit integer
^
<stdin>:2:1: note: scanning from here
li t5, 0x10000000000000000 # CHECK: :[[@line]]:8: error: unknown operand
^
<stdin>:2:1: note: with "@line" equal to "6"
li t5, 0x10000000000000000 # CHECK: :[[@line]]:8: error: unknown operand
^
<stdin>:13:67: note: possible intended match here
C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv64i-aliases-invalid.s:12:13: error: immediate must be an integer in the range [0, 63]
^
error: command failed with exit status: 1
------------------------------------------------------------------------
llvm-svn: 367217
------------------------------------------------------------------------ r367008 | stulova | 2019-07-25 13:04:29 +0200 (Thu, 25 Jul 2019) | 12 lines [OpenCL] Rename lang mode flag for C++ mode Rename lang mode flag to -cl-std=clc++/-cl-std=CLC++ or -std=clc++/-std=CLC++. This aligns with OpenCL C conversion and removes ambiguity with OpenCL C++. Differential Revision: https://reviews.llvm.org/D65102 ------------------------------------------------------------------------ llvm-svn: 367300
------------------------------------------------------------------------
r367314 | hans | 2019-07-30 16:17:58 +0200 (Tue, 30 Jul 2019) | 16 lines
gn build: Use rebase_path on filename args to libcxx/utils/gen_link_script.py
$ ninja -j800
[1/5] ACTION //libcxx/src:cxx_linker_script(//llvm/utils/gn/build/toolchain:stage2_unix)
FAILED: lib/libc++.so
python ../libcxx/utils/gen_link_script.py --input //build.gn/lib/libc++.so.0 --output //build.gn/lib/libc++.so c++abi unwind
GENERATING SCRIPT: 'INPUT(libc++.so.0 -lc++abi -lunwind)' as file //build.gn/lib/libc++.so
Traceback (most recent call last):
File "../libcxx/utils/gen_link_script.py", line 57, in <module>
sys.exit(main())
File "../libcxx/utils/gen_link_script.py", line 50, in main
with open(args.output, 'w') as f:
IOError: [Errno 2] No such file or directory: '//build.gn/lib/libc++.so'
ninja: build stopped: subcommand failed.
Differential revision: https://reviews.llvm.org/D65449
------------------------------------------------------------------------
llvm-svn: 367315
------------------------------------------------------------------------ r366487 | pcc | 2019-07-18 22:14:16 +0200 (Thu, 18 Jul 2019) | 1 line gn build: Merge r366458. ------------------------------------------------------------------------ llvm-svn: 367317
(Minus the linuxkernel part, which is not present on the branch.) ------------------------------------------------------------------------ r367340 | nico | 2019-07-30 20:16:55 +0200 (Tue, 30 Jul 2019) | 6 lines gn build: Fix check-clang-tools after r362702. r362702 added a test that requires clang-tidy to be linked into libclang, so add that to the gn build. Differential Revision: https://reviews.llvm.org/D65462 ------------------------------------------------------------------------ ------------------------------------------------------------------------ r367341 | nico | 2019-07-30 20:19:13 +0200 (Tue, 30 Jul 2019) | 1 line gn build: Update comment I failed to update in r367340 / D65462 ------------------------------------------------------------------------ llvm-svn: 367390
------------------------------------------------------------------------ r366878 | s.desmalen | 2019-07-24 10:42:34 +0200 (Wed, 24 Jul 2019) | 12 lines [SVE][Inline-Asm] Add support to specify SVE registers in the clobber list Adds the SVE vector and predicate registers to the list of known registers. Patch by Kerry McLaughlin. Reviewers: erichkeane, sdesmalen, rengolin Reviewed By: sdesmalen Differential Revision: https://reviews.llvm.org/D64739 ------------------------------------------------------------------------ ------------------------------------------------------------------------ r367301 | s.desmalen | 2019-07-30 12:14:39 +0200 (Tue, 30 Jul 2019) | 15 lines [AArch64] Disable __ARM_FEATURE_SVE without ACLE. The Arm C Language Extensions for SVE document specifies that __ARM_FEATURE_SVE should be set when the compiler supports SVE and implements all the extensions described in the document. This is currently not yet the case, so the feature should be disabled until the compiler can provide all the extensions as described. Reviewers: c-rhodes, rengolin, rovka, ktkachov Reviewed By: rengolin Differential Revision: https://reviews.llvm.org/D65404 ------------------------------------------------------------------------ llvm-svn: 367432
------------------------------------------------------------------------ r367124 | c-rhodes | 2019-07-26 17:57:50 +0200 (Fri, 26 Jul 2019) | 14 lines [AArch64][SVE2] Rename bitperm feature to sve2-bitperm Summary: The bitperm feature flag is now prefixed with SVE2, as it is for all other SVE2 extensions Patch by Maciej Gabka. Reviewers: sdesmalen, rovka, chill, SjoerdMeijer, rengolin Reviewed By: SjoerdMeijer, rengolin Differential Revision: https://reviews.llvm.org/D65327 ------------------------------------------------------------------------ ------------------------------------------------------------------------ r367292 | c-rhodes | 2019-07-30 09:47:48 +0200 (Tue, 30 Jul 2019) | 10 lines [AArch64][AsmParser] Remove SVE and SVE2 from ARMTargetParser Summary: Patch removes SVE and SVE2 features from ARMTargetParser as these features are not supported on ARM. Reviewed By: rengolin Differential Revision: https://reviews.llvm.org/D65385 ------------------------------------------------------------------------ ------------------------------------------------------------------------ r367394 | c-rhodes | 2019-07-31 10:45:57 +0200 (Wed, 31 Jul 2019) | 25 lines [AArch64][SVE2] Use destination register as source register Summary: This patch fixes a bug in the following instructions that should have been implemented as destructive. A destructive instruction is an instruction where one of the source registers also acts as the destination register. Therefore, the contents of the source register, when the instruction begins execution, are replaced by the result of the instruction when the instruction completes execution [1]: * SRI/SLI * EORBT/EORTB * TBX * Narrowing top instructions * FP convert precision instructions These changes are non-functional from the assembler/diassembler point-of-view but are necessary for correct codegen. [1] https://static.docs.arm.com/ddi0584/ae/DDI0584A_e_SVE_supp_armv8A.pdf Reviewed By: sdesmalen Differential Revision: https://reviews.llvm.org/D65389 ------------------------------------------------------------------------ ------------------------------------------------------------------------ r367396 | c-rhodes | 2019-07-31 10:58:16 +0200 (Wed, 31 Jul 2019) | 15 lines [AArch64][SVE2] Minor refactoring and cleanup Summary: * Clarify comment with SVE2 for predicated shifts and move next to other shift instructions. * Clarify comments for various instructions. * Move FCVTX instruction next to other fp conversions. * Move FLOGB to next to other fp instructions and fix description. * Remove "cons" from non-constructive multiclass for bitwise shift-right and accumulate instructions. Reviewed By: sdesmalen Differential Revision: https://reviews.llvm.org/D65390 ------------------------------------------------------------------------ ------------------------------------------------------------------------ r367398 | c-rhodes | 2019-07-31 11:10:36 +0200 (Wed, 31 Jul 2019) | 14 lines [AArch64][SVE2] Load/store instruction fixes Summary: * Loads and stores in SVE2 are gather/scatter not contiguous, fixed by renaming multiclasses to reflect this and also updated comments. * Remove aliases from load/store multiclasses that reflect the behaviour of the original form. * Fix bug in scatter store implementation, vector list should be used as input, not output. Reviewed By: sdesmalen Differential Revision: https://reviews.llvm.org/D65392 ------------------------------------------------------------------------ llvm-svn: 367434
------------------------------------------------------------------------ r367414 | tkrasnukha | 2019-07-31 14:00:30 +0200 (Wed, 31 Jul 2019) | 7 lines [ProcessWindows] Choose a register context file by preprocessor Replaced Cmake option based check with the preprocessor macro as CMAKE_SYSTEM_PROCESSOR doesn't work as expected on Windows. Fixes llvm.org/pr42724 Differential Revision: https://reviews.llvm.org/D65409 ------------------------------------------------------------------------ llvm-svn: 367523
------------------------------------------------------------------------ r367442 | arichardson | 2019-07-31 18:31:55 +0200 (Wed, 31 Jul 2019) | 30 lines [Sanitizer][ASAN][MSAN] Fix infinite recursion on FreeBSD Summary: MSAN was broken on FreeBSD by https://reviews.llvm.org/D55703: after this change accesses to the key variable call __tls_get_addr, which is intercepted. The interceptor then calls GetCurrentThread which calls MsanTSDGet which again calls __tls_get_addr, etc... Using the default implementation in the SANITIZER_FREEBSD case fixes MSAN for me. I then applied the same change to ASAN (introduced in https://reviews.llvm.org/D55596) but that did not work yet. In the ASAN case, we get infinite recursion again during initialization, this time because calling pthread_key_create() early on results in infinite recursion. pthread_key_create() calls sysctlbyname() which is intercepted but COMMON_INTERCEPTOR_NOTHING_IS_INITIALIZED returns true, so the interceptor calls internal_sysctlbyname() which then ends up calling the interceptor again. I fixed this issue by using dlsym() to get the libc version of sysctlbyname() instead. This fixes https://llvm.org/PR40761 Reviewers: vitalybuka, krytarowski, devnexen, dim, bsdjhb, #sanitizers, MaskRay Reviewed By: MaskRay Subscribers: MaskRay, emaste, kubamracek, jfb, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D65221 ------------------------------------------------------------------------ llvm-svn: 367524
------------------------------------------------------------------------ r367323 | dmajor | 2019-07-30 17:32:49 +0200 (Tue, 30 Jul 2019) | 9 lines [COFF][ARM64] Reorder handling of aarch64 MSVC builtins In `CodeGenFunction::EmitAArch64BuiltinExpr()`, bulk move all of the aarch64 MSVC-builtin cases to an earlier point in the function (the `// Handle non-overloaded intrinsics first` switch block) in order to avoid an unreachable in `GetNeonType()`. The NEON type-overloading logic is not appropriate for the Windows builtins. Fixes https://llvm.org/pr42775 Differential Revision: https://reviews.llvm.org/D65403 ------------------------------------------------------------------------ llvm-svn: 367525
------------------------------------------------------------------------ r367304 | ro | 2019-07-30 12:33:20 +0200 (Tue, 30 Jul 2019) | 10 lines [CMake] Define _FILE_OFFSET_BITS=64 on Solaris This is the compantion patch to https://reviews.llvm.org/D64482, needed to ensure that builds with host compilers that don't yet predefine _FILE_OFFSET_BITS=64 on Solaris succeed by always making the host and freshly built clang consistent. Tested on x86_64-pc-solaris2.11. Differential Revision: https://reviews.llvm.org/D64483 ------------------------------------------------------------------------ llvm-svn: 367526
------------------------------------------------------------------------ r367305 | ro | 2019-07-30 12:38:41 +0200 (Tue, 30 Jul 2019) | 32 lines [Driver] Define _FILE_OFFSET_BITS=64 on Solaris make check-all currently fails on x86_64-pc-solaris2.11 when building with GCC 9: Undefined first referenced symbol in file _ZN11__sanitizer14internal_lseekEimi SANITIZER_TEST_OBJECTS.sanitizer_libc_test.cc.i386.o _ZN11__sanitizer23MapWritableFileToMemoryEPvmim SANITIZER_TEST_OBJECTS.sanitizer_libc_test.cc.i386.o ld: fatal: symbol referencing errors clang-9: error: linker command failed with exit code 1 (use -v to see invocation) make[3]: *** [projects/compiler-rt/lib/sanitizer_common/tests/CMakeFiles/TSanitizer-i386-Test.dir/build.make:92: projects/compiler-rt/lib/sanitizer_common/tests/Sanitizer-i386-Test] Error 1 While e.g. __sanitizer::internal_lseek is defined in sanitizer_solaris.cc, g++ 9 predefines _FILE_OFFSET_BITS=64 while clang++ currently does not. This patch resolves this inconsistency by following the gcc lead, which allows make check-all to finish successfully. There's one caveat: gcc defines _LARGEFILE_SOURCE and _LARGEFILE64_SOURCE for C++ only, while clang has long been doing it for all languages. I'd like to keep it this way because those macros do is to make declarations of fseek/ftello (_LARGEFILE_SOURCE) resp. the 64-bit versions of largefile functions (*64 with _LARGEFILE64_SOURCE) visible additionally. However, _FILE_OFFSET_BITS=64 changes all affected functions to be largefile-aware. I'd like to restrict this to C++, just like gcc does. To avoid a similar inconsistence with host compilers that don't predefine _FILE_OFFSET_BITS=64 (e.g. clang < 9, gcc < 9), this needs a compantion patch https://reviews.llvm.org/D64483. Tested on x86_64-pc-solaris2.11. Differential Revision: https://reviews.llvm.org/D64482 ------------------------------------------------------------------------ llvm-svn: 367527
------------------------------------------------------------------------
r367387 | jdoerfert | 2019-07-31 07:16:38 +0200 (Wed, 31 Jul 2019) | 26 lines
[Fix] Customize warnings for missing built-in types
If we detect a built-in declaration for which we cannot derive a type
matching the pattern in the Builtins.def file, we currently emit a
warning that the respective header is needed. However, this is not
necessarily the behavior we want as it has no connection to the location
of the declaration (which can actually be in the header in question).
Instead, this warning is generated
- if we could not build the type for the pattern on file (for some
reason). Here we should make the reason explicit. The actual problem
is otherwise circumvented as the warning is misleading, see [0] for
an example.
- if we could not build the type for the pattern because we do not
have a type on record, possible since D55483, we should not emit any
warning. See [1] for a legitimate problem.
This patch address both cases. For the "setjmp" family a new warning is
introduced and for built-ins without type on record, so far
"pthread_create", we do not emit the warning anymore.
Also see: PR40692
[0] https://lkml.org/lkml/2019/1/11/718
[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235583
Differential Revision: https://reviews.llvm.org/D58091
------------------------------------------------------------------------
llvm-svn: 367528
------------------------------------------------------------------------
r367417 | lebedevri | 2019-07-31 14:06:38 +0200 (Wed, 31 Jul 2019) | 38 lines
[DivRemPairs] Avoid RAUW pitfalls (PR42823)
Summary:
`DivRemPairs` internally creates two maps:
* {sign, divident, divisor} -> div instruction
* {sign, divident, divisor} -> rem instruction
Then it iterates over rem map, and looks if there is an entry
in div map with the same key. Then depending on some internal logic
it may RAUW rem instruction with something else.
But if that rem instruction is an input to other div/rem,
then it was used as a key in these maps, so the old value (used in key)
is now dandling, because RAUW didn't update those maps.
And we can't even RAUW map keys in general, there's `ValueMap`,
but we don't have a single `Value` as key...
The bug was discovered via D65298, and the test there exists.
Now, i'm not sure how to expose this issue in trunk.
The bug is clearly there if i change the map keys to be `AssertingVH`/`PoisoningVH`,
but i guess this didn't miscompiled anything thus far?
I really don't think this is benin without that patch.
The fix is actually rather straight-forward - instead of trying to somehow
shoe-horn `ValueMap` here (doesn't fit, key isn't just `Value`), or writing a new
`ValueMap` with key being a struct of `Value`s, we can just have an intermediate
data structure - a vector, each entry containing matching `Div, Rem` pair,
and pre-filling it before doing any modifications.
This way we won't need to query map after doing RAUW, so no bug is possible.
Reviewers: spatel, bogner, RKSimon, craig.topper
Reviewed By: spatel
Subscribers: hiraditya, hans, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65451
------------------------------------------------------------------------
llvm-svn: 367531
------------------------------------------------------------------------
r367308 | teemperor | 2019-07-30 14:31:24 +0200 (Tue, 30 Jul 2019) | 27 lines
[lldb] Fix crash when tab-completing in multi-line expr
Summary:
Tab completing inside the multiline expression command can cause LLDB to crash. The easiest way
to do this is to go inside a frame with at least one local variable and then try to complete:
(lldb) expr
1. a[tab]
Reason for this was some mixup when we calculate the cursor position. Obviously we should calculate
the offset inside the string by doing 'end - start', but we are doing 'start - end' (which causes the offset to
become -1 which will lead to some out-of-bounds reading).
Fixes rdar://51754005
I don't see any way to test this as the *multiline* expression completion is completely untested at the moment
and I don't think we have any existing code for testing infrastructure for it.
Reviewers: shafik, davide, labath
Reviewed By: labath
Subscribers: abidh, lldb-commits, davide, clayborg, labath
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64995
------------------------------------------------------------------------
llvm-svn: 367534
------------------------------------------------------------------------ r366545 | kadircet | 2019-07-19 11:08:22 +0200 (Fri, 19 Jul 2019) | 17 lines [clangd] Handle windows line endings in QueryDriver Summary: The previous patch did not fix the end mark. D64789 fixes second case of clangd/clangd#93 Patch by @lh123 ! Reviewers: sammccall, kadircet Reviewed By: kadircet Subscribers: MaskRay, ilya-biryukov, jkorous, arphaman, cfe-commits Tags: #clang-tools-extra, #clang Differential Revision: https://reviews.llvm.org/D64970 ------------------------------------------------------------------------ llvm-svn: 367571
llvm-svn: 367609
llvm-svn: 367610
llvm-svn: 367611
------------------------------------------------------------------------ r367530 | ibiryukov | 2019-08-01 11:10:37 +0200 (Thu, 01 Aug 2019) | 17 lines [Preprocessor] Always discard body of #define if we failed to parse it Summary: Preivously we would only discard it if we failed to parse parameter lists. If we do not consume the body, parser sees tokens inside directive. In turn, this leads to spurious diagnostics and a crash in TokenBuffer, see the added tests. Reviewers: sammccall Reviewed By: sammccall Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D65517 ------------------------------------------------------------------------ llvm-svn: 367681
------------------------------------------------------------------------ r367520 | hans | 2019-08-01 10:01:09 +0200 (Thu, 01 Aug 2019) | 15 lines Delay emitting dllexport explicitly defaulted members until the class is fully parsed (PR40006) This is similar to r245139, but that only addressed dllexported classes. It was still possible to run into the same problem with dllexported members in an otherwise normal class (see bug). This uses the same strategy to fix: delay defining the method until the whole class has been parsed. (The easiest way to see the ordering problem is in Parser::ParseCXXMemberSpecification(): it calls ParseLexedMemberInitializers() *after* ActOnFinishCXXMemberDecls(), which was trying to define the dllexport method. Now we delay it to ActOnFinishCXXNonNestedClass() which is called after both of those.) Differential revision: https://reviews.llvm.org/D65511 ------------------------------------------------------------------------ llvm-svn: 367804
------------------------------------------------------------------------ r367661 | hans | 2019-08-02 09:51:41 +0200 (Fri, 02 Aug 2019) | 5 lines Don't try emitting dllexported explicitly defaulted non-trivial ctors twice during explicit template instantiation definition (PR42857) Trying to emit the definition twice triggers an assert. Differential revision: https://reviews.llvm.org/D65579 ------------------------------------------------------------------------ llvm-svn: 367805
…D65565) llvm-svn: 367806
------------------------------------------------------------------------ r367687 | ibiryukov | 2019-08-02 17:23:04 +0200 (Fri, 02 Aug 2019) | 16 lines [clangd] Fix a crash when presenting values for Hover Summary: We should pass the expression type, not a variable type when printing the resulting value. Variable type may be different from what the pretty-printing function expects, e.g. have references. Reviewers: sammccall Reviewed By: sammccall Subscribers: MaskRay, jkorous, arphaman, kadircet, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D65655 ------------------------------------------------------------------------ llvm-svn: 367807
------------------------------------------------------------------------ r367753 | nikic | 2019-08-03 08:47:23 +0200 (Sat, 03 Aug 2019) | 12 lines [Thumb] Fix invalid symbol redefinition due to duplicated jumptable (PR42760) Fix for https://bugs.llvm.org/show_bug.cgi?id=42760. A tBR_JTr instruction is duplicated by tail duplication, which results in the same jumptable with the same label being emitted twice. Fix this by marking tBR_JTr as not duplicable. The corresponding ARM/Thumb instructions are already marked as not duplicable. Additionally also mark tTBB_JT and tTBH_JT to be consistent with Thumb2, even though this shouldn't be strictly necessary. Differential Revision: https://reviews.llvm.org/D65606 ------------------------------------------------------------------------ llvm-svn: 367808
------------------------------------------------------------------------ r366868 | rogfer01 | 2019-07-24 07:33:46 +0200 (Wed, 24 Jul 2019) | 6 lines [RISCV] Implement benchmark::cycleclock::Now This is a cherrypick of D64237 onto llvm/utils/benchmark and libcxx/utils/google-benchmark. Differential Revision: https://reviews.llvm.org/D65142 ------------------------------------------------------------------------ llvm-svn: 367810
------------------------------------------------------------------------ r366868 | rogfer01 | 2019-07-24 07:33:46 +0200 (Wed, 24 Jul 2019) | 6 lines [RISCV] Implement benchmark::cycleclock::Now This is a cherrypick of D64237 onto llvm/utils/benchmark and libcxx/utils/google-benchmark. Differential Revision: https://reviews.llvm.org/D65142 ------------------------------------------------------------------------ llvm-svn: 367813
------------------------------------------------------------------------ r367662 | psmith | 2019-08-02 10:05:14 +0200 (Fri, 02 Aug 2019) | 17 lines [AliasAnalysis] Initialize a member variable that may be used by unit test. The unit tests in BasicAliasAnalysisTest use the alias analysis API directly and do not call setAAResults to initalize AAR. This gives a valgrind error "Conditional Jump depends on unitialized variable". On most buildbots the variable is nullptr, but in some cases it can be non nullptr leading to seemingly random failures. These tests were disabled in r366986. With the initialization they can be enabled again. Fixes PR42719 Differential Revision: https://reviews.llvm.org/D65568 ------------------------------------------------------------------------ llvm-svn: 367818
Bumps [ajv](https://github.com/ajv-validator/ajv) from 6.8.1 to 6.12.6. - [Release notes](https://github.com/ajv-validator/ajv/releases) - [Commits](ajv-validator/ajv@v6.8.1...v6.12.6) --- updated-dependencies: - dependency-name: ajv dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
bot
added
dependencies
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
10 participants
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.
Bumps ajv from 6.8.1 to 6.12.6.
Release notes
Sourced from ajv's releases.
... (truncated)
Commits
fe591436.12.6d580d3eMerge pull request #1298 from ajv-validator/fix-urlfd36389fix: regular expression for "url" format490e34cdocs: link to v7-beta branch9cd93a1docs: note about v7 in readme877d286Merge pull request #1262 from b4h0-c4t/refactor-opt-object-typef1c8e456.12.5764035eMerge branch 'ChALkeR-chalker/fix-comma'3798160Merge branch 'chalker/fix-comma' of git://github.com/ChALkeR/ajv into ChALkeR...a3c7ebaMerge branch 'refactor-opt-object-type' of github.com:b4h0-c4t/ajv into refac...Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)@dependabot use these labelswill set the current labels as the default for future PRs for this repo and language@dependabot use these reviewerswill set the current reviewers as the default for future PRs for this repo and language@dependabot use these assigneeswill set the current assignees as the default for future PRs for this repo and language@dependabot use this milestonewill set the current milestone as the default for future PRs for this repo and languageYou can disable automated security fix PRs for this repo from the Security Alerts page.