Merge pull request #2796 from Ko496-glitch/update-date-check-march-2026

Updated dates
This commit is contained in:
jyn
2026-03-23 10:44:20 +01:00
committed by GitHub
4 changed files with 5 additions and 6 deletions
@@ -1,6 +1,5 @@
# Updating LLVM
<!-- date-check: Aug 2024 -->
Rust supports building against multiple LLVM versions:
* Tip-of-tree for the current LLVM development branch is usually supported within a few days.
@@ -91,7 +90,6 @@ An example PR: [#59089](https://github.com/rust-lang/rust/pull/59089)
## New LLVM Release Updates
<!-- date-check: Jul 2023 -->
Unlike bugfixes,
updating to a new release of LLVM typically requires a lot more work.
@@ -172,12 +170,14 @@ so let's go through each in detail.
You'll change at least
`src/llvm-project` and will likely also change [`llvm-wrapper`] as well.
<!-- date-check: mar 2025 -->
<!-- date-check: March 2026 -->
> For prior art, here are some previous LLVM updates:
> - [LLVM 17](https://github.com/rust-lang/rust/pull/115959)
> - [LLVM 18](https://github.com/rust-lang/rust/pull/120055)
> - [LLVM 19](https://github.com/rust-lang/rust/pull/127513)
> - [LLVM 20](https://github.com/rust-lang/rust/pull/135763)
> - [LLVM 21](https://github.com/rust-lang/rust/pull/143684)
> - [LLVM 22](https://github.com/rust-lang/rust/pull/150722)
Note that sometimes it's easiest to land [`llvm-wrapper`] compatibility as a PR
before actually updating `src/llvm-project`.
@@ -92,7 +92,7 @@ member constraints come in.
## Choices are always lifetime parameters
At present, the "choice" regions from a member constraint are always lifetime
parameters from the current function. As of <!-- date-check --> October 2021,
parameters from the current function. As of <!-- date-check --> March 2026,
this falls out from the placement of impl Trait, though in the future it may not
be the case. We take some advantage of this fact, as it simplifies the current
code. In particular, we don't have to consider a case like `'0 member of ['1,
@@ -10,7 +10,7 @@ Note that not all _historical_ (no longer emitted) error codes have explanations
The explanations are written in Markdown (see the [CommonMark Spec] for
specifics around syntax), and all of them are linked in the [`rustc_error_codes`] crate.
Please read [RFC 1567] for details on how to format and write long error codes.
As of <!-- date-check --> February 2023, there is an
As of <!-- date-check --> March 2026, there is an
effort[^new-explanations] to replace this largely outdated RFC with a new more flexible standard.
Error explanations should expand on the error message and provide details about
@@ -21,7 +21,6 @@ which boils down to a static with type [`&rustc_lint_defs::Lint`]
as the macro is somewhat unwieldy to add new fields to,
like all macros).
As of <!-- date-check --> Aug 2022,
we lint against direct declarations without the use of the macro.
Lint declarations don't carry any "state" - they are merely global identifiers