mirror of
https://github.com/rust-lang/rust.git
synced 2026-04-27 18:57:42 +03:00
Merge pull request #2796 from Ko496-glitch/update-date-check-march-2026
Updated dates
This commit is contained in:
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user