Skip to content

Tidy feature: deny commits with a tracking issue of 0 #41260

New issue

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

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

Already on GitHub? # to your account

Closed
clarfonthey opened this issue Apr 12, 2017 · 5 comments · Fixed by #67480
Closed

Tidy feature: deny commits with a tracking issue of 0 #41260

clarfonthey opened this issue Apr 12, 2017 · 5 comments · Fixed by #67480
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)

Comments

@clarfonthey
Copy link
Contributor

clarfonthey commented Apr 12, 2017

A reasonable number of commits get pushed that forget a tracking issue, so, I think that this would be useful to have. Additionally, it'd be nice if any #[unstable] attributes got checked to make sure that the tracking issues are all the same.

This should also check links in the unstable book.

@GuillaumeGomez
Copy link
Member

GuillaumeGomez commented Apr 14, 2017

I'm against it. A lot of commits/improvements don't have an issue because it has been discussed outside github.

@Mark-Simulacrum Mark-Simulacrum added the T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) label Jun 20, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-feature-request Category: A feature request, i.e: not implemented / a PR. label Jul 27, 2017
@varkor
Copy link
Member

varkor commented Apr 22, 2019

As discussed in #49985 (comment), the way forward here is making the issue field optional. This should be easy to fix. You can probably just remove this branch:

_ => {
span_err!(diagnostic, attr.span, E0547, "missing 'issue'");
continue
}

and remove any existing issue = "0" fields.

@varkor varkor added E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. labels Apr 22, 2019
@Julian-Wollersberger
Copy link
Contributor

I have looked into this and the easiest way to do it is to internally use 0 as the issue number if it wasn't given.
This feels a bit hacky. Should I try to change the type in StabilityLevel::Unstable from issue: i32 to issue: Option<i32> instead?

@varkor
Copy link
Member

varkor commented Apr 27, 2019

Should I try to change the type in StabilityLevel::Unstable from issue: i32 to issue: Option<i32> instead?

Yes, that's right. 0 should not be used to encode an issue anywhere; we should be using Option instead.

@Julian-Wollersberger
Copy link
Contributor

Ok, the types were changed to issue: Option<i32> in a few places and I added a basic ui test. It turned out that issue fields were already Option<i32> in most places.

Tomorrow I'll try to fix the 79 #[unstable(... , issue = "0")] I found. (And make a proper warning)

Julian-Wollersberger added a commit to Julian-Wollersberger/rust that referenced this issue May 15, 2019
JohnTitor added a commit to JohnTitor/rust that referenced this issue Nov 12, 2019
…-0, r=varkor

support issue = "none" in unstable attributes

This works towards fixing rust-lang#41260.

This PR allows the use of `issue = "none"` in unstable attributes and makes changes to internally store the issue number as an `Option<NonZeroU32>`. For example:

```rust
#[unstable(feature = "unstable_test_feature", issue = "none")]
fn unstable_issue_none() {}
```

It was not made optional because feedback seen here rust-lang#60860 suggested that people might forget the issue field if it was optional.

I could not remove the current uses of `issue = "0"` (of which there are a lot) because the stage 0 compiler expects the old syntax. Once this is available in the stage 0 compiler we can replace all uses of `"0"` with `"none"` and no longer allow `"0"`. This is my first time contributing, so I'm not sure what the protocol is with two-part things like this, so some guidance would be appreciated.

r? @varkor
Centril added a commit to Centril/rust that referenced this issue Dec 22, 2019
…-0-part-2, r=Centril

Require issue = "none" over issue = "0" in unstable attributes

These changes make the use of `issue = "none"` required in unstable attributes throughout the compiler.

Notes:
- rust-lang#66299 is now in beta so `issue = "none"` is accepted.
- The `tidy` tool now fails on `issue = "0"`.
- Tests that used `issue = "0"` were changed to use `issue = "none"`, except for _one_ that asserts `issue = "0"` can still be used.
- The compiler still allows `issue = "0"` because some submodules require it, this could be disallowed once these are updated.

Resolves rust-lang#41260

r? @varkor
@bors bors closed this as completed in eaeb113 Dec 22, 2019
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
Projects
None yet
5 participants