Move even more early buffered lints to dyn lint diagnostics #147634
Conversation
rustbot
added
S-waiting-on-author
This comment has been minimized.
This comment has been minimized.
Yeah, and it's even more complex as check-cfg lints are emitted from both rustc & rustdoc, which do not operate at the same time, rustc is at expansion time, while rustdoc is after expansion (and therefore has direct access to a |
|
The thing is, while currently only the post-expansion lint pass gets passed a We can easily pass the Not being able to name Footnotes
|
And I know we don't do that right now (we use |
This comment was marked as resolved.
This comment was marked as resolved.
fmease
force-pushed
the
mv-var-to-dyn-buf-lints-next
branch
from
a944814 to
3bce608
Compare
fmease
changed the title
|
Fully dropped the check-cfg migration due to the reasons above. Maybe #149215 will fix the |
rustbot
added
S-waiting-on-review
|
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
Move even more early buffered lints to dyn lint diagnostics
This comment has been minimized.
This comment has been minimized.
rustbot
added
the
S-waiting-on-perf
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
fmease
force-pushed
the
mv-var-to-dyn-buf-lints-next
branch
from
3bce608 to
b1bf1e5
Compare
|
Finished benchmarking commit (cb75625): comparison URL. Overall result: ✅ improvements - no action neededBenchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf. @bors rollup=never 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 3.3%, secondary -4.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary -3.3%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 469.915s -> 468.944s (-0.21%) |
rustbot
removed
the
S-waiting-on-perf
|
cc: @JonathanBrouwer you were also running into the cfg lint issue recently weren't you? take a look at this pr |
|
I hate all the proxy traits but I guess it will be the way to do it... what's here looks good. The lints that are migrated look good. @fmease if you know more about error codes on lints, lmk, otherwise r=me |
|
@jdonszelmann Yeah the linked PR #149215 is my PR :p The problem blocking that PR is that attribute lints have their own enum ( |
|
@rustbot author |
rustbot
added
S-waiting-on-author
|
I didn't even link to the dropped commit even though most of the comments in this PR are concerned with it. So for reference / "posterity" (will probably get pruned at some point): fmease@c97e79f. |
fmease
force-pushed
the
mv-var-to-dyn-buf-lints-next
branch
from
b1bf1e5 to
109e5e5
Compare
|
@bors r=jdonszelmann |
bors
added
S-waiting-on-bors
Probably extension as in syntax extension, the precursor to proc macros. It is the context object passed to syntax extension implementations. Eg https://doc.rust-lang.org/1.26.0/nightly-rustc/syntax/ext/base/trait.TTMacroExpander.html |
|
☀️ Test successful - checks-actions |
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 63b1db0 (parent) -> 47cd712 (this PR) Test differencesShow 242 test diffsStage 0
Stage 1
(and 104 additional test diffs) Additionally, 38 doctest diffs were found. These are ignored, as they are noisy. Job group index Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 47cd7120d9b4e1b64eb27c87522a07888197fae8 --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 (47cd712): comparison URL. Overall result: ❌✅ regressions and improvements - please read the text belowOur benchmarks found a performance regression caused by this PR. Next Steps:
@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 (secondary -3.8%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary -2.7%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 468.853s -> 469.029s (0.04%) |
Mark-Simulacrum
added
the
perf-regression-triaged
|
Only a single secondary run regressed (ucd) so while it doesn't look spurious I don't think it merits investigation, especially coupled with some improvements. Marking as triaged. |
…nszelmann Move attribute lints to `rustc_lint` This PR changes two things: - This decouples the `AttributeLintKind` from the `Lint` it is emitted in. `cx.emit_lint` now takes both as an argument, rather than inferring the `Lint` from the `AttributeLintKind`. This is nice because: - It allows us to remove `AttributeLintKind::InvalidMacroExportArguments` - It allows us to move the choice between `USELESS_DEPRECATED` and `UNUSED_ATTRIBUTES` out of the lint emitting code - It allows the next change: - This moves `AttributeLintKind` to `rustc_lint_defs`, and the decorating code to `rustc_lint`. This is nice because: - It allows attribute lint decorating code to access the TypeCtxt, which unblocks rust-lang#149215 - It might allow most early buffered attribute lints to become dyn lint diagnostics in the future, as in rust-lang#147634 - It deduplicates `IllFormedAttributeInput` This PR does not change observable output of the compiler, as can be seen by no uitests being affected. r? `@jdonszelmann`
Rollup merge of #149662 - JonathanBrouwer:lint-rework, r=jdonszelmann Move attribute lints to `rustc_lint` This PR changes two things: - This decouples the `AttributeLintKind` from the `Lint` it is emitted in. `cx.emit_lint` now takes both as an argument, rather than inferring the `Lint` from the `AttributeLintKind`. This is nice because: - It allows us to remove `AttributeLintKind::InvalidMacroExportArguments` - It allows us to move the choice between `USELESS_DEPRECATED` and `UNUSED_ATTRIBUTES` out of the lint emitting code - It allows the next change: - This moves `AttributeLintKind` to `rustc_lint_defs`, and the decorating code to `rustc_lint`. This is nice because: - It allows attribute lint decorating code to access the TypeCtxt, which unblocks #149215 - It might allow most early buffered attribute lints to become dyn lint diagnostics in the future, as in #147634 - It deduplicates `IllFormedAttributeInput` This PR does not change observable output of the compiler, as can be seen by no uitests being affected. r? `@jdonszelmann`
10 participants
Follow-up to #145881 and #145747.
I originally wanted to migrate most if not the entire rest of the early buffered lints. However, when trying to migrate the buffered lints used by check-cfg I encountered a roadblock. Namely, it depends on
TyCtxt(well,Option<TyCtxt>) which makes it quite hard to migrate (see also #147634 (comment), #147634 (comment) & #149215).So for now, I won't migrate it (maybe #149215 will find a solution), nor will I migrate the rest since it's quite tedious to migrate these. I'll leave them for future me.