This was one of the original issues filed against rustfmt that discussed
using a natural sort order instead of a lexicographical order. At the
time it was closed, but now that we're supporting version-sorting in
`style_edition=2024` I thought it would be good to add a test case.
Stabilize `unsafe_attributes`
# Stabilization report
## Summary
This is a tracking issue for the RFC 3325: unsafe attributes
We are stabilizing `#![feature(unsafe_attributes)]`, which makes certain attributes considered 'unsafe', meaning that they must be surrounded by an `unsafe(...)`, as in `#[unsafe(no_mangle)]`.
RFC: rust-lang/rfcs#3325
Tracking issue: #123757
## What is stabilized
### Summary of stabilization
Certain attributes will now be designated as unsafe attributes, namely, `no_mangle`, `export_name`, and `link_section` (stable only), and these attributes will need to be called by surrounding them in `unsafe(...)` syntax. On editions prior to 2024, this is simply an edition lint, but it will become a hard error in 2024. This also works in `cfg_attr`, but `unsafe` is not allowed for any other attributes, including proc-macros ones.
```rust
#[unsafe(no_mangle)]
fn a() {}
#[cfg_attr(any(), unsafe(export_name = "c"))]
fn b() {}
```
For a table showing the attributes that were considered to be included in the list to require unsafe, and subsequent reasoning about why each such attribute was or was not included, see [this comment here](https://github.com/rust-lang/rust/pull/124214#issuecomment-2124753464)
## Tests
The relevant tests are in `tests/ui/rust-2024/unsafe-attributes` and `tests/ui/attributes/unsafe`.
This commit ensures that `fn config_path` in `rustfmt/src/config/mod.rs`
always returns canonicalized paths. This is achieved by canonicalizing
both: 1) paths received via `CliOptions` (after checking if the path
exists) as well as 2) paths returned via `get_toml_path` (canonicalizing
within `fn get_toml_path`).
Fixes https://github.com/rust-lang/rustfmt/issues/6178
