Tags: carbon-language/carbon-lang
Tags
Bump certifi from 2023.11.17 to 2024.7.4 in /github_tools in the pip … …group across 1 directory (#4111) Bumps the pip group with 1 update in the /github_tools directory: [certifi](https://github.com/certifi/python-certifi). Updates `certifi` from 2023.11.17 to 2024.7.4 <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/certifi/python-certifi/commit/bd8153872e9c6fc98f4023df9c2deaffea2fa463"><code>bd81538</code></a> 2024.07.04 (<a href="https://redirect.github.com/certifi/python-certifi/issues/295">#295</a>)</li> <li><a href="https://github.com/certifi/python-certifi/commit/06a2cbf21f345563dde6c28b60e29d57e9b210b3"><code>06a2cbf</code></a> Bump peter-evans/create-pull-request from 6.0.5 to 6.1.0 (<a href="https://redirect.github.com/certifi/python-certifi/issues/294">#294</a>)</li> <li><a href="https://github.com/certifi/python-certifi/commit/13bba02b72bac97c432c277158bc04b4d2a6bc23"><code>13bba02</code></a> Bump actions/checkout from 4.1.6 to 4.1.7 (<a href="https://redirect.github.com/certifi/python-certifi/issues/293">#293</a>)</li> <li><a href="https://github.com/certifi/python-certifi/commit/e8abcd0e62b334c164b95d49fcabdc9ecbca0554"><code>e8abcd0</code></a> Bump pypa/gh-action-pypi-publish from 1.8.14 to 1.9.0 (<a href="https://redirect.github.com/certifi/python-certifi/issues/292">#292</a>)</li> <li><a href="https://github.com/certifi/python-certifi/commit/124f4adf171e15cd9a91a8b6e0325ecc97be8fe1"><code>124f4ad</code></a> 2024.06.02 (<a href="https://redirect.github.com/certifi/python-certifi/issues/291">#291</a>)</li> <li><a href="https://github.com/certifi/python-certifi/commit/c2196ce5d6ee675b27755a19948480a7823e2c6a"><code>c2196ce</code></a> --- (<a href="https://redirect.github.com/certifi/python-certifi/issues/290">#290</a>)</li> <li><a href="https://github.com/certifi/python-certifi/commit/fefdeec7588ff1c05214b85a552afcad5fdb51b2"><code>fefdeec</code></a> Bump actions/checkout from 4.1.4 to 4.1.5 (<a href="https://redirect.github.com/certifi/python-certifi/issues/289">#289</a>)</li> <li><a href="https://github.com/certifi/python-certifi/commit/3c5fb1560b826a7f83f1f9750173ff766492c9cf"><code>3c5fb15</code></a> Bump actions/download-artifact from 4.1.6 to 4.1.7 (<a href="https://redirect.github.com/certifi/python-certifi/issues/286">#286</a>)</li> <li><a href="https://github.com/certifi/python-certifi/commit/4a9569a3eb58db8548536fc16c5c5c7af946a5b1"><code>4a9569a</code></a> Bump actions/checkout from 4.1.2 to 4.1.4 (<a href="https://redirect.github.com/certifi/python-certifi/issues/287">#287</a>)</li> <li><a href="https://github.com/certifi/python-certifi/commit/1fc808626a895a916b1e4c2b63abae6c5eafdbe3"><code>1fc8086</code></a> Bump peter-evans/create-pull-request from 6.0.4 to 6.0.5 (<a href="https://redirect.github.com/certifi/python-certifi/issues/288">#288</a>)</li> <li>Additional commits viewable in <a href="https://github.com/certifi/python-certifi/compare/2023.11.17...2024.07.04">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore <dependency name> major version` will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself) - `@dependabot ignore <dependency name> minor version` will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself) - `@dependabot ignore <dependency name>` will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself) - `@dependabot unignore <dependency name>` will remove all of the ignore conditions of the specified dependency - `@dependabot unignore <dependency name> <ignore condition>` will remove the ignore condition of the specified dependency and ignore conditions You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/carbon-language/carbon-lang/network/alerts). </details> Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Refactor InstBlockStack to use ArrayStack. (#4104) The use of ArrayStack here is intended to simplify the logic, and also make better use of the inst heap allocations. Prior changes #4101 and #4103 removed the less related logic from InstBlockStack, although #4103 is the actual part that blocked using ArrayStack. BTW, note the PrintForStackDump implementation was incorrect because it didn't apply size_. This simplification fixes the issue.
Refactor InstBlockStack to use ArrayStack. (#4104) The use of ArrayStack here is intended to simplify the logic, and also make better use of the inst heap allocations. Prior changes #4101 and #4103 removed the less related logic from InstBlockStack, although #4103 is the actual part that blocked using ArrayStack. BTW, note the PrintForStackDump implementation was incorrect because it didn't apply size_. This simplification fixes the issue.
Refactor InstBlockStack to use ArrayStack. (#4104) The use of ArrayStack here is intended to simplify the logic, and also make better use of the inst heap allocations. Prior changes #4101 and #4103 removed the less related logic from InstBlockStack, although #4103 is the actual part that blocked using ArrayStack. BTW, note the PrintForStackDump implementation was incorrect because it didn't apply size_. This simplification fixes the issue.
Port the toolchain to use the new Carbon hashtable (#4097) This works to leverage the capabilities of the hashtable as much as possible, for example using the key context in the value stores. However, there may still be opportunities to refactor more deeply and use the functionality even better. Hopefully this is at least a reasonable start and gets us a clean baseline. On an Arm M1, this is a 15% improvement on my large lexing stress test, but ends up a wash on my x86-64 server. This is a smaller benefit than I expected, and it's because we're using a set-of-IDs and looking up values with a key context for things like identifiers. This pattern has a surprising tradeoff. The new hashtable uses significantly less memory, a 10% peak RSS reduction just from the hashtable change. But indirecting through the vector of values makes growing the hashtable dramatically less cache-friendly: it causes growth to randomly access every key when rehashing. On x86, everything gained by the faster hashtable is lost in even slower growth. And even on Arm, this eats into the benefits. But I have a plan to tweak how identifiers specifically work to avoid most of the growth, and so I suspect this is the right tradeoff on the whole. It gives us significant working set size reduction and we can likely avoid the regressed operation (growth with rehash) in most cases by clever reserving and if necessary by adding a hash caching layer to the table infrastructure. --------- Co-authored-by: Jon Ross-Perkins <[email protected]>
Track a list of dependent instructions created within a generic (#4092) When checking a declaration or definition of a generic, track a list of created instructions that depend on the generic's parameters in some way, along with information on how they depend on the parameters. This will eventually be used to determine what information we need to compute when creating instances of the generic, but for now we're just building the list. Information is tracked separately for the declaration region and the definition region of the generic, because in general these may be first provided in separate declarations, and they should be substituted into at different times.
Fix some subtle UB found by MSan. (#4093) Technically, any small size buffer's lifetime has ended by the time we get to the base's destructor. This means its no longer valid to access table contents if stored there from the base destructor. We need to handle destruction in the table class instead. This ends up being a trivial change because the logic is already factored out, we just need to call it from a different point.
Fix some subtle UB found by MSan. (#4093) Technically, any small size buffer's lifetime has ended by the time we get to the base's destructor. This means its no longer valid to access table contents if stored there from the base destructor. We need to handle destruction in the table class instead. This ends up being a trivial change because the logic is already factored out, we just need to call it from a different point.
Change implicit import handling to be namespace-oriented. (#4089) This refactors how the implicit import is handled in order to retain more name scope information. As a consequence, private access control works better between api files and implementation files. Note though that this will also be essential for name poisoning between the API and implementation, as discussed in #3763. In implementing this, I ran into a couple issues with namespaces that I think point to flaws in their handling. I've fixed some and added a TODO for the biggest issue (in check.cpp line 281-288), which relates to the handling of namespaces of direct imports which are first evaluated indirectly.
Build Generic objects for generic classes and interfaces. (#4086) In `ClassType`s and `InterfaceType`s, track a `GenericInstanceId` for the instance rather than just the argument list. --------- Co-authored-by: Jon Ross-Perkins <[email protected]>
PreviousNext