Bump the llvm-docs-requirements group in /llvm/docs with 26 updates #1

dependabot · 2024-12-17T16:54:52Z

Bumps the llvm-docs-requirements group in /llvm/docs with 26 updates:

Package	From	To
alabaster	`0.7.13`	`1.0.0`
babel	`2.14.0`	`2.16.0`
beautifulsoup4	`4.12.2`	`4.12.3`
certifi	`2023.11.17`	`2024.12.14`
charset-normalizer	`3.3.2`	`3.4.0`
docutils	`0.20.1`	`0.21.2`
furo	`2024.1.29`	`2024.8.6`
idna	`3.6`	`3.10`
jinja2	`3.1.2`	`3.1.4`
markdown	`3.5.1`	`3.7`
markupsafe	`2.1.3`	`3.0.2`
mdit-py-plugins	`0.4.0`	`0.4.2`
myst-parser	`2.0.0`	`4.0.0`
packaging	`23.2`	`24.2`
pygments	`2.17.2`	`2.18.0`
pyyaml	`6.0.1`	`6.0.2`
requests	`2.31.0`	`2.32.3`
soupsieve	`2.5`	`2.6`
sphinx	`7.2.6`	`8.1.3`
sphinx-automodapi	`0.17.0`	`0.18.0`
sphinxcontrib-applehelp	`1.0.8`	`2.0.0`
sphinxcontrib-devhelp	`1.0.5`	`2.0.0`
sphinxcontrib-htmlhelp	`2.0.4`	`2.1.0`
sphinxcontrib-qthelp	`1.0.6`	`2.0.0`
sphinxcontrib-serializinghtml	`1.1.9`	`2.0.0`
urllib3	`2.1.0`	`2.2.3`

Updates alabaster from 0.7.13 to 1.0.0

Release notes

Sourced from alabaster's releases.

Alabaster 1.0.0

Changelog: https://alabaster.readthedocs.io/en/latest/changelog.html

Alabaster 0.7.16

Changelog: https://alabaster.readthedocs.io/en/latest/changelog.html

Alabaster 0.7.15

Changelog: https://alabaster.readthedocs.io/en/latest/changelog.html

Alabaster 0.7.14

Changelog: https://alabaster.readthedocs.io/en/latest/changelog.html

Changelog

Sourced from alabaster's changelog.

:git_tag:1.0.0 -- 2024-07-26

Dropped support for Python 3.9 and earlier.

Dropped support for Sphinx 6.1 and earlier.

Use a new SVG image for the GitHub banner.

:feature:217 Use the new searchfield component for the search box. Patch by Tim Hoffmann.

:feature:104 Allow translating strings in relations.html.

🐛125 Do not underline linked images. Patch by Joshua Bronson.

🐛169 Do not ignore the Pygments background colour. Patch by Matthias Geier.

🐛174 Fix clipping caused by incorrect CSS breakpoints.

:git_tag:0.7.16 -- 2024-01-10

🐛215 Do not display logo_name if it is set to False.

:git_tag:0.7.15 -- 2024-01-08

:feature:213 Allow an arbitrary string in the logo_name option.

:feature:114 Improved sidebar CSS styles.

:issue:178 Deprecated canonical_url in favor of html_baseurl.

🐛200 Removed duplicate <meta name="viewport" ... /> tag.

🐛188 Removed underline from whitespace.

🐛164 Removed type="text/javascript" from elements.

🐛161 Replaced © with unicode decimal code entity [#169](https://github.com/sphinx-doc/alabaster/issues/169);.

:git_tag:0.7.14 -- 2024-01-08

Dropped support for Python 3.8 and earlier.

Dropped support for Sphinx 3.3 and earlier.

:issue:198 Fix horizontal scrolling on mobile.

:issue:206 Properly support the html_support_sphinx config value.

:issue:211 Fix the GitHub 'forkme' banner.

Added alabaster_version_info to the HTML template context.

Declare support for Python 3.13.

Adopt the Ruff linter and formatter.

Migrate from CircleCI to GitHub Actions.

Commits

fba58a4 Bump to 1.0.0
7d5c318 Update project maintainers
d25c4bc List basic.css in theme.conf (#219)
97235d1 Fix incorrect breakpoints that cause clipping around 875px (#174)
5bb4411 Remove explicit width for search field input (#218)
9fdb57c Update references to searchbox
a35a1df Don't ignore the Pygments background (#169)
17e55e5 Fix for "Don't put an underline on linked images" (#125)
73be878 Allow translations for strings in relations.html (#104)
eb522b8 Use searchfield instead of searchbox component in sidebar (#217)
Additional commits viewable in compare view

Updates babel from 2.14.0 to 2.16.0

Release notes

Sourced from babel's releases.

Version 2.16.0

The changelog below is auto-generated by GitHub.

Please see CHANGELOG.rst for additional details.

What's Changed

Upgrade GitHub Actions versions to avoid deprecation warnings by @akx in python-babel/babel#1080

Replace deprecated ast.Str with ast.Constant by @tomasr8 in python-babel/babel#1083

Fix #1094 by @john-psina in python-babel/babel#1095

CI fixes by @akx in python-babel/babel#1097

Upgrade to CLDR 45 by @tomasr8 in python-babel/babel#1077

Make pgettext search plurals when translation is not found by @tomasr8 in python-babel/babel#1085

Fix for #832 by @Edwin18 in python-babel/babel#1052

Support list format fallbacks by @akx in python-babel/babel#1099

Improve Codecov configuration by @akx in python-babel/babel#1103

Avoid crashing on importing localtime when TZ is malformed by @akx in python-babel/babel#1100

Allow parsing .po files that have an extant but empty Language header by @akx in python-babel/babel#1101

Add a mention to the docs that format_skeleton(..., fuzzy=True) may raise by @tomasr8 in python-babel/babel#1106

Allow falling back to modifier-less locale data by @akx in python-babel/babel#1104

Allow use of importlib.metadata for finding entrypoints by @akx in python-babel/babel#1102

Test on Python 3.13 beta releases by @akx in python-babel/babel#1107

Normalize package name to lower-case in setup.py by @akx in python-babel/babel#1110

Do not allow substituting alternates or drafts in derived locales by @akx in python-babel/babel#1113

Two hyperlinks (to CLDR) and some typos by @buhtz in python-babel/babel#1115

Initial support for reading mapping configuration as TOML by @akx in python-babel/babel#1108

Prepare for 2.16.0 release by @akx in python-babel/babel#1116

New Contributors

@tomasr8 made their first contribution in python-babel/babel#1083

@john-psina made their first contribution in python-babel/babel#1095

@Edwin18 made their first contribution in python-babel/babel#1052

@buhtz made their first contribution in python-babel/babel#1115

Full Changelog: python-babel/babel@v2.15.0...v2.16.0

v2.15.0

The changelog below is auto-generated by GitHub.

The binary artifacts attached to this GitHub release were generated by the GitHub Actions workflow.

Please see CHANGELOG.rst for additional details.

What's Changed

Drop support for Python 3.7 (EOL since June 2023) by @akx in python-babel/babel#1048

Upgrade GitHub Actions by @cclauss in python-babel/babel#1054

Improve .po IO by @akx in python-babel/babel#1068

Use CLDR 44 by @akx in python-babel/babel#1071

Allow alternative space characters as group separator when parsing numbers by @ronnix in python-babel/babel#1007

... (truncated)

Changelog

Sourced from babel's changelog.

Version 2.16.0

Features

* CLDR: Upgrade to CLDR 45 by @tomasr8 in :gh:`1077` * Lists: Support list format fallbacks by @akx in :gh:`1099` * Messages: Initial support for reading mapping configuration as TOML by @akx in :gh:`1108`

Bugfixes

CLDR: Do not allow substituting alternates or drafts in derived locales by @akx in :gh:1113
Core: Allow falling back to modifier-less locale data by @akx in :gh:1104
Core: Allow use of importlib.metadata for finding entrypoints by @akx in :gh:1102
Dates: Avoid crashing on importing localtime when TZ is malformed by @akx in :gh:1100
Messages: Allow parsing .po files that have an extant but empty Language header by @akx in :gh:1101
Messages: Fix --ignore-dirs being incorrectly read (#1094) by @john-psina and @Edwin18 in :gh:1052 and :gh:1095
Messages: Make pgettext search plurals when translation is not found by @tomasr8 in :gh:1085

Infrastructure


* Replace deprecated `ast.Str` with `ast.Constant` by @tomasr8 in :gh:`1083`
* CI fixes by @akx in :gh:`1080`, :gh:`1097`, :gh:`1103`, :gh:`1107`
* Test on Python 3.13 beta releases by @akx in
* Normalize package name to lower-case in setup.py by @akx in :gh:`1110`
Documentation

* Add a mention to the docs that `format_skeleton(..., fuzzy=True)` may raise by @tomasr8 in :gh:`1106`
* Two hyperlinks (to CLDR) and some typos by @buhtz in :gh:`1115`
Version 2.15.0
Python version support

</code></pre>

<ul>

<li>Babel 2.15.0 will require Python 3.8 or newer. (:gh:<code>1048</code>)</li>

</ul>

<p>Features</p>

<pre><code>

CLDR: Upgrade to CLDR 44 (:gh:1071) (@akx)
Dates: Support for the &quot;fall back to short format&quot; logic for time delta formatting (:gh:1075) (@akx)
Message: More versatile .po IO functions (:gh:1068) (@akx)

&lt;/tr&gt;&lt;/table&gt;

</code></pre>

</blockquote>

<p>... (truncated)</p>

</details>

<details>

<summary>Commits</summary>

<ul>

<li><a href="https://github.com/python-babel/babel/commit/cf7d22369cf40a8218cff1d3dc823eefa174aee0&quot;&gt;&lt;code&gt;cf7d223&lt;/code&gt;&lt;/a> Prepare for 2.16.0 release (<a href="https://redirect.github.com/python-babel/babel/issues/1116&quot;&gt;#1116&lt;/a&gt;)&lt;/li>

<li><a href="https://github.com/python-babel/babel/commit/d26a669826d6c963dfdc21ae09e8cd5659fc95e2&quot;&gt;&lt;code&gt;d26a669&lt;/code&gt;&lt;/a> Initial support for reading mapping configuration as TOML (<a href="https://redirect.github.com/python-babel/babel/issues/1108&quot;&gt;#1108&lt;/a&gt;)&lt;/li>

<li><a href="https://github.com/python-babel/babel/commit/34ed517de44cf3c3002f3b69713b1693d329646d&quot;&gt;&lt;code&gt;34ed517&lt;/code&gt;&lt;/a> Two hyperlinks (to CLDR) and some typos (<a href="https://redirect.github.com/python-babel/babel/issues/1115&quot;&gt;#1115&lt;/a&gt;)&lt;/li>

<li><a href="https://github.com/python-babel/babel/commit/b4ba84382f3ce7bdf0e5a68e7108a21f4e8e7926&quot;&gt;&lt;code&gt;b4ba843&lt;/code&gt;&lt;/a> Do not allow substituting alternates or drafts in derived locales (<a href="https://redirect.github.com/python-babel/babel/issues/1113&quot;&gt;#1113&lt;/a&gt;)&lt;/li>

<li><a href="https://github.com/python-babel/babel/commit/d3346ee33b13f50af582e31ae5c337aa409dda11&quot;&gt;&lt;code&gt;d3346ee&lt;/code&gt;&lt;/a> Normalize package name to lower-case in setup.py (<a href="https://redirect.github.com/python-babel/babel/issues/1110&quot;&gt;#1110&lt;/a&gt;)&lt;/li>

<li><a href="https://github.com/python-babel/babel/commit/a32f15ecec23d5d5049100fd8e65606be7ad12a1&quot;&gt;&lt;code&gt;a32f15e&lt;/code&gt;&lt;/a> Test on Python 3.13 beta releases (<a href="https://redirect.github.com/python-babel/babel/issues/1107&quot;&gt;#1107&lt;/a&gt;)&lt;/li>

<li><a href="https://github.com/python-babel/babel/commit/4d3fd0e0198185cd023f4d3cd1495bda211867f4&quot;&gt;&lt;code&gt;4d3fd0e&lt;/code&gt;&lt;/a> Allow use of importlib.metadata for finding entrypoints (<a href="https://redirect.github.com/python-babel/babel/issues/1102&quot;&gt;#1102&lt;/a&gt;)&lt;/li>

<li><a href="https://github.com/python-babel/babel/commit/42d793cb4408a296e5618e1bce8d176fc588ce57&quot;&gt;&lt;code&gt;42d793c&lt;/code&gt;&lt;/a> Allow falling back to modifier-less locale data when modified data is missing...</li>

<li><a href="https://github.com/python-babel/babel/commit/32f41c22d589d7f187448be477affe1cfbcbc59d&quot;&gt;&lt;code&gt;32f41c2&lt;/code&gt;&lt;/a> Improve docs for <code>format_skeleton</code> (<a href="https://redirect.github.com/python-babel/babel/issues/1106&quot;&gt;#1106&lt;/a&gt;)&lt;/li>

<li><a href="https://github.com/python-babel/babel/commit/2ebc47e63211df8b7636ed8e74bb99ac5bd36c25&quot;&gt;&lt;code&gt;2ebc47e&lt;/code&gt;&lt;/a> Allow parsing .po files that have an extant but empty Language header (<a href="https://redirect.github.com/python-babel/babel/issues/1101&quot;&gt;#1101&lt;/a&gt;)&lt;/li>

<li>Additional commits viewable in <a href="https://github.com/python-babel/babel/compare/v2.14.0...v2.16.0&quot;&gt;compare view</a></li>

</ul>

</details>
<br />


Updates beautifulsoup4 from 4.12.2 to 4.12.3
Updates certifi from 2023.11.17 to 2024.12.14

Commits

4ba3900 2024.12.14 (#329)
9164660 Bump pypa/gh-action-pypi-publish from 1.12.2 to 1.12.3 (#331)
3dc3651 Bump pypa/gh-action-pypi-publish from 1.11.0 to 1.12.2 (#328)
c5bf18d Bump pypa/gh-action-pypi-publish from 1.10.3 to 1.11.0 (#327)
b908391 Bump actions/setup-python from 5.2.0 to 5.3.0 (#326)
bc26b41 Bump actions/checkout from 4.2.1 to 4.2.2 (#325)
57afc22 Bump actions/upload-artifact from 4.4.1 to 4.4.3 (#323)
a495091 test against 3.13 final
62f8144 Added 3.13 classifier (#322)
94d23a0 Bump pypa/gh-action-pypi-publish from 1.10.2 to 1.10.3 (#321)
Additional commits viewable in compare view




Updates charset-normalizer from 3.3.2 to 3.4.0

Release notes
Sourced from charset-normalizer's releases.

Version 3.4.0
🚀 charset-normalizer is raising awareness around HTTP/2, and HTTP/3!
Did you know that Internet Explorer 11 shipped with an optional HTTP/2 support back in 2013? also libcurl did ship it in 2014[...]
All of this while our community is still struggling to make a firm advancement in HTTP clients. Now, many of you use Requests
as the defacto http client, now, and for many years now, Requests has been frozen. Being left in a vegetative state and not evolving,
this blocked millions of developers from using more advanced features.
We promptly invite Python developers to look at the drop-in replacement for Requests, namely Niquests.
It leverage charset-normalizer in a better way! Check it out, you will be positively surprised! Don't wait another decade.
We are thankful to @microsoft and involved parties for funding our work through the Microsoft FOSS Fund program.
3.4.0 (2024-10-08)
Added

Argument --no-preemptive in the CLI to prevent the detector to search for hints.
Support for Python 3.13 (#512)

Fixed

Relax the TypeError exception thrown when trying to compare a CharsetMatch with anything else than a CharsetMatch.
Improved the general reliability of the detector based on user feedbacks. (#520) (#509) (#498) (#407) (#537)
Declared charset in content (preemptive detection) not changed when converting to utf-8 bytes. (#381)




Changelog
Sourced from charset-normalizer's changelog.

3.4.0 (2024-10-08)
Added

Argument --no-preemptive in the CLI to prevent the detector to search for hints.
Support for Python 3.13 (#512)

Fixed

Relax the TypeError exception thrown when trying to compare a CharsetMatch with anything else than a CharsetMatch.
Improved the general reliability of the detector based on user feedbacks. (#520) (#509) (#498) (#407) (#537)
Declared charset in content (preemptive detection) not changed when converting to utf-8 bytes. (#381)




Commits

f3118e3 :wrench: change download/upload artifact version to last working version
33e67e8 :wrench: set compile-generator in generator_generic_slsa3 action
73dd24c :wrench: add explicit build deps to setuptools
78f1e9b :wrench: attempt to fix cd.yml *3
56ae702 :wrench: attempt to fix cd.yml *2
9720055 :wrench: attempt to fix cd.yml (macos part)
1e10d06 Update CHANGELOG.md
36c103a :bookmark: Release 3.4.0 (#545)
7658dfc :arrow_up: Bump github/codeql-action from 3.26.11 to 3.26.12 (#544)
ca2535d :arrow_up: Bump github/codeql-action from 3.26.9 to 3.26.11 (#542)
Additional commits viewable in compare view




Updates docutils from 0.20.1 to 0.21.2
Updates furo from 2024.1.29 to 2024.8.6

Changelog
Sourced from furo's changelog.

Changelog

2024.08.06 -- Energetic Eminence

✨ Add support for Sphinx 8
✨ Add smoother transitions between breakpoints
Increase specificity of table-wrapper selector
Avoid page breaks inside paragraphs

2024.07.18 -- Dull Denim

Improve how icons are handled and aligned.
Improve scroll event handler.
Hide the copybutton by default.
Fix source_view_link configuration handling.
Fix close tag on pencil icon.

2024.05.06 -- Cheerful Cerulean

✨ Add new custom icons for auto mode, reflecting the currently active theme.
✨ Add a view this page button.
✨ Add colours and highlighting to "version modified" API helpers.
✨ Add release information to various customisation knobs.
Make all icons bigger and use a thinner stroke with them.

2024.04.27 -- Bold Burgundy

Add a skip to content link.
Add --font-stack--headings.
Add :visited colour and enforce uniform contrast between light/dark.
Add an offset of :target to reduce back-to-top overlap.
Improve dark mode colours.
Fix outstanding colour contrast warnings on Firefox.
Fix bad indent in footnotes.
Tweak handling of default configuration options in a more resilient manner.
Tweak length and sizing of API source links.
Stop search engine indexing on search page.

2024.01.29 -- Amazing Amethyst


... (truncated)


Commits

1bbf4ee Prepare release: 2024.08.06
bcb22c3 Update changelog
e633f02 Improve the selector for sidebar
d2fa2e0 [pre-commit.ci] pre-commit autoupdate (#821)
05a2d63 Add smoother transitions between breakpoints
d261d3b [pre-commit.ci] pre-commit autoupdate (#810)
2d3b6ba Add support for Sphinx 8
bf98041 Increase specificity of table-wrapper selector
fc6337c Fix the figures
fd3f422 Avoid page breaks inside paragraphs
Additional commits viewable in compare view




Updates idna from 3.6 to 3.10

Release notes
Sourced from idna's releases.

v3.10
No release notes provided.
v3.9
No release notes provided.
v3.8
What's Changed

Fix regression where IDNAError exception was not being produced for certain inputs.
Add support for Python 3.13, drop support for Python 3.5 as it is no longer testable.
Documentation improvements
Updates to package testing using Github actions

Thanks to Hugo van Kemenade for contributions to this release.
Full Changelog: https://github.com/kjd/idna/compare/v3.7...v3.8
v3.7
What's Changed

Fix issue where specially crafted inputs to encode() could take exceptionally long amount of time to process. [CVE-2024-3651]

Thanks to Guido Vranken for reporting the issue.
Full Changelog: https://github.com/kjd/idna/compare/v3.6...v3.7



Changelog
Sourced from idna's changelog.

3.10 (2024-09-15)
+++++++++++++++++

Reverted to Unicode 15.1.0 data. Unicode 16 has some significant changes
to UTS46 processing that will require more work to properly implement.

3.9 (2024-09-13)
++++++++++++++++

Update to Unicode 16.0.0
Deprecate setup.cfg in favour of pyproject.toml
Use ruff for code formatting

Thanks to Waket Zheng for contributions to this release.
3.8 (2024-08-23)
++++++++++++++++

Fix regression where IDNAError exception was not being produced for
certain inputs.
Add support for Python 3.13, drop support for Python 3.5 as it is no
longer testable.
Documentation improvements
Updates to package testing using Github actions

Thanks to Hugo van Kemenade for contributions to this release.
3.7 (2024-04-11)
++++++++++++++++

Fix issue where specially crafted inputs to encode() could
take exceptionally long amount of time to process. [CVE-2024-3651]

Thanks to Guido Vranken for reporting the issue.



Commits

729225d Release v3.10
3eef168 Merge pull request #194 from kjd/revert-unicode-16
ceca619 Revert Unicode 16.0.0 data updates
c43ac75 Merge pull request #191 from kjd/release-3.9
1b8800a Release v3.9
a1fd168 Merge pull request #190 from kjd/unicode-16
7732c61 Merge branch 'master' into unicode-16
4ed183d Refactor membership test
762216b Format with ruff
580ece9 Implement changes to UTS46 algorithm
Additional commits viewable in compare view




Updates jinja2 from 3.1.2 to 3.1.4

Release notes
Sourced from jinja2's releases.

3.1.4
This is the Jinja 3.1.4 security release, which fixes security issues and bugs but does not otherwise change behavior and should not result in breaking changes.
PyPI: https://pypi.org/project/Jinja2/3.1.4/
Changes: https://jinja.palletsprojects.com/en/3.1.x/changes/#version-3-1-4

The xmlattr filter does not allow keys with / solidus, > greater-than sign, or = equals sign, in addition to disallowing spaces. Regardless of any validation done by Jinja, user input should never be used as keys to this filter, or must be separately validated first. GHSA-h75v-3vvj-5mfj

3.1.3
This is a fix release for the 3.1.x feature branch.

Fix for GHSA-h5c8-rqwp-cp95. You are affected if you are using xmlattr and passing user input as attribute keys.
Changes: https://jinja.palletsprojects.com/en/3.1.x/changes/#version-3-1-3
Milestone: https://github.com/pallets/jinja/milestone/15?closed=1




Changelog
Sourced from jinja2's changelog.

Version 3.1.4
Released 2024-05-05

The xmlattr filter does not allow keys with / solidus, >
greater-than sign, or = equals sign, in addition to disallowing spaces.
Regardless of any validation done by Jinja, user input should never be used
as keys to this filter, or must be separately validated first.
:ghsa:h75v-3vvj-5mfj

Version 3.1.3
Released 2024-01-10

Fix compiler error when checking if required blocks in parent templates are
empty. :pr:1858
xmlattr filter does not allow keys with spaces. :ghsa:h5c8-rqwp-cp95
Make error messages stemming from invalid nesting of {% trans %} blocks
more helpful. :pr:1918




Commits

dd4a8b5 release version 3.1.4
0668239 Merge pull request from GHSA-h75v-3vvj-5mfj
d655030 disallow invalid characters in keys to xmlattr filter
a7863ba add ghsa links
b5c98e7 start version 3.1.4
da3a9f0 update project files (#1968)
0ee5eb4 satisfy formatter, linter, and strict mypy
20477c6 update project files (#5457)
e491223 update pyyaml dev dependency
36f9885 fix pr link
Additional commits viewable in compare view




Updates markdown from 3.5.1 to 3.7

Release notes
Sourced from markdown's releases.

Release 3.7
Changed
Refactor abbr Extension
A new AbbrTreeprocessor has been introduced, which replaces the now deprecated
AbbrInlineProcessor. Abbreviation processing now happens after Attribute Lists,
avoiding a conflict between the two extensions (#1460).
The AbbrPreprocessor class has been renamed to AbbrBlockprocessor, which
better reflects what it is. AbbrPreprocessor has been deprecated.
A call to Markdown.reset() now clears all previously defined abbreviations.
Abbreviations are now sorted by length before executing AbbrTreeprocessor
to ensure that multi-word abbreviations are implemented even if an abbreviation
exists for one of those component words. (#1465)
Abbreviations without a definition are now ignored. This avoids applying
abbr tags to text without a title value.
Added an optional glossary configuration option to the abbreviations extension.
This provides a simple and efficient way to apply a dictionary of abbreviations
to every page.
Abbreviations can now be disabled by setting their definition to "" or ''.
This can be useful when using the glossary option.
Fixed

Fixed links to source code on GitHub from the documentation (#1453).

Release 3.6
Changed
Refactor TOC Sanitation

All postprocessors are now run on heading content.
Footnote references are now stripped from heading content. Fixes #660.
A more robust striptags is provided to convert headings to plain text.
Unlike, the markupsafe implementation, HTML entities are not unescaped.
The plain text name, rich html, and unescaped raw data-toc-label are
saved to toc_tokens, allowing users to access the full rich text content of
the headings directly from toc_tokens.
The value of data-toc-label is sanitized separate from heading content
before being written to name. This fixes a bug which allowed markup through
in certain circumstances. To access the raw unsanitized data, retrieve the
value from token['data-toc-label'] directly.
An html.unescape call is made just prior to calling slugify so that



... (truncated)


Changelog
Sourced from markdown's changelog.

[3.7] -- 2024-08-16
Changed
Refactor abbr Extension
A new AbbrTreeprocessor has been introduced, which replaces the now deprecated
AbbrInlineProcessor. Abbreviation processing now happens after Attribute Lists,
avoiding a conflict between the two extensions (#1460).
The AbbrPreprocessor class has been renamed to AbbrBlockprocessor, which
better reflects what it is. AbbrPreprocessor has been deprecated.
A call to Markdown.reset() now clears all previously defined abbreviations.
Abbreviations are now sorted by length before executing AbbrTreeprocessor
to ensure that multi-word abbreviations are implemented even if an abbreviation
exists for one of those component words. (#1465)
Abbreviations without a definition are now ignored. This avoids applying
abbr tags to text without a title value.
Added an optional glossary configuration option to the abbreviations extension.
This provides a simple and efficient way to apply a dictionary of abbreviations
to every page.
Abbreviations can now be disabled by setting their definition to "" or ''.
This can be useful when using the glossary option.
Fixed

Fixed links to source code on GitHub from the documentation (#1453).

[3.6] -- 2024-03-14
Changed
Refactor TOC Sanitation

All postprocessors are now run on heading content.
Footnote references are now stripped from heading content. Fixes #660.
A more robust striptags is provided to convert headings to plain text.
Unlike, the markupsafe implementation, HTML entities are not unescaped.
The plain text name, rich html, and unescaped raw data-toc-label are
saved to toc_tokens, allowing users to access the full rich text content of
the headings directly from toc_tokens.
The value of data-toc-label is sanitized separate from heading content
before being written to name. This fixes a bug which allowed markup through
in certain circumstances. To access the raw unsanitized data, retrieve the



... (truncated)


Commits

da03cd6 Bump version to 3.7
bd836a1 Update griffe_extensions to support Griffe v 1.0.
33359fa Abbr Extension: Definition Sorting and Glossary storage
ec8c305 Refactor abbr Extension
993b57b Fixed links to source code on GitHub from the documentation
e524b8f Bump version to 3.6
3d8afc6 Allow attr_list quoted values to contain curly braces
9edba85 Refactor abbr escaping
e4ab4a6 Refactor TOC sanitation
a18765c Explicitly omit carot and backslash from abbr
Additional commits viewable in compare view




Updates markupsafe from 2.1.3 to 3.0.2

Release notes
Sourced from markupsafe's releases.

3.0.2
This is the MarkupSafe 3.0.2 fix release, which fixes bugs but does not otherwise change behavior and should not result in breaking changes.
PyPI: https://pypi.org/project/MarkupSafe/3.0.2/
Changes: https://markupsafe.palletsprojects.com/en/stable/changes/#version-3-0-2
Milestone: https://github.com/pallets/markupsafe/milestone/14?closed=1

Fix compatibility when __str__ returns a str subclass. #472
Build requires setuptools >= 70.1. #475

3.0.1
This is the MarkupSafe 3.0.1 fix release, which fixes bugs but does not otherwise change behavior and should not result in breaking changes.
PyPI: https://pypi.org/project/MarkupSafe/3.0.1/
Changes: https://markupsafe.palletsprojects.com/en/stable/changes/#version-3-0-1
Milestone: https://github.com/pallets/markupsafe/milestone/13?closed=1

Address compiler warnings that became errors in GCC 14. #466
Fix compatibility with proxy objects. #467

3.0.0
This is the MarkupSafe 3.0.0 feature release. A feature release may include new features, remove previously deprecated code, add new deprecations, or introduce potentially breaking changes. The 3.0.x branch is now the supported fix branch, the 2.1.x branch will become a tag marking the end of support for that branch. We encourage everyone to upgrade, and to use a tool such as pip-tools to pin all dependencies and control upgrades. Test with warnings treated as errors to be able to adapt to deprecation warnings early.
PyPI: https://pypi.org/project/MarkupSafe/3.0.0/
Changes: https://markupsafe.palletsprojects.com/en/stable/changes/#version-3-0-0
Milestone: https://github.com/pallets/markupsafe/milestone/10?closed=1

Support Python 3.13 and its experimental free-threaded build. #461
Drop support for Python 3.7 and 3.8.
Use modern packaging metadata with pyproject.toml instead of setup.cfg. #348
Change distutils imports to setuptools. #399
Use deferred evaluation of annotations. #400
Update signatures for Markup methods to match str signatures. Use positional-only arguments. #400
Some str methods on Markup no longer escape their argument: strip, lstrip, rstrip, removeprefix, removesuffix, partition, and rpartition; replace only escapes its new argument. These methods are conceptually linked to search methods such as in, find, and index, which already do not escape their argument. #401
The __version__ attribute is deprecated. Use feature detection, or importlib.metadata.version("markupsafe"), instead. #402
Speed up escaping plain strings by 40%. #434
Simplify speedups implementation. #437

2.1.5
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.
Fixes a regression in striptags behavior from 2.14. Spaces are now collapsed correctly.

Changes: https://markupsafe.palletsprojects.com/en/stable/changes/#version-2-1-5
Milestone: https://github.com/pallets/markupsafe/milestone/12?closed=1
PyPI: https://pypi.org/project/MarkupSafe/2.1.5/

2.1.4
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.


... (truncated)


Changelog
Sourced from markupsafe's changelog.

Version 3.0.2
Released 2024-10-18

Fix compatibility when __str__ returns a str subclass. :issue:472
Build requires setuptools >= 70.1. :issue:475

Version 3.0.1
Released 2024-10-08

Address compiler warnings that became errors in GCC 14. :issue:466
Fix compatibility with proxy objects. :issue:467

Version 3.0.0
Released 2024-10-07

Support Python 3.13 and its experimental free-threaded build. :pr:461
Drop support for Python 3.7 and 3.8.
Use modern packaging metadata with pyproject.toml instead of setup.cfg.
:pr:348
Change distutils imports to setuptools. :pr:399
Use deferred evaluation of annotations. :pr:400
Update signatures for Markup methods to match str signatures. Use
positional-only arguments. :pr:400
Some str methods on Markup no longer escape their argument:
strip, lstrip, rstrip, removeprefix, removesuffix,
partition, and rpartition; replace only escapes its new
argument. These methods are conceptually linked to search methods such as
in, find, and index, which already do not escape their argument.
:issue:401
The __version__ attribute is deprecated. Use feature detection, or
importlib.metadata.version("markupsafe"), instead. :pr:402
Speed up escaping plain strings by 40%. :pr:434
Simplify speedups implementation. :pr:437

Version 2.1.5
Released 2024-02-02

Fix striptags not collapsing spaces. :issue:417



... (truncated)


Commits

28ace20 release version 3.0.2
6b51fd8 build requires at least setuptools 70.1 (#478)
99dda9f build requires at least setuptools 70.1
3d8fd8c fix version
1933c4b fix version
e85aff4 relax speedups str check (#477)
8cb1691 relax speedups str check
4dafb7c start version 3.1.0
9c44ecf update docs build
275c769 Merge branch '2.1.x' into 3.0.x
Additional commits viewable in compare view




Updates mdit-py-plugins from 0.4.0 to 0.4.2

Release notes
Sourced from mdit-py-plugins's releases.

v0.4.2
What's Changed

👌 Improve parsing of nested amsmath by @chrisjsewell in executablebooks/mdit-py-plugins#119
✨ Add allowed option for inline/block attributes by @joker21663 in executablebooks/mdit-py-plugins#115

New Contributors

@joker21663 made their first contribution in executablebooks/mdit-py-plugins#115

Full Changelog: https://github.com/executablebooks/mdit-py-plugins/compare/v0.4.1...v0.4.2
v0.4.1
What's Changed


👌 Expand support for Python-Markdown in the admon plugin by @KyleKing in executablebooks/mdit-py-plugins#94


👌 Add option for footnotes references to always be matched by @chrisjsewell in executablebooks/mdit-py-plugins#108


🔧 Export plugins explicitly with __all__ by @llimllib in executablebooks/mdit-py-plugins#91


🔧 Use ruff-format by @chrisjsewell in executablebooks/mdit-py-plugins#107


🧪 Test against 3.12 by @chrisjsewell in executablebooks/mdit-py-plugins#109


New Contributors

@llimllib made their first contribution in executablebooks/mdit-py-plugins#91

Full Changelog: https://github.com/executablebooks/mdit-py-plugins/compare/v0.4.0...v0.4.1



Changelog
Sourced from mdit-py...
Description has been truncated

Bumps the llvm-docs-requirements group in /llvm/docs with 26 updates: | Package | From | To | | --- | --- | --- | | [alabaster](https://github.com/sphinx-doc/alabaster) | `0.7.13` | `1.0.0` | | [babel](https://github.com/python-babel/babel) | `2.14.0` | `2.16.0` | | [beautifulsoup4](https://www.crummy.com/software/BeautifulSoup/bs4/) | `4.12.2` | `4.12.3` | | [certifi](https://github.com/certifi/python-certifi) | `2023.11.17` | `2024.12.14` | | [charset-normalizer](https://github.com/Ousret/charset_normalizer) | `3.3.2` | `3.4.0` | | [docutils](https://docutils.sourceforge.io) | `0.20.1` | `0.21.2` | | [furo](https://github.com/pradyunsg/furo) | `2024.1.29` | `2024.8.6` | | [idna](https://github.com/kjd/idna) | `3.6` | `3.10` | | [jinja2](https://github.com/pallets/jinja) | `3.1.2` | `3.1.4` | | [markdown](https://github.com/Python-Markdown/markdown) | `3.5.1` | `3.7` | | [markupsafe](https://github.com/pallets/markupsafe) | `2.1.3` | `3.0.2` | | [mdit-py-plugins](https://github.com/executablebooks/mdit-py-plugins) | `0.4.0` | `0.4.2` | | [myst-parser](https://github.com/executablebooks/MyST-Parser) | `2.0.0` | `4.0.0` | | [packaging](https://github.com/pypa/packaging) | `23.2` | `24.2` | | [pygments](https://github.com/pygments/pygments) | `2.17.2` | `2.18.0` | | [pyyaml](https://github.com/yaml/pyyaml) | `6.0.1` | `6.0.2` | | [requests](https://github.com/psf/requests) | `2.31.0` | `2.32.3` | | [soupsieve](https://github.com/facelessuser/soupsieve) | `2.5` | `2.6` | | [sphinx](https://github.com/sphinx-doc/sphinx) | `7.2.6` | `8.1.3` | | [sphinx-automodapi](https://github.com/astropy/sphinx-automodapi) | `0.17.0` | `0.18.0` | | [sphinxcontrib-applehelp](https://github.com/sphinx-doc/sphinxcontrib-applehelp) | `1.0.8` | `2.0.0` | | [sphinxcontrib-devhelp](https://github.com/sphinx-doc/sphinxcontrib-devhelp) | `1.0.5` | `2.0.0` | | [sphinxcontrib-htmlhelp](https://github.com/sphinx-doc/sphinxcontrib-htmlhelp) | `2.0.4` | `2.1.0` | | [sphinxcontrib-qthelp](https://github.com/sphinx-doc/sphinxcontrib-qthelp) | `1.0.6` | `2.0.0` | | [sphinxcontrib-serializinghtml](https://github.com/sphinx-doc/sphinxcontrib-serializinghtml) | `1.1.9` | `2.0.0` | | [urllib3](https://github.com/urllib3/urllib3) | `2.1.0` | `2.2.3` | Updates `alabaster` from 0.7.13 to 1.0.0 - [Release notes](https://github.com/sphinx-doc/alabaster/releases) - [Changelog](https://github.com/sphinx-doc/alabaster/blob/master/docs/changelog.rst) - [Commits](sphinx-doc/alabaster@0.7.13...1.0.0) Updates `babel` from 2.14.0 to 2.16.0 - [Release notes](https://github.com/python-babel/babel/releases) - [Changelog](https://github.com/python-babel/babel/blob/master/CHANGES.rst) - [Commits](python-babel/babel@v2.14.0...v2.16.0) Updates `beautifulsoup4` from 4.12.2 to 4.12.3 Updates `certifi` from 2023.11.17 to 2024.12.14 - [Commits](certifi/python-certifi@2023.11.17...2024.12.14) Updates `charset-normalizer` from 3.3.2 to 3.4.0 - [Release notes](https://github.com/Ousret/charset_normalizer/releases) - [Changelog](https://github.com/jawah/charset_normalizer/blob/master/CHANGELOG.md) - [Commits](jawah/charset_normalizer@3.3.2...3.4.0) Updates `docutils` from 0.20.1 to 0.21.2 Updates `furo` from 2024.1.29 to 2024.8.6 - [Release notes](https://github.com/pradyunsg/furo/releases) - [Changelog](https://github.com/pradyunsg/furo/blob/main/docs/changelog.md) - [Commits](pradyunsg/furo@2024.01.29...2024.08.06) Updates `idna` from 3.6 to 3.10 - [Release notes](https://github.com/kjd/idna/releases) - [Changelog](https://github.com/kjd/idna/blob/master/HISTORY.rst) - [Commits](kjd/idna@v3.6...v3.10) Updates `jinja2` from 3.1.2 to 3.1.4 - [Release notes](https://github.com/pallets/jinja/releases) - [Changelog](https://github.com/pallets/jinja/blob/main/CHANGES.rst) - [Commits](pallets/jinja@3.1.2...3.1.4) Updates `markdown` from 3.5.1 to 3.7 - [Release notes](https://github.com/Python-Markdown/markdown/releases) - [Changelog](https://github.com/Python-Markdown/markdown/blob/master/docs/changelog.md) - [Commits](Python-Markdown/markdown@3.5.1...3.7) Updates `markupsafe` from 2.1.3 to 3.0.2 - [Release notes](https://github.com/pallets/markupsafe/releases) - [Changelog](https://github.com/pallets/markupsafe/blob/main/CHANGES.rst) - [Commits](pallets/markupsafe@2.1.3...3.0.2) Updates `mdit-py-plugins` from 0.4.0 to 0.4.2 - [Release notes](https://github.com/executablebooks/mdit-py-plugins/releases) - [Changelog](https://github.com/executablebooks/mdit-py-plugins/blob/master/CHANGELOG.md) - [Commits](executablebooks/mdit-py-plugins@v0.4.0...v0.4.2) Updates `myst-parser` from 2.0.0 to 4.0.0 - [Release notes](https://github.com/executablebooks/MyST-Parser/releases) - [Changelog](https://github.com/executablebooks/MyST-Parser/blob/master/CHANGELOG.md) - [Commits](executablebooks/MyST-Parser@v2.0.0...v4.0.0) Updates `packaging` from 23.2 to 24.2 - [Release notes](https://github.com/pypa/packaging/releases) - [Changelog](https://github.com/pypa/packaging/blob/main/CHANGELOG.rst) - [Commits](pypa/packaging@23.2...24.2) Updates `pygments` from 2.17.2 to 2.18.0 - [Release notes](https://github.com/pygments/pygments/releases) - [Changelog](https://github.com/pygments/pygments/blob/master/CHANGES) - [Commits](pygments/pygments@2.17.2...2.18.0) Updates `pyyaml` from 6.0.1 to 6.0.2 - [Release notes](https://github.com/yaml/pyyaml/releases) - [Changelog](https://github.com/yaml/pyyaml/blob/main/CHANGES) - [Commits](yaml/pyyaml@6.0.1...6.0.2) Updates `requests` from 2.31.0 to 2.32.3 - [Release notes](https://github.com/psf/requests/releases) - [Changelog](https://github.com/psf/requests/blob/main/HISTORY.md) - [Commits](psf/requests@v2.31.0...v2.32.3) Updates `soupsieve` from 2.5 to 2.6 - [Release notes](https://github.com/facelessuser/soupsieve/releases) - [Commits](facelessuser/soupsieve@2.5...2.6) Updates `sphinx` from 7.2.6 to 8.1.3 - [Release notes](https://github.com/sphinx-doc/sphinx/releases) - [Changelog](https://github.com/sphinx-doc/sphinx/blob/v8.1.3/CHANGES.rst) - [Commits](sphinx-doc/sphinx@v7.2.6...v8.1.3) Updates `sphinx-automodapi` from 0.17.0 to 0.18.0 - [Release notes](https://github.com/astropy/sphinx-automodapi/releases) - [Changelog](https://github.com/astropy/sphinx-automodapi/blob/main/CHANGES.rst) - [Commits](astropy/sphinx-automodapi@v0.17.0...v0.18.0) Updates `sphinxcontrib-applehelp` from 1.0.8 to 2.0.0 - [Release notes](https://github.com/sphinx-doc/sphinxcontrib-applehelp/releases) - [Changelog](https://github.com/sphinx-doc/sphinxcontrib-applehelp/blob/master/CHANGES.rst) - [Commits](sphinx-doc/sphinxcontrib-applehelp@1.0.8...2.0.0) Updates `sphinxcontrib-devhelp` from 1.0.5 to 2.0.0 - [Release notes](https://github.com/sphinx-doc/sphinxcontrib-devhelp/releases) - [Changelog](https://github.com/sphinx-doc/sphinxcontrib-devhelp/blob/master/CHANGES.rst) - [Commits](sphinx-doc/sphinxcontrib-devhelp@1.0.5...2.0.0) Updates `sphinxcontrib-htmlhelp` from 2.0.4 to 2.1.0 - [Release notes](https://github.com/sphinx-doc/sphinxcontrib-htmlhelp/releases) - [Changelog](https://github.com/sphinx-doc/sphinxcontrib-htmlhelp/blob/master/CHANGES.rst) - [Commits](sphinx-doc/sphinxcontrib-htmlhelp@2.0.4...2.1.0) Updates `sphinxcontrib-qthelp` from 1.0.6 to 2.0.0 - [Release notes](https://github.com/sphinx-doc/sphinxcontrib-qthelp/releases) - [Changelog](https://github.com/sphinx-doc/sphinxcontrib-qthelp/blob/master/CHANGES.rst) - [Commits](sphinx-doc/sphinxcontrib-qthelp@1.0.6...2.0.0) Updates `sphinxcontrib-serializinghtml` from 1.1.9 to 2.0.0 - [Release notes](https://github.com/sphinx-doc/sphinxcontrib-serializinghtml/releases) - [Changelog](https://github.com/sphinx-doc/sphinxcontrib-serializinghtml/blob/master/CHANGES.rst) - [Commits](sphinx-doc/sphinxcontrib-serializinghtml@1.1.9...2.0.0) Updates `urllib3` from 2.1.0 to 2.2.3 - [Release notes](https://github.com/urllib3/urllib3/releases) - [Changelog](https://github.com/urllib3/urllib3/blob/main/CHANGES.rst) - [Commits](urllib3/urllib3@2.1.0...2.2.3) --- updated-dependencies: - dependency-name: alabaster dependency-type: direct:production update-type: version-update:semver-major dependency-group: llvm-docs-requirements - dependency-name: babel dependency-type: direct:production update-type: version-update:semver-minor dependency-group: llvm-docs-requirements - dependency-name: beautifulsoup4 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: llvm-docs-requirements - dependency-name: certifi dependency-type: direct:production update-type: version-update:semver-major dependency-group: llvm-docs-requirements - dependency-name: charset-normalizer dependency-type: direct:production update-type: version-update:semver-minor dependency-group: llvm-docs-requirements - dependency-name: docutils dependency-type: direct:production update-type: version-update:semver-minor dependency-group: llvm-docs-requirements - dependency-name: furo dependency-type: direct:production update-type: version-update:semver-minor dependency-group: llvm-docs-requirements - dependency-name: idna dependency-type: direct:production update-type: version-update:semver-minor dependency-group: llvm-docs-requirements - dependency-name: jinja2 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: llvm-docs-requirements - dependency-name: markdown dependency-type: direct:production update-type: version-update:semver-minor dependency-group: llvm-docs-requirements - dependency-name: markupsafe dependency-type: direct:production update-type: version-update:semver-major dependency-group: llvm-docs-requirements - dependency-name: mdit-py-plugins dependency-type: direct:production update-type: version-update:semver-patch dependency-group: llvm-docs-requirements - dependency-name: myst-parser dependency-type: direct:production update-type: version-update:semver-major dependency-group: llvm-docs-requirements - dependency-name: packaging dependency-type: direct:production update-type: version-update:semver-major dependency-group: llvm-docs-requirements - dependency-name: pygments dependency-type: direct:production update-type: version-update:semver-minor dependency-group: llvm-docs-requirements - dependency-name: pyyaml dependency-type: direct:production update-type: version-update:semver-patch dependency-group: llvm-docs-requirements - dependency-name: requests dependency-type: direct:production update-type: version-update:semver-minor dependency-group: llvm-docs-requirements - dependency-name: soupsieve dependency-type: direct:production update-type: version-update:semver-minor dependency-group: llvm-docs-requirements - dependency-name: sphinx dependency-type: direct:production update-type: version-update:semver-major dependency-group: llvm-docs-requirements - dependency-name: sphinx-automodapi dependency-type: direct:production update-type: version-update:semver-minor dependency-group: llvm-docs-requirements - dependency-name: sphinxcontrib-applehelp dependency-type: direct:production update-type: version-update:semver-major dependency-group: llvm-docs-requirements - dependency-name: sphinxcontrib-devhelp dependency-type: direct:production update-type: version-update:semver-major dependency-group: llvm-docs-requirements - dependency-name: sphinxcontrib-htmlhelp dependency-type: direct:production update-type: version-update:semver-minor dependency-group: llvm-docs-requirements - dependency-name: sphinxcontrib-qthelp dependency-type: direct:production update-type: version-update:semver-major dependency-group: llvm-docs-requirements - dependency-name: sphinxcontrib-serializinghtml dependency-type: direct:production update-type: version-update:semver-major dependency-group: llvm-docs-requirements - dependency-name: urllib3 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: llvm-docs-requirements ... Signed-off-by: dependabot[bot] <[email protected]>

``` UBSan-Standalone-sparc :: TestCases/Misc/Linux/diag-stacktrace.cpp ``` `FAIL`s on 32 and 64-bit Linux/sparc64 (and on Solaris/sparcv9, too: the test isn't Linux-specific at all). With `UBSAN_OPTIONS=fast_unwind_on_fatal=1`, the stack trace shows a duplicate innermost frame: ``` compiler-rt/test/ubsan/TestCases/Misc/Linux/diag-stacktrace.cpp:14:31: runtime error: execution reached the end of a value-returning function without returning a value #0 0x7003a708 in f() compiler-rt/test/ubsan/TestCases/Misc/Linux/diag-stacktrace.cpp:14:35 #1 0x7003a708 in f() compiler-rt/test/ubsan/TestCases/Misc/Linux/diag-stacktrace.cpp:14:35 #2 0x7003a714 in g() compiler-rt/test/ubsan/TestCases/Misc/Linux/diag-stacktrace.cpp:17:38 ``` which isn't seen with `fast_unwind_on_fatal=0`. This turns out to be another fallout from fixing `__builtin_return_address`/`__builtin_extract_return_addr` on SPARC. In `sanitizer_stacktrace_sparc.cpp` (`BufferedStackTrace::UnwindFast`) the `pc` arg is the return address, while `pc1` from the stack frame (`fr_savpc`) is the address of the `call` insn, leading to a double entry for the innermost frame in `trace_buffer[]`. This patch fixes this by moving the adjustment before all uses. Tested on `sparc64-unknown-linux-gnu` and `sparcv9-sun-solaris2.11` (with the `ubsan/TestCases/Misc/Linux` tests enabled). (cherry picked from commit 3368a32)

dependabot · 2024-12-17T17:09:31Z

This pull request was built based on a group rule. Closing it will not ignore any of these versions in future pull requests.

To ignore these dependencies, configure ignore rules in dependabot.yml

According to the documentation described at https://github.com/loongson/la-abi-specs/blob/release/ladwarf.adoc, the dwarf numbers for floating-point registers range from 32 to 63. An incorrect dwarf number will prevent the register values from being properly restored during unwinding. This test reflects this problem: ``` loongson@linux:~$ cat test.c void foo() { asm volatile ("movgr2fr.d $fs2, $ra":::"$fs2"); } int main() { asm volatile ("movgr2fr.d $fs2, $sp":::"$fs2"); foo(); return 0; } loongson@linux:~$ clang -g test.c -o test ``` Without this patch: ``` loongson@linux:~$ ./_build/bin/lldb ./t (lldb) target create "./t" Current executable set to '/home/loongson/llvm-project/_build_lldb/t' (loongarch64). (lldb) b foo Breakpoint 1: where = t`foo + 20 at test.c:4:1, address = 0x0000000000000714 (lldb) r Process 2455626 launched: '/home/loongson/llvm-project/_build_lldb/t' (loongarch64) Process 2455626 stopped * thread #1, name = 't', stop reason = breakpoint 1.1 frame #0: 0x0000555555554714 t`foo at test.c:4:1 1 #include <stdio.h> 2 3 void foo() { -> 4 asm volatile ("movgr2fr.d $fs2, $ra":::"$fs2"); 5 } 6 int main() { 7 asm volatile ("movgr2fr.d $fs2, $sp":::"$fs2"); (lldb) si Process 2455626 stopped * thread #1, name = 't', stop reason = instruction step into frame #0: 0x0000555555554718 t`foo at test.c:4:1 1 #include <stdio.h> 2 3 void foo() { -> 4 asm volatile ("movgr2fr.d $fs2, $ra":::"$fs2"); 5 } 6 int main() { 7 asm volatile ("movgr2fr.d $fs2, $sp":::"$fs2"); (lldb) f 1 frame #1: 0x0000555555554768 t`main at test.c:8:1 5 } 6 int main() { 7 asm volatile ("movgr2fr.d $fs2, $sp":::"$fs2"); -> 8 foo(); 9 return 0; 10 } (lldb) register read -a General Purpose Registers: r1 = 0x0000555555554768 t`main + 40 at test.c:8:1 r3 = 0x00007ffffffef780 r22 = 0x00007ffffffef7b0 r23 = 0x00007ffffffef918 r24 = 0x0000000000000001 r25 = 0x0000000000000000 r26 = 0x000055555555be08 t`__do_global_dtors_aux_fini_array_entry r27 = 0x0000555555554740 t`main at test.c:6 r28 = 0x00007ffffffef928 r29 = 0x00007ffff7febc88 ld-linux-loongarch-lp64d.so.1`_rtld_global_ro r30 = 0x000055555555be08 t`__do_global_dtors_aux_fini_array_entry pc = 0x0000555555554768 t`main + 40 at test.c:8:1 33 registers were unavailable. Floating Point Registers: f13 = 0x00007ffffffef780 !!!!! wrong register f24 = 0xffffffffffffffff f25 = 0xffffffffffffffff f26 = 0x0000555555554768 t`main + 40 at test.c:8:1 f27 = 0xffffffffffffffff f28 = 0xffffffffffffffff f29 = 0xffffffffffffffff f30 = 0xffffffffffffffff f31 = 0xffffffffffffffff 32 registers were unavailable. ``` With this patch: ``` The previous operations are the same. (lldb) register read -a General Purpose Registers: r1 = 0x0000555555554768 t`main + 40 at test.c:8:1 r3 = 0x00007ffffffef780 r22 = 0x00007ffffffef7b0 r23 = 0x00007ffffffef918 r24 = 0x0000000000000001 r25 = 0x0000000000000000 r26 = 0x000055555555be08 t`__do_global_dtors_aux_fini_array_entry r27 = 0x0000555555554740 t`main at test.c:6 r28 = 0x00007ffffffef928 r29 = 0x00007ffff7febc88 ld-linux-loongarch-lp64d.so.1`_rtld_global_ro r30 = 0x000055555555be08 t`__do_global_dtors_aux_fini_array_entry pc = 0x0000555555554768 t`main + 40 at test.c:8:1 33 registers were unavailable. Floating Point Registers: f24 = 0xffffffffffffffff f25 = 0xffffffffffffffff f26 = 0x00007ffffffef780 f27 = 0xffffffffffffffff f28 = 0xffffffffffffffff f29 = 0xffffffffffffffff f30 = 0xffffffffffffffff f31 = 0xffffffffffffffff 33 registers were unavailable. ``` Reviewed By: SixWeining Pull Request: llvm/llvm-project#120391

…r dwarf number According to the documentation described at https://github.com/loongson/la-abi-specs/blob/release/ladwarf.adoc, the dwarf numbers for floating-point registers range from 32 to 63. An incorrect dwarf number will prevent the register values from being properly restored during unwinding. This test reflects this problem: ``` loongson@linux:~$ cat test.c void foo() { asm volatile ("movgr2fr.d $fs2, $ra":::"$fs2"); } int main() { asm volatile ("movgr2fr.d $fs2, $sp":::"$fs2"); foo(); return 0; } loongson@linux:~$ clang -g test.c -o test ``` Without this patch: ``` loongson@linux:~$ ./_build/bin/lldb ./t (lldb) target create "./t" Current executable set to '/home/loongson/llvm-project/_build_lldb/t' (loongarch64). (lldb) b foo Breakpoint 1: where = t`foo + 20 at test.c:4:1, address = 0x0000000000000714 (lldb) r Process 2455626 launched: '/home/loongson/llvm-project/_build_lldb/t' (loongarch64) Process 2455626 stopped * thread #1, name = 't', stop reason = breakpoint 1.1 frame #0: 0x0000555555554714 t`foo at test.c:4:1 1 #include <stdio.h> 2 3 void foo() { -> 4 asm volatile ("movgr2fr.d $fs2, $ra":::"$fs2"); 5 } 6 int main() { 7 asm volatile ("movgr2fr.d $fs2, $sp":::"$fs2"); (lldb) si Process 2455626 stopped * thread #1, name = 't', stop reason = instruction step into frame #0: 0x0000555555554718 t`foo at test.c:4:1 1 #include <stdio.h> 2 3 void foo() { -> 4 asm volatile ("movgr2fr.d $fs2, $ra":::"$fs2"); 5 } 6 int main() { 7 asm volatile ("movgr2fr.d $fs2, $sp":::"$fs2"); (lldb) f 1 frame #1: 0x0000555555554768 t`main at test.c:8:1 5 } 6 int main() { 7 asm volatile ("movgr2fr.d $fs2, $sp":::"$fs2"); -> 8 foo(); 9 return 0; 10 } (lldb) register read -a General Purpose Registers: r1 = 0x0000555555554768 t`main + 40 at test.c:8:1 r3 = 0x00007ffffffef780 r22 = 0x00007ffffffef7b0 r23 = 0x00007ffffffef918 r24 = 0x0000000000000001 r25 = 0x0000000000000000 r26 = 0x000055555555be08 t`__do_global_dtors_aux_fini_array_entry r27 = 0x0000555555554740 t`main at test.c:6 r28 = 0x00007ffffffef928 r29 = 0x00007ffff7febc88 ld-linux-loongarch-lp64d.so.1`_rtld_global_ro r30 = 0x000055555555be08 t`__do_global_dtors_aux_fini_array_entry pc = 0x0000555555554768 t`main + 40 at test.c:8:1 33 registers were unavailable. Floating Point Registers: f13 = 0x00007ffffffef780 !!!!! wrong register f24 = 0xffffffffffffffff f25 = 0xffffffffffffffff f26 = 0x0000555555554768 t`main + 40 at test.c:8:1 f27 = 0xffffffffffffffff f28 = 0xffffffffffffffff f29 = 0xffffffffffffffff f30 = 0xffffffffffffffff f31 = 0xffffffffffffffff 32 registers were unavailable. ``` With this patch: ``` The previous operations are the same. (lldb) register read -a General Purpose Registers: r1 = 0x0000555555554768 t`main + 40 at test.c:8:1 r3 = 0x00007ffffffef780 r22 = 0x00007ffffffef7b0 r23 = 0x00007ffffffef918 r24 = 0x0000000000000001 r25 = 0x0000000000000000 r26 = 0x000055555555be08 t`__do_global_dtors_aux_fini_array_entry r27 = 0x0000555555554740 t`main at test.c:6 r28 = 0x00007ffffffef928 r29 = 0x00007ffff7febc88 ld-linux-loongarch-lp64d.so.1`_rtld_global_ro r30 = 0x000055555555be08 t`__do_global_dtors_aux_fini_array_entry pc = 0x0000555555554768 t`main + 40 at test.c:8:1 33 registers were unavailable. Floating Point Registers: f24 = 0xffffffffffffffff f25 = 0xffffffffffffffff f26 = 0x00007ffffffef780 f27 = 0xffffffffffffffff f28 = 0xffffffffffffffff f29 = 0xffffffffffffffff f30 = 0xffffffffffffffff f31 = 0xffffffffffffffff 33 registers were unavailable. ``` Reviewed By: SixWeining Pull Request: llvm/llvm-project#120391

Fix for the Coverity hit with CID1579964 in VPlan.cpp. Coverity message with some context follows. [Cov] var_compare_op: Comparing TermBr to null implies that TermBr might be null. 434 } else if (TermBr && !TermBr->isConditional()) { 435 TermBr->setSuccessor(0, NewBB); 436 } else { 437 // Set each forward successor here when it is created, excluding 438 // backedges. A backward successor is set when the branch is created. 439 unsigned idx = PredVPSuccessors.front() == this ? 0 : 1; [Cov] CID 1579964: (#1 of 1): Dereference after null check (FORWARD_NULL) [Cov] var_deref_model: Passing null pointer TermBr to getSuccessor, which dereferences it.

This will be sent by Arm's Guarded Control Stack extension when an invalid return is executed. The signal does have an address we could show, but it's the PC at which the fault occured. The debugger has plenty of ways to show you that already, so I've left it out. ``` (lldb) c Process 460 resuming Process 460 stopped * thread #1, name = 'test', stop reason = signal SIGSEGV: control protection fault frame #0: 0x0000000000400784 test`main at main.c:57:1 54 afunc(); 55 printf("return from main\n"); 56 return 0; -> 57 } (lldb) dis <...> -> 0x400784 <+100>: ret ``` The new test case generates the signal by corrupting the link register then attempting to return. This will work whether we manually enable GCS or the C library does it for us. (in the former case you could just return from main and it would fault)

…" (#123877) Reverts llvm/llvm-project#122811 due to buildbot breakage e.g., https://lab.llvm.org/buildbot/#/builders/52/builds/5421/steps/11/logs/stdio ASan output from local re-run: ``` ==2780289==ERROR: AddressSanitizer: use-after-poison on address 0x7e0b87e28d28 at pc 0x55a979a99e7e bp 0x7ffe4b18f0b0 sp 0x7ffe4b18f0a8 READ of size 1 at 0x7e0b87e28d28 thread T0 #0 0x55a979a99e7d in getStorageClass /usr/local/google/home/thurston/buildbot_repro/llvm-project/llvm/include/llvm/Object/COFF.h:344 #1 0x55a979a99e7d in isSectionDefinition /usr/local/google/home/thurston/buildbot_repro/llvm-project/llvm/include/llvm/Object/COFF.h:429:9 #2 0x55a979a99e7d in getSymbols /usr/local/google/home/thurston/buildbot_repro/llvm-project/lld/COFF/LLDMapFile.cpp:54:42 #3 0x55a979a99e7d in lld::coff::writeLLDMapFile(lld::coff::COFFLinkerContext const&) /usr/local/google/home/thurston/buildbot_repro/llvm-project/lld/COFF/LLDMapFile.cpp:103:40 #4 0x55a979a16879 in (anonymous namespace)::Writer::run() /usr/local/google/home/thurston/buildbot_repro/llvm-project/lld/COFF/Writer.cpp:810:3 #5 0x55a979a00aac in lld::coff::writeResult(lld::coff::COFFLinkerContext&) /usr/local/google/home/thurston/buildbot_repro/llvm-project/lld/COFF/Writer.cpp:354:15 #6 0x55a97985f7ed in lld::coff::LinkerDriver::linkerMain(llvm::ArrayRef<char const*>) /usr/local/google/home/thurston/buildbot_repro/llvm-project/lld/COFF/Driver.cpp:2826:3 #7 0x55a97984cdd3 in lld::coff::link(llvm::ArrayRef<char const*>, llvm::raw_ostream&, llvm::raw_ostream&, bool, bool) /usr/local/google/home/thurston/buildbot_repro/llvm-project/lld/COFF/Driver.cpp:97:15 #8 0x55a9797f9793 in lld::unsafeLldMain(llvm::ArrayRef<char const*>, llvm::raw_ostream&, llvm::raw_ostream&, llvm::ArrayRef<lld::DriverDef>, bool) /usr/local/google/home/thurston/buildbot_repro/llvm-project/lld/Common/DriverDispatcher.cpp:163:12 #9 0x55a9797fa3b6 in operator() /usr/local/google/home/thurston/buildbot_repro/llvm-project/lld/Common/DriverDispatcher.cpp:188:15 #10 0x55a9797fa3b6 in void llvm::function_ref<void ()>::callback_fn<lld::lldMain(llvm::ArrayRef<char const*>, llvm::raw_ostream&, llvm::raw_ostream&, llvm::ArrayRef<lld::DriverDef>)::$_0>(long) /usr/local/google/home/thurston/buildbot_repro/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:46:12 #11 0x55a97966cb93 in operator() /usr/local/google/home/thurston/buildbot_repro/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:69:12 #12 0x55a97966cb93 in llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) /usr/local/google/home/thurston/buildbot_repro/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:426:3 #13 0x55a9797f9dc3 in lld::lldMain(llvm::ArrayRef<char const*>, llvm::raw_ostream&, llvm::raw_ostream&, llvm::ArrayRef<lld::DriverDef>) /usr/local/google/home/thurston/buildbot_repro/llvm-project/lld/Common/DriverDispatcher.cpp:187:14 #14 0x55a979627512 in lld_main(int, char**, llvm::ToolContext const&) /usr/local/google/home/thurston/buildbot_repro/llvm-project/lld/tools/lld/lld.cpp:103:14 #15 0x55a979628731 in main /usr/local/google/home/thurston/buildbot_repro/llvm_build_asan/tools/lld/tools/lld/lld-driver.cpp:17:10 #16 0x7ffb8b202c89 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 #17 0x7ffb8b202d44 in __libc_start_main csu/../csu/libc-start.c:360:3 #18 0x55a97953ef60 in _start (/usr/local/google/home/thurston/buildbot_repro/llvm_build_asan/bin/lld+0x8fd1f60) ```

…der objects" (#123877) Reverts llvm/llvm-project#122811 due to buildbot breakage e.g., https://lab.llvm.org/buildbot/#/builders/52/builds/5421/steps/11/logs/stdio ASan output from local re-run: ``` ==2780289==ERROR: AddressSanitizer: use-after-poison on address 0x7e0b87e28d28 at pc 0x55a979a99e7e bp 0x7ffe4b18f0b0 sp 0x7ffe4b18f0a8 READ of size 1 at 0x7e0b87e28d28 thread T0 #0 0x55a979a99e7d in getStorageClass /usr/local/google/home/thurston/buildbot_repro/llvm-project/llvm/include/llvm/Object/COFF.h:344 #1 0x55a979a99e7d in isSectionDefinition /usr/local/google/home/thurston/buildbot_repro/llvm-project/llvm/include/llvm/Object/COFF.h:429:9 #2 0x55a979a99e7d in getSymbols /usr/local/google/home/thurston/buildbot_repro/llvm-project/lld/COFF/LLDMapFile.cpp:54:42 #3 0x55a979a99e7d in lld::coff::writeLLDMapFile(lld::coff::COFFLinkerContext const&) /usr/local/google/home/thurston/buildbot_repro/llvm-project/lld/COFF/LLDMapFile.cpp:103:40 #4 0x55a979a16879 in (anonymous namespace)::Writer::run() /usr/local/google/home/thurston/buildbot_repro/llvm-project/lld/COFF/Writer.cpp:810:3 #5 0x55a979a00aac in lld::coff::writeResult(lld::coff::COFFLinkerContext&) /usr/local/google/home/thurston/buildbot_repro/llvm-project/lld/COFF/Writer.cpp:354:15 #6 0x55a97985f7ed in lld::coff::LinkerDriver::linkerMain(llvm::ArrayRef<char const*>) /usr/local/google/home/thurston/buildbot_repro/llvm-project/lld/COFF/Driver.cpp:2826:3 #7 0x55a97984cdd3 in lld::coff::link(llvm::ArrayRef<char const*>, llvm::raw_ostream&, llvm::raw_ostream&, bool, bool) /usr/local/google/home/thurston/buildbot_repro/llvm-project/lld/COFF/Driver.cpp:97:15 #8 0x55a9797f9793 in lld::unsafeLldMain(llvm::ArrayRef<char const*>, llvm::raw_ostream&, llvm::raw_ostream&, llvm::ArrayRef<lld::DriverDef>, bool) /usr/local/google/home/thurston/buildbot_repro/llvm-project/lld/Common/DriverDispatcher.cpp:163:12 #9 0x55a9797fa3b6 in operator() /usr/local/google/home/thurston/buildbot_repro/llvm-project/lld/Common/DriverDispatcher.cpp:188:15 #10 0x55a9797fa3b6 in void llvm::function_ref<void ()>::callback_fn<lld::lldMain(llvm::ArrayRef<char const*>, llvm::raw_ostream&, llvm::raw_ostream&, llvm::ArrayRef<lld::DriverDef>)::$_0>(long) /usr/local/google/home/thurston/buildbot_repro/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:46:12 #11 0x55a97966cb93 in operator() /usr/local/google/home/thurston/buildbot_repro/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:69:12 #12 0x55a97966cb93 in llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) /usr/local/google/home/thurston/buildbot_repro/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:426:3 #13 0x55a9797f9dc3 in lld::lldMain(llvm::ArrayRef<char const*>, llvm::raw_ostream&, llvm::raw_ostream&, llvm::ArrayRef<lld::DriverDef>) /usr/local/google/home/thurston/buildbot_repro/llvm-project/lld/Common/DriverDispatcher.cpp:187:14 #14 0x55a979627512 in lld_main(int, char**, llvm::ToolContext const&) /usr/local/google/home/thurston/buildbot_repro/llvm-project/lld/tools/lld/lld.cpp:103:14 #15 0x55a979628731 in main /usr/local/google/home/thurston/buildbot_repro/llvm_build_asan/tools/lld/tools/lld/lld-driver.cpp:17:10 #16 0x7ffb8b202c89 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 #17 0x7ffb8b202d44 in __libc_start_main csu/../csu/libc-start.c:360:3 #18 0x55a97953ef60 in _start (/usr/local/google/home/thurston/buildbot_repro/llvm_build_asan/bin/lld+0x8fd1f60) ```

Prevents avoidable memory leaks. Looks like exchange added in aa1333a didn't take "continue" into account. ``` ==llc==2150782==ERROR: LeakSanitizer: detected memory leaks Direct leak of 10 byte(s) in 1 object(s) allocated from: #0 0x5f1b0f9ac14a in strdup llvm-project/compiler-rt/lib/asan/asan_interceptors.cpp:593:3 #1 0x5f1b1768428d in FileToRemoveList llvm-project/llvm/lib/Support/Unix/Signals.inc:105:55 ```

…124065) Prevents avoidable memory leaks. Looks like exchange added in aa1333a didn't take "continue" into account. ``` ==llc==2150782==ERROR: LeakSanitizer: detected memory leaks Direct leak of 10 byte(s) in 1 object(s) allocated from: #0 0x5f1b0f9ac14a in strdup llvm-project/compiler-rt/lib/asan/asan_interceptors.cpp:593:3 #1 0x5f1b1768428d in FileToRemoveList llvm-project/llvm/lib/Support/Unix/Signals.inc:105:55 ```

…ible (#123752) This patch adds a new option `-aarch64-enable-zpr-predicate-spills` (which is disabled by default), this option replaces predicate spills with vector spills in streaming[-compatible] functions. For example: ``` str p8, [sp, #7, mul vl] // 2-byte Folded Spill // ... ldr p8, [sp, #7, mul vl] // 2-byte Folded Reload ``` Becomes: ``` mov z0.b, p8/z, #1 str z0, [sp] // 16-byte Folded Spill // ... ldr z0, [sp] // 16-byte Folded Reload ptrue p4.b cmpne p8.b, p4/z, z0.b, #0 ``` This is done to avoid streaming memory hazards between FPR/vector and predicate spills, which currently occupy the same stack area even when the `-aarch64-stack-hazard-size` flag is set. This is implemented with two new pseudos SPILL_PPR_TO_ZPR_SLOT_PSEUDO and FILL_PPR_FROM_ZPR_SLOT_PSEUDO. The expansion of these pseudos handles scavenging the required registers (z0 in the above example) and, in the worst case spilling a register to an emergency stack slot in the expansion. The condition flags are also preserved around the `cmpne` in case they are live at the expansion point.

…ds are possible (#123752) This patch adds a new option `-aarch64-enable-zpr-predicate-spills` (which is disabled by default), this option replaces predicate spills with vector spills in streaming[-compatible] functions. For example: ``` str p8, [sp, #7, mul vl] // 2-byte Folded Spill // ... ldr p8, [sp, #7, mul vl] // 2-byte Folded Reload ``` Becomes: ``` mov z0.b, p8/z, #1 str z0, [sp] // 16-byte Folded Spill // ... ldr z0, [sp] // 16-byte Folded Reload ptrue p4.b cmpne p8.b, p4/z, z0.b, #0 ``` This is done to avoid streaming memory hazards between FPR/vector and predicate spills, which currently occupy the same stack area even when the `-aarch64-stack-hazard-size` flag is set. This is implemented with two new pseudos SPILL_PPR_TO_ZPR_SLOT_PSEUDO and FILL_PPR_FROM_ZPR_SLOT_PSEUDO. The expansion of these pseudos handles scavenging the required registers (z0 in the above example) and, in the worst case spilling a register to an emergency stack slot in the expansion. The condition flags are also preserved around the `cmpne` in case they are live at the expansion point.

…StrictPackMatch field (#126215) This addresses the MSAN failure reported in llvm/llvm-project#125791 (comment): ``` ==5633==WARNING: MemorySanitizer: use-of-uninitialized-value #0 in clang::ASTNodeImporter::CallOverloadedCreateFun<clang::ClassTemplateSpecializationDecl>::operator() #1 in bool clang::ASTNodeImporter::GetImportedOrCreateSpecialDecl<...> ... ``` The ASTImporter reads `D->hasStrictPackMatch()` and forwards it to the constructor of the destination `ClassTemplateSpecializationDecl`. But if `D` is a decl that LLDB created from debug-info, it would've been created using `ClassTemplateSpecializationDecl::CreateDeserialized`, which doesn't initialize the `StrictPackMatch` field. This patch just initializes the field to a fixed value of `false`, to preserve previous behaviour and avoid the use-of-uninitialized-value. An alternative would be to always initialize it in the `ClassTemplateSpecializationDecl` constructor, but there were reservations about providing a default value for it because it might lead to hard-to-diagnose problems down the line.

…tionDecl's StrictPackMatch field (#126215) This addresses the MSAN failure reported in llvm/llvm-project#125791 (comment): ``` ==5633==WARNING: MemorySanitizer: use-of-uninitialized-value #0 in clang::ASTNodeImporter::CallOverloadedCreateFun<clang::ClassTemplateSpecializationDecl>::operator() #1 in bool clang::ASTNodeImporter::GetImportedOrCreateSpecialDecl<...> ... ``` The ASTImporter reads `D->hasStrictPackMatch()` and forwards it to the constructor of the destination `ClassTemplateSpecializationDecl`. But if `D` is a decl that LLDB created from debug-info, it would've been created using `ClassTemplateSpecializationDecl::CreateDeserialized`, which doesn't initialize the `StrictPackMatch` field. This patch just initializes the field to a fixed value of `false`, to preserve previous behaviour and avoid the use-of-uninitialized-value. An alternative would be to always initialize it in the `ClassTemplateSpecializationDecl` constructor, but there were reservations about providing a default value for it because it might lead to hard-to-diagnose problems down the line.

…ible (#123752) This patch adds a new option `-aarch64-enable-zpr-predicate-spills` (which is disabled by default), this option replaces predicate spills with vector spills in streaming[-compatible] functions. For example: ``` str p8, [sp, #7, mul vl] // 2-byte Folded Spill // ... ldr p8, [sp, #7, mul vl] // 2-byte Folded Reload ``` Becomes: ``` mov z0.b, p8/z, #1 str z0, [sp] // 16-byte Folded Spill // ... ldr z0, [sp] // 16-byte Folded Reload ptrue p4.b cmpne p8.b, p4/z, z0.b, #0 ``` This is done to avoid streaming memory hazards between FPR/vector and predicate spills, which currently occupy the same stack area even when the `-aarch64-stack-hazard-size` flag is set. This is implemented with two new pseudos SPILL_PPR_TO_ZPR_SLOT_PSEUDO and FILL_PPR_FROM_ZPR_SLOT_PSEUDO. The expansion of these pseudos handles scavenging the required registers (z0 in the above example) and, in the worst case spilling a register to an emergency stack slot in the expansion. The condition flags are also preserved around the `cmpne` in case they are live at the expansion point.

…ds are possible (#123752) This patch adds a new option `-aarch64-enable-zpr-predicate-spills` (which is disabled by default), this option replaces predicate spills with vector spills in streaming[-compatible] functions. For example: ``` str p8, [sp, #7, mul vl] // 2-byte Folded Spill // ... ldr p8, [sp, #7, mul vl] // 2-byte Folded Reload ``` Becomes: ``` mov z0.b, p8/z, #1 str z0, [sp] // 16-byte Folded Spill // ... ldr z0, [sp] // 16-byte Folded Reload ptrue p4.b cmpne p8.b, p4/z, z0.b, #0 ``` This is done to avoid streaming memory hazards between FPR/vector and predicate spills, which currently occupy the same stack area even when the `-aarch64-stack-hazard-size` flag is set. This is implemented with two new pseudos SPILL_PPR_TO_ZPR_SLOT_PSEUDO and FILL_PPR_FROM_ZPR_SLOT_PSEUDO. The expansion of these pseudos handles scavenging the required registers (z0 in the above example) and, in the worst case spilling a register to an emergency stack slot in the expansion. The condition flags are also preserved around the `cmpne` in case they are live at the expansion point.

We can't guaranty that underlying string is 0-terminated and [String.size()] is even in the same allocation. https://lab.llvm.org/buildbot/#/builders/94/builds/4152/steps/17/logs/stdio ``` ==c-index-test==1846256==WARNING: MemorySanitizer: use-of-uninitialized-value #0 in clang::cxstring::createRef(llvm::StringRef) llvm-project/clang/tools/libclang/CXString.cpp:96:36 #1 in DumpCXCommentInternal llvm-project/clang/tools/c-index-test/c-index-test.c:521:39 #2 in DumpCXCommentInternal llvm-project/clang/tools/c-index-test/c-index-test.c:674:7 #3 in DumpCXCommentInternal llvm-project/clang/tools/c-index-test/c-index-test.c:674:7 #4 in DumpCXComment llvm-project/clang/tools/c-index-test/c-index-test.c:685:3 #5 in PrintCursorComments llvm-project/clang/tools/c-index-test/c-index-test.c:768:7 Memory was marked as uninitialized #0 in __msan_allocated_memory llvm-project/compiler-rt/lib/msan/msan_interceptors.cpp:1023:5 #1 in Allocate llvm-project/llvm/include/llvm/Support/Allocator.h:172:7 #2 in Allocate llvm-project/llvm/include/llvm/Support/Allocator.h:216:12 #3 in Allocate llvm-project/llvm/include/llvm/Support/AllocatorBase.h:53:43 #4 in Allocate<char> llvm-project/llvm/include/llvm/Support/AllocatorBase.h:76:29 #5 in convertCodePointToUTF8 llvm-project/clang/lib/AST/CommentLexer.cpp:42:30 #6 in clang::comments::Lexer::resolveHTMLDecimalCharacterReference(llvm::StringRef) const llvm-project/clang/lib/AST/CommentLexer.cpp:76:10 #7 in clang::comments::Lexer::lexHTMLCharacterReference(clang::comments::Token&) llvm-project/clang/lib/AST/CommentLexer.cpp:615:16 #8 in consumeToken llvm-project/clang/include/clang/AST/CommentParser.h:62:9 #9 in clang::comments::Parser::parseParagraphOrBlockCommand() llvm-project/clang/lib/AST/CommentParser.cpp #10 in clang::comments::Parser::parseFullComment() llvm-project/clang/lib/AST/CommentParser.cpp:925:22 #11 in clang::RawComment::parse(clang::ASTContext const&, clang::Preprocessor const*, clang::Decl const*) const llvm-project/clang/lib/AST/RawCommentList.cpp:221:12 #12 in clang::ASTContext::getCommentForDecl(clang::Decl const*, clang::Preprocessor const*) const llvm-project/clang/lib/AST/ASTContext.cpp:714:35 #13 in clang_Cursor_getParsedComment llvm-project/clang/tools/libclang/CXComment.cpp:36:35 #14 in PrintCursorComments llvm-project/clang/tools/c-index-test/c-index-test.c:756:25 ```

Reverts llvm/llvm-project#125020 https://lab.llvm.org/buildbot/#/builders/24/builds/5252/steps/12/logs/stdio ``` ==c-index-test==2512295==ERROR: AddressSanitizer: heap-use-after-free on address 0xe19338c27992 at pc 0xc66be4784830 bp 0xe0e33660df00 sp 0xe0e33660d6e8 READ of size 23 at 0xe19338c27992 thread T1 #0 0xc66be478482c in printf_common(void*, char const*, std::__va_list) /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors_format.inc:563:9 #1 0xc66be478643c in vprintf /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:1699:1 #2 0xc66be478643c in printf /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:1757:1 #3 0xc66be4839384 in FilteredPrintingVisitor /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/clang/tools/c-index-test/c-index-test.c:1359:5 #4 0xe4e3454f12e8 in clang::cxcursor::CursorVisitor::Visit(CXCursor, bool) /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/clang/tools/libclang/CIndex.cpp:227:11 #5 0xe4e3454f48a8 in bool clang::cxcursor::CursorVisitor::visitPreprocessedEntities<clang::PreprocessingRecord::iterator>(clang::PreprocessingRecord::iterator, clang::PreprocessingRecord::iterator, clang::PreprocessingRecord&, clang::FileID) CIndex.cpp 0xe19338c27992 is located 82 bytes inside of 105-byte region [0xe19338c27940,0xe19338c279a9) freed by thread T1 here: #0 0xc66be480040c in free /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:51:3 #1 0xc66be4839728 in GetCursorSource c-index-test.c #2 0xc66be4839368 in FilteredPrintingVisitor /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/clang/tools/c-index-test/c-index-test.c:1360:12 #3 0xe4e3454f12e8 in clang::cxcursor::CursorVisitor::Visit(CXCursor, bool) /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/clang/tools/libclang/CIndex.cpp:227:11 #4 0xe4e3454f48a8 in bool clang::cxcursor::CursorVisitor::visitPreprocessedEntities<clang::PreprocessingRecord::iterator>(clang::PreprocessingRecord::iterator, clang::PreprocessingRecord::iterator, clang::PreprocessingRecord&, clang::FileID) CIndex.cpp previously allocated by thread T1 here: #0 0xc66be4800680 in malloc /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:67:3 #1 0xe4e3456379b0 in safe_malloc /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/llvm/include/llvm/Support/MemAlloc.h:26:18 #2 0xe4e3456379b0 in createDup /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/clang/tools/libclang/CXString.cpp:95:40 #3 0xe4e3456379b0 in clang::cxstring::createRef(llvm::StringRef) /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/clang/tools/libclang/CXString.cpp:90:10 ```

…27076) Reverts llvm/llvm-project#125020 https://lab.llvm.org/buildbot/#/builders/24/builds/5252/steps/12/logs/stdio ``` ==c-index-test==2512295==ERROR: AddressSanitizer: heap-use-after-free on address 0xe19338c27992 at pc 0xc66be4784830 bp 0xe0e33660df00 sp 0xe0e33660d6e8 READ of size 23 at 0xe19338c27992 thread T1 #0 0xc66be478482c in printf_common(void*, char const*, std::__va_list) /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors_format.inc:563:9 #1 0xc66be478643c in vprintf /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:1699:1 #2 0xc66be478643c in printf /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:1757:1 #3 0xc66be4839384 in FilteredPrintingVisitor /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/clang/tools/c-index-test/c-index-test.c:1359:5 #4 0xe4e3454f12e8 in clang::cxcursor::CursorVisitor::Visit(CXCursor, bool) /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/clang/tools/libclang/CIndex.cpp:227:11 #5 0xe4e3454f48a8 in bool clang::cxcursor::CursorVisitor::visitPreprocessedEntities<clang::PreprocessingRecord::iterator>(clang::PreprocessingRecord::iterator, clang::PreprocessingRecord::iterator, clang::PreprocessingRecord&, clang::FileID) CIndex.cpp 0xe19338c27992 is located 82 bytes inside of 105-byte region [0xe19338c27940,0xe19338c279a9) freed by thread T1 here: #0 0xc66be480040c in free /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:51:3 #1 0xc66be4839728 in GetCursorSource c-index-test.c #2 0xc66be4839368 in FilteredPrintingVisitor /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/clang/tools/c-index-test/c-index-test.c:1360:12 #3 0xe4e3454f12e8 in clang::cxcursor::CursorVisitor::Visit(CXCursor, bool) /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/clang/tools/libclang/CIndex.cpp:227:11 #4 0xe4e3454f48a8 in bool clang::cxcursor::CursorVisitor::visitPreprocessedEntities<clang::PreprocessingRecord::iterator>(clang::PreprocessingRecord::iterator, clang::PreprocessingRecord::iterator, clang::PreprocessingRecord&, clang::FileID) CIndex.cpp previously allocated by thread T1 here: #0 0xc66be4800680 in malloc /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:67:3 #1 0xe4e3456379b0 in safe_malloc /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/llvm/include/llvm/Support/MemAlloc.h:26:18 #2 0xe4e3456379b0 in createDup /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/clang/tools/libclang/CXString.cpp:95:40 #3 0xe4e3456379b0 in clang::cxstring::createRef(llvm::StringRef) /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/clang/tools/libclang/CXString.cpp:90:10 ```

Fixes the following crash in clang-repl ```c++ clang-repl> try { throw 1; } catch { 0; } In file included from <<< inputs >>>:1: input_line_1:1:23: error: expected '(' 1 | try { throw 1; } catch { 0; } | ^ | ( clang-repl: /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/clang/lib/AST/DeclBase.cpp:1757: void clang::DeclContext::addHiddenDecl(clang::Decl*): Assertion `D->getLexicalDeclContext() == this && "Decl inserted into wrong lexical context"' failed. #0 0x000059b28459e6da llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/llvm/lib/Support/Unix/Signals.inc:804:22 #1 0x000059b28459eaed PrintStackTraceSignalHandler(void*) /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/llvm/lib/Support/Unix/Signals.inc:880:1 #2 0x000059b28459bf7f llvm::sys::RunSignalHandlers() /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/llvm/lib/Support/Signals.cpp:105:20 #3 0x000059b28459df8e SignalHandler(int, siginfo_t*, void*) /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/llvm/lib/Support/Unix/Signals.inc:418:13 #4 0x000077cdf444ea50 (/usr/lib/libc.so.6+0x42a50) #5 0x000077cdf44aee3b pthread_kill (/usr/lib/libc.so.6+0xa2e3b) #6 0x000077cdf444e928 raise (/usr/lib/libc.so.6+0x42928) #7 0x000077cdf443156c abort (/usr/lib/libc.so.6+0x2556c) #8 0x000077cdf44314d2 __assert_perror_fail (/usr/lib/libc.so.6+0x254d2) #9 0x000077cdf4444c56 (/usr/lib/libc.so.6+0x38c56) #10 0x000059b28495bfc4 clang::DeclContext::addHiddenDecl(clang::Decl*) /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/clang/lib/AST/DeclBase.cpp:1759:3 #11 0x000059b28495c0f5 clang::DeclContext::addDecl(clang::Decl*) /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/clang/lib/AST/DeclBase.cpp:1785:37 #12 0x000059b28773cc2a clang::Sema::ActOnStartTopLevelStmtDecl(clang::Scope*) /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/clang/lib/Sema/SemaDecl.cpp:20302:18 #13 0x000059b286f1efdf clang::Parser::ParseTopLevelStmtDecl() /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/clang/lib/Parse/ParseDecl.cpp:6024:62 #14 0x000059b286ef18ee clang::Parser::ParseExternalDeclaration(clang::ParsedAttributes&, clang::ParsedAttributes&, clang::ParsingDeclSpec*) /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/clang/lib/Parse/Parser.cpp:1065:35 #15 0x000059b286ef0702 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&, clang::Sema::ModuleImportState&) /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/clang/lib/Parse/Parser.cpp:758:36 #16 0x000059b28562dff2 clang::IncrementalParser::ParseOrWrapTopLevelDecl() /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/clang/lib/Interpreter/IncrementalParser.cpp:66:36 #17 0x000059b28562e5b7 clang::IncrementalParser::Parse(llvm::StringRef) /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/clang/lib/Interpreter/IncrementalParser.cpp:132:8 #18 0x000059b28561832b clang::Interpreter::Parse(llvm::StringRef) /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/clang/lib/Interpreter/Interpreter.cpp:570:8 #19 0x000059b285618cbd clang::Interpreter::ParseAndExecute(llvm::StringRef, clang::Value*) /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/clang/lib/Interpreter/Interpreter.cpp:649:8 #20 0x000059b2836f9343 main /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/clang/tools/clang-repl/ClangRepl.cpp:255:59 #21 0x000077cdf443388e (/usr/lib/libc.so.6+0x2788e) #22 0x000077cdf443394a __libc_start_main (/usr/lib/libc.so.6+0x2794a) #23 0x000059b2836f7965 _start (./bin/clang-repl+0x73b8965) fish: Job 1, './bin/clang-repl' terminated by signal SIGABRT (Abort) ``` With this change: ```c++ clang-repl> try { throw 1; } catch { 0; } In file included from <<< inputs >>>:1: input_line_1:1:23: error: expected '(' 1 | try { throw 1; } catch { 0; } | ^ | ( error: Parsing failed. clang-repl> 1; clang-repl> %quit ```

…ails (#127087) Fixes the following crash in clang-repl ```c++ clang-repl> try { throw 1; } catch { 0; } In file included from <<< inputs >>>:1: input_line_1:1:23: error: expected '(' 1 | try { throw 1; } catch { 0; } | ^ | ( clang-repl: /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/clang/lib/AST/DeclBase.cpp:1757: void clang::DeclContext::addHiddenDecl(clang::Decl*): Assertion `D->getLexicalDeclContext() == this && "Decl inserted into wrong lexical context"' failed. #0 0x000059b28459e6da llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/llvm/lib/Support/Unix/Signals.inc:804:22 #1 0x000059b28459eaed PrintStackTraceSignalHandler(void*) /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/llvm/lib/Support/Unix/Signals.inc:880:1 #2 0x000059b28459bf7f llvm::sys::RunSignalHandlers() /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/llvm/lib/Support/Signals.cpp:105:20 #3 0x000059b28459df8e SignalHandler(int, siginfo_t*, void*) /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/llvm/lib/Support/Unix/Signals.inc:418:13 #4 0x000077cdf444ea50 (/usr/lib/libc.so.6+0x42a50) #5 0x000077cdf44aee3b pthread_kill (/usr/lib/libc.so.6+0xa2e3b) #6 0x000077cdf444e928 raise (/usr/lib/libc.so.6+0x42928) #7 0x000077cdf443156c abort (/usr/lib/libc.so.6+0x2556c) #8 0x000077cdf44314d2 __assert_perror_fail (/usr/lib/libc.so.6+0x254d2) #9 0x000077cdf4444c56 (/usr/lib/libc.so.6+0x38c56) #10 0x000059b28495bfc4 clang::DeclContext::addHiddenDecl(clang::Decl*) /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/clang/lib/AST/DeclBase.cpp:1759:3 #11 0x000059b28495c0f5 clang::DeclContext::addDecl(clang::Decl*) /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/clang/lib/AST/DeclBase.cpp:1785:37 #12 0x000059b28773cc2a clang::Sema::ActOnStartTopLevelStmtDecl(clang::Scope*) /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/clang/lib/Sema/SemaDecl.cpp:20302:18 #13 0x000059b286f1efdf clang::Parser::ParseTopLevelStmtDecl() /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/clang/lib/Parse/ParseDecl.cpp:6024:62 #14 0x000059b286ef18ee clang::Parser::ParseExternalDeclaration(clang::ParsedAttributes&, clang::ParsedAttributes&, clang::ParsingDeclSpec*) /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/clang/lib/Parse/Parser.cpp:1065:35 #15 0x000059b286ef0702 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&, clang::Sema::ModuleImportState&) /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/clang/lib/Parse/Parser.cpp:758:36 #16 0x000059b28562dff2 clang::IncrementalParser::ParseOrWrapTopLevelDecl() /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/clang/lib/Interpreter/IncrementalParser.cpp:66:36 #17 0x000059b28562e5b7 clang::IncrementalParser::Parse(llvm::StringRef) /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/clang/lib/Interpreter/IncrementalParser.cpp:132:8 #18 0x000059b28561832b clang::Interpreter::Parse(llvm::StringRef) /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/clang/lib/Interpreter/Interpreter.cpp:570:8 #19 0x000059b285618cbd clang::Interpreter::ParseAndExecute(llvm::StringRef, clang::Value*) /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/clang/lib/Interpreter/Interpreter.cpp:649:8 #20 0x000059b2836f9343 main /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/clang/tools/clang-repl/ClangRepl.cpp:255:59 #21 0x000077cdf443388e (/usr/lib/libc.so.6+0x2788e) #22 0x000077cdf443394a __libc_start_main (/usr/lib/libc.so.6+0x2794a) #23 0x000059b2836f7965 _start (./bin/clang-repl+0x73b8965) fish: Job 1, './bin/clang-repl' terminated by signal SIGABRT (Abort) ``` With this change: ```c++ clang-repl> try { throw 1; } catch { 0; } In file included from <<< inputs >>>:1: input_line_1:1:23: error: expected '(' 1 | try { throw 1; } catch { 0; } | ^ | ( error: Parsing failed. clang-repl> 1; clang-repl> %quit ```

For function declarations (i.e. func op has no entry block), the FunctionOpInterface method `insertArgument` and `eraseArgument` will cause segfault. This PR guards against manipulation of empty entry block by checking whether func op is external. An example can be seen in google/heir#1324 The segfault trace ``` #1 0x0000560f1289d9db PrintStackTraceSignalHandler(void*) /proc/self/cwd/external/llvm-project/llvm/lib/Support/Unix/Signals.inc:874:1 #2 0x0000560f1289b116 llvm::sys::RunSignalHandlers() /proc/self/cwd/external/llvm-project/llvm/lib/Support/Signals.cpp:105:5 #3 0x0000560f1289e145 SignalHandler(int) /proc/self/cwd/external/llvm-project/llvm/lib/Support/Unix/Signals.inc:415:1 #4 0x00007f829a3d9520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520) #5 0x0000560f1257f8bc void __gnu_cxx::new_allocator<mlir::BlockArgument>::construct<mlir::BlockArgument, mlir::BlockArgument>(mlir::BlockArgument*, mlir::BlockArgument&&) /usr/lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/ext/new_allocator.h:162:23 #6 0x0000560f1257f84d void std::allocator_traits<std::allocator<mlir::BlockArgument> >::construct<mlir::BlockArgument, mlir::BlockArgument>(std::allocator<mlir::BlockArgument>&, mlir::BlockArgument*, mlir::BlockArgument&&) /usr/lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/alloc_traits.h:520:2 #7 0x0000560f12580498 void std::vector<mlir::BlockArgument, std::allocator<mlir::BlockArgument> >::_M_insert_aux<mlir::BlockArgument>(__gnu_cxx::__normal_iterator<mlir::BlockArgument*, std::vector<mlir::BlockArgument, std::allocator<mlir::BlockArgument> > >, mlir::BlockArgument&&) /usr/lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/vector.tcc:405:7 #8 0x0000560f1257cf7e std::vector<mlir::BlockArgument, std::allocator<mlir::BlockArgument> >::insert(__gnu_cxx::__normal_iterator<mlir::BlockArgument const*, std::vector<mlir::BlockArgument, std::allocator<mlir::BlockArgument> > >, mlir::BlockArgument const&) /usr/lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/vector.tcc:154:6 #9 0x0000560f1257b349 mlir::Block::insertArgument(unsigned int, mlir::Type, mlir::Location) /proc/self/cwd/external/llvm-project/mlir/lib/IR/Block.cpp:178:13 #10 0x0000560f123d2a1c mlir::function_interface_impl::insertFunctionArguments(mlir::FunctionOpInterface, llvm::ArrayRef<unsigned int>, mlir::TypeRange, llvm::ArrayRef<mlir::DictionaryAttr>, llvm::ArrayRef<mlir::Location>, unsigned int, mlir::Type) /proc/self/cwd/external/llvm-project/mlir/lib/Interfaces/FunctionInterfaces.cpp:232:11 #11 0x0000560f0be6b727 mlir::detail::FunctionOpInterfaceTrait<mlir::func::FuncOp>::insertArguments(llvm::ArrayRef<unsigned int>, mlir::TypeRange, llvm::ArrayRef<mlir::DictionaryAttr>, llvm::ArrayRef<mlir::Location>) /proc/self/cwd/bazel-out/k8-dbg/bin/external/llvm-project/mlir/include/mlir/Interfaces/FunctionInterfaces.h.inc:809:7 #12 0x0000560f0be6b536 mlir::detail::FunctionOpInterfaceTrait<mlir::func::FuncOp>::insertArgument(unsigned int, mlir::Type, mlir::DictionaryAttr, mlir::Location) /proc/self/cwd/bazel-out/k8-dbg/bin/external/llvm-project/mlir/include/mlir/Interfaces/FunctionInterfaces.h.inc:796:7 ```

… `getForwardSlice` matchers (#115670) Improve mlir-query tool by implementing `getBackwardSlice` and `getForwardSlice` matchers. As an addition `SetQuery` also needed to be added to enable custom configuration for each query. e.g: `inclusive`, `omitUsesFromAbove`, `omitBlockArguments`. Note: backwardSlice and forwardSlice algoritms are the same as the ones in `mlir/lib/Analysis/SliceAnalysis.cpp` Example of current matcher. The query was made to the file: `mlir/test/mlir-query/complex-test.mlir` ```mlir ./mlir-query /home/dbudii/personal/llvm-project/mlir/test/mlir-query/complex-test.mlir -c "match getDefinitions(hasOpName(\"arith.add f\"),2)" Match #1: /home/dbudii/personal/llvm-project/mlir/test/mlir-query/complex-test.mlir:5:8: %0 = linalg.generic {indexing_maps = [#map, #map], iterator_types = ["parallel", "parallel"]} ins(%arg0 : tensor<5x5xf32>) outs(%arg1 : tensor<5x5xf32>) { ^ /home/dbudii/personal/llvm-project/mlir/test/mlir-query/complex-test.mlir:7:10: note: "root" binds here %2 = arith.addf %in, %in : f32 ^ Match #2: /home/dbudii/personal/llvm-project/mlir/test/mlir-query/complex-test.mlir:10:16: %collapsed = tensor.collapse_shape %0 [[0, 1]] : tensor<5x5xf32> into tensor<25xf32> ^ /home/dbudii/personal/llvm-project/mlir/test/mlir-query/complex-test.mlir:13:11: %c2 = arith.constant 2 : index ^ /home/dbudii/personal/llvm-project/mlir/test/mlir-query/complex-test.mlir:14:18: %extracted = tensor.extract %collapsed[%c2] : tensor<25xf32> ^ /home/dbudii/personal/llvm-project/mlir/test/mlir-query/complex-test.mlir:15:10: note: "root" binds here %2 = arith.addf %extracted, %extracted : f32 ^ 2 matches. ```

…dSlice` and `getForwardSlice` matchers (#115670) Improve mlir-query tool by implementing `getBackwardSlice` and `getForwardSlice` matchers. As an addition `SetQuery` also needed to be added to enable custom configuration for each query. e.g: `inclusive`, `omitUsesFromAbove`, `omitBlockArguments`. Note: backwardSlice and forwardSlice algoritms are the same as the ones in `mlir/lib/Analysis/SliceAnalysis.cpp` Example of current matcher. The query was made to the file: `mlir/test/mlir-query/complex-test.mlir` ```mlir ./mlir-query /home/dbudii/personal/llvm-project/mlir/test/mlir-query/complex-test.mlir -c "match getDefinitions(hasOpName(\"arith.add f\"),2)" Match #1: /home/dbudii/personal/llvm-project/mlir/test/mlir-query/complex-test.mlir:5:8: %0 = linalg.generic {indexing_maps = [#map, #map], iterator_types = ["parallel", "parallel"]} ins(%arg0 : tensor<5x5xf32>) outs(%arg1 : tensor<5x5xf32>) { ^ /home/dbudii/personal/llvm-project/mlir/test/mlir-query/complex-test.mlir:7:10: note: "root" binds here %2 = arith.addf %in, %in : f32 ^ Match #2: /home/dbudii/personal/llvm-project/mlir/test/mlir-query/complex-test.mlir:10:16: %collapsed = tensor.collapse_shape %0 [[0, 1]] : tensor<5x5xf32> into tensor<25xf32> ^ /home/dbudii/personal/llvm-project/mlir/test/mlir-query/complex-test.mlir:13:11: %c2 = arith.constant 2 : index ^ /home/dbudii/personal/llvm-project/mlir/test/mlir-query/complex-test.mlir:14:18: %extracted = tensor.extract %collapsed[%c2] : tensor<25xf32> ^ /home/dbudii/personal/llvm-project/mlir/test/mlir-query/complex-test.mlir:15:10: note: "root" binds here %2 = arith.addf %extracted, %extracted : f32 ^ 2 matches. ```

…404) `clang-repl --cuda` was previously crashing with a segmentation fault, instead of reporting a clean error ``` (base) anutosh491@Anutoshs-MacBook-Air bin % ./clang-repl --cuda #0 0x0000000111da4fbc llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/local/libexec/llvm-20/lib/libLLVM.dylib+0x150fbc) #1 0x0000000111da31dc llvm::sys::RunSignalHandlers() (/opt/local/libexec/llvm-20/lib/libLLVM.dylib+0x14f1dc) #2 0x0000000111da5628 SignalHandler(int) (/opt/local/libexec/llvm-20/lib/libLLVM.dylib+0x151628) #3 0x000000019b242de4 (/usr/lib/system/libsystem_platform.dylib+0x180482de4) #4 0x0000000107f638d0 clang::IncrementalCUDADeviceParser::IncrementalCUDADeviceParser(std::__1::unique_ptr<clang::CompilerInstance, std::__1::default_delete<clang::CompilerInstance>>, clang::CompilerInstance&, llvm::IntrusiveRefCntPtr<llvm::vfs::InMemoryFileSystem>, llvm::Error&, std::__1::list<clang::PartialTranslationUnit, std::__1::allocator<clang::PartialTranslationUnit>> const&) (/opt/local/libexec/llvm-20/lib/libclang-cpp.dylib+0x216b8d0) #5 0x0000000107f638d0 clang::IncrementalCUDADeviceParser::IncrementalCUDADeviceParser(std::__1::unique_ptr<clang::CompilerInstance, std::__1::default_delete<clang::CompilerInstance>>, clang::CompilerInstance&, llvm::IntrusiveRefCntPtr<llvm::vfs::InMemoryFileSystem>, llvm::Error&, std::__1::list<clang::PartialTranslationUnit, std::__1::allocator<clang::PartialTranslationUnit>> const&) (/opt/local/libexec/llvm-20/lib/libclang-cpp.dylib+0x216b8d0) #6 0x0000000107f6bac8 clang::Interpreter::createWithCUDA(std::__1::unique_ptr<clang::CompilerInstance, std::__1::default_delete<clang::CompilerInstance>>, std::__1::unique_ptr<clang::CompilerInstance, std::__1::default_delete<clang::CompilerInstance>>) (/opt/local/libexec/llvm-20/lib/libclang-cpp.dylib+0x2173ac8) #7 0x000000010206f8a8 main (/opt/local/libexec/llvm-20/bin/clang-repl+0x1000038a8) #8 0x000000019ae8c274 Segmentation fault: 11 ``` The underlying issue was that the `DeviceCompilerInstance` (used for device-side CUDA compilation) was never initialized with a `Sema`, which is required before constructing the `IncrementalCUDADeviceParser`. https://github.com/llvm/llvm-project/blob/89687e6f383b742a3c6542dc673a84d9f82d02de/clang/lib/Interpreter/DeviceOffload.cpp#L32 https://github.com/llvm/llvm-project/blob/89687e6f383b742a3c6542dc673a84d9f82d02de/clang/lib/Interpreter/IncrementalParser.cpp#L31 Unlike the host-side `CompilerInstance` which runs `ExecuteAction` inside the Interpreter constructor (thereby setting up Sema), the device-side CI was passed into the parser uninitialized, leading to an assertion or crash when accessing its internals. To fix this, I refactored the `Interpreter::create` method to include an optional `DeviceCI` parameter. If provided, we know we need to take care of this instance too. Only then do we construct the `IncrementalCUDADeviceParser`. (cherry picked from commit 21fb19f)

…egation case (#138091) Check this error for more context (https://github.com/compiler-research/CppInterOp/actions/runs/14749797085/job/41407625681?pr=491#step:10:531) This fails with ``` * thread #1, name = 'CppInterOpTests', stop reason = signal SIGSEGV: address not mapped to object (fault address: 0x55500356d6d3) * frame #0: 0x00007fffee41cfe3 libclangCppInterOp.so.21.0gitclang::PragmaNamespace::~PragmaNamespace() + 99 frame #1: 0x00007fffee435666 libclangCppInterOp.so.21.0gitclang::Preprocessor::~Preprocessor() + 3830 frame #2: 0x00007fffee20917a libclangCppInterOp.so.21.0gitstd::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() + 58 frame #3: 0x00007fffee224796 libclangCppInterOp.so.21.0gitclang::CompilerInstance::~CompilerInstance() + 838 frame #4: 0x00007fffee22494d libclangCppInterOp.so.21.0gitclang::CompilerInstance::~CompilerInstance() + 13 frame #5: 0x00007fffed95ec62 libclangCppInterOp.so.21.0gitclang::IncrementalCUDADeviceParser::~IncrementalCUDADeviceParser() + 98 frame #6: 0x00007fffed9551b6 libclangCppInterOp.so.21.0gitclang::Interpreter::~Interpreter() + 102 frame #7: 0x00007fffed95598d libclangCppInterOp.so.21.0gitclang::Interpreter::~Interpreter() + 13 frame #8: 0x00007fffed9181e7 libclangCppInterOp.so.21.0gitcompat::createClangInterpreter(std::vector<char const*, std::allocator<char const*>>&) + 2919 ``` Problem : 1) The destructor currently handles no clearance for the DeviceParser and the DeviceAct. We currently only have this https://github.com/llvm/llvm-project/blob/976493822443c52a71ed3c67aaca9a555b20c55d/clang/lib/Interpreter/Interpreter.cpp#L416-L419 2) The ownership for DeviceCI currently is present in IncrementalCudaDeviceParser. But this should be similar to how the combination for hostCI, hostAction and hostParser are managed by the Interpreter. As on master the DeviceAct and DeviceParser are managed by the Interpreter but not DeviceCI. This is problematic because : IncrementalParser holds a Sema& which points into the DeviceCI. On master, DeviceCI is destroyed before the base class ~IncrementalParser() runs, causing Parser::reset() to access a dangling Sema (and as Sema holds a reference to Preprocessor which owns PragmaNamespace) we see this ``` * frame #0: 0x00007fffee41cfe3 libclangCppInterOp.so.21.0gitclang::PragmaNamespace::~PragmaNamespace() + 99 frame #1: 0x00007fffee435666 libclangCppInterOp.so.21.0gitclang::Preprocessor::~Preprocessor() + 3830 ``` (cherry picked from commit 529b6fc)

Fixes #123300 What is seen ``` clang-repl> int x = 42; clang-repl> auto capture = [&]() { return x * 2; }; In file included from <<< inputs >>>:1: input_line_4:1:17: error: non-local lambda expression cannot have a capture-default 1 | auto capture = [&]() { return x * 2; }; | ^ zsh: segmentation fault clang-repl --Xcc="-v" (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x8) * frame #0: 0x0000000107b4f8b8 libclang-cpp.19.1.dylib`clang::IncrementalParser::CleanUpPTU(clang::PartialTranslationUnit&) + 988 frame #1: 0x0000000107b4f1b4 libclang-cpp.19.1.dylib`clang::IncrementalParser::ParseOrWrapTopLevelDecl() + 416 frame #2: 0x0000000107b4fb94 libclang-cpp.19.1.dylib`clang::IncrementalParser::Parse(llvm::StringRef) + 612 frame #3: 0x0000000107b52fec libclang-cpp.19.1.dylib`clang::Interpreter::ParseAndExecute(llvm::StringRef, clang::Value*) + 180 frame #4: 0x0000000100003498 clang-repl`main + 3560 frame #5: 0x000000018d39a0e0 dyld`start + 2360 ``` Though the error is justified, we shouldn't be interested in exiting through a segfault in such cases. The issue is that empty named decls weren't being taken care of resulting into this assert https://github.com/llvm/llvm-project/blob/c1a229252617ed58f943bf3f4698bd8204ee0f04/clang/include/clang/AST/DeclarationName.h#L503 Can also be seen when the example is attempted through xeus-cpp-lite. ![image](https://github.com/user-attachments/assets/9b0e6ead-138e-4b06-9ad9-fcb9f8d5bf6e)

# Symptom We have seen SIGSEGV like this: ``` * thread #1, name = 'lldb-server', stop reason = SIGSEGV frame #0: 0x00007f39e529c993 libc.so.6`__pthread_kill_internal(signo=11, threadid=<unavailable>) at pthread_kill.c:46:37 ... * frame #5: 0x000056027c94fe48 lldb-server`lldb_private::process_linux::GetPtraceScope() + 72 frame #6: 0x000056027c92f94f lldb-server`lldb_private::process_linux::NativeProcessLinux::Attach(int) + 1087 ... ``` See [full stack trace](https://pastebin.com/X0d6QhYj). This happens on Linux where LLDB doesn't have access to `/proc/sys/kernel/yama/ptrace_scope`. A similar error (an unchecked `Error`) can be reproduced by running the newly added unit test without the fix. See the "Test" section below. # Root cause `GetPtraceScope()` ([code](https://github.com/llvm/llvm-project/blob/328f40f408c218f25695ea42c844e43bef38660b/lldb/source/Plugins/Process/Linux/Procfs.cpp#L77)) has the following `if` statement: ``` llvm::Expected<int> lldb_private::process_linux::GetPtraceScope() { ErrorOr<std::unique_ptr<MemoryBuffer>> ptrace_scope_file = getProcFile("sys/kernel/yama/ptrace_scope"); if (!*ptrace_scope_file) return errorCodeToError(ptrace_scope_file.getError()); ... } ``` The intention of the `if` statement is to check whether the `ptrace_scope_file` is an `Error` or not, and return the error if it is. However, the `operator*` of `ErrorOr` returns the value that is stored (which is a `std::unique_ptr<MemoryBuffer>`), so what the `if` condition actually do is to check if the unique pointer is non-null. Note that the method `ErrorOr::getStorage()` ([called by](https://github.com/llvm/llvm-project/blob/328f40f408c218f25695ea42c844e43bef38660b/llvm/include/llvm/Support/ErrorOr.h#L162-L164) `ErrorOr::operator *`) **does** assert on whether or not `HasError` has been set (see [ErrorOr.h](https://github.com/llvm/llvm-project/blob/328f40f408c218f25695ea42c844e43bef38660b/llvm/include/llvm/Support/ErrorOr.h#L235-L243)). However, it seems this wasn't executed, probably because the LLDB was a release build. # Fix The fix is simply remove the `*` in the said `if` statement.

…#142224) # Symptom We have seen SIGSEGV like this: ``` * thread #1, name = 'lldb-server', stop reason = SIGSEGV frame #0: 0x00007f39e529c993 libc.so.6`__pthread_kill_internal(signo=11, threadid=<unavailable>) at pthread_kill.c:46:37 ... * frame #5: 0x000056027c94fe48 lldb-server`lldb_private::process_linux::GetPtraceScope() + 72 frame #6: 0x000056027c92f94f lldb-server`lldb_private::process_linux::NativeProcessLinux::Attach(int) + 1087 ... ``` See [full stack trace](https://pastebin.com/X0d6QhYj). This happens on Linux where LLDB doesn't have access to `/proc/sys/kernel/yama/ptrace_scope`. A similar error (an unchecked `Error`) can be reproduced by running the newly added unit test without the fix. See the "Test" section below. # Root cause `GetPtraceScope()` ([code](https://github.com/llvm/llvm-project/blob/328f40f408c218f25695ea42c844e43bef38660b/lldb/source/Plugins/Process/Linux/Procfs.cpp#L77)) has the following `if` statement: ``` llvm::Expected<int> lldb_private::process_linux::GetPtraceScope() { ErrorOr<std::unique_ptr<MemoryBuffer>> ptrace_scope_file = getProcFile("sys/kernel/yama/ptrace_scope"); if (!*ptrace_scope_file) return errorCodeToError(ptrace_scope_file.getError()); ... } ``` The intention of the `if` statement is to check whether the `ptrace_scope_file` is an `Error` or not, and return the error if it is. However, the `operator*` of `ErrorOr` returns the value that is stored (which is a `std::unique_ptr<MemoryBuffer>`), so what the `if` condition actually do is to check if the unique pointer is non-null. Note that the method `ErrorOr::getStorage()` ([called by](https://github.com/llvm/llvm-project/blob/328f40f408c218f25695ea42c844e43bef38660b/llvm/include/llvm/Support/ErrorOr.h#L162-L164) `ErrorOr::operator *`) **does** assert on whether or not `HasError` has been set (see [ErrorOr.h](https://github.com/llvm/llvm-project/blob/328f40f408c218f25695ea42c844e43bef38660b/llvm/include/llvm/Support/ErrorOr.h#L235-L243)). However, it seems this wasn't executed, probably because the LLDB was a release build. # Fix The fix is simply remove the `*` in the said `if` statement.

This was removed in llvm/llvm-project#135343 in favour of making it a format variable, which we do here. This follows the precedent of the `[opt]` and `[artificial]` markers. Before: ``` thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.2 * frame #0: 0x000000010000037c a.out`inlined1() at inline.cpp:4:3 frame #1: 0x000000010000037c a.out`regular() at inline.cpp:6:17 frame #2: 0x00000001000003b8 a.out`inlined2() at inline.cpp:7:43 frame #3: 0x00000001000003b4 a.out`main at inline.cpp:10:3 frame #4: 0x0000000186345be4 dyld`start + 7040 ``` After (note the `[inlined]` markers): ``` thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.2 * frame #0: 0x000000010000037c a.out`inlined1() at inline.cpp:4:3 [inlined] frame #1: 0x000000010000037c a.out`regular() at inline.cpp:6:17 frame #2: 0x00000001000003b8 a.out`inlined2() at inline.cpp:7:43 [inlined] frame #3: 0x00000001000003b4 a.out`main at inline.cpp:10:3 frame #4: 0x0000000186345be4 dyld`start + 7040 ``` rdar://152642178

…ames (#142952) This was removed in llvm/llvm-project#135343 in favour of making it a format variable, which we do here. This follows the precedent of the `[opt]` and `[artificial]` markers. Before: ``` thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.2 * frame #0: 0x000000010000037c a.out`inlined1() at inline.cpp:4:3 frame #1: 0x000000010000037c a.out`regular() at inline.cpp:6:17 frame #2: 0x00000001000003b8 a.out`inlined2() at inline.cpp:7:43 frame #3: 0x00000001000003b4 a.out`main at inline.cpp:10:3 frame #4: 0x0000000186345be4 dyld`start + 7040 ``` After (note the `[inlined]` markers): ``` thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.2 * frame #0: 0x000000010000037c a.out`inlined1() at inline.cpp:4:3 [inlined] frame #1: 0x000000010000037c a.out`regular() at inline.cpp:6:17 frame #2: 0x00000001000003b8 a.out`inlined2() at inline.cpp:7:43 [inlined] frame #3: 0x00000001000003b4 a.out`main at inline.cpp:10:3 frame #4: 0x0000000186345be4 dyld`start + 7040 ``` rdar://152642178

These were failing on our Windows on Arm bot, or more precisely, not even completing. This is because Microsoft's C runtime does extra parameter validation. So when we called _read with an invalid fd, it called an invalid parameter handler instead of returning an error. https://learn.microsoft.com/en-us/%20cpp/c-runtime-library/reference/read?view=msvc-170 https://learn.microsoft.com/en-us/%20cpp/c-runtime-library/parameter-validation?view=msvc-170 (lldb) run Process 8440 launched: 'C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\tools\lldb\unittests\Host\HostTests.exe' (aarch64) Process 8440 stopped * thread #1, stop reason = Exception 0xc0000409 encountered at address 0x7ffb7453564c frame #0: 0x00007ffb7453564c ucrtbase.dll`_get_thread_local_invalid_parameter_handler + 652 ucrtbase.dll`_get_thread_local_invalid_parameter_handler: -> 0x7ffb7453564c <+652>: brk #0xf003 ucrtbase.dll`_invalid_parameter_noinfo: 0x7ffb74535650 <+0>: b 0x7ffb745354d8 ; _get_thread_local_invalid_parameter_handler + 280 0x7ffb74535654 <+4>: nop 0x7ffb74535658 <+8>: nop You can override this handler but I'm assuming that this reading after close isn't a crucial feature, so disabling the tests seems like the way to go. If it is crucial, we can check the fd before we use it. Tests added by llvm/llvm-project#143946.

…indows These were failing on our Windows on Arm bot, or more precisely, not even completing. This is because Microsoft's C runtime does extra parameter validation. So when we called _read with an invalid fd, it called an invalid parameter handler instead of returning an error. https://learn.microsoft.com/en-us/%20cpp/c-runtime-library/reference/read?view=msvc-170 https://learn.microsoft.com/en-us/%20cpp/c-runtime-library/parameter-validation?view=msvc-170 (lldb) run Process 8440 launched: 'C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\tools\lldb\unittests\Host\HostTests.exe' (aarch64) Process 8440 stopped * thread #1, stop reason = Exception 0xc0000409 encountered at address 0x7ffb7453564c frame #0: 0x00007ffb7453564c ucrtbase.dll`_get_thread_local_invalid_parameter_handler + 652 ucrtbase.dll`_get_thread_local_invalid_parameter_handler: -> 0x7ffb7453564c <+652>: brk #0xf003 ucrtbase.dll`_invalid_parameter_noinfo: 0x7ffb74535650 <+0>: b 0x7ffb745354d8 ; _get_thread_local_invalid_parameter_handler + 280 0x7ffb74535654 <+4>: nop 0x7ffb74535658 <+8>: nop You can override this handler but I'm assuming that this reading after close isn't a crucial feature, so disabling the tests seems like the way to go. If it is crucial, we can check the fd before we use it. Tests added by llvm/llvm-project#143946.

# Benefit This patch fixes: 1. After `platform select ios-simulator`, `platform process list` will now print processes which are running in the iOS simulator. Previously, no process will be listed. 2. After `platform select ios-simulator`, `platform attach --name <name>` will succeed. Previously, it will error out saying no process is found. # Several bugs that is being fixed 1. During the process listing, add `aarch64` to the list of CPU types for which iOS simulators are checked for. 2. Given a candidate process, when checking for simulators, the original code will find the desired environment variable (`SIMULATOR_UDID`) and set the OS to iOS, but then the immediate next environment variable will set it back to macOS. 3. For processes running on simulator, set the triple's `Environment` to `Simulator`, so that such processes can pass the filtering [in this line](https://fburl.com/8nivnrjx). The original code leave it as the default `UnknownEnvironment`. # Manual test **With this patch:** ``` royshi-mac-home ~/public_llvm/build % bin/lldb (lldb) platform select ios-simulator (lldb) platform process list 240 matching processes were found on "ios-simulator" PID PARENT USER TRIPLE NAME ====== ====== ========== ============================== ============================ 40511 28844 royshi arm64-apple-ios-simulator FocusPlayground // my toy iOS app running on simulator ... // omit 28844 1 royshi arm64-apple-ios-simulator launchd_sim (lldb) process attach --name FocusPlayground Process 40511 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP frame #0: 0x0000000104e3cb70 libsystem_kernel.dylib`mach_msg2_trap + 8 libsystem_kernel.dylib`mach_msg2_trap: -> 0x104e3cb70 <+8>: ret ... // omit ``` **Without this patch:** ``` $ bin/lldb (lldb) platform select ios-simulator (lldb) platform process list error: no processes were found on the "ios-simulator" platform (lldb) process attach --name FocusPlayground error: attach failed: could not find a process named FocusPlayground ``` # Unittest See PR.

The function already exposes a work list to avoid deep recursion, this commit starts utilizing it in a helper that could also lead to a deep recursion. We have observed this crash on `clang/test/C/C99/n590.c` with our internal builds that enable aggressive optimizations and hit the limit earlier than default release builds of Clang. See the added test for an example with a deeper recursion that used to crash in upstream Clang before this change with the following stack trace: ``` #0 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /usr/local/google/home/ibiryukov/code/llvm-project/llvm/lib/Support/Unix/Signals.inc:804:13 #1 llvm::sys::RunSignalHandlers() /usr/local/google/home/ibiryukov/code/llvm-project/llvm/lib/Support/Signals.cpp:106:18 #2 SignalHandler(int, siginfo_t*, void*) /usr/local/google/home/ibiryukov/code/llvm-project/llvm/lib/Support/Unix/Signals.inc:0:3 #3 (/lib/x86_64-linux-gnu/libc.so.6+0x3fdf0) #4 AnalyzeImplicitConversions(clang::Sema&, clang::Expr*, clang::SourceLocation, bool) /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:12772:0 #5 CheckCommaOperand /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:0:3 #6 AnalyzeImplicitConversions /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:12644:7 #7 AnalyzeImplicitConversions(clang::Sema&, clang::Expr*, clang::SourceLocation, bool) /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:12776:5 #8 CheckCommaOperand /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:0:3 #9 AnalyzeImplicitConversions /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:12644:7 #10 AnalyzeImplicitConversions(clang::Sema&, clang::Expr*, clang::SourceLocation, bool) /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:12776:5 #11 CheckCommaOperand /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:0:3 #12 AnalyzeImplicitConversions /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:12644:7 #13 AnalyzeImplicitConversions(clang::Sema&, clang::Expr*, clang::SourceLocation, bool) /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:12776:5 #14 CheckCommaOperand /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:0:3 #15 AnalyzeImplicitConversions /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:12644:7 #16 AnalyzeImplicitConversions(clang::Sema&, clang::Expr*, clang::SourceLocation, bool) /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:12776:5 #17 CheckCommaOperand /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:0:3 #18 AnalyzeImplicitConversions /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:12644:7 #19 AnalyzeImplicitConversions(clang::Sema&, clang::Expr*, clang::SourceLocation, bool) /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:12776:5 ... 700+ more stack frames. ```

…(#145734) The function already exposes a work list to avoid deep recursion, this commit starts utilizing it in a helper that could also lead to a deep recursion. We have observed this crash on `clang/test/C/C99/n590.c` with our internal builds that enable aggressive optimizations and hit the limit earlier than default release builds of Clang. See the added test for an example with a deeper recursion that used to crash in upstream Clang before this change with the following stack trace: ``` #0 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /usr/local/google/home/ibiryukov/code/llvm-project/llvm/lib/Support/Unix/Signals.inc:804:13 #1 llvm::sys::RunSignalHandlers() /usr/local/google/home/ibiryukov/code/llvm-project/llvm/lib/Support/Signals.cpp:106:18 #2 SignalHandler(int, siginfo_t*, void*) /usr/local/google/home/ibiryukov/code/llvm-project/llvm/lib/Support/Unix/Signals.inc:0:3 #3 (/lib/x86_64-linux-gnu/libc.so.6+0x3fdf0) #4 AnalyzeImplicitConversions(clang::Sema&, clang::Expr*, clang::SourceLocation, bool) /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:12772:0 #5 CheckCommaOperand /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:0:3 #6 AnalyzeImplicitConversions /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:12644:7 #7 AnalyzeImplicitConversions(clang::Sema&, clang::Expr*, clang::SourceLocation, bool) /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:12776:5 #8 CheckCommaOperand /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:0:3 #9 AnalyzeImplicitConversions /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:12644:7 #10 AnalyzeImplicitConversions(clang::Sema&, clang::Expr*, clang::SourceLocation, bool) /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:12776:5 #11 CheckCommaOperand /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:0:3 #12 AnalyzeImplicitConversions /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:12644:7 #13 AnalyzeImplicitConversions(clang::Sema&, clang::Expr*, clang::SourceLocation, bool) /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:12776:5 #14 CheckCommaOperand /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:0:3 #15 AnalyzeImplicitConversions /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:12644:7 #16 AnalyzeImplicitConversions(clang::Sema&, clang::Expr*, clang::SourceLocation, bool) /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:12776:5 #17 CheckCommaOperand /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:0:3 #18 AnalyzeImplicitConversions /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:12644:7 #19 AnalyzeImplicitConversions(clang::Sema&, clang::Expr*, clang::SourceLocation, bool) /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:12776:5 ... 700+ more stack frames. ```

Fix unnecessary conversion of C-String to StringRef in the `Cmp` lambda inside `lookupLLVMIntrinsicByName`. This both fixes an ASAN error in the code that happens when the `Name` StringRef passed in is not a Null terminated StringRef, and additionally can potentially speed up the code as well by eliminating the unnecessary computation of string length every time a C String is converted to StringRef in this code (It seems practically this computation is eliminated in optimized builds, but this will avoid it in O0 builds as well). Added a unit test that demonstrates this issue by building LLVM with these options: ``` CMAKE_BUILD_TYPE=Debug LLVM_USE_SANITIZER=Address LLVM_OPTIMIZE_SANITIZED_BUILDS=OFF ``` The error reported is as follows: ``` ==462665==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x5030000391a2 at pc 0x56525cc30bbf bp 0x7fff9e4ccc60 sp 0x7fff9e4cc428 READ of size 19 at 0x5030000391a2 thread T0 #0 0x56525cc30bbe in strlen (upstream-llvm-second/llvm-project/build/unittests/IR/IRTests+0x713bbe) (BuildId: 0651acf1e582a4d2) #1 0x7f8ff22ad334 in std::char_traits<char>::length(char const*) /usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/char_traits.h:399:9 #2 0x7f8ff22a34a0 in llvm::StringRef::StringRef(char const*) /home/rjoshi/upstream-llvm-second/llvm-project/llvm/include/llvm/ADT/StringRef.h:96:33 #3 0x7f8ff28ca184 in _ZZL25lookupLLVMIntrinsicByNameN4llvm8ArrayRefIjEENS_9StringRefES2_ENK3$_0clIjPKcEEDaT_T0_ upstream-llvm-second/llvm-project/llvm/lib/IR/Intrinsics.cpp:673:18 ```

…147444) Fix unnecessary conversion of C-String to StringRef in the `Cmp` lambda inside `lookupLLVMIntrinsicByName`. This both fixes an ASAN error in the code that happens when the `Name` StringRef passed in is not a Null terminated StringRef, and additionally can potentially speed up the code as well by eliminating the unnecessary computation of string length every time a C String is converted to StringRef in this code (It seems practically this computation is eliminated in optimized builds, but this will avoid it in O0 builds as well). Added a unit test that demonstrates this issue by building LLVM with these options: ``` CMAKE_BUILD_TYPE=Debug LLVM_USE_SANITIZER=Address LLVM_OPTIMIZE_SANITIZED_BUILDS=OFF ``` The error reported is as follows: ``` ==462665==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x5030000391a2 at pc 0x56525cc30bbf bp 0x7fff9e4ccc60 sp 0x7fff9e4cc428 READ of size 19 at 0x5030000391a2 thread T0 #0 0x56525cc30bbe in strlen (upstream-llvm-second/llvm-project/build/unittests/IR/IRTests+0x713bbe) (BuildId: 0651acf1e582a4d2) #1 0x7f8ff22ad334 in std::char_traits<char>::length(char const*) /usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/char_traits.h:399:9 #2 0x7f8ff22a34a0 in llvm::StringRef::StringRef(char const*) /home/rjoshi/upstream-llvm-second/llvm-project/llvm/include/llvm/ADT/StringRef.h:96:33 #3 0x7f8ff28ca184 in _ZZL25lookupLLVMIntrinsicByNameN4llvm8ArrayRefIjEENS_9StringRefES2_ENK3$_0clIjPKcEEDaT_T0_ upstream-llvm-second/llvm-project/llvm/lib/IR/Intrinsics.cpp:673:18 ```

…148205) In the original motivating test case, [FoldList](https://github.com/llvm/llvm-project/blob/d8a2141ff98ee35cd1886f536ccc3548b012820b/llvm/lib/Target/AMDGPU/SIFoldOperands.cpp#L1764) had entries: ``` #0: UseMI: %224:sreg_32 = S_OR_B32 %219.sub0:sreg_64, %219.sub1:sreg_64, implicit-def dead $scc UseOpNo: 1 #1: UseMI: %224:sreg_32 = S_OR_B32 %219.sub0:sreg_64, %219.sub1:sreg_64, implicit-def dead $scc UseOpNo: 2 ``` After calling [updateOperand(#0)](https://github.com/llvm/llvm-project/blob/d8a2141ff98ee35cd1886f536ccc3548b012820b/llvm/lib/Target/AMDGPU/SIFoldOperands.cpp#L1773), [tryConstantFoldOp(#0.UseMI)](https://github.com/llvm/llvm-project/blob/d8a2141ff98ee35cd1886f536ccc3548b012820b/llvm/lib/Target/AMDGPU/SIFoldOperands.cpp#L1786) removed operand 1, and entry #1.UseOpNo was no longer valid, resulting in an [assert](https://github.com/llvm/llvm-project/blob/4a35214bddbb67f9597a500d48ab8c4fb25af150/llvm/include/llvm/ADT/ArrayRef.h#L452). This change defers constant folding until all operands have been updated so that UseOpNo values remain stable.

…ding imm (#148205) In the original motivating test case, [FoldList](https://github.com/llvm/llvm-project/blob/d8a2141ff98ee35cd1886f536ccc3548b012820b/llvm/lib/Target/AMDGPU/SIFoldOperands.cpp#L1764) had entries: ``` #0: UseMI: %224:sreg_32 = S_OR_B32 %219.sub0:sreg_64, %219.sub1:sreg_64, implicit-def dead $scc UseOpNo: 1 #1: UseMI: %224:sreg_32 = S_OR_B32 %219.sub0:sreg_64, %219.sub1:sreg_64, implicit-def dead $scc UseOpNo: 2 ``` After calling [updateOperand(#0)](https://github.com/llvm/llvm-project/blob/d8a2141ff98ee35cd1886f536ccc3548b012820b/llvm/lib/Target/AMDGPU/SIFoldOperands.cpp#L1773), [tryConstantFoldOp(#0.UseMI)](https://github.com/llvm/llvm-project/blob/d8a2141ff98ee35cd1886f536ccc3548b012820b/llvm/lib/Target/AMDGPU/SIFoldOperands.cpp#L1786) removed operand 1, and entry #1.UseOpNo was no longer valid, resulting in an [assert](https://github.com/llvm/llvm-project/blob/4a35214bddbb67f9597a500d48ab8c4fb25af150/llvm/include/llvm/ADT/ArrayRef.h#L452). This change defers constant folding until all operands have been updated so that UseOpNo values remain stable.

Extend support in LLDB for WebAssembly. This PR adds a new Process plugin (ProcessWasm) that extends ProcessGDBRemote for WebAssembly targets. It adds support for WebAssembly's memory model with separate address spaces, and the ability to fetch the call stack from the WebAssembly runtime. I have tested this change with the WebAssembly Micro Runtime (WAMR, https://github.com/bytecodealliance/wasm-micro-runtime) which implements a GDB debug stub and supports the qWasmCallStack packet. ``` (lldb) process connect --plugin wasm connect://localhost:4567 Process 1 stopped * thread #1, name = 'nobody', stop reason = trace frame #0: 0x40000000000001ad wasm32_args.wasm`main: -> 0x40000000000001ad <+3>: global.get 0 0x40000000000001b3 <+9>: i32.const 16 0x40000000000001b5 <+11>: i32.sub 0x40000000000001b6 <+12>: local.set 0 (lldb) b add Breakpoint 1: where = wasm32_args.wasm`add + 28 at test.c:4:12, address = 0x400000000000019c (lldb) c Process 1 resuming Process 1 stopped * thread #1, name = 'nobody', stop reason = breakpoint 1.1 frame #0: 0x400000000000019c wasm32_args.wasm`add(a=<unavailable>, b=<unavailable>) at test.c:4:12 1 int 2 add(int a, int b) 3 { -> 4 return a + b; 5 } 6 7 int (lldb) bt * thread #1, name = 'nobody', stop reason = breakpoint 1.1 * frame #0: 0x400000000000019c wasm32_args.wasm`add(a=<unavailable>, b=<unavailable>) at test.c:4:12 frame #1: 0x40000000000001e5 wasm32_args.wasm`main at test.c:12:12 frame #2: 0x40000000000001fe wasm32_args.wasm ``` This PR is based on an unmerged patch from Paolo Severini: https://reviews.llvm.org/D78801. I intentionally stuck to the foundations to keep this PR small. I have more PRs in the pipeline to support the other features/packets. My motivation for supporting Wasm is to support debugging Swift compiled to WebAssembly: https://www.swift.org/documentation/articles/wasm-getting-started.html

…erver (#148774) Summary: There was a deadlock was introduced by [PR #146441](llvm/llvm-project#146441) which changed `CurrentThreadIsPrivateStateThread()` to `CurrentThreadPosesAsPrivateStateThread()`. This change caused the execution path in [`ExecutionContextRef::SetTargetPtr()`](https://github.com/llvm/llvm-project/blob/10b5558b61baab59c7d3dff37ffdf0861c0cc67a/lldb/source/Target/ExecutionContext.cpp#L513) to now enter a code block that was previously skipped, triggering [`GetSelectedFrame()`](https://github.com/llvm/llvm-project/blob/10b5558b61baab59c7d3dff37ffdf0861c0cc67a/lldb/source/Target/ExecutionContext.cpp#L522) which leads to a deadlock. Thread 1 gets m_modules_mutex in [`ModuleList::AppendImpl`](https://github.com/llvm/llvm-project/blob/96148f92146e5211685246722664e51ec730e7ba/lldb/source/Core/ModuleList.cpp#L218), Thread 3 gets m_language_runtimes_mutex in [`GetLanguageRuntime`](https://github.com/llvm/llvm-project/blob/96148f92146e5211685246722664e51ec730e7ba/lldb/source/Target/Process.cpp#L1501), but then Thread 1 waits for m_language_runtimes_mutex in [`GetLanguageRuntime`](https://github.com/llvm/llvm-project/blob/96148f92146e5211685246722664e51ec730e7ba/lldb/source/Target/Process.cpp#L1501) while Thread 3 waits for m_modules_mutex in [`ScanForGNUstepObjCLibraryCandidate`](https://github.com/llvm/llvm-project/blob/96148f92146e5211685246722664e51ec730e7ba/lldb/source/Plugins/LanguageRuntime/ObjC/GNUstepObjCRuntime/GNUstepObjCRuntime.cpp#L57). This fixes the deadlock by adding a scoped block around the mutex lock before the call to the notifier, and moved the notifier call outside of the mutex-guarded section. The notifier call [`NotifyModuleAdded`](https://github.com/llvm/llvm-project/blob/96148f92146e5211685246722664e51ec730e7ba/lldb/source/Target/Target.cpp#L1810) should be thread-safe, since the module should be added to the `ModuleList` before the mutex is released, and the notifier doesn't modify the module list further, and the call is operates on local state and the `Target` instance. ### Deadlocked Thread backtraces: ``` * thread #3, name = 'dbg.evt-handler', stop reason = signal SIGSTOP * frame #0: 0x00007f2f1e2973dc libc.so.6`futex_wait(private=0, expected=2, futex_word=0x0000563786bd5f40) at futex-internal.h:146:13 /*... a bunch of mutex related bt ... */ liblldb.so.21.0git`std::lock_guard<std::recursive_mutex>::lock_guard(this=0x00007f2f0f1927b0, __m=0x0000563786bd5f40) at std_mutex.h:229:19 frame #8: 0x00007f2f27946eb7 liblldb.so.21.0git`ScanForGNUstepObjCLibraryCandidate(modules=0x0000563786bd5f28, TT=0x0000563786bd5eb8) at GNUstepObjCRuntime.cpp:60:41 frame #9: 0x00007f2f27946c80 liblldb.so.21.0git`lldb_private::GNUstepObjCRuntime::CreateInstance(process=0x0000563785e1d360, language=eLanguageTypeObjC) at GNUstepObjCRuntime.cpp:87:8 frame #10: 0x00007f2f2746fca5 liblldb.so.21.0git`lldb_private::LanguageRuntime::FindPlugin(process=0x0000563785e1d360, language=eLanguageTypeObjC) at LanguageRuntime.cpp:210:36 frame #11: 0x00007f2f2742c9e3 liblldb.so.21.0git`lldb_private::Process::GetLanguageRuntime(this=0x0000563785e1d360, language=eLanguageTypeObjC) at Process.cpp:1516:9 ... frame #21: 0x00007f2f2750b5cc liblldb.so.21.0git`lldb_private::Thread::GetSelectedFrame(this=0x0000563785e064d0, select_most_relevant=DoNoSelectMostRelevantFrame) at Thread.cpp:274:48 frame #22: 0x00007f2f273f9957 liblldb.so.21.0git`lldb_private::ExecutionContextRef::SetTargetPtr(this=0x00007f2f0f193778, target=0x0000563786bd5be0, adopt_selected=true) at ExecutionContext.cpp:525:32 frame #23: 0x00007f2f273f9714 liblldb.so.21.0git`lldb_private::ExecutionContextRef::ExecutionContextRef(this=0x00007f2f0f193778, target=0x0000563786bd5be0, adopt_selected=true) at ExecutionContext.cpp:413:3 frame #24: 0x00007f2f270e80af liblldb.so.21.0git`lldb_private::Debugger::GetSelectedExecutionContext(this=0x0000563785d83bc0) at Debugger.cpp:1225:23 frame #25: 0x00007f2f271bb7fd liblldb.so.21.0git`lldb_private::Statusline::Redraw(this=0x0000563785d83f30, update=true) at Statusline.cpp:136:41 ... * thread #1, name = 'lldb', stop reason = signal SIGSTOP * frame #0: 0x00007f2f1e2973dc libc.so.6`futex_wait(private=0, expected=2, futex_word=0x0000563785e1dd98) at futex-internal.h:146:13 /*... a bunch of mutex related bt ... */ liblldb.so.21.0git`std::lock_guard<std::recursive_mutex>::lock_guard(this=0x00007ffe62be0488, __m=0x0000563785e1dd98) at std_mutex.h:229:19 frame #8: 0x00007f2f2742c8d1 liblldb.so.21.0git`lldb_private::Process::GetLanguageRuntime(this=0x0000563785e1d360, language=eLanguageTypeC_plus_plus) at Process.cpp:1510:41 frame #9: 0x00007f2f2743c46f liblldb.so.21.0git`lldb_private::Process::ModulesDidLoad(this=0x0000563785e1d360, module_list=0x00007ffe62be06a0) at Process.cpp:6082:36 ... frame #13: 0x00007f2f2715cf03 liblldb.so.21.0git`lldb_private::ModuleList::AppendImpl(this=0x0000563786bd5f28, module_sp=ptr = 0x563785cec560, use_notifier=true) at ModuleList.cpp:246:19 frame #14: 0x00007f2f2715cf4c liblldb.so.21.0git`lldb_private::ModuleList::Append(this=0x0000563786bd5f28, module_sp=ptr = 0x563785cec560, notify=true) at ModuleList.cpp:251:3 ... frame #19: 0x00007f2f274349b3 liblldb.so.21.0git`lldb_private::Process::ConnectRemote(this=0x0000563785e1d360, remote_url=(Data = "connect://localhost:1234", Length = 24)) at Process.cpp:3250:9 frame #20: 0x00007f2f27411e0e liblldb.so.21.0git`lldb_private::Platform::DoConnectProcess(this=0x0000563785c59990, connect_url=(Data = "connect://localhost:1234", Length = 24), plugin_name=(Data = "gdb-remote", Length = 10), debugger=0x0000563785d83bc0, stream=0x00007ffe62be3128, target=0x0000563786bd5be0, error=0x00007ffe62be1ca0) at Platform.cpp:1926:23 ``` ## Test Plan: Built a hello world a.out Run server in one terminal: ``` ~/llvm/build/Debug/bin/lldb-server g :1234 a.out ``` Run client in another terminal ``` ~/llvm/build/Debug/bin/lldb -o "gdb-remote 1234" -o "b hello.cc:3" ``` Before: Client hangs indefinitely ``` ~/llvm/build/Debug/bin/lldb -o "gdb-remote 1234" -o "b main" (lldb) gdb-remote 1234 ^C^C ``` After: ``` ~/llvm/build/Debug/bin/lldb -o "gdb-remote 1234" -o "b hello.cc:3" (lldb) gdb-remote 1234 Process 837068 stopped * thread #1, name = 'a.out', stop reason = signal SIGSTOP frame #0: 0x00007ffff7fe4a60 ld-linux-x86-64.so.2`_start: -> 0x7ffff7fe4a60 <+0>: movq %rsp, %rdi 0x7ffff7fe4a63 <+3>: callq 0x7ffff7fe5780 ; _dl_start at rtld.c:522:1 ld-linux-x86-64.so.2`_dl_start_user: 0x7ffff7fe4a68 <+0>: movq %rax, %r12 0x7ffff7fe4a6b <+3>: movl 0x18067(%rip), %eax ; _dl_skip_args (lldb) b hello.cc:3 Breakpoint 1: where = a.out`main + 15 at hello.cc:4:13, address = 0x00005555555551bf (lldb) c Process 837068 resuming Process 837068 stopped * thread #1, name = 'a.out', stop reason = breakpoint 1.1 frame #0: 0x00005555555551bf a.out`main at hello.cc:4:13 1 #include <iostream> 2 3 int main() { -> 4 std::cout << "Hello World" << std::endl; 5 return 0; 6 } ```

…db client/server (#148774) Summary: There was a deadlock was introduced by [PR #146441](llvm/llvm-project#146441) which changed `CurrentThreadIsPrivateStateThread()` to `CurrentThreadPosesAsPrivateStateThread()`. This change caused the execution path in [`ExecutionContextRef::SetTargetPtr()`](https://github.com/llvm/llvm-project/blob/10b5558b61baab59c7d3dff37ffdf0861c0cc67a/lldb/source/Target/ExecutionContext.cpp#L513) to now enter a code block that was previously skipped, triggering [`GetSelectedFrame()`](https://github.com/llvm/llvm-project/blob/10b5558b61baab59c7d3dff37ffdf0861c0cc67a/lldb/source/Target/ExecutionContext.cpp#L522) which leads to a deadlock. Thread 1 gets m_modules_mutex in [`ModuleList::AppendImpl`](https://github.com/llvm/llvm-project/blob/96148f92146e5211685246722664e51ec730e7ba/lldb/source/Core/ModuleList.cpp#L218), Thread 3 gets m_language_runtimes_mutex in [`GetLanguageRuntime`](https://github.com/llvm/llvm-project/blob/96148f92146e5211685246722664e51ec730e7ba/lldb/source/Target/Process.cpp#L1501), but then Thread 1 waits for m_language_runtimes_mutex in [`GetLanguageRuntime`](https://github.com/llvm/llvm-project/blob/96148f92146e5211685246722664e51ec730e7ba/lldb/source/Target/Process.cpp#L1501) while Thread 3 waits for m_modules_mutex in [`ScanForGNUstepObjCLibraryCandidate`](https://github.com/llvm/llvm-project/blob/96148f92146e5211685246722664e51ec730e7ba/lldb/source/Plugins/LanguageRuntime/ObjC/GNUstepObjCRuntime/GNUstepObjCRuntime.cpp#L57). This fixes the deadlock by adding a scoped block around the mutex lock before the call to the notifier, and moved the notifier call outside of the mutex-guarded section. The notifier call [`NotifyModuleAdded`](https://github.com/llvm/llvm-project/blob/96148f92146e5211685246722664e51ec730e7ba/lldb/source/Target/Target.cpp#L1810) should be thread-safe, since the module should be added to the `ModuleList` before the mutex is released, and the notifier doesn't modify the module list further, and the call is operates on local state and the `Target` instance. ### Deadlocked Thread backtraces: ``` * thread #3, name = 'dbg.evt-handler', stop reason = signal SIGSTOP * frame #0: 0x00007f2f1e2973dc libc.so.6`futex_wait(private=0, expected=2, futex_word=0x0000563786bd5f40) at futex-internal.h:146:13 /*... a bunch of mutex related bt ... */ liblldb.so.21.0git`std::lock_guard<std::recursive_mutex>::lock_guard(this=0x00007f2f0f1927b0, __m=0x0000563786bd5f40) at std_mutex.h:229:19 frame #8: 0x00007f2f27946eb7 liblldb.so.21.0git`ScanForGNUstepObjCLibraryCandidate(modules=0x0000563786bd5f28, TT=0x0000563786bd5eb8) at GNUstepObjCRuntime.cpp:60:41 frame #9: 0x00007f2f27946c80 liblldb.so.21.0git`lldb_private::GNUstepObjCRuntime::CreateInstance(process=0x0000563785e1d360, language=eLanguageTypeObjC) at GNUstepObjCRuntime.cpp:87:8 frame #10: 0x00007f2f2746fca5 liblldb.so.21.0git`lldb_private::LanguageRuntime::FindPlugin(process=0x0000563785e1d360, language=eLanguageTypeObjC) at LanguageRuntime.cpp:210:36 frame #11: 0x00007f2f2742c9e3 liblldb.so.21.0git`lldb_private::Process::GetLanguageRuntime(this=0x0000563785e1d360, language=eLanguageTypeObjC) at Process.cpp:1516:9 ... frame #21: 0x00007f2f2750b5cc liblldb.so.21.0git`lldb_private::Thread::GetSelectedFrame(this=0x0000563785e064d0, select_most_relevant=DoNoSelectMostRelevantFrame) at Thread.cpp:274:48 frame #22: 0x00007f2f273f9957 liblldb.so.21.0git`lldb_private::ExecutionContextRef::SetTargetPtr(this=0x00007f2f0f193778, target=0x0000563786bd5be0, adopt_selected=true) at ExecutionContext.cpp:525:32 frame #23: 0x00007f2f273f9714 liblldb.so.21.0git`lldb_private::ExecutionContextRef::ExecutionContextRef(this=0x00007f2f0f193778, target=0x0000563786bd5be0, adopt_selected=true) at ExecutionContext.cpp:413:3 frame #24: 0x00007f2f270e80af liblldb.so.21.0git`lldb_private::Debugger::GetSelectedExecutionContext(this=0x0000563785d83bc0) at Debugger.cpp:1225:23 frame #25: 0x00007f2f271bb7fd liblldb.so.21.0git`lldb_private::Statusline::Redraw(this=0x0000563785d83f30, update=true) at Statusline.cpp:136:41 ... * thread #1, name = 'lldb', stop reason = signal SIGSTOP * frame #0: 0x00007f2f1e2973dc libc.so.6`futex_wait(private=0, expected=2, futex_word=0x0000563785e1dd98) at futex-internal.h:146:13 /*... a bunch of mutex related bt ... */ liblldb.so.21.0git`std::lock_guard<std::recursive_mutex>::lock_guard(this=0x00007ffe62be0488, __m=0x0000563785e1dd98) at std_mutex.h:229:19 frame #8: 0x00007f2f2742c8d1 liblldb.so.21.0git`lldb_private::Process::GetLanguageRuntime(this=0x0000563785e1d360, language=eLanguageTypeC_plus_plus) at Process.cpp:1510:41 frame #9: 0x00007f2f2743c46f liblldb.so.21.0git`lldb_private::Process::ModulesDidLoad(this=0x0000563785e1d360, module_list=0x00007ffe62be06a0) at Process.cpp:6082:36 ... frame #13: 0x00007f2f2715cf03 liblldb.so.21.0git`lldb_private::ModuleList::AppendImpl(this=0x0000563786bd5f28, module_sp=ptr = 0x563785cec560, use_notifier=true) at ModuleList.cpp:246:19 frame #14: 0x00007f2f2715cf4c liblldb.so.21.0git`lldb_private::ModuleList::Append(this=0x0000563786bd5f28, module_sp=ptr = 0x563785cec560, notify=true) at ModuleList.cpp:251:3 ... frame #19: 0x00007f2f274349b3 liblldb.so.21.0git`lldb_private::Process::ConnectRemote(this=0x0000563785e1d360, remote_url=(Data = "connect://localhost:1234", Length = 24)) at Process.cpp:3250:9 frame #20: 0x00007f2f27411e0e liblldb.so.21.0git`lldb_private::Platform::DoConnectProcess(this=0x0000563785c59990, connect_url=(Data = "connect://localhost:1234", Length = 24), plugin_name=(Data = "gdb-remote", Length = 10), debugger=0x0000563785d83bc0, stream=0x00007ffe62be3128, target=0x0000563786bd5be0, error=0x00007ffe62be1ca0) at Platform.cpp:1926:23 ``` ## Test Plan: Built a hello world a.out Run server in one terminal: ``` ~/llvm/build/Debug/bin/lldb-server g :1234 a.out ``` Run client in another terminal ``` ~/llvm/build/Debug/bin/lldb -o "gdb-remote 1234" -o "b hello.cc:3" ``` Before: Client hangs indefinitely ``` ~/llvm/build/Debug/bin/lldb -o "gdb-remote 1234" -o "b main" (lldb) gdb-remote 1234 ^C^C ``` After: ``` ~/llvm/build/Debug/bin/lldb -o "gdb-remote 1234" -o "b hello.cc:3" (lldb) gdb-remote 1234 Process 837068 stopped * thread #1, name = 'a.out', stop reason = signal SIGSTOP frame #0: 0x00007ffff7fe4a60 ld-linux-x86-64.so.2`_start: -> 0x7ffff7fe4a60 <+0>: movq %rsp, %rdi 0x7ffff7fe4a63 <+3>: callq 0x7ffff7fe5780 ; _dl_start at rtld.c:522:1 ld-linux-x86-64.so.2`_dl_start_user: 0x7ffff7fe4a68 <+0>: movq %rax, %r12 0x7ffff7fe4a6b <+3>: movl 0x18067(%rip), %eax ; _dl_skip_args (lldb) b hello.cc:3 Breakpoint 1: where = a.out`main + 15 at hello.cc:4:13, address = 0x00005555555551bf (lldb) c Process 837068 resuming Process 837068 stopped * thread #1, name = 'a.out', stop reason = breakpoint 1.1 frame #0: 0x00005555555551bf a.out`main at hello.cc:4:13 1 #include <iostream> 2 3 int main() { -> 4 std::cout << "Hello World" << std::endl; 5 return 0; 6 } ```

…152156) With this new A320 in-order core, we follow adding the FeatureUseFixedOverScalableIfEqualCost feature to A510 and A520 (#132246), which reaps the same code generation benefits of preferring fixed over scalable when the cost is equal. So when we have: ``` void foo(float* a, float* b, float* dst, unsigned n) { for (unsigned i = 0; i < n; ++i) dst[i] = a[i] + b[i]; } ``` When compiling without the feature enabled, we get: ``` ... ld1b { z0.b }, p0/z, [x0, x10] ld1b { z2.b }, p0/z, [x1, x10] add x12, x0, x10 ldr z1, [x12, #1, mul vl] add x12, x1, x10 ldr z3, [x12, #1, mul vl] fadd z0.s, z2.s, z0.s add x12, x2, x10 fadd z1.s, z3.s, z1.s dech x11 st1b { z0.b }, p0, [x2, x10] incb x10, all, mul #2 str z1, [x12, #1, mul vl] ... ``` When compiling with, we get: ``` ... ldp q0, q1, [x12, #-16] ldp q2, q3, [x11, #-16] subs x13, x13, #8 fadd v0.4s, v2.4s, v0.4s fadd v1.4s, v3.4s, v1.4s add x11, x11, #32 add x12, x12, #32 stp q0, q1, [x10, #-16] add x10, x10, #32 ... ```

…for A320 (#152156) With this new A320 in-order core, we follow adding the FeatureUseFixedOverScalableIfEqualCost feature to A510 and A520 (#132246), which reaps the same code generation benefits of preferring fixed over scalable when the cost is equal. So when we have: ``` void foo(float* a, float* b, float* dst, unsigned n) { for (unsigned i = 0; i < n; ++i) dst[i] = a[i] + b[i]; } ``` When compiling without the feature enabled, we get: ``` ... ld1b { z0.b }, p0/z, [x0, x10] ld1b { z2.b }, p0/z, [x1, x10] add x12, x0, x10 ldr z1, [x12, #1, mul vl] add x12, x1, x10 ldr z3, [x12, #1, mul vl] fadd z0.s, z2.s, z0.s add x12, x2, x10 fadd z1.s, z3.s, z1.s dech x11 st1b { z0.b }, p0, [x2, x10] incb x10, all, mul #2 str z1, [x12, #1, mul vl] ... ``` When compiling with, we get: ``` ... ldp q0, q1, [x12, #-16] ldp q2, q3, [x11, #-16] subs x13, x13, #8 fadd v0.4s, v2.4s, v0.4s fadd v1.4s, v3.4s, v1.4s add x11, x11, #32 add x12, x12, #32 stp q0, q1, [x10, #-16] add x10, x10, #32 ... ```

Downstream issue: arm#482 With this new A320 in-order core, we follow adding the FeatureUseFixedOverScalableIfEqualCost feature to A510 and A520 (#132246), which reaps the same code generation benefits of preferring fixed over scalable when the cost is equal. So when we have: ``` void foo(float* a, float* b, float* dst, unsigned n) { for (unsigned i = 0; i < n; ++i) dst[i] = a[i] + b[i]; } ``` When compiling without the feature enabled, we get: ``` ... ld1b { z0.b }, p0/z, [x0, x10] ld1b { z2.b }, p0/z, [x1, x10] add x12, x0, x10 ldr z1, [x12, arm#1, mul vl] add x12, x1, x10 ldr z3, [x12, arm#1, mul vl] fadd z0.s, z2.s, z0.s add x12, x2, x10 fadd z1.s, z3.s, z1.s dech x11 st1b { z0.b }, p0, [x2, x10] incb x10, all, mul arm#2 str z1, [x12, arm#1, mul vl] ... ``` When compiling with, we get: ``` ... ldp q0, q1, [x12, #-16] ldp q2, q3, [x11, #-16] subs x13, x13, arm#8 fadd v0.4s, v2.4s, v0.4s fadd v1.4s, v3.4s, v1.4s add x11, x11, arm#32 add x12, x12, arm#32 stp q0, q1, [x10, #-16] add x10, x10, arm#32 ... ``` This patch also moves FeatureUseFixedOverScalableIfEqualCost for A510 and A520 from the CPU features to the tune features.

) Downstream issue: #482 With this new A320 in-order core, we follow adding the FeatureUseFixedOverScalableIfEqualCost feature to A510 and A520 (#132246), which reaps the same code generation benefits of preferring fixed over scalable when the cost is equal. So when we have: ``` void foo(float* a, float* b, float* dst, unsigned n) { for (unsigned i = 0; i < n; ++i) dst[i] = a[i] + b[i]; } ``` When compiling without the feature enabled, we get: ``` ... ld1b { z0.b }, p0/z, [x0, x10] ld1b { z2.b }, p0/z, [x1, x10] add x12, x0, x10 ldr z1, [x12, #1, mul vl] add x12, x1, x10 ldr z3, [x12, #1, mul vl] fadd z0.s, z2.s, z0.s add x12, x2, x10 fadd z1.s, z3.s, z1.s dech x11 st1b { z0.b }, p0, [x2, x10] incb x10, all, mul #2 str z1, [x12, #1, mul vl] ... ``` When compiling with, we get: ``` ... ldp q0, q1, [x12, #-16] ldp q2, q3, [x11, #-16] subs x13, x13, #8 fadd v0.4s, v2.4s, v0.4s fadd v1.4s, v3.4s, v1.4s add x11, x11, #32 add x12, x12, #32 stp q0, q1, [x10, #-16] add x10, x10, #32 ... ``` This patch also moves FeatureUseFixedOverScalableIfEqualCost for A510 and A520 from the CPU features to the tune features.

M68k's SETCC instruction (`scc`) distinctly fills the destination byte with all 1s. If boolean contents are set to `ZeroOrOneBooleanContent`, LLVM can mistakenly think the destination holds `0x01` instead of `0xff` and emit broken code as a result. This change corrects the boolean content type to `ZeroOrNegativeOneBooleanContent`. For example, this IR: ```llvm define dso_local signext range(i8 0, 2) i8 @testBool(i32 noundef %a) local_unnamed_addr #0 { entry: %cmp = icmp eq i32 %a, 4660 %. = zext i1 %cmp to i8 ret i8 %. } ``` would previously build as: ```asm testBool: ; @testBool cmpi.l #4660, (4,%sp) seq %d0 and.l #255, %d0 rts ``` Notice the `zext` is erroneously not clearing the low bits, and thus the register returns with 255 instead of 1. This patch fixes the issue: ```asm testBool: ; @testBool cmpi.l #4660, (4,%sp) seq %d0 and.l #1, %d0 rts ``` Most of the tests containing `scc` suffered from the same value error as described above, so those tests have been updated to match the new output (which also logically corrects them).

dependabot bot added dependencies Pull requests that update a dependency file python Pull requests that update Python code labels Dec 17, 2024

pratlucas closed this Dec 17, 2024

pratlucas deleted the dependabot/pip/llvm/docs/llvm-docs-requirements-2e3265a506 branch December 17, 2024 17:09

Bump the llvm-docs-requirements group in /llvm/docs with 26 updates #1

Bump the llvm-docs-requirements group in /llvm/docs with 26 updates #1

Uh oh!

Conversation

dependabot bot commented on behalf of github Dec 17, 2024

Alabaster 1.0.0

Alabaster 0.7.16

Alabaster 0.7.15

Alabaster 0.7.14

:git_tag:1.0.0 -- 2024-07-26

:git_tag:0.7.16 -- 2024-01-10

:git_tag:0.7.15 -- 2024-01-08

:git_tag:0.7.14 -- 2024-01-08

Version 2.16.0

What's Changed

New Contributors

v2.15.0

What's Changed

Version 2.16.0

Version 2.15.0

Version 3.4.0

🚀 charset-normalizer is raising awareness around HTTP/2, and HTTP/3!

3.4.0 (2024-10-08)

Added

Fixed

3.4.0 (2024-10-08)

Added

Fixed

Changelog

2024.08.06 -- Energetic Eminence

2024.07.18 -- Dull Denim

2024.05.06 -- Cheerful Cerulean

2024.04.27 -- Bold Burgundy

2024.01.29 -- Amazing Amethyst

v3.10

v3.9

v3.8

What's Changed

v3.7

What's Changed

3.1.4

3.1.3

Version 3.1.4

Version 3.1.3

Release 3.7

Changed

Refactor abbr Extension

Fixed

Release 3.6

Changed

Refactor TOC Sanitation

[3.7] -- 2024-08-16

Changed

Refactor abbr Extension

Fixed

[3.6] -- 2024-03-14

Changed

Refactor TOC Sanitation

3.0.2

3.0.1

3.0.0

2.1.5

2.1.4

Version 3.0.2

Version 3.0.1

Version 3.0.0

Version 2.1.5

v0.4.2

What's Changed

New Contributors

v0.4.1

What's Changed

New Contributors

Uh oh!

dependabot bot commented on behalf of github Dec 17, 2024

Uh oh!

Uh oh!

:git_tag:`1.0.0` -- 2024-07-26

:git_tag:`0.7.16` -- 2024-01-10

:git_tag:`0.7.15` -- 2024-01-08

:git_tag:`0.7.14` -- 2024-01-08

Refactor `abbr` Extension

Refactor `abbr` Extension