Skip to content

Fix most of "unnecessary parentheses", "unnecessary trailing semicolon" and "unused std::result::Result" lints in the generated code #8966

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

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

badicsalex
Copy link
Contributor

@badicsalex badicsalex commented Jul 23, 2025

Recently we noticed a slowdown of our build times of our relatively large slint files when we started using many many conditionals in functions.
Even incremental builds where we only changed a single string literal in an unrelated rust source file takes a minute to build, when a few months ago it took only seconds.

I checked what rustc was spending its time on, and it turns out it was busy generating tons and tons of unused_paren lints. Now this lint is #[allow]-ed in the module, but I assume that allow only comes into play when printing the lints, they are still generated during compilation.
(The callstack is roughly rustc_lint::unused::UnusedDelimLint::emit_unused_delims <= rustc_interface::passes::**early_lint_checks** <= rustc_ast_lowering::lower_to_hir)

Another symptom of this is looking_for_entry_point taking a lot of time when printed by RUSTFLAGS=-Ztime-passes

We think the solution is that slint should generate code with these lints in the first place, instead of just allowing them. With the changes in the PR, our incremental builds take only seconds again.

This PR is a somewhat quick-n-dirty fix for the above problems, I'd be glad to hear how else this (not adding parentheses around expressions, depending on the context) could be tackled.

Just "allow"-ing lints will still record them and later filter them,
affecting compilation times.
Unused parentheses generate lints in the rust compiler, which get stored
and later filtered. Having too many of these lints impact compile times.
@tronical
Copy link
Member

Fascinating discovery that lints causing such a slowdown.

I'll let Olivier have the final say (please give us a couple of days), but to me the patch looks good (thank you!). Seems like we should definitely avoid adding more allow() in the future.

Thanks again:)

@hunger
Copy link
Member

hunger commented Jul 24, 2025

Just out of curiosity: How much faster did the build get with your patch applied?

@badicsalex
Copy link
Contributor Author

In our most pathological case (hundreds of conditionals, only touching .rs files, with incremental build), the times went from 50s to 5s.

In a more usual case (reasonable amount of slint code, and actually modifying slint files), the performance improvement is on the order of 10-20%.

@hunger
Copy link
Member

hunger commented Jul 24, 2025

WOW! Amazing work!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants