Tracking issue for release notes of #118159: Implementation of fmt::FormattingOptions

[rustbot]

This issue tracks the release notes text for #118159.

Steps

• Proposed text is drafted by PR author (or team) making the noteworthy change.
• Issue is nominated for release team review of clarity for wider audience.
• Release team includes text in release notes/blog posts.

Release notes text

The responsible team for the underlying change should edit this section to replace the automatically generated link with a succinct description of what changed, drawing upon text proposed by the author (either in discussion or through direct editing).

# Compatibility Notes
- [`Sign` can now be ambiguous due to `std::fmt::Sign` being added](https://github.com/rust-lang/rust/pull/118159)

Tip

Use the previous releases categories to help choose which one(s) to use.
The category will be de-duplicated with all the other ones by the release team.

More than one section can be included if needed.

Release blog section

If the change is notable enough for inclusion in the blog post, the responsible team should add content to this section.
Otherwise leave it empty.

cc @EliasHolzmann, @m-ou-se -- origin issue/PR authors and assignees for starting to draft text

[EliasHolzmann]

This has been labelled for inclusion in the release notes because of an accepted Crater regression. One crate (crypt_guard) used an ambiguous name Sign due to implicit glob import of std::fmt::Sign: #135672

The crate author has been notified (mm9942/crypt_guard#9) and will hopefully have a fix until the release of 1.85.

If we really want to include this in the release notes, I suggest waiting until the issue is fixed in crypt_guard (as long as this happens before the Rust 1.85 release) so that we can mention the version of the crate that fixes the issue. However, I'm not sure this is important enough to include mention in the release notes – after all, crypt_guard isn't a widely used crate which breakage would affect many users.

Is there any guideline on how widely used a crate has to be to warrant mention of a breakage in a new Rust release? The only example of such a mention I found in the previous release notes was the time breakage in the 1.80.0 release, which is definitely big enough...

[Mark-Simulacrum]

My sense is that we generally don't mention breakage due to ambiguous imports, since it's (AFAIK) possible for such cases to exist in principle for any new importable item being added, which makes it a bit noisy. So I think I'm going to go ahead and close this without inclusion.