-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change defaults of accept-comment-above-statement
and accept-comment-above-attributes
#11170
Change defaults of accept-comment-above-statement
and accept-comment-above-attributes
#11170
Conversation
r? @giraffate (rustbot has picked a reviewer for you, use r? to override) |
dcfb32e
to
d90de23
Compare
☔ The latest upstream changes (presumably #11003) made this pull request unmergeable. Please resolve the merge conflicts. |
d90de23
to
90c37e1
Compare
Conflicts should be resolved Since you were involved in the original conversation: r? @Centri3 |
LGTM, though we should probably use revisions for the default/custom configuration options instead of duplicating the file with minor comment changes, but that's not a big deal Ideally however, these wouldn't even be configuration options as I highly doubt there are any cases (other than bugs) where somebody would actually want to have these set to @bors r+ |
…r=Centri3 Change defaults of `accept-comment-above-statement` and `accept-comment-above-attributes` This patch sets the two configuration options for `undocumented_unsafe_blocks` to `true` by default: these are `accept-comment-above-statement` and `accept-comment-above-attributes`. Having these values `false` by default prevents what many users would consider clean code, e.g. placing the `// SAFETY:` comment above a single-line functino call, rather than directly next to the argument. This was originally discussed in #11162 changelog: [`undocumented_unsafe_blocks`]: set `accept-comment-above-statement` and `accept-comment-above-attributes` to `true` by default.
💔 Test failed - checks-action_test |
If this is something that we can do now, is there an example? I have to fix something here anyway it seems so might as well change that too if possible |
You usually put the following headers at the top of the file: //@revisions: a b
//@[a] rustc-env:CLIPPY_CONF_DIR=tests/ui-toml/mylint/a
//@[b] rustc-env:CLIPPY_CONF_DIR=tests/ui-toml/mylint/b With a |
☔ The latest upstream changes (presumably #11418) made this pull request unmergeable. Please resolve the merge conflicts. |
Hey @tgross35, any progress on the revisions? If not, this just needs a |
468c39e
to
e57bf7e
Compare
@Centri3 sorry about that, it fell off my radar. I think I got the dual config working right as you suggested, and did the rebase. I'm not sure why github shows the four deleted/renamed files as conflicts when my tree is clean, I am trying to figure this out but do you have any ideas? |
e57bf7e
to
872590f
Compare
This patch sets the two configuration options for `undocumented_unsafe_blocks` to `true` by default: these are `accept-comment-above-statement` and `accept-comment-above-attributes`. Having these values `false` by default prevents what many users would consider clean code, e.g. placing the `// SAFETY:` comment above a single-line functino call, rather than directly next to the argument. changelog: [`undocumented_unsafe_blocks`]: set `accept-comment-above-statement` and `accept-comment-above-attributes` to `true` by default.
872590f
to
1b3e5dd
Compare
I guess I was just rebasing against my own fork instead of upstream 🤦 I think this should be good to go |
Thanks! @bors r+ |
☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test |
This commit moves the safety comments above what they're annotating. It also adds a safety comment about the `transmute` from bytes loaded from an ELF into an extern C struct. Had to extract `mod_id_ptr` to change the `is_err_status` line's formatting to fit on one line. This is to work around a clippy bug which is fixed in <rust-lang/rust-clippy#11170> but our Rust toolchain is too old. Signed-off-by: James Wainwright <[email protected]>
This commit moves the safety comments above what they're annotating. It also adds a safety comment about the `transmute` from bytes loaded from an ELF into an extern C struct. Had to extract `mod_id_ptr` to change the `is_err_status` line's formatting to fit on one line. This is to work around a clippy bug which is fixed in <rust-lang/rust-clippy#11170> but our Rust toolchain is too old. Signed-off-by: James Wainwright <[email protected]>
This commit moves the safety comments above what they're annotating. It also adds a safety comment about the `transmute` from bytes loaded from an ELF into an extern C struct. Had to extract `mod_id_ptr` to change the `is_err_status` line's formatting to fit on one line. This is to work around a clippy bug which is fixed in <rust-lang/rust-clippy#11170> but our Rust toolchain is too old. Signed-off-by: James Wainwright <[email protected]>
This commit moves the safety comments above what they're annotating. It also adds a safety comment about the `transmute` from bytes loaded from an ELF into an extern C struct. Had to extract `mod_id_ptr` to change the `is_err_status` line's formatting to fit on one line. This is to work around a clippy bug which is fixed in <rust-lang/rust-clippy#11170> but our Rust toolchain is too old. Signed-off-by: James Wainwright <[email protected]>
This patch sets the two configuration options for
undocumented_unsafe_blocks
totrue
by default: these areaccept-comment-above-statement
andaccept-comment-above-attributes
. Having these valuesfalse
by default prevents what many users would consider clean code, e.g. placing the// SAFETY:
comment above a single-line functino call, rather than directly next to the argument.This was originally discussed in #11162
changelog: [
undocumented_unsafe_blocks
]: setaccept-comment-above-statement
andaccept-comment-above-attributes
totrue
by default.