Files
rust/tests/ui
bors 104ac7bb6a Auto merge of #117148 - dtolnay:sinceversion, r=cjgillot
Store #[stable] attribute's `since` value in structured form

Followup to https://github.com/rust-lang/rust/pull/116773#pullrequestreview-1680913901.

Prior to this PR, if you wrote an improper `since` version in a `stable` attribute, such as `#[stable(feature = "foo", since = "wat.0")]`, rustc would emit a diagnostic saying **_'since' must be a Rust version number, such as "1.31.0"_** and then throw out the whole `stable` attribute as if it weren't there. This strategy had 2 problems, both fixed in this PR:

1. If there was also a `#[deprecated]` attribute on the same item, rustc would want to enforce that the stabilization version is older than the deprecation version. This involved reparsing the `stable` attribute's `since` version, with a diagnostic **_invalid stability version found_** if it failed to parse. Of course this diagnostic was unreachable because an invalid `since` version would have already caused the `stable` attribute to be thrown out. This PR deletes that unreachable diagnostic.

2. By throwing out the `stable` attribute when `since` is invalid, you'd end up with a second diagnostic saying **_function has missing stability attribute_** even though your function is not missing a stability attribute. This PR preserves the `stable` attribute even when `since` cannot be parsed, avoiding the misleading second diagnostic.

Followups I plan to try next:

- Do the same for the `since` value of `#[deprecated]`.

- See whether it makes sense to also preserve `stable` and/or `unstable` attributes when they contain an invalid `feature`. What redundant/misleading diagnostics can this eliminate? What problems arise from not having a usable feature name for some API, in the situation that we're already failing compilation, so not concerned about anything that happens in downstream code?
2023-10-26 06:59:19 +00:00
..
2023-10-17 17:33:55 +00:00
2023-09-19 12:48:40 +00:00
2023-10-20 21:14:01 +00:00
2023-10-08 10:06:17 +00:00
2023-09-22 18:57:27 +03:00
2023-10-05 01:04:41 +00:00
2023-10-20 21:14:01 +00:00
2023-10-04 08:01:11 +08:00
2023-10-08 10:06:17 +00:00
2023-05-30 13:03:40 +02:00
2023-10-20 21:14:02 +00:00
2023-10-04 08:01:11 +08:00
2023-07-17 22:06:32 +00:00
2023-10-20 21:14:01 +00:00
2023-09-06 12:09:29 +03:00
2023-10-12 21:50:18 +00:00
2023-10-08 10:06:17 +00:00
2023-10-16 16:29:35 +00:00
2023-10-20 21:14:01 +00:00
2023-10-20 21:14:01 +00:00
2023-10-08 10:06:17 +00:00
2023-10-11 04:55:55 +02:00
2023-10-17 17:33:55 +00:00
2023-10-20 21:14:01 +00:00
2023-08-28 17:47:37 -03:00
2023-10-20 21:14:01 +00:00
2023-04-29 13:01:46 +01:00
2023-07-29 11:47:26 +02:00
2023-10-11 04:55:55 +02:00
2023-10-20 21:14:01 +00:00
2023-04-03 09:24:11 +02:00
2023-08-14 16:57:51 -07:00
2023-10-02 23:14:29 +00:00
2023-10-17 17:33:55 +00:00
2023-03-29 18:04:44 -04:00
2023-09-18 17:29:13 +01:00
2023-10-20 21:14:01 +00:00
2023-10-05 01:04:41 +00:00
2023-10-20 21:14:01 +00:00
2023-04-29 13:01:46 +01:00
2023-10-05 01:04:41 +00:00
2023-04-13 22:10:26 -05:00
2023-04-13 22:10:26 -05:00
2023-09-10 23:06:14 +02:00
2023-09-10 23:06:14 +02:00
2023-10-20 21:14:01 +00:00