-
Notifications
You must be signed in to change notification settings - Fork 769
[SYCL][Doc] SYCL 2020 specialization constants design #3331
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SYCL][Doc] SYCL 2020 specialization constants design #3331
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
1 design question, 1 nit.
This is a draft patch to get early feedback. Spec is currently under review here - intel#3331 Signed-off-by: Elizabeth Andrews <[email protected]>
|
||
> A constant variable where the value is not known until compilation of the | ||
> SYCL kernel function. | ||
> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we get clarification about exactly what constitutes compilation time of the SYCL kernel function?
In ahead of time compilation does this mean that all specialization constants must be known at that time?
In JIT compilation, does this mean the the first time the kernel is jitted for a device the specialization constants can all be resolved, and that the kernel never needs to be jitted for that device again?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The SYCL 2020 specification describes specialization constants this way:
Device code can make use of specialization constants which represent constants whose values can be set dynamically during execution of the SYCL application. The values of these constants are fixed when a SYCL kernel function is invoked, and they do not change during the execution of the kernel. However, the application is able to set a new value for a specialization constant each time a kernel is invoked, so the values can be tuned differently for each invocation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, so the above should change to say "A constant variable where the value is not known until invocation of the SYCL kernel function." rather than compilation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, so the above should change to say "A constant variable where the value is not known until invocation of the SYCL kernel function." rather than compilation.
@kbsmith-intel, @romanovvlad, please note that this was a quote from the spec (Glossary section), so if we change it here we should also reflect that in the spec.
Can we get clarification about exactly what constitutes compilation time of the SYCL kernel function?
I guess it depends on whether we are talking about online or offline compilation. Plus, even for offline compilation SYCL spec doesn't specify the exact formats used by the compiler:
When a SYCL application contains SYCL kernel function objects, the SYCL implementation must provide
an offline compilation mechanism that enables the integration of the device binaries into the SYCL application. The output of the offline compiler can be an intermediate representation, such as SPIR-V, that
will be finalized during execution or a final device ISA.3.5. The SYCL platform model
In ahead of time compilation does this mean that all specialization constants must be known at that time?
For AOT, we produce a native executable object and the idea that it don't need any further online compilation/linking before being executed. Therefore, we can only two ways of dealing with spec constants:
- Capture some default values of them and embed them into generated binary
- Emulate support of specialization constants without needing to recompile the binary
SYCL 2020 spec mandates us to support changing specialization constants values even for AOT-compiled programs, which means that we go with (2) here.
In JIT compilation, does this mean the the first time the kernel is jitted for a device the specialization constants can all be resolved, and that the kernel never needs to be jitted for that device again?
This is not entirely true: it is possible that kernel needs to be jitted again for the same device, because it was launched with different values of specialization constants. See the following note from the spec:
Implementations that support online compilation of kernel bundles will likely implement both methods of specialization constants using kernel bundles. Therefore, applications should expect that there is some overhead associated with invoking a kernel with
new values for its specialization constants. A typical implementation records the values
of specialization constants set viahandler::set_specialization_constant()
and remembers these values until a kernel is invoked (e.g. viaparallel_for()
). At this point, the
implementation determines the bundle that contains the invoked kernel. If that bundle
has already been compiled for the handler’s device and compiled with the correct values
for the specialization constants, the kernel is scheduled for invocation. Otherwise, the
implementation compiles the bundle before scheduling the kernel for invocation. Therefore, applications that frequently change the values of specialization constants may see
an overhead associated with recompilation of the kernel’s bundle.4.9.5. Specialization constants
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that this is resolved for the purposes of the design discussion. I think the SYCL spec wording is still confusing :-).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kbsmith-intel, I quoted the SYCL spec's description of specialization constant above. If you can tell me the part that seems confusing, I can update the spec.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These statements, from 4.9.5, seem very clear.
Device code can make use of specialization constants which represent constants whose values can be set
dynamically during execution of the SYCL application. The values of these constants are fixed when a
SYCL kernel function is invoked, and they do not change during the execution of the kernel. However,
the application is able to set a new value for a specialization constant each time a kernel is invoked, so
the values can be tuned differently for each invocation.
This statement, from page 502 of the glossary, and what is quoted above in the design document is wrong/confusing:
specialization constant
A constant variable where the value is not known until compilation of the SYCL kernel function.
I think in the design document above, we should change the wording from the glossary wording to:
"SYCL 2020, 4.9.5: Device code can make use of specialization constants which represent constants whose values can be set
dynamically during execution of the SYCL application. The values of these constants are fixed when a
SYCL kernel function is invoked, and they do not change during the execution of the kernel. However,
the application is able to set a new value for a specialization constant each time a kernel is invoked, so
the values can be tuned differently for each invocation."
And I think the SYCL 2020 glossary should be updated to be consistent with 4.9.5.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And I think the SYCL 2020 glossary should be updated to be consistent with 4.9.5.
Oh yes, that should be updated. I'll fix it. Thanks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Greg
Will update wording today. |
Added overview of new mapping design, detailed description for each component TBD.
This is still WIP, see TODOs in the document
template<> | ||
const char *get_spec_constant_symbolic_ID<Wrapper::float_const>() { | ||
return "unique_name_for_Wrapper_float_const"; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think these template functions need to be defined inline
because you might get duplicates across translation units. For example, consider a case where Wrapper
is declared in a second translation unit and that second TU also uses Wrapper::float_const
. That second TU will also have a definition of get_spec_constant_symbolic_ID<Wrapper::float_const>()
. Unless the two definitions are inline
, the linker will give a multiply-defined-symbol error.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, added inline in edb1586
template<> | ||
const char *get_spec_constant_symbolic_ID<Wrapper::float_const>() { | ||
return "unique_name_for_Wrapper_float_const"; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Somewhere (either here are below in "DPC++ Compiler: front-end") there should be a description about the requirements for the strings that are returned by get_spec_constant_symbolic_ID()
. I think the requirement is:
-
If the
specialization_id
variable has internal linkage, the string must be unique across all translation units. Since the mangled name is not necessarily unique, you cannot use that. Instead, the FE probably needs to generate a GUID. -
If the
specialization_id
variable has external linkage, the string must be consistent in all translation units that reference this same variable. The mangled name would be a good choice because it will have the same value in every translation unit that references this same variable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added those requirements in ce4788a. Note: I've also added a requirement that the built-in should return the same unique string if it was called twice within a single translation unit for the same variable, i.e. the compiler should preserve a mapping internal linkage variable
-> GUID
in order to do that.
This additional requirement is related to another conversation we have below in this PR - let's wait for some feedback from @erichkeane about what what be easier for FE to implement - stable unique names for variable with internal linkage or including integration footer into device code compilation, depending on that we can update our design document
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought we already decided on a integration footer, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The built-in is used twice in the codebase:
- within
kernel_handler::get_specialization_constant
method - device code - within
handler::set_specialization_constant
method - host code
The first one is used by sycl-post-link
to identify specialization constants and generate corresponding device image properties.
The second one is used by DPC++ RT to connect specialization_id
s to device image properties.
So, for (1) we call the built-in directly as we are in device code and we can rely on its availability. For (2) we can't do that, because we would like to support 3rd-party host compilers and therefore we rely on the compiler here, in particular on the fact that integration footer will provide to us pre-computed result of calling that built-in without actually putting the call into the source code.
This comes down to a requirement that even though we should get unique strings for internal variables from different translation units, we should get the same string if we call the built-in second time for the same variable within a single translation unit
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, ok, I think we're on the same page. The value at host-side would be pre-computed by the device side. We can do the 'same TU, same answer' thing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well... maybe? that would be really rough and I'm not sure makes it unique. There are some constexpr/template tricks to cause 'counting' that might defeat it, but none I'm smart enough to write myself.
I think I like the idea of having the driver pass us a unique token per-TU during the device compile instead. That way it can just pass us some random value and have it be the same to each invocation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea of having the driver pass some sort of unique token to each is possible, at that point we can just do away with the GUID and do the normal mangling for the internal types. Though, of course, that can be affected by macros in some cases...
This seems like a workable direction. The driver creates a GUID and passes it via a command line parameter to the device compiler. For a specialization constant with internal linkage, the device compiler generates a string "GUID" + "mangled name".
I didn't understand @erichkeane's concern about "that can be affected by macros in some cases...". Can you elaborate?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gmlueck : A sometimes used pattern (particularly in some of the boost code generators IIRC) is to generate a single .cpp file to represent multiple TUs and execute it multiple times with predefined macros. So something like:
clang++ My_File.cpp -DALL
clang++ My_File.cpp -DSECTION1
clang++ My_File.cpp -DSECTION2
clang++ My_File.cpp -DSECTION3
etc. The nasty part about this is sometimes there are code-generation/modification steps in between each, so My_File.cpp isn't actually the same file (let alone having different sections compiled each time!). So something like:
clang++ My_File.cpp -DALL
clang++ My_File.cpp -DSECTION1
./SomeScriptThatInsertsInfoFromThePreviousThingIntoMyFile
clang++ My_File.cpp -DSECTION2
clang++ My_File.cpp -DSECTION3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. I think this is not a problem for the proposed design where the driver creates the GUID. In the case you describe, each invocation of "clang++" (e.g. "clang++ My_File.cpp -DALL") would generate a different GUID, so each TU will still get unique strings for internal spec constants, despite being compiled from the same source file.
Of course, another solution would be for the driver to have some new pass that created the integration footer before any invocations of the device compiler. In this case, the footer could be appended to the source file before invoking the device compiler, and then we wouldn't need __builtin_unique_ID()
at all. In some ways, this seems like a cleaner design, but I presume we are concerned about extra compilation time overhead by adding a new pass.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me point out that anything involving full path name is not going to work from a privacy perspective. That potentially leaks private user identifiable data, such as login id.
The driver creating GUID sounds OK
[sycl-registry]: https://www.khronos.org/registry/SYCL/ | ||
[sycl-2020-spec]: https://www.khronos.org/registry/SYCL/specs/sycl-2020/html/sycl-2020.html | ||
|
||
TODO: feature overview? code example? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was pressed to 'LGTM' for a bit here... can we fix the "TODOs" before we do so?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This particular TODO
fixed in 0e756c1, but there are still at least one more left
// }; | ||
|
||
template<> | ||
inline const char *get_spec_constant_symbolic_ID<int_const>() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This still hasn't been closed on (anonymous namespaces being 'hidden'). At the moment, we're likely going to cause a host-error.
Co-authored-by: Dmitry Vodopyanov <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM overall, just a couple of comments.
Co-authored-by: Romanov Vlad <[email protected]>
…#3499) The Spec-constant design (#3331) has a few dependencies on the CFE, including generating unique names for reachable specialization_id variables and putting the results in the integration footer. This patch helps with this effort in 2 ways: First, it creates a command line option that will be used eventually to ensure that types with internal linkage have names unique to this translation unit. This will eventually be used by the unique-id/unique-stable-name implementation, but is required as a CC1 option to unblock the Driver implementation. Second, it generates the integration footer sans the generated names (which will be added when we have the unique-id/unique-stable-name implementation in place). This is necessary to unblock library implementation of this feature.
…or non-native spec constants (#3561) The main purpose of this change is to emit the same device image property SYCL/specialization constants not only when native spec constants are supported, but also when they are emulated. This is needed to support SYCL 2020 specialization constants, design document can be found in: #3331. The task is achieved by changing the way how SpecConstantsPass works with metadata: in order to provide info which should be put into device image properties, it was attached as metadata to __spirv_SpecConstant intrinsics and they are not generated if native spec constants are not available. New approach creates a single named metadata sycl.specialization-constants which contains a list of metadatas, corresponding to each specialization constant found in the module. Such new representation makes it easier to generate metadata and more significantly, it should improve the speed of reading them, because we don't need to look over each call to __spirv_SpecConstant intrinsic.
…thub.com:romanovvlad/llvm into private/vromanov/sycl-2020-spec-constants-design
@erichkeane, I've updated FE/integration footer sections of the doc in e88f402 Could you please take a look? |
I think you mean fc2faf3? That looks accurate/correct to me. |
I think I meant 71ece59. Note: |
doing so we can still use this non-standard built-in function and preserve | ||
support for third-party host compilers. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have any instruction how a user can build an app with a third-party host compiler. Specifically - what is our recommendation how user can "include" integration footer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have any instruction how a user can build an app with a third-party host compiler.
AFAIK, we have a command line option which allows to specify the host compiler and its options, but it is likely that we don't have an specific guide for that.
}; | ||
|
||
constexpr specialization_id<int> id_int; | ||
struct Wraper { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any description why this is needed in the doc?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a user code snippet which is added to demonstrate the content which should be generated by the compiler in integration footer.
constexpr specialization_id<int> id_int; | ||
struct Wraper { | ||
public: | ||
static constexpr specialization_id<A> id_A; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should also mention wrappers which are being introduced in the patch which does "integration footer integration".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They are mentioned in the section Ambiguous references to specialization_id
…12884) Bumps the llvm-docs-requirements group in /llvm/docs with 5 updates: | Package | From | To | | --- | --- | --- | | [sphinx-automodapi](https://github.com/astropy/sphinx-automodapi) | `0.16.0` | `0.17.0` | | [furo](https://github.com/pradyunsg/furo) | `2023.9.10` | `2024.1.29` | | [certifi](https://github.com/certifi/python-certifi) | `2023.11.17` | `2024.2.2` | | [markupsafe](https://github.com/pallets/markupsafe) | `2.1.4` | `2.1.5` | | [urllib3](https://github.com/urllib3/urllib3) | `2.1.0` | `2.2.1` | Updates `sphinx-automodapi` from 0.16.0 to 0.17.0 <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/astropy/sphinx-automodapi/releases">sphinx-automodapi's releases</a>.</em></p> <blockquote> <h2>v0.17.0 Release Notes</h2> <p>Also see <code>CHANGES.rst</code>.</p> <h2>What's Changed</h2> <ul> <li>MNT: Drop Python 3.7 and update test matrix again by <a href="https://github.com/pllim"><code>@pllim</code></a> in <a href="https://redirect.github.com/astropy/sphinx-automodapi/pull/177">astropy/sphinx-automodapi#177</a></li> <li>CI: fix environment name by <a href="https://github.com/bsipocz"><code>@bsipocz</code></a> in <a href="https://redirect.github.com/astropy/sphinx-automodapi/pull/178">astropy/sphinx-automodapi#178</a></li> <li>CI: update versions by <a href="https://github.com/bsipocz"><code>@bsipocz</code></a> in <a href="https://redirect.github.com/astropy/sphinx-automodapi/pull/179">astropy/sphinx-automodapi#179</a></li> <li>Updated "Use <strong>dict</strong> and ignore <strong>slots</strong> on classes <a href="https://redirect.github.com/astropy/sphinx-automodapi/issues/169">#169</a> by <a href="https://github.com/kylefawcett"><code>@kylefawcett</code></a> in <a href="https://redirect.github.com/astropy/sphinx-automodapi/pull/181">astropy/sphinx-automodapi#181</a></li> <li>Add automodsumm_included_members option, take2 by <a href="https://github.com/bsipocz"><code>@bsipocz</code></a> in <a href="https://redirect.github.com/astropy/sphinx-automodapi/pull/165">astropy/sphinx-automodapi#165</a></li> <li>Bump codecov/codecov-action from 3 to 4 in /.github/workflows by <a href="https://github.com/dependabot"><code>@dependabot</code></a> in <a href="https://redirect.github.com/astropy/sphinx-automodapi/pull/183">astropy/sphinx-automodapi#183</a></li> <li>Fix nonascii object names by <a href="https://github.com/m-rossi"><code>@m-rossi</code></a> in <a href="https://redirect.github.com/astropy/sphinx-automodapi/pull/184">astropy/sphinx-automodapi#184</a></li> </ul> <h2>New Contributors</h2> <ul> <li><a href="https://github.com/kylefawcett"><code>@kylefawcett</code></a> made their first contribution in <a href="https://redirect.github.com/astropy/sphinx-automodapi/pull/181">astropy/sphinx-automodapi#181</a></li> <li><a href="https://github.com/dependabot"><code>@dependabot</code></a> made their first contribution in <a href="https://redirect.github.com/astropy/sphinx-automodapi/pull/183">astropy/sphinx-automodapi#183</a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/astropy/sphinx-automodapi/compare/v0.16.0...v0.17.0">https://github.com/astropy/sphinx-automodapi/compare/v0.16.0...v0.17.0</a></p> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/astropy/sphinx-automodapi/blob/main/CHANGES.rst">sphinx-automodapi's changelog</a>.</em></p> <blockquote> <h2>0.17.0 (2024-02-22)</h2> <ul> <li> <p>Fixes issue where <code>__slots__</code> hides class variables. <a href="https://redirect.github.com/astropy/sphinx-automodapi/issues/181">#181</a></p> </li> <li> <p>Minimum supported Python version is now 3.8. <a href="https://redirect.github.com/astropy/sphinx-automodapi/issues/177">#177</a></p> </li> <li> <p>Fixed issue with non-ascii characters in object names. <a href="https://redirect.github.com/astropy/sphinx-automodapi/issues/184">#184</a></p> </li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/astropy/sphinx-automodapi/commit/e5cb71b9b5a33d4fe26e2b9fe7130577bbff2207"><code>e5cb71b</code></a> Finalize change log for 0.17.0</li> <li><a href="https://github.com/astropy/sphinx-automodapi/commit/2963d43ec252ec9f973a2f5767a2e973f3e5f27a"><code>2963d43</code></a> Merge pull request <a href="https://redirect.github.com/astropy/sphinx-automodapi/issues/184">#184</a> from m-rossi/more-nonascii-fixes</li> <li><a href="https://github.com/astropy/sphinx-automodapi/commit/5ab68d0d3f5c90bb1fd2b260e457ae7ba2091226"><code>5ab68d0</code></a> Also update filename</li> <li><a href="https://github.com/astropy/sphinx-automodapi/commit/5cb1818309dc54d3680f0474dac96faa1700bb72"><code>5cb1818</code></a> Ensure <a href="https://github.com/bsipocz"><code>@bsipocz</code></a> name is handled</li> <li><a href="https://github.com/astropy/sphinx-automodapi/commit/4d78a2cf5b96c3edb1afd1862e95abd325b47fed"><code>4d78a2c</code></a> Add period at the end of sentence</li> <li><a href="https://github.com/astropy/sphinx-automodapi/commit/f111d36fef67feb8780e384d454a9018666a2ed5"><code>f111d36</code></a> Update changelog</li> <li><a href="https://github.com/astropy/sphinx-automodapi/commit/511f6de231fe298d9d48e21271cf10cfe577a1d8"><code>511f6de</code></a> Set another open dialog with encoding utf8 to try to fix errors on Windows</li> <li><a href="https://github.com/astropy/sphinx-automodapi/commit/bb6d65ee942068eba79076cccf7861110d9c6007"><code>bb6d65e</code></a> Fix nonascii object names</li> <li><a href="https://github.com/astropy/sphinx-automodapi/commit/56f69fe6ace1ad90bdf539614e3b6c2504820a3f"><code>56f69fe</code></a> Merge pull request <a href="https://redirect.github.com/astropy/sphinx-automodapi/issues/183">#183</a> from astropy/dependabot/github_actions/dot-github/wor...</li> <li><a href="https://github.com/astropy/sphinx-automodapi/commit/25b3e5f07becbcd8fce94d19373f765fbc59dab2"><code>25b3e5f</code></a> Bump codecov/codecov-action from 3 to 4 in /.github/workflows</li> <li>Additional commits viewable in <a href="https://github.com/astropy/sphinx-automodapi/compare/v0.16.0...v0.17.0">compare view</a></li> </ul> </details> <br /> Updates `furo` from 2023.9.10 to 2024.1.29 <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/pradyunsg/furo/blob/main/docs/changelog.md">furo's changelog</a>.</em></p> <blockquote> <h1>Changelog</h1> <!-- raw HTML omitted --> <h2>2024.01.29 -- Amazing Amethyst</h2> <ul> <li>Fix canonical url when building with <code>dirhtml</code>.</li> <li>Relicense the demo module.</li> </ul> <h2>2023.09.10 -- Zesty Zaffre</h2> <ul> <li>Make asset hash injection idempotent, fixing Sphinx 6 compatibility.</li> <li>Fix the check for HTML builders, fixing non-HTML Read the Docs builds.</li> </ul> <h2>2023.08.19 -- Xenolithic Xanadu</h2> <ul> <li>Fix missing search context with Sphinx 7.2, for dirhtml builds.</li> <li>Drop support for Python 3.7.</li> <li>Present configuration errors in a better format -- thanks <a href="https://github.com/AA-Turner"><code>@AA-Turner</code></a>!</li> <li>Bump <code>require_sphinx()</code> to Sphinx 6.0, in line with dependency changes in Unassuming Ultramarine.</li> </ul> <h2>2023.08.17 -- Wonderous White</h2> <ul> <li>Fix compatiblity with Sphinx 7.2.0 and 7.2.1.</li> </ul> <h2>2023.07.26 -- Vigilant Volt</h2> <ul> <li>Fix compatiblity with Sphinx 7.1.</li> <li>Improve how content overflow is handled.</li> <li>Improve how literal blocks containing inline code are handled.</li> </ul> <h2>2023.05.20 -- Unassuming Ultramarine</h2> <ul> <li>✨ Add support for Sphinx 7.</li> <li>Drop support for Sphinx 5.</li> <li>Improve the screen-reader label for sidebar collapse.</li> <li>Make it easier to create derived themes from Furo.</li> <li>Bump all JS dependencies (NodeJS and npm packages).</li> </ul> <h2>2023.03.27 -- Tasty Tangerine</h2> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/pradyunsg/furo/commit/9e9225cb5fc5075d27efff89ecb9bdcf3d959a26"><code>9e9225c</code></a> Prepare release: 2024.01.29</li> <li><a href="https://github.com/pradyunsg/furo/commit/10a63fb2b19f3e52c9d41586f45a9c7e8d50f1ea"><code>10a63fb</code></a> Update changelog</li> <li><a href="https://github.com/pradyunsg/furo/commit/222684bffb6a7261cabf264e0fa002d8fa62bcef"><code>222684b</code></a> Bump JS dependencies</li> <li><a href="https://github.com/pradyunsg/furo/commit/5732e4ac22216453dfce4467f80cdc58714e15ce"><code>5732e4a</code></a> [pre-commit.ci] pre-commit autoupdate (<a href="https://redirect.github.com/pradyunsg/furo/issues/746">#746</a>)</li> <li><a href="https://github.com/pradyunsg/furo/commit/e16ca0133061beb619f81cb9f1d1bc1024139a30"><code>e16ca01</code></a> [pre-commit.ci] pre-commit autoupdate (<a href="https://redirect.github.com/pradyunsg/furo/issues/735">#735</a>)</li> <li><a href="https://github.com/pradyunsg/furo/commit/0af0547d9d086bbb18b1f8e3f4e4203c2d72326d"><code>0af0547</code></a> Update the linters</li> <li><a href="https://github.com/pradyunsg/furo/commit/d14286c8345cc5509bc8363d15c77a4607529f74"><code>d14286c</code></a> [pre-commit.ci] pre-commit autoupdate (<a href="https://redirect.github.com/pradyunsg/furo/issues/691">#691</a>)</li> <li><a href="https://github.com/pradyunsg/furo/commit/f0a9a2750ce061109fbf853c2695f79d76bbd904"><code>f0a9a27</code></a> Fix as -> are typo in blocks.rst (<a href="https://redirect.github.com/pradyunsg/furo/issues/734">#734</a>)</li> <li><a href="https://github.com/pradyunsg/furo/commit/258d5540817bb441ef503374a7d9d0fcd6438dcc"><code>258d554</code></a> Fix dirhtml canonical url (<a href="https://redirect.github.com/pradyunsg/furo/issues/727">#727</a>)</li> <li><a href="https://github.com/pradyunsg/furo/commit/079d829fa63091b51522c28de4e6140a9e4552a6"><code>079d829</code></a> Relicense the demo module</li> <li>Additional commits viewable in <a href="https://github.com/pradyunsg/furo/compare/2023.09.10...2024.01.29">compare view</a></li> </ul> </details> <br /> Updates `certifi` from 2023.11.17 to 2024.2.2 <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/certifi/python-certifi/commit/45eb6113c0cff15293611eedf237f7345dcf24bd"><code>45eb611</code></a> 2024.02.02 (<a href="https://redirect.github.com/certifi/python-certifi/issues/266">#266</a>)</li> <li><a href="https://github.com/certifi/python-certifi/commit/83f4f04419f0f2d14fe3ee1309feebb9d776072d"><code>83f4f04</code></a> fix leaking certificate issue (<a href="https://redirect.github.com/certifi/python-certifi/issues/265">#265</a>)</li> <li><a href="https://github.com/certifi/python-certifi/commit/bbf2208229ce26cfcd860eb6c551dded130eea04"><code>bbf2208</code></a> Bump actions/upload-artifact from 4.2.0 to 4.3.0 (<a href="https://redirect.github.com/certifi/python-certifi/issues/264">#264</a>)</li> <li><a href="https://github.com/certifi/python-certifi/commit/9e837a5fbd135b95057abb8f14b775a50aee8a01"><code>9e837a5</code></a> Bump actions/upload-artifact from 4.1.0 to 4.2.0 (<a href="https://redirect.github.com/certifi/python-certifi/issues/262">#262</a>)</li> <li><a href="https://github.com/certifi/python-certifi/commit/05d071b6125558e97cf3a8ef12d9c393e3967d17"><code>05d071b</code></a> Bump actions/upload-artifact from 4.0.0 to 4.1.0 (<a href="https://redirect.github.com/certifi/python-certifi/issues/261">#261</a>)</li> <li><a href="https://github.com/certifi/python-certifi/commit/2a3088a1cb569a93dab8c8ba6e8d959902b682d5"><code>2a3088a</code></a> Bump actions/download-artifact from 4.1.0 to 4.1.1 (<a href="https://redirect.github.com/certifi/python-certifi/issues/260">#260</a>)</li> <li><a href="https://github.com/certifi/python-certifi/commit/d4ca66e11e8200be0332590dd92a15d9a58ae894"><code>d4ca66e</code></a> Bump actions/upload-artifact from 3.1.3 to 4.0.0 (<a href="https://redirect.github.com/certifi/python-certifi/issues/258">#258</a>)</li> <li><a href="https://github.com/certifi/python-certifi/commit/5d1566377a5449aac90d7080928ae77027c7c85b"><code>5d15663</code></a> Bump actions/download-artifact from 3.0.2 to 4.1.0 (<a href="https://redirect.github.com/certifi/python-certifi/issues/257">#257</a>)</li> <li><a href="https://github.com/certifi/python-certifi/commit/d66ef9de10a59e5a162230abd1c46a4c94242633"><code>d66ef9d</code></a> Bump actions/setup-python from 4.7.1 to 5.0.0 (<a href="https://redirect.github.com/certifi/python-certifi/issues/256">#256</a>)</li> <li><a href="https://github.com/certifi/python-certifi/commit/8f0d4125b269a45f366eb37e04d1a0a7866d0f52"><code>8f0d412</code></a> Bump pypa/gh-action-pypi-publish from 1.8.10 to 1.8.11 (<a href="https://redirect.github.com/certifi/python-certifi/issues/255">#255</a>)</li> <li>Additional commits viewable in <a href="https://github.com/certifi/python-certifi/compare/2023.11.17...2024.02.02">compare view</a></li> </ul> </details> <br /> Updates `markupsafe` from 2.1.4 to 2.1.5 <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/pallets/markupsafe/releases">markupsafe's releases</a>.</em></p> <blockquote> <h2>2.1.5</h2> <p>This is a fix release for the 2.1.x feature release branch. It fixes bugs but does not otherwise change behavior and should not result in breaking changes.</p> <p>Fixes a regression in <code>striptags</code> behavior from 2.14. Spaces are now collapsed correctly.</p> <ul> <li>Changes: <a href="https://markupsafe.palletsprojects.com/en/2.1.x/changes/#version-2-1-5">https://markupsafe.palletsprojects.com/en/2.1.x/changes/#version-2-1-5</a></li> <li>Milestone: <a href="https://github.com/pallets/markupsafe/milestone/12?closed=1">https://github.com/pallets/markupsafe/milestone/12?closed=1</a></li> <li>PyPI: <a href="https://pypi.org/project/MarkupSafe/2.1.5/">https://pypi.org/project/MarkupSafe/2.1.5/</a></li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/pallets/markupsafe/blob/main/CHANGES.rst">markupsafe's changelog</a>.</em></p> <blockquote> <h2>Version 2.1.5</h2> <p>Released 2024-02-02</p> <ul> <li>Fix <code>striptags</code> not collapsing spaces. :issue:<code>417</code></li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/pallets/markupsafe/commit/fbba4acd0312826cec9cfe18371c7df07962cb65"><code>fbba4ac</code></a> release version 2.1.5</li> <li><a href="https://github.com/pallets/markupsafe/commit/c5fa23ba96336160204ed1376d60693b0d65e18d"><code>c5fa23b</code></a> update publish actions</li> <li><a href="https://github.com/pallets/markupsafe/commit/60a6512315d0ce05e6788808f80be526f2084b3f"><code>60a6512</code></a> striptags collapses spaces correctly (<a href="https://redirect.github.com/pallets/markupsafe/issues/418">#418</a>)</li> <li><a href="https://github.com/pallets/markupsafe/commit/0b6bee071fbd8d3171fb1ac4fb669baace808438"><code>0b6bee0</code></a> collapse spaces after stripping tags</li> <li><a href="https://github.com/pallets/markupsafe/commit/73e6a4886564a554c4a19983d29c97f9fc95457d"><code>73e6a48</code></a> start version 2.1.5</li> <li><a href="https://github.com/pallets/markupsafe/commit/d704bf45a1f77926a669261b394afef38eda2a70"><code>d704bf4</code></a> use pip-compile, dependabot updates (<a href="https://redirect.github.com/pallets/markupsafe/issues/419">#419</a>)</li> <li><a href="https://github.com/pallets/markupsafe/commit/1f82932e5c5a6e54181308afeb8443df21858ea0"><code>1f82932</code></a> use pip-compile, dependabot updates</li> <li><a href="https://github.com/pallets/markupsafe/commit/25a640f38297bfdc2ec2c82fe68df4c7613d083a"><code>25a640f</code></a> release version 2.1.4 (<a href="https://redirect.github.com/pallets/markupsafe/issues/414">#414</a>)</li> <li>See full diff in <a href="https://github.com/pallets/markupsafe/compare/2.1.4...2.1.5">compare view</a></li> </ul> </details> <br /> Updates `urllib3` from 2.1.0 to 2.2.1 <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/urllib3/urllib3/releases">urllib3's releases</a>.</em></p> <blockquote> <h2>2.2.1</h2> <h2>🚀 urllib3 is fundraising for HTTP/2 support</h2> <p><a href="https://sethmlarson.dev/urllib3-is-fundraising-for-http2-support">urllib3 is raising ~$40,000 USD</a> to release HTTP/2 support and ensure long-term sustainable maintenance of the project after a sharp decline in financial support for 2023. If your company or organization uses Python and would benefit from HTTP/2 support in Requests, pip, cloud SDKs, and thousands of other projects <a href="https://opencollective.com/urllib3">please consider contributing financially</a> to ensure HTTP/2 support is developed sustainably and maintained for the long-haul.</p> <p>Thank you for your support.</p> <h2>Changes</h2> <ul> <li>Fixed issue where <code>InsecureRequestWarning</code> was emitted for HTTPS connections when using Emscripten. (<a href="https://redirect.github.com/urllib3/urllib3/issues/3331">#3331</a>)</li> <li>Fixed <code>HTTPConnectionPool.urlopen</code> to stop automatically casting non-proxy headers to <code>HTTPHeaderDict</code>. This change was premature as it did not apply to proxy headers and <code>HTTPHeaderDict</code> does not handle byte header values correctly yet. (<a href="https://redirect.github.com/urllib3/urllib3/issues/3343">#3343</a>)</li> <li>Changed <code>ProtocolError</code> to <code>InvalidChunkLength</code> when response terminates before the chunk length is sent. (<a href="https://redirect.github.com/urllib3/urllib3/issues/2860">#2860</a>)</li> <li>Changed <code>ProtocolError</code> to be more verbose on incomplete reads with excess content. (<a href="https://redirect.github.com/urllib3/urllib3/issues/3261">#3261</a>)</li> </ul> <h2>2.2.0</h2> <h2>🖥️ urllib3 now works in the browser</h2> <p>:tada: <strong>This release adds experimental support for <a href="https://urllib3.readthedocs.io/en/stable/reference/contrib/emscripten.html">using urllib3 in the browser with Pyodide</a>!</strong> 🎉</p> <p>Thanks to Joe Marshall (<a href="https://github.com/joemarshall"><code>@joemarshall</code></a>) for contributing this feature. This change was possible thanks to work done in urllib3 v2.0 to detach our API from <code>http.client</code>. Please report all bugs to the <a href="https://github.com/urllib3/urllib3/issues">urllib3 issue tracker</a>.</p> <h2>🚀 urllib3 is fundraising for HTTP/2 support</h2> <p><a href="https://sethmlarson.dev/urllib3-is-fundraising-for-http2-support">urllib3 is raising ~$40,000 USD</a> to release HTTP/2 support and ensure long-term sustainable maintenance of the project after a sharp decline in financial support for 2023. If your company or organization uses Python and would benefit from HTTP/2 support in Requests, pip, cloud SDKs, and thousands of other projects <a href="https://opencollective.com/urllib3">please consider contributing financially</a> to ensure HTTP/2 support is developed sustainably and maintained for the long-haul.</p> <p>Thank you for your support.</p> <h2>Changes</h2> <ul> <li>Added support for <a href="https://urllib3.readthedocs.io/en/latest/reference/contrib/emscripten.html">Emscripten and Pyodide</a>, including streaming support in cross-origin isolated browser environments where threading is enabled. (<a href="https://redirect.github.com/urllib3/urllib3/issues/2951">#2951</a>)</li> <li>Added support for <code>HTTPResponse.read1()</code> method. (<a href="https://redirect.github.com/urllib3/urllib3/issues/3186">#3186</a>)</li> <li>Added rudimentary support for HTTP/2. (<a href="https://redirect.github.com/urllib3/urllib3/issues/3284">#3284</a>)</li> <li>Fixed issue where requests against urls with trailing dots were failing due to SSL errors when using proxy. (<a href="https://redirect.github.com/urllib3/urllib3/issues/2244">#2244</a>)</li> <li>Fixed <code>HTTPConnection.proxy_is_verified</code> and <code>HTTPSConnection.proxy_is_verified</code> to be always set to a boolean after connecting to a proxy. It could be <code>None</code> in some cases previously. (<a href="https://redirect.github.com/urllib3/urllib3/issues/3130">#3130</a>)</li> <li>Fixed an issue where <code>headers</code> passed in a request with <code>json=</code> would be mutated (<a href="https://redirect.github.com/urllib3/urllib3/issues/3203">#3203</a>)</li> <li>Fixed <code>HTTPSConnection.is_verified</code> to be set to <code>False</code> when connecting from a HTTPS proxy to an HTTP target. It was set to <code>True</code> previously. (<a href="https://redirect.github.com/urllib3/urllib3/issues/3267">#3267</a>)</li> <li>Fixed handling of new error message from OpenSSL 3.2.0 when configuring an HTTP proxy as HTTPS (<a href="https://redirect.github.com/urllib3/urllib3/issues/3268">#3268</a>)</li> <li>Fixed TLS 1.3 post-handshake auth when the server certificate validation is disabled (<a href="https://redirect.github.com/urllib3/urllib3/issues/3325">#3325</a>)</li> </ul> <p>Note for downstream distributors: To run integration tests, you now need to run the tests a second time with the <code>--integration</code> pytest flag. (<a href="https://redirect.github.com/urllib3/urllib3/issues/3181">#3181</a>)</p> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/urllib3/urllib3/blob/main/CHANGES.rst">urllib3's changelog</a>.</em></p> <blockquote> <h1>2.2.1 (2024-02-16)</h1> <ul> <li>Fixed issue where <code>InsecureRequestWarning</code> was emitted for HTTPS connections when using Emscripten. (<code>[#3331](urllib3/urllib3#3331) <https://github.com/urllib3/urllib3/issues/3331></code>__)</li> <li>Fixed <code>HTTPConnectionPool.urlopen</code> to stop automatically casting non-proxy headers to <code>HTTPHeaderDict</code>. This change was premature as it did not apply to proxy headers and <code>HTTPHeaderDict</code> does not handle byte header values correctly yet. (<code>[#3343](urllib3/urllib3#3343) <https://github.com/urllib3/urllib3/issues/3343></code>__)</li> <li>Changed <code>InvalidChunkLength</code> to <code>ProtocolError</code> when response terminates before the chunk length is sent. (<code>[#2860](urllib3/urllib3#2860) <https://github.com/urllib3/urllib3/issues/2860></code>__)</li> <li>Changed <code>ProtocolError</code> to be more verbose on incomplete reads with excess content. (<code>[#3261](urllib3/urllib3#3261) <https://github.com/urllib3/urllib3/issues/3261></code>__)</li> </ul> <h1>2.2.0 (2024-01-30)</h1> <ul> <li>Added support for <code>Emscripten and Pyodide <https://urllib3.readthedocs.io/en/latest/reference/contrib/emscripten.html></code><strong>, including streaming support in cross-origin isolated browser environments where threading is enabled. (<code>[#2951](urllib3/urllib3#2951) <https://github.com/urllib3/urllib3/issues/2951></code></strong>)</li> <li>Added support for <code>HTTPResponse.read1()</code> method. (<code>[#3186](urllib3/urllib3#3186) <https://github.com/urllib3/urllib3/issues/3186></code>__)</li> <li>Added rudimentary support for HTTP/2. (<code>[#3284](urllib3/urllib3#3284) <https://github.com/urllib3/urllib3/issues/3284></code>__)</li> <li>Fixed issue where requests against urls with trailing dots were failing due to SSL errors when using proxy. (<code>[#2244](urllib3/urllib3#2244) <https://github.com/urllib3/urllib3/issues/2244></code>__)</li> <li>Fixed <code>HTTPConnection.proxy_is_verified</code> and <code>HTTPSConnection.proxy_is_verified</code> to be always set to a boolean after connecting to a proxy. It could be <code>None</code> in some cases previously. (<code>[#3130](urllib3/urllib3#3130) <https://github.com/urllib3/urllib3/issues/3130></code>__)</li> <li>Fixed an issue where <code>headers</code> passed in a request with <code>json=</code> would be mutated (<code>[#3203](urllib3/urllib3#3203) <https://github.com/urllib3/urllib3/issues/3203></code>__)</li> <li>Fixed <code>HTTPSConnection.is_verified</code> to be set to <code>False</code> when connecting from a HTTPS proxy to an HTTP target. It was set to <code>True</code> previously. (<code>[#3267](urllib3/urllib3#3267) <https://github.com/urllib3/urllib3/issues/3267></code>__)</li> <li>Fixed handling of new error message from OpenSSL 3.2.0 when configuring an HTTP proxy as HTTPS (<code>[#3268](urllib3/urllib3#3268) <https://github.com/urllib3/urllib3/issues/3268></code>__)</li> <li>Fixed TLS 1.3 post-handshake auth when the server certificate validation is disabled (<code>[#3325](urllib3/urllib3#3325) <https://github.com/urllib3/urllib3/issues/3325></code>__)</li> <li>Note for downstream distributors: To run integration tests, you now need to run the tests a second time with the <code>--integration</code> pytest flag. (<code>[#3181](urllib3/urllib3#3181) <https://github.com/urllib3/urllib3/issues/3181></code>__)</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/urllib3/urllib3/commit/54d6edf2a671510a5c029d3b76ffe71a5b07147a"><code>54d6edf</code></a> Release 2.2.1</li> <li><a href="https://github.com/urllib3/urllib3/commit/49b2ddaf07ec9ef65ef12d0218117f20e739ee6e"><code>49b2dda</code></a> Stop casting request headers to HTTPHeaderDict (<a href="https://redirect.github.com/urllib3/urllib3/issues/3344">#3344</a>)</li> <li><a href="https://github.com/urllib3/urllib3/commit/e22f651079ae65d06efbb28222c27000256ce7a5"><code>e22f651</code></a> Fix docstring of retries parameter</li> <li><a href="https://github.com/urllib3/urllib3/commit/fa541793ad42f2f49846de0a9808ee0a484c53cf"><code>fa54179</code></a> Distinguish between truncated and excess content in response (<a href="https://redirect.github.com/urllib3/urllib3/issues/3273">#3273</a>)</li> <li><a href="https://github.com/urllib3/urllib3/commit/cfe52f96fb65fe2269981d6bba4f22c2bce00b2d"><code>cfe52f9</code></a> Fix InsecureRequestWarning for HTTPS Emscripten requests (<a href="https://redirect.github.com/urllib3/urllib3/issues/3333">#3333</a>)</li> <li><a href="https://github.com/urllib3/urllib3/commit/25155d7d3b7d91ef8400bc3cb7600b9253b765a3"><code>25155d7</code></a> Ensure no remote connections during testing (<a href="https://redirect.github.com/urllib3/urllib3/issues/3328">#3328</a>)</li> <li><a href="https://github.com/urllib3/urllib3/commit/12f923325a1794bab26c82dbfef2c47d44f054f8"><code>12f9233</code></a> Bump cryptography to 42.0.2 and PyOpenSSL to 24.0.0 (<a href="https://redirect.github.com/urllib3/urllib3/issues/3340">#3340</a>)</li> <li><a href="https://github.com/urllib3/urllib3/commit/9929d3c4e03b71ba485148a8390cd9411981f40f"><code>9929d3c</code></a> Add nox session to start local Pyodide console</li> <li><a href="https://github.com/urllib3/urllib3/commit/aa8d3dd2535cc125e123e5c2bca38738d6864b2a"><code>aa8d3dd</code></a> Fix ssl_version tests for upcoming migration to pytest 8</li> <li><a href="https://github.com/urllib3/urllib3/commit/23f2287eb526d9384dddeedb6f6345e263bb9b86"><code>23f2287</code></a> Remove TODO about informational responses (<a href="https://redirect.github.com/urllib3/urllib3/issues/3319">#3319</a>)</li> <li>Additional commits viewable in <a href="https://github.com/urllib3/urllib3/compare/2.1.0...2.2.1">compare view</a></li> </ul> </details> <br /> 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-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore <dependency name> major version` will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself) - `@dependabot ignore <dependency name> minor version` will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself) - `@dependabot ignore <dependency name>` will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself) - `@dependabot unignore <dependency name>` will remove all of the ignore conditions of the specified dependency - `@dependabot unignore <dependency name> <ignore condition>` will remove the ignore condition of the specified dependency and ignore conditions </details> Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
The author of the doc is @AlexeySachkov