Mark method receivers in builtin derives as being from the derive.#149350
Mark method receivers in builtin derives as being from the derive.#149350rust-bors[bot] merged 1 commit intorust-lang:mainfrom
Conversation
|
Any test that we can add here? |
|
Clippy will eventually end up with a test that covers this, but I don't think I can easily add anything here. At least I don't know of any way to test the context of arbitrary tokens. For context this is from testing the code in Clippy which detects when a proc-macro generates tokens with a span which has the context of the macro's input, but weren't actually part of the input. |
|
I'm pretty unfamiliar with out we could add a test for this . Maybe @petrochenkov would know. At the least, maybe you can provide some concrete example of what would change here. Is the span meaningful here or is it e.g. only used for diagnostics? |
|
shrug This seems obviously simple and okay. @bors r+ |
Mark method receivers in builtin derives as being from the derive. Another small annoyance while working on clippy. This was clearly using the root context on purpose, but it also has no reason to do so. All the uses of the receiver are generated by the macros so they can just use the marked context rather than the root.
Mark method receivers in builtin derives as being from the derive. Another small annoyance while working on clippy. This was clearly using the root context on purpose, but it also has no reason to do so. All the uses of the receiver are generated by the macros so they can just use the marked context rather than the root.
Mark method receivers in builtin derives as being from the derive. Another small annoyance while working on clippy. This was clearly using the root context on purpose, but it also has no reason to do so. All the uses of the receiver are generated by the macros so they can just use the marked context rather than the root.
|
Maybe #154628 (comment)? @bors try jobs=aarch64-gnu-llvm-21-1 |
This comment has been minimized.
This comment has been minimized.
Mark method receivers in builtin derives as being from the derive. try-job: aarch64-gnu-llvm-21-1
|
💔 Test for a2ea554 failed: CI. Failed job:
|
This comment has been minimized.
This comment has been minimized.
|
@bors r- |
|
This pull request was unapproved. This PR was contained in a rollup (#154629), which was unapproved. |
|
Some changes occurred in src/tools/rustfmt cc @rust-lang/rustfmt |
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
Missed this earlier. This changes the context of the impl Clone for T {
fn clone(
&self // this `self`'s context.
) -> Self {
Self {
x: self.x.clone() // also this `self`'s context.
}
}
}The context shouldn't change the meaning here since the receiver on any of the generated methods isn't accessible to anything outside the macro generated code in the first place. From a linting perspective |
|
@rustbot label -T-rustfmt |
|
@bors r+ |
This comment has been minimized.
This comment has been minimized.
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing fff9e44 (parent) -> a92a99e (this PR) Test differencesShow 2 test diffs2 doctest diffs were found. These are ignored, as they are noisy. Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard a92a99ef1479a9987b0ef76a064c2bd8e779babd --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
|
Finished benchmarking commit (a92a99e): comparison URL. Overall result: ❌ regressions - no action needed@rustbot label: -perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary -0.7%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary -3.6%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (secondary -0.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 488.874s -> 487.739s (-0.23%) |
View all comments
Another small annoyance while working on clippy. This was clearly using the root context on purpose, but it also has no reason to do so. All the uses of the receiver are generated by the macros so they can just use the marked context rather than the root.