[pull] main from llvm:main - #1711
Merged
Merged
Conversation
… not match WideTy (#203014) **Problem:** `LegalizerHelper::widenScalarMergeValues` does not handle the case where the destination register type is a floating-point type but the widen operation produces an integer type of the same size. For example, given: ``` %0:_(i8) = G_CONSTANT i8 0 %1:_(i8) = G_CONSTANT i8 1 %2:_(f16) = G_MERGE_VALUES %0:_(i8), %1_:(i8) ``` With a `minScalarOrElt` rule widening the source type to I16, `widenScalarMergeValues` enters the `WideSize >= DstSize` path and assigns the result to a new virtual register. The condition used to assign directly to DstReg uses type equality (WideTy == DstTy), which fails when DstTy = f16. As a result, DstReg is left without a definition. **Fix:** After the OR-reduction loop, add a check for the case where DstTy and WideTy have equal sizes but different types, and emit a G_BITCAST. **Testing:** No currently upstream target exercises `G_MERGE_VALUES` with a floating-point destination type through this widen path, as most targets promote f16 to s16 before legalization. The fix is therefore covered by a unit test in `LegalizerHelperTest.cpp`, modeled after the existing `WidenScalarMergeValuesPointer` test, which directly invokes widenScalar on a manually constructed `f16 = G_MERGE_VALUES i8, i8` instruction and verifies that a `G_BITCAST` is emitted as the final instruction.
…cludes (#213158) Clear out the headers in <optional> that were left in to not break other headers, and fix them also. Also fix tests.
…206733) With extended LLT, scalar LLT carry an integer/float kind information. The `G_TRUNC(G_MERGE_VALUES)` fold in `LegalizationArtifactCombiner::tryCombineTrunc` truncated, copied or rebuilt a merge directly from the merge's source register. **Problem** When those sources are floating-point this produces artifacts with float source operand - e.g. `i1 = G_TRUNC f32` or a rebuilt `iN = G_MERGE_VALUES f32, ...` which are bit level integer operations and must not take a float operand. **Fix** Reinterpret a floating-point merge source to an integer of the same size via `G_BITCAST` before truncating, copying or rebuilding the merge. So the emitted artifacts stay on integer operands. Non-float sources and non-extended-LLT builds are unaffected.
#196960) This is refactoring to prepare for #87471. Where we will be adding support for describing registers as unions and vectors. See: https://sourceware.org/gdb/current/onlinedocs/gdb.html/Target-Description-Format.html A union is like a C union and references other types defined in the XML. Just like a set of register flags might reference an enum for one of those flags. By introducing this base class I'm making the treatment of all these different types generic. So that when encoding them as XML we can emit the type's dependencies recursively, and then emit the type itself. This strategy will also be used later in RegisterTypeBuilderClang to generate AST to represent these types. As GDB decided to include size in enums, whenever we emit something it will get a "user" pointer. This allows an enum type to read the size of the register it's being attached to. No other type class requires this. I would call this "parent" but it is not usually the parent. The heirarchy is: * A RegisterFlags type contains many flags. * One of those flags has an enum as its type. * That enum needs to query two levels up to get the RegisterFlag's size. LLDB does not care about this enum size attribute, but GDB does so we emit it for compatibility. I don't expect anything other than a RegisterFlags to reference an enum at this time. In theory, a vector's element could be an enum but I do not know of anything available today that does this. I'd like to support arbitrary nesting of these types, but only later once known use cases work well. For the time being, the generic RegisterType pointer is cast into a RegisterFlags before use. In future this will become a switch over the possible register types we support.
We can't call `getNumElems()` for unknown-size arrays.
Second part of generalisations requested in #207377. Extend real sum reassociation to flatten unparenthesized addition and subtraction into signed terms. Rebuild split groups with addition and subtraction while preserving parenthesized subtrees as opaque values. I did not observe any benchmark result changes as a result of this patch. Assisted-by: Codex
…se (#213032) Use libc++'s own _LIBCPP_BIG_ENDIAN macro instead of BYTE_ORDER, which was relied upon from a transitive <endian.h> include on Glibc.
Several headers use entities from `<__locale>` but rely on picking them up transitively, in most cases through `<ios>`. Fix this in preparation for splitting up `<__locale>`.
…213245) We've removed transitive includes by default in LLVM 23, but added an opt-in to keep the transitive includes for the release. Now that we've branched we can remove the transitive includes unconditionally. RFC: https://discourse.llvm.org/t/rfc-remove-unused-transitive-includes-from-the-libc-headers
Complete CIR lowering coverage for the remaining AArch64 NEON FP16 fused multiply-accumulate and fused multiply-subtract builtins. This covers ACLE wrappers from section 2.6.1.9.3: - vfma_n_f16, vfmaq_n_f16 - vfms_f16, vfmsq_f16 - vfms_lane_f16, vfmsq_lane_f16 - vfms_laneq_f16, vfmsq_laneq_f16 - vfms_n_f16, vfmsq_n_f16 - vfmsh_lane_f16, vfmsh_laneq_f16 The existing CIR lowering paths already handle these wrappers. Move their tests from AArch64/v8.2a-neon-intrinsics.c into AArch64/neon/fused-multiple-fullfp16.c, add direct LLVM, CIR-to-LLVM, and CIR coverage, and remove the superseded tests. Strengthen the LLVM checks by tracking operands from their defining operations and using LLVM-DAG for order-independent setup operations. Part of #185382
…nd from their utility methods (#212186) This patch eliminates the remaining uses of the class `NodeBuilder` from the `ExprEngine::Visit*` methods and from their utility methods such as `evalLocation`, `evalLoad`, `CreateCXXTemporaryObject` and `handleConstructor`.
Enable -fopenmp-assume-teams-oversubscription and -fopenmp-assume-threads-oversubscription by default under -fopenmp-target-fast. Adds driver test coverage for both. Split out of #205325 as a standalone change.
…utput (#213659) These now lower to vXi1 reduction (as bitcast) patterns The PR39665_c_ray_opt test folds to the same IR, so I've merged the tests
…per (#209262) Copy printing only special cased Aligned, so alias list and scope IDs were then misread as additional masks
…tils (#213647) Added a lit test test for branch weight
…INTEL storage class (#192973) CodeSectionINTEL pointers are not valid operands for PtrCastToGeneric/GenericCastToPtr (including inside OpSpecConstantOp)
…verlay (#213602) The TargetParser lit regression test (`llvm/test/tools/TargetParser/get-triple-system-name.test`) runs `get_triple_system_name_test.py`, which imports `get_triple_system_name.py` from `llvm/utils/` and reads `TripleName.def` from `llvm/include/llvm/TargetParser/`. When executing lit regression tests in downstream sandboxed build systems, the test fails with `ModuleNotFoundError: No module named 'get_triple_system_name'` because these standalone files are located outside the test directory and are not staged into the test runfiles sandbox. Add `TripleName.def` and `get_triple_system_name.py` to `exports_files` in the overlay so downstream builds can reference them as test runfile dependencies. Assited by: Gemini
This can happen via virtual bases. Fixes #213569
…on output (#213671) This now lowers to a vXi1 reduction (as bitcast) pattern
…tries (#211287) Fixes #211132. Also removes the trigger for #198621, see below. `AAKernelInfo` treats the loop body passed to the `__kmpc_*_static_loop_*` entries as opaque and records an unknown parallel region for it, per the TODO at the site. Consequently `NestedParallelism` is true for any kernel whose parallel region contains a device workshare loop, and `MayUseNestedParallelism` is written to the kernel environment as 1 where it should be 0. The callback is a direct function operand at the callsite, so resolve it and consult its `AAKernelInfo`, exactly as the `__kmpc_parallel_60` handling already does for its parallel-region operand a few lines away. Only record an unknown region when it does not resolve, or does reach parallel regions. The SPMD-izability half of the TODO is left alone. Only flang lowers device workshare loops through these entries; clang emits `__kmpc_for_static_init_4` plus an explicit loop, which the preceding case already handles. So flang kernels get 1 and clang kernels get 0 on identical source. Controlled pair, flang, gfx90a: | construct | runtime loop entry | before | after | |---|---|---|---| | `!$omp target parallel` | none | 0 | 0 | | `!$omp target parallel do` | `__kmpc_for_static_loop_4u` | 1 | **0** | What the 1 costs. It stops `config::mayUseNestedParallelism()` folding, so the serialized branch in `__kmpc_parallel_60` stays live and carries its own call to the microtask. After `__kmpc_parallel_60` is inlined into the kernel there are then two calls to the outlined region rather than one, `isSoleCallToLocalFunction` is false, and `LastCallToStaticBonus` never applies. On AMDGPU that is 15000 x 11 = 165000; the analysis starts at -165045 with one callsite and -45 with two. With two the region stays out of line and the kernel is no longer a leaf. `-Rpass-analysis=kernel-resource-usage`, VGPRs / scratch / occupancy: | | before | after | |---|---|---| | reproducer from #211132, gfx90a | 212 / 48 B / 2 | **94 / 0 / 5** | | WENO5 + HLLC NEQ=8, gfx942 | 196 / 64 B / 2 | **110 / 0 / 4** | | NEQ=16 | 214 / 328 B / 2 | **138 / 0 / 3** | | NEQ=24 | 196 / 456 B / 2 | **110 / 392 B / 4** | End-to-end on gfx942 (MI325X), 1M cells, best of 50, Mcell/s, checksums bit-identical: 1.35x, 1.47x, 1.28x at NEQ=8/16/24. Baseline run-to-run spread across jobs is wider than the patched one, so treat the resource numbers above, which are deterministic, as the primary evidence. For #198621: step 2 of that root cause identifies the same `MayUseNestedParallelism=1` as what prevents LTO folding `omp_get_num_threads()` into a register read, which is what leaves `DistributeFor` with `NumThreads=1` and skips a suffix of iterations. Scalar kernels are immune there because they get 0. This refines the field for the array-expression kernels too, so it addresses that cause rather than the symptom. Testing: added `spmdization_kernel_env_static_loop.ll`, which covers both directions, a callback with no parallel region refining to 0 and a callback that does contain one staying at 1. It fails without the patch. `llvm/test/Transforms` (11676) and `llvm/test/CodeGen/AMDGPU` (4920), 16596 tests, 14668 passed with 39 expected failures and no regression. The one failure, `Transforms/ThinLTOBitcodeWriter/no-type-md.ll`, is pre-existing and fails identically with the patch reverted. This affects performance-critical applications on large AMD GPU supercomputers, including [MFC](https://github.com/MFlowCode/MFC). All numbers above come from the validated reproducers attached to #211132 and are independently reproducible; they stand on their own. This was found and root-caused with the assistance of AI tools.
…209727) Offload API functions may fail with error codes that shouldn't be ignored. Most notably, if `olInit` fails and its error return value is ignored, it is easy to use the library in an invalid uninitialized state, which can and has caused confusion. In those cases, it may be useful to have the ability to mark some API function with `[[nodiscard]]` This PR adds an optional `nodiscard` property to offload-tblgen's `Function`, `Enum`, and `Struct`. If set, an `OL_NODISCARD` macro is emitted, which expands to `[[nodiscard]]` on >=C++17 and >=C23, and to nothing otherwise. `nodiscard` is set for `ol_errc_t`, meaning every call to a function that returns it will emit a compiler warning if the return value is ignored and the TU is compiled on a supported language mode. `libsycl` and `llvm-gpu-loader` still build cleanly and are unaffected by the change. Worth considering: should there be an opt-out (`#define OL_DISABLE_NODISCARD` or similar)? Assisted-by: Claude
Reviewers: Pull Request: #213693
Make check lines more generic so that we can move and rename components without breaking the tests This is in preparation for splitting off parts of libomptarget into libompaccsupport, which will be used by both OpenACC and OpenMP. Some debug prints will be printed from `ompaccsupport` and not `omptarget`, thus the need for this change.
…#210737) This PR adds a new template into `dlwrap` namespace that can be used to check if a symbol was correctly loaded. It adds and easy way to see if version of shared object in a system has required capability. We could use it to improve prefetch in CUDA backend as noted [here](https://github.com/llvm/llvm-project/blob/main/offload/plugins-nextgen/cuda/src/rtl.cpp#L912) without breaking compatibility with older platforms using CUDA older than 13. In the case of prefetch, the new `dlwrap` API could be used like: ```cpp bool BatchedPrefetchAvailable = dlwrap::loaded<cuMemPrefetchBatchAsync>(); if (BatchedPrefetchAvailable) cuMemPrefetchAsync(....) else // Current implementation ``` Small note, to implement the prefetch we will also have to make loading of the symbols optional inside plugins too. This would require to change it [here](https://github.com/llvm/llvm-project/blob/main/offload/plugins-nextgen/cuda/dynamic_cuda/cuda.cpp#L176), but I think that the change can be a part of a PR that implements prefetch.
…ntrinsics (#213683) These more closely match middle-end IR and currently expand to the existing shuffle/bitcast patterns.
Prior to this patch, unit test default actions for mock liboffload returned errors when receiving invalid arguments. There are only a few valid scenarios where the runtime should expect and handle error codes returned by liboffload (for example, checking whether a pointer is USM or not). In most cases, the calls should not be made with invalid arguments by libsycl at all, and especially not with the type of invalid arguments that we can check for in default actions, like nullptrs or invalid size values. This patch changes such default action checks to trigger test failures directly instead of mocking error codes.
`restoreIPandDebugLoc` previously only recovered a debug location when the insertion block was non-empty, using its last instruction. For an empty block it left the current debug location unchanged so instructions emitted afterwards could have wrong debug location. This PR enhance `restoreIPandDebugLoc` to also handle the empty-block case: when the insertion point is at the end of an empty block, synthesize a location scoped to the parent function's subprogram provided the function has debug metadata. This helps us get a valid debug location when we switch to `CodeGenIP` in `emitOffloadingArrays` even when `CodeGenIP` is pointing to an empty `BB`. Fixes #212488 Co-authored-by: Cursor <cursoragent@cursor.com>
Without this, clang-format attempts to reflow check lines in tests, resulting in broken tests.
… to cmake and ninja (#213511) macOS/Xcode don't have cmake or ninja anywhere in a default PATH, so run-buildbot and libcxx-lit fail unless you do some PATH surgery before running them. Allow passing them as environment variables instead, so run-buildbot can be invoked as `CMAKE=$(xcrun --find cmake) NINJA=$(xcrun --find ninja) CC=$(xcrun --find clang) CXX=$(xcrun --find clang++) run-buildbot` on macOS. Allow cmake to be passed to libcxx-lit in a similar fashion.
Add ELF section type `SHT_LLVM_DYNDBG_ELF` for embedding the "inner" unoptimized dynamic debugging ELF object within the "outer" optimized ELF object. RFC: https://discourse.llvm.org/t/90113
libcxx/vendor/apple/{availability-with-pedantic-errors.compile.pass.cpp,disable-availability.sh.cpp}
both require the platform to support availability markup but weren't
labeled as such. std/time/time.hash/time.hash_enabled.pass.cpp has some
leap second tests that are missing the guards <chrono> uses to include
<__chrono/leap_second.h> and will fail if experimental tzdb is set but
the other ones aren't.
…12279) The deque::iterator benchmarks were not truly about deque::iterator, but about specialized algorithm implementations we have for segmented iterators. This patch handles them as such, like we do for other specialized algorithms like vector<bool>.
…ing (#208791) Original test by @fhahn in #191867, further reduced here. Before this change LAA results in > maximum safe store-load forward width of 32|0 bits for `i32` accesses, effectively meaning that only `VF == 1` is safe, yet not explicitly returning `false` from `couldPreventStoreLoadForward`. This PR fixes that.
…t size" (#213635) Reverts #212628 This relands #211493, which was reverted because ockl_dm_alloc/ockl_dm_dealloc in device-libs emit an i32 ballot on wave64, which GlobalISel cannot select (one bit per lane doesn't fit). [#212813](#212813) widens the clang ballot builtins to the wavefront size so a narrower-than-wave ballot is no longer emitted, fixing the root cause.
This part of the engine code had assumed that an `evalBind` call always produced exactly one transition. This was probably always satisfied by the existing `eval::Bind` checkers (because the code is old and I don't know about any bugs caused by this), but it was still fragile and problematic to rely on this undocumented property of checkers. This commit introduces a `for` loop to ensure that all nodes produced by `evalBind` are handled in an identical manner (the same way as the single node was handled previously). (Note that not passing a `State` to `makeNodeWithBinding` is equivalent to passing the state of the predecessor node.) We noticed this problem during the review of the NFC commit 53ee7b1 and decided to put this (arguably non-NFC) change into a separate PR.
The DIL bitfield extraction operator `base[high:low]` creates a synthetic bitfield child without validating the requested range. Three malformed ranges reach the data layer and either return nonsense or crash. Reproduced with a 32-bit `int value` and DIL enabled: ``` (lldb) settings set target.experimental.use-DIL true (lldb) frame variable 'value[-1:0]' (int:2) value[-1:0] = 2 ``` A negative index is accepted and produces a meaningless child. `first_index`/`last_index` are signed `int64_t`, but `GetSyntheticBitFieldChild` takes `uint32_t`, so `-1` silently wraps to a huge unsigned offset. ``` (lldb) frame variable 'value[0:64]' Assertion failed: (bitfield_bit_size <= 64), function GetMaxU64Bitfield, file DataExtractor.cpp, line 580. ``` A width greater than 64 bits aborts. `DataExtractor::GetMaxU64Bitfield` only supports up to 64 bits: it asserts in an assertions build and otherwise performs an out-of-bounds shift. A 32-bit `value` with range `[0:64]` is 65 bits, enough to trip it. ``` (lldb) frame variable 'value[100:50]' (int:51) value[100:50] = 0 ``` A high index past the base object's storage returns a garbage child in a normal build. Under UBSan the read/format path shifts by an oversized amount derived from the offset: ``` (lldb) frame variable 'value[100:50]' DataExtractor.cpp:591:12: runtime error: shift exponent 234 is too large for 64-bit type 'uint64_t' ``` Reject all three in the DIL evaluator before the synthetic child is created: a negative `first_index`/`last_index`, a normalized width greater than 64 bits, and a high index at or beyond the base object's bit size (queried with `GetCompilerType().GetBitSize`). Each returns a `DILDiagnosticError` with a clear message. Valid in-range extractions are unaffected. Adds the three malformed ranges to the DIL bitfield extraction API test (`TestFrameVarDILBitFieldExtraction`). Without the fix the test fails on the first case (`value[-1:0]` is expected to error but succeeds); the `[0:64]` case additionally asserts and the `[100:50]` case is a UBSan shift-out-of-bounds.
…ibute and APINotes. (#199531) This is the upstream version of swiftlang#12995 from the swiftlang fork. **Motivation:** Swift 6.2 added support for [raw identifiers](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0451-escaped-identifiers.md), which are backtick-delimited identifiers that can contain non-identifier characters like `` let `hello world` = `foo/bar:baz` ``. This change ensures that those identifiers can be used when setting Swift names for C decls in APINotes and the `swift_name` attribute.
AsyncScore is a snapshot of the counter scores used by async operations, which recordAsyncMark stores into AsyncMarks. Like the other scores tracked by the brackets, these snapshots need to be monotonically increasing: determineAsyncWait indexes into AsyncMarks and uses the selected entry directly to compute the wait, so each mark has to describe the state of every async operation issued before it, not just those issued since the previous mark.
Mach-O balanced partitioning currently discovers candidate sections by walking the input-file section graph. In `--icf=safe_thunks` mode, address-significant functions can instead be emitted as linker-created thunk sections after that graph has been built. A temporal-profile name then resolves to the dead folded input while the callable section present in the final binary is never eligible for BP ordering. Factor candidate collection into a helper, then inspect the final `inputSections` set for sections containing a `Defined` symbol marked `ICFFoldKind::Thunk`. This makes emitted ICF safe thunks visible while keeping unrelated synthetic metadata outside BP. The new arm64 regression folds a profiled address-significant function into a 4-byte safe thunk and verifies both the BP startup count and final symbol order. Without the change, BP orders zero startup sections for that profile; with the change it orders the emitted thunk first.
Expands `LegalityQuery` to include instruction immediates in the query. This allows instructions with immediates to be handled more fully with legalization rules/predicates (e.g. `G_SEXT_INREG` based on its sext width) rather than having to resort to custom legalizer logic. Split from #198979
This will help deal with syntax changes across different versions of OpenMP. There are certain cases where being able to generate different AST for the same source code depending on the version of the OpenMP spec makes semantic analysis easier. --------- Co-authored-by: Michael Kruse <llvm-project@meinersbur.de>
Up until 5.2, ALWAYS, CLOSE, and PRESENT were keywords of the map-type-modifier. Starting from 6.0 they all became their own single-keyword modifiers. This allowed specifying them together, unlike in the past where map-type-modifier was unique. To avoid using a single representation of the modifiers, and be able to validate them through non-conditional properties, the AST was rewritten back to the older form in canonicalization when the spec version was set to 5.2 or earlier. Now that the parser is version-aware, it can generate the desired AST from the start. Additionally, extract the OMPX_HOLD modifier out of the map-type- modifier into its own AST node regardless of version.
Tracking issue: #201242 See the [migration guide] for more information. [migration guide]: https://llvm.org/docs/SphinxQuickstartTemplate.html#markdown-migration-guidelines This is the initial straight rename commit. It will probably break the docs build, but it has to be a separate PR for blame preservation purposes.
…es (#213177) llvm-profdata merge previously silently merged single-byte-coverage profiles with count profiles. We should reject this, because SingleByteCoverage will always be set to true in the merged profile, and mess up the PGO pipeline. mergeProfileKind now errors with cannot merge single-byte-coverage profiles with count (non-coverage) profiles when exactly one side has InstrProfKind::SingleByteCoverage set. Note: Used AI to generate the code --------- Co-authored-by: Sharon Xu <sharonxu@fb.com>
To make stray whitespace more visible (see #212523) ``` $ echo end > tmp.f90 && flang -fuse-ld=lld -Wl,"-z execstack" tmp.f90 ld.lld: warning: unknown -z value: execstack ``` Drop the colon (colon is typically used without quotes in lld/ELF diagnostics). Change ErrAlways to Err so that --noinhibit-exec downgrades the errors to warnings. Read --noinhibit-exec before readConfigs, as Err depends on it.
Tracking issue: #201242 See the [migration guide] for more information. [migration guide]: https://llvm.org/docs/SphinxQuickstartTemplate.html#markdown-migration-guidelines This is a stacked PR based on #210842 , which will be a standalone commit that renames *.rst -> *.md before this PR lands for history preservation purposes. This was prepared with rst2myst plus LLM-assisted cleanup. I paged through all the generated HTML looking for migration artifacts, and all of the differences I could find appear to be formatting error corrections.
More tests for #211680. Also cleaned up some commented out code that slipped through with the old test. New test stresses the scheduling updates.
…on (#207689) This Patch adds more precise diagnostics for when a pass is missing a target/source materialization function, making it easier to locate the issue in the pass.
Add tests for loading embedded bytecode formatters from binaries. Assisted-by: claude
…epareForLTO` is set (#192154) Indirect calls may be resolved during the post-link LLVM pipeline. Thus, count them as potential inline candidates during the pre-link LTO phase.
…213532) When simplifying ssub.with.overflow to a plain sub, we already proven that the sub does not sign wrap. Replace it with `sub nsw`. No changes on dtcxzyw/llvm-opt-benchmark-nightly#842, but there is very little usage of ssub.with.overflow in default C/C++ builds. It improves optimizations for code where ssub.with.overflow is used more widely, like Clang + UBSan or Swift where checked arithmetic is the default. A simple C example is https://clang.godbolt.org/z/cv5MbYsrz PR: #213532
…wavefront size"" (#213713) Reverts #213635 buildbot failures are reported here: #213635 (comment)
The unordered reduction matcher required isAssociative() for fadd, i.e. reassoc + nsz, a condition inherited from InstCombine-style reassociation that also cancels and folds terms. Pure regrouping of additions cannot change the sign of a zero result, so nsz is not needed here: the reduction is seeded with the exact -0.0 identity, the repeated-value multiplier preserves the sign of zero, and constant folding is IEEE-exact. Brings the fadd requirement in line with RecurrenceDescriptor, LV and with fmul, which accept reassoc alone. Reviewers: hiraditya, bababuck, RKSimon Pull Request: #213261
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
20 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.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )