Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft release notes for 1.86.0 #138795

Open
cuviper opened this issue Mar 21, 2025 · 13 comments
Open

Draft release notes for 1.86.0 #138795

cuviper opened this issue Mar 21, 2025 · 13 comments
Labels
relnotes-tracking-issue Marks issues tracking what text to put in release notes. T-release Relevant to the release subteam, which will review and decide on the PR/issue.
Milestone

Comments

@cuviper
Copy link
Member

cuviper commented Mar 21, 2025

NOTE: We are trying this issue as a new way to work on the draft release notes.
Use the 📝 links to edit those that have a relnotes-tracking-issue,
and they will be updated when we regenerate the notes periodically.

cc @rust-lang/release


Version 1.86.0 (2025-04-03)

Language

Compiler

Platform Support

Refer to Rust's platform support page
for more information on Rust's tiered platform support.

Libraries

Stabilized APIs

These APIs are now stable in const contexts:

Cargo

Rustdoc

Compatibility Notes

Internal Changes

These changes do not affect any public interfaces of Rust, but they represent
significant improvements to the performance or internals of rustc and related
tools.

Other

@cuviper cuviper added relnotes-tracking-issue Marks issues tracking what text to put in release notes. T-release Relevant to the release subteam, which will review and decide on the PR/issue. labels Mar 21, 2025
@cuviper cuviper added this to the 1.86.0 milestone Mar 21, 2025
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Mar 21, 2025
@cuviper cuviper removed the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Mar 21, 2025
@cuviper cuviper changed the title Tracking issue for 1.86.0 release notes Draft release notes for 1.86.0 Mar 21, 2025
@cuviper
Copy link
Member Author

cuviper commented Mar 21, 2025

@rustbot ping relnotes-interest-group

@rustbot
Copy link
Collaborator

rustbot commented Mar 21, 2025

Hi relnotes-interest-group, this PR adds release notes. Could you review this PR
if you have time? Thanks <3

cc @alex-semenyuk @jieyouxu @joshtriplett @lcnr @traviscross

@cuviper cuviper pinned this issue Mar 21, 2025
@joshtriplett
Copy link
Member

Made several updates. The new system and process, of editing the underlying relnotes tracking issues and regenerating the release notes from those, seems like a great improvement!

@jieyouxu
Copy link
Member

This is much easier to find the actual PR <-> relnotes tracking issue ❤

I made several edits to the underlying relnotes as well.

One nit for the "Stabilized APIs" section is to maybe fully qualify them, i.e. std::sync::Once::wait vs inherent methods on primitive types like {float}::round_down, but maybe that's too noisy.

@cuviper
Copy link
Member Author

cuviper commented Mar 22, 2025

One nit for the "Stabilized APIs" section is to maybe fully qualify them, i.e. std::sync::Once::wait

I usually only qualify enough to disambiguate it, but I forgot in this case there's also an iter::Once. Is sync::Once::wait clear enough to you, or do you think it should really have the full path?

(I also tend to leave the crate out when it's available in both core and std, but that doesn't apply in this case.)

@jieyouxu
Copy link
Member

jieyouxu commented Mar 22, 2025

I think the short form is good enough (or rather, better since it's less noisy) especially if we already have links to the docs anyway. But in the case of potential ambiguity like iter::Once vs sync::Once, the extra segment(s) like sync::Once might be nice yeah.

Is sync::Once::wait clear enough to you

Yes, that's perfectly clear to me.

@cuviper
Copy link
Member Author

cuviper commented Mar 22, 2025

Ok, I updated that, and sync::OnceLock with it just for local consistency, even though that's not ambiguous.

@jieyouxu
Copy link
Member

jieyouxu commented Mar 22, 2025

(Changed #138810, #138809 and #138813 to say "Add new Tier 3 target(s) ..." for consistency because apparently I also can't make up my mind if the "target(s)" bit goes before or after the target tuples.)

@WaffleLapkin
Copy link
Member

Fix accidentally not emitting overflowing_literals lints anymore in patterns and certain macro environments.
📝

Is this correctly included? From the PR description it sounds like this bug never hit stable. cc @apiraino @oli-obk

@cuviper
Copy link
Member Author

cuviper commented Mar 23, 2025

#137893 indicates that the lint did change between stable (1.85) and beta (1.86). Maybe this isn't significant enough for a release note -- then close that tracking issue #138715 -- but I'd prefer to let @oli-obk decide.

@jieyouxu
Copy link
Member

jieyouxu commented Mar 23, 2025

EDIT: now reading back the issues I'm no longer sure, so Oli probably need to review the note.

@oli-obk
Copy link
Contributor

oli-obk commented Mar 24, 2025

The bugfix PR accidentally made another unrelated bugfix, which was what was found on crater. I didn't think it needed relnotes, but when the relnotes label was added I added a description. It's pretty minor considering what you need to to do trigger the new (correct) emission of the lint.

@jieyouxu
Copy link
Member

jieyouxu commented Mar 24, 2025

Maybe sth like "Fix emission of overflowing_literals under certain macro environments" instead, since that's the crater bit right?

EDIT: edited

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
relnotes-tracking-issue Marks issues tracking what text to put in release notes. T-release Relevant to the release subteam, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

6 participants