Error codes are integers, but `String` is used everywhere to represent
them. Gross!
This commit introduces `ErrCode`, an integral newtype for error codes,
replacing `String`. It also introduces a constant for every error code,
e.g. `E0123`, and removes the `error_code!` macro. The constants are
imported wherever used with `use rustc_errors::codes::*`.
With the old code, we have three different ways to specify an error code
at a use point:
```
error_code!(E0123) // macro call
struct_span_code_err!(dcx, span, E0123, "msg"); // bare ident arg to macro call
\#[diag(name, code = "E0123")] // string
struct Diag;
```
With the new code, they all use the `E0123` constant.
```
E0123 // constant
struct_span_code_err!(dcx, span, E0123, "msg"); // constant
\#[diag(name, code = E0123)] // constant
struct Diag;
```
The commit also changes the structure of the error code definitions:
- `rustc_error_codes` now just defines a higher-order macro listing the
used error codes and nothing else.
- Because that's now the only thing in the `rustc_error_codes` crate, I
moved it into the `lib.rs` file and removed the `error_codes.rs` file.
- `rustc_errors` uses that macro to define everything, e.g. the error
code constants and the `DIAGNOSTIC_TABLES`. This is in its new
`codes.rs` file.
Remove myself from review rotation
Still willing to do reviews (and make it through my backlog), but I don't have the bandwidth to be on the rotation right now.
Don't add needs-triage to A-diagnostics
A-diagnostics is already labeled correctly thanks to the template and there usually isn't much to do on those issues, so it's fine to just add them to the pile.
A-diagnostics is already labeled correctly thanks to the template and there usually isn't much to do on those issues, so it's fine to just add them to the pile.
Comment out `change-id` in `config.example.toml`
This way, we only update CONFIG_CHANGE_HISTORY for major changes, which is much simpler (and updating example.toml doesn't make much sense)
r? `@Kobzol` (as this was mainly your idea)
This way, we only update CONFIG_CHANGE_HISTORY for major changes, which is
much simpler (and updating example.toml doesn't make much sense)
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Remove @JohnTitor from diagnostics pings
I've been inactive around diagnostics for a while so would like to remove myself from the diagnostics-related ping groups for now.
Allow setting `rla` labels via `rustbot`
https://github.com/rust-lang/rust-log-analyzer/pull/75 adds a `rla-silenced` label flag that will turn off RLA updates for non-bors tests. Allow setting that labels and others via `rustbot`.
Because bootstrap lib is already large and complicated, this should
make the "bumping change-id" process easier.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Revert "Remove TaKO8Ki from reviewers"
ref #116061
It's been a month since this pull request, and I now have some available time for reviews. Would it be okay to revisit it as a reviewer?
This reverts commit 8e06b25e39.
r? `@Nilstrieb`
Enable triagebot no-merges check
Follow-up on https://github.com/rust-lang/triagebot/pull/1704
### Motivation
Occasionally, a merge commit like cb5c011670 makes it past manual review and gets merged into master.
At one point, we tried adding a check to CI to prevent this from happening (https://github.com/rust-lang/rust/pull/105058), but that ended up [problematic](https://github.com/rust-lang/rust/pull/106319#issuecomment-1368144076) and was [reverted](https://github.com/rust-lang/rust/pull/106320). This kind of check is simply too fragile for CI, and there must be a way for a human to override the bot's decision.
The capability to detect and warn about merge commits has been present in triagebot for quite some time, but was never enabled at rust-lang/rust, possibly due to concerns about false positives on rollup and subtree sync PRs. This PR intends to alleviate those concerns.
### Configuration
This configuration will exclude rollup PRs and subtree sync PRs from merge commit detection, and it will post the default warning message and add the `has-merge-commits` and `S-waiting-on-author` labels when merge commits are detected on other PRs.
The eventual vision is to have bors refuse to merge if the `has-merge-commits` label is present. A reviewer can still force the merge by removing that label if they so wish.
### Note for contributors
The rollup tool should add that label automatically, but anyone performing subtree updates should begin including "subtree update" in the titles of those PRs, to avoid false positives.
r? infra
## Open Questions
1. This configuration uses the default message that's built into triagebot:
> There are merge commits (commits with multiple parents) in your changes. We have a [no merge policy](https://rustc-dev-guide.rust-lang.org/git.html#no-merge-policy) so these commits will need to be removed for this pull request to be merged.
>
> You can start a rebase with the following commands:
> ```shell-session
> $ # rebase
> $ git rebase -i master
> $ # delete any merge commits in the editor that appears
> $ git push --force-with-lease
> ```
Any changes to this are easy, I'll just have to add a `message` option. Should we mention the excluded titles in the message?
This configuration will exclude rollup PRs and subtree sync PRs from
merge commit detection. On other PRs, it will post the default warning
message and add the `has-merge-commits` and `S-waiting-on-author`
labels when merge commits are detected.
The eventual vision is to have bors refuse to merge if the
`has-merge-commits` label is present. A reviewer can still
force the merge by removing that label if they so wish.
Remove me from libcore review rotation
I'm looking at my commitments right now, and unfortunately this needs to go for at least a while.
If there's something in particular I can probably still take them, but I should drop out of the rotation for now.
bootstrap major change detection implementation
The use of `changelog-seen` and `bootstrap/CHANGELOG.md` has not been functional in any way for many years. We often do major/breaking changes but never update the changelog file or the `changelog-seen`. This is an alternative method for tracking major or breaking changes and informing developers when such changes occur.
Example output when bootstrap detects a major change:
Add `fmease` to rustdoc review rotations
`@fmease` asked me if it was okay for them to be part of the rustdoc review rotation. Since they are already reviewing a lot of rustdoc PRs, I think it's fine to add them to the rotation.
What do you think `@rust-lang/rustdoc` ?
r? rust-lang/rustdoc
Automatically add OS labels to std PRs
I'd love to have `library/std/src/sys` PRs that touch Windows stuff to have the `O-windows` label for easier discovery (and rediscovery). While I'm here I added a couple of other auto OS labels. Perhaps `O-unix` is a little too broad but it's hard to be more specific and I think it's still useful insomuch as POSIX is a thing.
r? libs
Temporary remove myself from review rotation
I'm going on vacation from 7-th to 15-th and won't be reviewing PRs or writing code.
Feel free to still ping me if you want, I'll read everything when I'm back, but most likely not sooner =)
I don't like the current wording. It's obnoxious to be told by a bot
that a change I made intentionally is "probably unintentional"! I also
don't like describing unintentional changes as "Random", it's not the
right word.
Allow everyone to set the beta-nominated label
It is allowed both in cargo and clippy's triagebot.toml, and nomination does not automatically mean that the PR will be backported.
I'm going to be unable to review for the next few weeks, so I'm
removing myself from the review queue. Once I'm back and able to review
again, I'll add myself back to the list.
I have been reviewing PRs for a long while during weekends, however
recently I’ve been having trouble commiting to that as well. Every
weekend I’ve been spending working on a house.
I may return myself to the rotation in a couple of months. I may also
just start ninja'ing up some PRs from the PR list whenever I find some
time for reviews again, without putting myself back into the rotation,
in acknowledgement that me being able to review every weekend or every
second weekend is not a great experience for the contributors waiting on
reviews from me.
loudly tell people when they change `Cargo.lock`
It keeps happening that people accidentally commit changes to `Cargo.lock` and then have to be told by a reviewer to undo this. I've also seen cases where PRs are merged that accidentally changed `Cargo.lock` during a rebase.. I figure that purposeful changes to `Cargo.lock` are likely rarer than these accidental ones?
