-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Rollup of 5 pull requests #97795
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
Rollup of 5 pull requests #97795
Conversation
…er-errors Compute lifetimes in scope at diagnostic time The set of available lifetimes is currently computed during lifetime resolution on HIR. It is only used for one diagnostic. In this PR, HIR lifetime resolution just reports whether elided lifetimes are well-defined at the place of use. The diagnostic code is responsible for building a list of lifetime names if elision is not allowed. This will allow to remove lifetime resolution on HIR eventually.
…gisa Add E0788 for improper #[no_coverage] usage Essentially, this adds proper checking for the attribute (tracking issue rust-lang#84605) and throws errors when it's put in obviously-wrong places, like on struct or const definitions. Most of the code is taken directly from the checks for the `#[inline]` attribute, since it's very similar. Right now, the code only checks at the function level, but it seems reasonable to allow adding `#[no_coverage]` to individual blocks or expressions, so, for now those just throw `unused_attributes` warnings. Similarly, since there was a lot of desire to eventually allow recursive definitions as well on modules and impl blocks, these also throw `unused_attributes` instead of an error. I'm not sure if anything has to be done since this error is technically for an unstable feature, but since an error for using unstable features will show up anyway, I think it's okay. This is the first big piece needed for stabilising this attribute, although I personally would like to explore renaming it to `#[coverage(never)]` on a separate PR, which I will offer soon. There's a lot of discussion still to be had about that, which is why it will be kept separate. I don't think much is needed besides adding this simple check and a UI test, but let me know if there's something else that should be added to make this happen.
Avoid creating `SmallVec`s in `global_llvm_features` This PR made a simple optimization to avoid creating extra `SmallVec`s by adjusting the use of iterator statements. Also, given the very small size of `tied_target_features`, there is no need to insert each feature into the FxHashMap.
interpret: do not claim UB until we looked more into variadic functions I am not actually sure if this is UB, and anyway for FFI shims, Miri currently does not attempt to distinguish between arguments passed via variadics vs directly. So let's be consistent. (Programs that ran into this error will anyway immediately fall through to the "unsupported" message on the next line.)
…-DPC E0432: rust 2018 -> rust 2018 or later in --explain message
@bors r+ p=5 rollup=never |
📌 Commit 99afe26 has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (357bc27): comparison url. Instruction count
Max RSS (memory usage)Results
CyclesResults
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 Footnotes |
This looks to be caused by some variability in the Diesel benchmark. The regressions seen here are reversed in the next PR (an update to Clippy). @rustbot label: +perf-regression-triaged |
Successful merges:
SmallVec
s inglobal_llvm_features
#97579 (Avoid creatingSmallVec
s inglobal_llvm_features
)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup