Conversation
I think it's helpful to know what type was unused when looking at these warnings. The type will likely determine whether the result *should* be used, or whether it should just be ignored. Including the type also matches the behavior of the `must_use` lint: unused `SomeType` that must be used.
Fix suggestion of additional `pub` when using `pub pub fn ...` Fix rust-lang#87694. Marked as draft to start with because I want to explore doing the same fix for `const const fn` and other repeated-but-valid keywords. `@rustbot` label A-diagnostics D-invalid-suggestion T-compiler
Lint bare traits in AstConv. Removing the lint from lowering allows to: - make lowering querification easier; - have the lint implementation in only one place. r? `@estebank`
Show the unused type for `unused_results` lint I think it's helpful to know what type was unused when looking at these warnings. The type will likely determine whether the result *should* be used, or whether it should just be ignored. Including the type also matches the behavior of the `must_use` lint: unused `SomeType` that must be used.
miri: lift restriction on extern types being the only field in a struct Fixes rust-lang#91827. r? ````@RalfJung````
Constify (most) `Option` methods r? ``@oli-obk``
…h726 Move generator check earlier in inlining. Inlining into generator may create references to other generators. For instance, inlining `Pin::<&mut from_generator::GenFuture<[generator1]>>::new_unchecked` into `generator2`. This cross reference can then create cycles when computing inlining for `generator1`. In order to avoid this kind of surprises, we forbid all inlining into generators, and rely on LLVM to do the right thing. The existing `remove-zst-query-cycle` already ICEs in inline-mir mode, so we use it as test. Split from rust-lang#91743.
…sing, r=Amanieu builtin_macros: allow external consumers for AsmArgs parsing As discussed in Zulip (https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/parsing.20of.20AsmArgs.20for.20inline.20assembly), we need a function entry point that rustfmt can leverage from a pre-expansion context to get a more structured representation of the asm args without having to duplicate/maintain the token stream parsing r? ```@Amanieu``` and/or ```@joshtriplett```
|
@bors r+ rollup=never p=7 |
|
📌 Commit fd445dd has been approved by |
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (208ced6): comparison url. Summary: This change led to very large relevant regressions 😿 in compiler performance.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression |
|
Fairly likely a genuine regression, but due to more diagnostic output as a result of #89090 -- marking as triaged, not something we should address directly. |
Successful merges:
pubwhen usingpub pub fn ...#87901 (Fix suggestion of additionalpubwhen usingpub pub fn ...)unused_resultslint #91818 (Show the unused type forunused_resultslint)Optionmethods #91928 (Constify (most)Optionmethods)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup