You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A-runtimeArea: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflowsI-slowIssue: Problems and improvements with respect to performance of generated code.
This function does a busy wait until there are no outstanding references to the port. I believe this is what's causing #1922 - under valgrind it serializes threads so we end up waiting a very long time.
The text was updated successfully, but these errors were encountered:
I'm not sure how big a problem this is. It's obviously a big problem for valgrind, just based on the way valgrind works - callgrind shows it as taking up 50% of the running time on some benchmarks. In real multithreaded scenarios it is probably not nearly as bad. Still, it should be fixed just to reduce the cycle time on the linux bots.
…ednet
`while_let_on_iterator` Improvements
fixes: rust-lang#6491fixes: rust-lang#6231fixes: rust-lang#5844fixes: rust-lang#1924fixes: rust-lang#1033
The check for whether a field can be borrowed should probably be moved to utils at some point, but it would require some cleanup work and knowing what parts can actually be shared.
changelog: Suggest `&mut iter` when the iterator is used after the loop.
changelog: Suggest `&mut iter` when the iterator is a field in a struct.
changelog: Don't lint when the iterator is a field in a struct, and the struct is used in the loop.
changelog: Lint when the loop is nested in another loop, but suggest `&mut iter` unless the iterator is from a local declared inside the loop.
A-runtimeArea: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflowsI-slowIssue: Problems and improvements with respect to performance of generated code.
This function does a busy wait until there are no outstanding references to the port. I believe this is what's causing #1922 - under valgrind it serializes threads so we end up waiting a very long time.
The text was updated successfully, but these errors were encountered: