[pull] main from llvm:main - #1723
Merged
Merged
Conversation
This patch implements some non-functional refactoring changes: - It consolidates the two existing "utils" headers into one. - It renames fields and arguments to the `OffloadModuleOpts` structure to follow the MLIR style guide and more closely match the corresponding `OffloadModuleInterface` attributes. - It removes comments in OpenMP-to-LLVMIR translation referring to Flang frontend options associated to the `OffloadModuleInterface`.
#213649) The `mlir::omp::setOffloadModuleInterfaceAttributes` utility function can currently override any pre-existing OpenMP `requires` clauses in the module. This doesn't cause any problems at the moment because all calls to this function happen before any other `requires` are processed. However, it's safer to make sure it never deletes pre-existing flags in case the same function is reused in a different context.
The line number in a module's debug info was a guess: the source line of
the first module member we encountered, minus one. That was only correct
when the first declaration happened to be on the line right after the
MODULE statement, so debuggers usually reported a module at the wrong
line.
The location of `fir.module_debug_imports` is that of the MODULE
statement, so use it instead. That operation is now generated for every
module and not only for those containing a USE statement, so the
location is available in all cases. It is still only generated when
debug info is requested.
Co-authored-by: Cursor <cursoragent@cursor.com>
---------
Co-authored-by: Cursor <cursoragent@cursor.com>
LLVM can produce `llvm.{s,u}{min,max}.i1` from boolean value patterns.
In SPIR-V, however, LLVM `i1` is represented as `OpTypeBool`, not as an
integer type. The OpenCL/GLSL extended min/max instructions require
integer scalar or integer vector operands and results, so selecting
those instructions directly for `i1` can produce invalid SPIR-V.
This patch makes the SPIR-V legalizer reflect that type-system boundary.
Nonstandard integer widths remain legal when the relevant extensions are
enabled, but `s1` is not treated as an extended integer width. Scalar
`i1` min/max is widened to `i32` before instruction selection and
converted back to bool. Boolean vectors are scalarized first, then each
lane follows the same scalar legalization path.
The result is deliberately conservative: it preserves the existing
extended-integer behavior while preventing boolean values from reaching
integer-only SPIR-V extended instructions.
---
The Khronos SPIRV-LLVM-Translator follows the same type-model premise:
`SPIRVWriter::transType` maps LLVM `i1` to `OpTypeBool`, while wider
LLVM integer types map to `OpTypeInt`.
The translator also avoids using OpenCL/GLSL extended min/max
instructions for LLVM min/max intrinsics. Its `SPIRVWriter.cpp` lowering
for `llvm.umin`, `llvm.umax`, `llvm.smin`, and `llvm.smax` emits an
integer comparison followed by `OpSelect`. That compare/select strategy
does not provide evidence that boolean extended min/max is valid; it
sidesteps the integer-only extended-instruction constraint entirely.
There is also a useful precedent in the translator regularization pass
for shifts: because SPIR-V shift operands must be integer scalar/vector
types, LLVM `i1` operands are treated as boolean and extended to `i32`
before the integer operation, then converted back to bool. This patch
applies the same principle to the LLVM backend path that currently uses
extended min/max instructions.
---------
Co-authored-by: Codex <noreply@openai.com>
The change is made in HexagonFrameLowering::(optimizeSpillSlots) function. This Pass is responsible for managing function's stack frame and ensuring proper stack space allocation. Spill slots means temporary memory locations used for storing register values that need to be spilled from registers to memory during code execution. While Optimizing these spill slots we should not handle debug instructions. Optimized the pass by skipping debug instructions in optimizeSpillSlots function. A DBG_VALUE describing a variable that lives in a spill slot has a frame index operand, but it is neither a load from nor a store to that slot, so the slot was marked as one that cannot be optimized and the store/load pair using it was no longer replaced with register copies. The code generated for a function therefore differed depending on whether debug info was enabled. Co-authored-by: Chandana Sinderikeri <csinderi@qti.qualcomm.com>
For the case when we force userVF and epilogueVF, we create only 2 vplans.vThis patch reorder the vplans creation to create the main loop vplan firstly then the epilogue loop vplan.
…214465) These were missing `NO_EXEC_STACK_DIRECTIVE` to add `.note.GNU-stack`; without it, a binary including any of these files will have the stack marked executable. Add the directive here, matching other similar files. Symtab diff before: $ clang compiler-rt/lib/builtins/arm/aeabi_uread4.S --target=arm-unknown-linux-gnueabi -c $ llvm-readelf aeabi_uread4.o -S There are 5 section headers, starting at offset 0xe4: Section Headers: [Nr] Name Type Address Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .strtab STRTAB 00000000 0000a8 000039 00 0 0 1 [ 2] .text PROGBITS 00000000 000034 000020 00 AX 0 0 4 [ 3] .ARM.attributes ARM_ATTRIBUTES 00000000 000054 000022 00 0 0 1 [ 4] .symtab SYMTAB 00000000 000078 000030 10 1 2 4 After: $ clang compiler-rt/lib/builtins/arm/aeabi_uread4.S --target=arm-unknown-linux-gnueabi -c $ llvm-readelf aeabi_uread4.o -S There are 6 section headers, starting at offset 0xf4: Section Headers: [Nr] Name Type Address Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .strtab STRTAB 00000000 0000a8 000049 00 0 0 1 [ 2] .text PROGBITS 00000000 000034 000020 00 AX 0 0 4 [ 3] .note.GNU-stack PROGBITS 00000000 000054 000000 00 0 0 1 [ 4] .ARM.attributes ARM_ATTRIBUTES 00000000 000054 000022 00 0 0 1 [ 5] .symtab SYMTAB 00000000 000078 000030 10 1 2 4 Fixes: 39413af ("[Compiler-rt] Implement AEABI Unaligned Read/Write Helpers in compiler-rt (#167913)")
The current behavior of merging EC and native chunks to have a single TLS directory for both views matches the MSVC linker, but it has its shortcomings. In addition to merging, that solution requires all TLS callbacks to use -arm64xsameaddress, leaving it to the CRT to handle. If the appropriate EC object files are not pulled in by linked EC code and thus never have a chance to mark the callback with -arm64xsameaddress, this may lead to an invalid image that crashes at runtime. This patch avoids the entire problem by using entirely separate TLS directories for EC and native views along with the standard ARM64X dynamic relocation mechanism. Since callback lists are now separate, a missing -arm64xsameaddress is no longer a problem. Also, mingw-w64-crt currently doesn't mark its TLS callbacks with -arm64xsameaddress. That could be changed if needed, but with this change, it is no longer necessary.
This fixes 1bfde5f (#213648). Buildkite error link: https://buildkite.com/llvm-project/upstream-bazel/builds?commit=1bfde5fd3b8f809fc7ab1ce32862276144783ef5 Co-authored-by: Google Bazel Bot <google-bazel-bot@google.com>
PR #211512 introduced new lit tests that are missing colons. This PR adds them back so the lit tests introduced actually run.
Summary: Make sure the tests can conditionally run on the correct features. I think that it would be nice if we could print from these tests, but that would require linking against `libc` for GPUs and I'm unsure if that's worth it, so for now I'm just sticking with traps as the failure mechanism.
…built (#214334) Right now we define no top-level `check-offload` target if `libomptarget` isn't built. Instead, just define the target to run the unit tests instead instead of running both the unit tests and the `libomptarget` tests we would do if `libomptarget` were built. It's really useful to have a top-level target to run tests, especially for CI. This target will be used by our Windows buildbot, as `libomptarget` isn't supported on Windows. --------- Signed-off-by: Nick Sarnie <nick.sarnie@intel.com>
Previously, liboffload tests were parametrized only with different devices. The following changes enable creating tests with additional parameters, besides devices. The existing tests, which often used C-style macros instead of incorporating Google Test features, are rewritten so that macros are replaced fully with Google Test parametrized fixtures. This patch adds: - a new fixture that allows for creating parameterized tests - new macros for the instantiation of parameterized tests - a helper header file that contains information related to parameterized tests, including the definition of parameters - new and refactored printers used in test instantiation Moreover, selected existing tests are modified and parametrized in order to make the code less repetitive and more concise. Tests with up to two possible parameters are not parameterized. Previously, the tests were already parameterized with `TestEnvironment::Device`. However, this patch combines `TestEnvironment::Device` with an additional parameter within `OffloadParam = std::tuple<TestEnvironment::Device, T>`. `OffloadParam<T>` is handled by a new fixture `OffloadDeviceTestWithParam<T>`, which provides the `getTestParam()` method for the parameter extraction. Other functionalities, such as access to the `Host` and to the `Device`, are identical to the previous version of `OffloadDeviceTest`. In order to avoid code duplication, the unparameterized versions of fixtures are aliases for parameterized fixtures, with `int` type chosen arbitrarily as an ignored parameter type, for example: `using OffloadDeviceTest = OffloadDeviceTestWithParam<int>;`. The single mock parameter of value `0` is combined with the devices in the provided macros, yielding tuples of type `std::tuple<TestEnvironment::Device, int>`. The hidden `int` parameter is not used, but it enables users to instantiate unparameterized tests without knowledge about the implementation details. Moreover, it allows for modifying only one version of the fixture (the one being aliased), without the need to also change the other version: either parameterized or unparameterized. The following macros are added in this patch: - `OFFLOAD_TESTS_INSTANTIATE_DEVICE_FIXTURE_WITH_PARAM(FIXTURE, VALUES, PRINTER)`: instantiates `FIXTURE` with parameters stored in the provided container `VALUES` (a C-style array or an STL-style container) and with the given printer. The used devices do not include the host. - `OFFLOAD_TESTS_INSTANTIATE_HOST_DEVICE_FIXTURE_WITH_PARAM(FIXTURE, VALUES, PRINTER)`: similar to `OFFLOAD_TESTS_INSTANTIATE_DEVICE_FIXTURE_WITH_PARAM`, but includes the `Host` in the tested devices. - `OFFLOAD_TESTS_INSTANTIATE_HOST_DEVICE_FIXTURE(FIXTURE)`: instantiates `FIXTURE` without additional parameters, but also includes the `Host` in the used devices. - `OFFLOAD_TESTS_INSTANTIATE_WITH_DEVICES(FIXTURE, DEVICES)`: instantiates `FIXTURE` with the provided devices, internally using a mock parameter. It is not intended for direct use and acts as a helper macro for the instantiation of unparameterized tests. - `OFFLOAD_TESTS_INSTANTIATE_WITH_DEVICES_WITH_PARAM(FIXTURE, VALUES, DEVICES, PRINTER)`: instantiates `FIXTURE` with the provided devices, parameters and the given printer. It is not intended for direct use and acts as a helper macro for the instantiation of parameterized tests. Since the new macros enable testing the `Host` as part of the used devices, `offload/unittests/OffloadAPI/device/olGetHostInfo.cpp` is deleted and its tests have been moved to `offload/unittests/OffloadAPI/device/olGetDeviceInfo.cpp`. The new helper header `offload/unittests/OffloadAPI/common/Properties.hpp`: - pairs properties with their sizes for tests similar to `offload/unittests/OffloadAPI/device/olGetDeviceInfo.cpp` - packs selected properties into containers or arrays for easier access and instantiation of fixtures
…antFP::get` (#213721) Compiler was crashing with: ``` Constants.cpp:1124: static llvm::ConstantFP* llvm::ConstantFP::get(llvm::Type*, const llvm::APFloat&): Assertion `Ty->getScalarType() == Type::getFloatingPointTy(Cont ext, V.getSemantics()) && "ConstantFP type doesn't match the type implied by its value!"' failed. ``` Since the code was quite similar to `getConstantFloatVector`, I've ended up modifying its implementation to also handle scalars and renamed it.
…s. (#212914) HexagonTargetLowering::LowerSETCC widens i8/i16 SETCC operands to i32 with a sign extension when the extension is free, or when the compared constant is negative in the narrow type. That is what the compare instructions want for equality comparisons, since they can encode small negative immediates, but for unsigned comparisons a constant with the sign bit of the narrow type set becomes a large 32-bit value that has to be materialized in a register or use a constant extender. For %v = load i16, ptr %p %c = icmp ult i16 %v, 65524 we generated r1 = #-12 r0 = memh(r0+#0) p0 = cmp.gtu(r1,r0) instead of r0 = memuh(r0+#0) p0 = cmp.gtu(r0,##65523) Restrict the transformation to equality condition codes and let the generic operand promotion pick the extension for everything else. Signed comparisons are unaffected, as the generic promotion already sign-extends them. Note that only the quality of the generated code was affected: sign extension preserves the unsigned ordering of the values of the narrower type, so the code produced before this change was correct. Co-authored-by: Sumanth Gundapaneni <sgundapa@quicinc.com>
…db, flang, and bolt (#214410) This is basically a continuation of #214349... This change adds missing `#include <cmath>` and `#include <limits>` headers to several files across `llvm`, `mlir`, `lldb`, `flang`, and `bolt`. In commit ada3786, `<random>` stopped transitively pulling in the top-level `<cmath>` header in favor of internal granular `<__math/...>` headers. Multiple files across the codebase were implicitly relying on transitive `<cmath>` inclusions from headers like `llvm/Support/RandomNumberGenerator.h` and other headers that pull in `<random>`. I'm explicitly adding the missing dependency. ### Affected Files * **bolt**: `bolt/lib/Passes/SplitFunctions.cpp` (`std::pow`) * **flang**: `flang/lib/Optimizer/CodeGen/Target.cpp` (`std::ceil`) * **lldb**: `lldb/source/Plugins/Language/ObjC/Cocoa.cpp` (`std::floor`) * **llvm**: * `llvm/lib/Transforms/Utils/Debugify.cpp` (`std::log10`) * `llvm/lib/Transforms/Utils/LowerMemIntrinsics.cpp` (`std::round`) * `llvm/tools/llvm-dwarfdump/Statistics.cpp` (`std::round`, `std::numeric_limits`) * `llvm/tools/llvm-exegesis/lib/Analysis.cpp` (`std::sqrt`) * `llvm/tools/llvm-exegesis/lib/ResultAggregator.cpp` (`std::ceil`) * `llvm/tools/llvm-exegesis/lib/SchedClassResolution.cpp` (`std::round`) * **mlir**: * `mlir/include/mlir/Dialect/Quant/Utils/UniformSupport.h` (`std::round`) * `mlir/lib/Dialect/LLVMIR/IR/NVVMDialect.cpp` (`std::log2`) * `mlir/lib/Target/LLVMIR/Dialect/NVVM/NVVMToLLVMIRTranslation.cpp` (`std::log2`)
…in Intel syntax (#211003) Old patterns and why they broke - Decisions matching (CurrState, PrevState) tuples (e.g. CurrState == IES_REGISTER && PrevState != IES_MULTIPLY) to gate committing a register to Base/Index aren't paren-transparent: any (...) turns CurrState into IES_RPAREN, so the tuple stops matching and `[reg + (reg)]`, `[reg + (reg*2)]`, `[reg + 2*(reg)]` fell through the guards. - Duplicated commit blocks. Recognizing whether a register is Base or Scale was placed in four handlers (onPlus, onMinus, onRBrac, onRParen), forcing onRParen to replay it just to catch (reg). - Scale was committed immediately in onInteger; a parenthesized scale like (2) * 4 or 2 * (4) had nowhere to accumulate. New patterns - Pending value. Two pending fields: TmpReg and TmpScale, that store the register/scale which is currently being processed. Commit happens only at (+, -, ]), therefore the solution is parenthesis-independent and can handle more scale expressions. - Identical in onPlus/onMinus/onRBrac: !BaseReg && !TmpScale → BaseReg (unscaled); otherwise → IndexReg with Scale. onRParen no longer commits, parens are purely an infix-calculator concern. - Multiplicative scale accumulator onInteger. onStar on IES_INTEGER seeds it from the popped operand; reset at +, -, [, ]. Handles 2 * 4, (2) * 4, 2 * (4), 2 * 2 * 2, (2 * (2 * rbx)) * 2, etc. - Conflict detection. Pending state makes two invariants diagnosable: TmpReg already set when a new register arrives via * or ( means multiplication of two registers; NegativeAdditiveTerm at commit means negative scale. Both previously misassembled silently.
#214268) When the destination/background vector of a TBX instruction is a splat of zero, the operation is equivalent to a TBL instruction. TBL implicitly zeroes out any elements where the index is out of bounds, matching the behavior of TBX with a zero background vector. This patch adds a DAG combine to optimize this case, reducing instruction latency and register pressure. Fixes #214077
…14470) Currently, histograms are not disabled for vscale x 1 types, but LV will implicitly not generate them because surrounding arithmetic instructions are invalid for vscale x 1. SDAG does not implement operand widening for histograms, so this patch explicitly disables those cases.
Default build mode in SPIRV-Tools is Debug
) Tracking issue: #201242 See the [migration guide] for more information. [migration guide]: https://llvm.org/docs/SphinxQuickstartTemplate.html#markdown-migration-guidelines This is the mechanical rename for part 1/4 of the remaining `bugprone` check documentation. The rewrite is provided by the next PR in this stack.
…4413) Tracking issue: #201242 See the [migration guide] for more information. [migration guide]: https://llvm.org/docs/SphinxQuickstartTemplate.html#markdown-migration-guidelines This rewrites part 1/4 of the remaining bugprone check documentation from reST to MyST Markdown. AI Usage: This was prepared with rst2myst and GPT5.6-assisted cleanup. I manually verified that the documentation renders as expected. Preview site: https://broken.life/llvm-staging/bugprone-markdown-port/
…4337) The main purpose of this patch is to implement the 'tls_model' attribute for ClangIR. However, this required updating the LLVM-IR dialect to ALSO support this, not just as a bool. This patch threads it into both sides. CIR tries to refer to it as "TLS_Model" to match the C/C++ attribute closely, the LLVM Dialect refers to it as ThreadLocalMode to reflect better what LLVM does. Left as still 'not done' (in CIR only!) is the lowering of the 'other' kinds of thread-local settings, which are intended to do various levels of locking/initialization. Those are left for a future implementation effort. The C++ test itself is taken directly from classic codegen.
This adds operations to the LLVM dialect to represent coroutine intrinsics that were previously missing from the dialect. A few coroutine operations were already in place. This change adds operations for the remaining intrinsics that cab be generated by Clang. There are some additional coroutine intrinsics defined in LLVM IR that aren't covered, but I'm omitting those until they are needed. We are in the process of implementing coroutine support in CIR, and these are the operations we'll need for lowering to LLVM. Assisted-by: Cursor / Grok 4.5
This is another change to prepare AArch64 builtin handling for the transition to constrained FP handling. It replaces a number of places where we were creating CIR operations directly with calls to emitNeonCallToOp so that we will be able to centralize the constrained FP handling. This also updates the vrndns_f32 to eliminate a redundant load of the operand, which is the only part of this change with a visible difference in the output. Assisted-by: Cursor / Grok 4.5
This change adds special constrained forms of transcendental operations for the remaining cases that lower to contrained fp intrinsic calls. It also adds fast-math flag support to the constrained operations, which is needed to handle combinations of Clang command-line options such as "-ffinite-math-only -ftrapping-math". Assisted-by: Cursor / various models
…#214372) LoadBinaryWithUUIDAndAddress both searched for a binary and registered it with the Target. Split it into LocateBinaries, which only searches, and LoadBinaryInTarget, which mutates the Target, with LocateAndLoadBinary keeping the single binary case a one-liner. The eight binary parameters and the results of the search are bundled in a new BinarySpec struct, and both entry points return an llvm::Expected. The motivation is a follow-up that runs LocateBinaries in parallel on the thread pool. NFC, except for some small improvements to the error handling because we don't write to the async output stream directly (and fixed the newline).
…4174) Fixes #214171 `ComputeOffsetsHelper::DoSymbol()` in `flang/lib/Semantics/compute-offsets.cpp` returned early without calling `symbol.set_offset()` when a symbol had zero size (e.g. CHARACTER*0). As a result, every zero-size symbol in a COMMON block retained its default offset of 0 — the block base address — instead of its correct sequential position. This incorrect offset caused two observable bugs: 1. **Wrong storage address**: LOC() and lowering always returned the block base address for zero-size members instead of their actual sequential position. 2. **False "cannot backward-extend" error**: When a zero-size COMMON block member appeared in an EQUIVALENCE association, the backward-extend check (`dep.offset > symbol.offset()`) incorrectly fired because `symbol.offset()` was always 0. For example, the following valid code was falsely rejected: ```fortran program p09 integer(8) :: i8 character(0) :: zc0 character(8) :: c8 common /blk/ i8, zc0 equivalence (c8(5:8), zc0) end program Error before fix: `error: 'zc0' cannot backward-extend COMMON block /blk/ via EQUIVALENCE with 'c8'` After the fix, `zc0` is correctly assigned offset 8 (after `i8`), so `dep.offset` (4) < `symbol.offset()` (8) and no error is raised.
This is required when NEON is disabled with -mattr=-neon.
Before this, vector FABS that were scheduled for expansion would hit the getSignAsIntValue() case and either assert there or fail later for lock of instruction selection for a bitcast that's only looking at the scalar size. Now, we unroll to scalars as needed. Test pre-committed in #214288
…ombine (NFC) (#214355) Add regbank-combiner tests covering a copy to vgpr whose source is a merge or build_vector of `G_AMDGPU_READANYLANE` results mixed with uniform values. These currently keep the round trip through sgprs. The tests also cover the two cases where the transform must not fire: - the sgpr merge has another user, so it has to be kept; - all merge sources are uniform, so moving the copy to the sources would not remove any readanylane. Pre-commit only, no functional change. The combine that removes the round trip is in the stacked PR. Made with [Cursor](https://cursor.com) --------- Co-authored-by: Cursor <cursoragent@cursor.com> Co-authored-by: Matt Arsenault <Matthew.Arsenault@amd.com>
…during merging" (#208009) (#210138) This relands #208009, which was reverted in #209987 after an ASan heap-use-after-free surfaced in MergeFunctionsTest.TrueOutputModuleTest. The failure was caused by MergeFunctionsTest destroying FunctionAnalysisManager before ModuleAnalysisManager, while MAM holds a cached proxy result that calls FAM.clear() on destruction. This PR adds a commit reordering those members, so they are destroyed in the correct order, fixing the use-after-free. Original PR: #208009 Revert PR: #209987
…4380) CanDebug returns true whenever the plugin is requested by name, and the architecture is not known until the stub reports it after connecting. This means that a non-Wasm process can end up with a ThreadWasm whose register context and unwinder have nothing to operate on. Create the plain ThreadGDBRemote once the architecture is known, and add a helper so that the check covers wasm64 as well as wasm32. rdar://182229301
Add a new builtin type __spirv_event_t for SPIR-V targets. It represents
SPIR-V's OpTypeEvent and lowers to the target("spirv.Event") extension
type.
We would like to expose SPIR-V instructions to users via builtins (not
yet
implemented). The builtins return an event type.
Assisted by Claude Opus 4.8 for writing tests.
…14368) bufferizeBlockSignature only rewrote the first successor index that matched the target block. Branch ops such as cf.cond_br can list the same destination more than once, but the later edges were left as tensors and broke multi-block bufferization. Now we simply iterate the block's BlockOperands so each successor edge is handled once.
…ide arguments (#212881) Hovering on the slot identifier inside `register(t1)` (e.g. on `t1`) previously produced no tooltip, only hovering on the `register` keyword itself worked. `HLSLResourceBindingAttr`'s `SourceRange` was zero-width: both the start and end pointed to the start of the `register` keyword. `ParseHLSLAnnotations` called `Attrs.addNew` with a single `SourceLocation` instead of a full `SourceRange`. Since clangd's `SelectionTree` only matches when the cursor falls inside an attribute's range, a zero-width range never matched positions inside the argument. Capture the closing `)` location before it's consumed in the `AT_HLSLResourceBinding` case, and pass a full `SourceRange` (from the attribute start to the closing paren) to `addNew`. Fixes #212749
Consecutive wmma/swmmac ops accumulating into the same matrix C register reuse the accumulator in place, so the tied srcC read is omitted and no delay is needed. AMDGPUInsertDelayAlu did not model this and emitted an s_delay_alu that stalls the reuse chain. Detect a C-reuse edge (tied srcC exactly matches the previous wmma/ swmmac dest, with no intervening instruction) and skip the delay for that operand. This applies on all wmma-capable targets (gfx11+).
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 : )