-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Restrict From<S>
for {D,Subd}iagnosticMessage
.
#110579
Restrict From<S>
for {D,Subd}iagnosticMessage
.
#110579
Conversation
Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt
cc @davidtwco, @compiler-errors, @JohnTitor, @TaKO8Ki Some changes occurred in src/tools/clippy cc @rust-lang/clippy Some changes occurred in compiler/rustc_codegen_cranelift cc @bjorn3 The Miri subtree was changed cc @rust-lang/miri Some changes occurred to the CTFE / Miri engine cc @rust-lang/miri |
Apologies for the extremely tedious review! @bors p=1 because it's highly conflict-prone. |
@bors rollup=never |
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
⌛ Trying commit e98557dea040a0fd347c610b5e08e812375b1a62 with merge 8a10aae2e708dc03c92bc0a12e63e93b5ee85f6b... |
I suspect that the perf impact here will be smallish; LLVM should be able to figure this out in many cases. Definitely still a good change though. |
This comment has been minimized.
This comment has been minimized.
@@ -401,30 +401,32 @@ pub fn report_msg<'tcx>( | |||
} else { | |||
// Make sure we show the message even when it is a dummy span. | |||
for line in span_msg { | |||
err.note(&line); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that these changes are best addressed in PRs on their respective repos. Clippy and Miri aren't developed in-tree, they're just pulled regularly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You sure about that? I've done many PRs where I changed clippy and miri and rustfmt because of API changes to compiler code, and I'm following the same process here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh right, this isn't just fixing a lint; there's an API change involved. My mistake sorry.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it's definitely courteous to open the PR to them first if you can be arsed but the reason we switched to subtrees is precisely so that the development flow can be two-way (which it can't be with a submodule).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, this is a case where I think modifying in r-l/rust is fine.
@Ezrashaw unless everything gets inlined, I expect LLVM to do this optimization ~never, since it's exceedingly hard to get right |
@JakobDegen |
Yes, I wouldn't argue "LLVM can do this" as a reason for why not. I would expect the allocation and memcpy to be fast enough it's not worth shedding an allocation here and there, often. BUT I have seen smaller PRs shedding fewer (source-level) allocations have pretty unequivocal wins, so I expect this one to do pretty good. |
Fair enough. This is definitely a good API change anyways, it enforces correctness :) |
@Ezrashaw LLVM would need to inline the |
I measured |
e98557d
to
c89e467
Compare
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
⌛ Trying commit c89e467512aa9844afb48998df42baf16e814d9c with merge c5e11dd12ff8c69bfcf77a98131b1660f304d1fd... |
This comment has been minimized.
This comment has been minimized.
I'm not sure this PR is worth doing considering we're trying to move all the diagnostics to fluent/struct based ones, so hopefully we won't have any more custom That said, I gave it a review and it's mechanical and trivial enough to just do. |
Apologies, didn't get to this quick enough, r=me once you've rebased - most of the changes will be trivial. |
c29b6d3
to
bbc457e
Compare
Some changes might have occurred in exhaustiveness checking cc @Nadrieril |
@bors r=davidtwco |
📌 Commit bbc457ef0e3bb9a07313f7d7b9f80800a043b807 has been approved by It is now in the queue for this repository. |
This comment has been minimized.
This comment has been minimized.
Currently a `{D,Subd}iagnosticMessage` can be created from any type that impls `Into<String>`. That includes `&str`, `String`, and `Cow<'static, str>`, which are reasonable. It also includes `&String`, which is pretty weird, and results in many places making unnecessary allocations for patterns like this: ``` self.fatal(&format!(...)) ``` This creates a string with `format!`, takes a reference, passes the reference to `fatal`, which does an `into()`, which clones the reference, doing a second allocation. Two allocations for a single string, bleh. This commit changes the `From` impls so that you can only create a `{D,Subd}iagnosticMessage` from `&str`, `String`, or `Cow<'static, str>`. This requires changing all the places that currently create one from a `&String`. Most of these are of the `&format!(...)` form described above; each one removes an unnecessary static `&`, plus an allocation when executed. There are also a few places where the existing use of `&String` was more reasonable; these now just use `clone()` at the call site. As well as making the code nicer and more efficient, this is a step towards possibly using `Cow<'static, str>` in `{D,Subd}iagnosticMessage::{Str,Eager}`. That would require changing the `From<&'a str>` impls to `From<&'static str>`, which is doable, but I'm not yet sure if it's worthwhile.
bbc457e
to
6b62f37
Compare
@bors r=davidtwco |
☀️ Test successful - checks-actions |
Finished benchmarking commit (71af5c4): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 657.453s -> 654.674s (-0.42%) |
Currently a
{D,Subd}iagnosticMessage
can be created from any type that implsInto<String>
. That includes&str
,String
, andCow<'static, str>
, which are reasonable. It also includes&String
, which is pretty weird, and results in many places making unnecessary allocations for patterns like this:This creates a string with
format!
, takes a reference, passes the reference tofatal
, which does aninto()
, which clones the reference, doing a second allocation. Two allocations for a single string, bleh.This commit changes the
From
impls so that you can only create a{D,Subd}iagnosticMessage
from&str
,String
, orCow<'static, str>
. This requires changing all the places that currently create one from a&String
. Most of these are of the&format!(...)
form described above; each one removes an unnecessary static&
, plus an allocation when executed. There are also a few places where the existing use of&String
was more reasonable; these now just useclone()
at the call site.As well as making the code nicer and more efficient, this is a step towards possibly using
Cow<'static, str>
in{D,Subd}iagnosticMessage::{Str,Eager}
. That would require changing theFrom<&'a str>
impls toFrom<&'static str>
, which is doable, but I'm not yet sure if it's worthwhile.r? @davidtwco