-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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 8 pull requests #115009
Rollup of 8 pull requests #115009
Conversation
This enables LLVM to optimize this function as if it was strlen without having to enable std-aware LTO.
I think this was simply forgotten in rust-lang#113464.
this previously was a off-by-one error.
…reate a single String and write!() to it (clippy::format_collect)
…=thomcc Increase clarity about Hash - Eq consistency in HashMap and HashSet docs As discussed [here](https://users.rust-lang.org/t/what-hapens-if-hash-and-partialeq-dont-match-when-using-hashmap/98052/13) the description of logic errors in `HashMap` and `HashSet` does not explicitly apply to ```text k1 == k2 -> hash(k1) == hash(k2) ``` but this is likely what is intended. This PR is a small doc change to correct this. r? rust-lang/libs
…ompiler-errors instantiate response: no unnecessary new universe this previously was a off-by-one error. fixes rust-lang/trait-system-refactor-initiative#55 r? ````@compiler-errors````
Inline strlen_rt in CStr::from_ptr This enables LLVM to optimize this function as if it was strlen (LLVM knows what it does, and can avoid calling it in certain situations) without having to enable std-aware LTO. This is essentially doing what rust-lang#90007 did, except updated for this function being `const`. Pretty sure it's safe to roll-up, considering last time I did make this change it didn't affect performance (`CStr::from_ptr` isn't really used all that often in Rust code that is checked by rust-perf).
…anieu Expose core::error::request_value in std I think this was simply forgotten in rust-lang#113464. /cc ``@waynr`` r? ``@Amanieu``
Usage zero as language id for `FormatMessageW()` This switches the language selection from using system language (note that this might be different than application language, typically stored as thread ui language) to use `FormatMessageW` default search strategy, which is `neutral` first, then `thread ui lang`, then `user language`, then `system language`, then `English`. (See https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-formatmessagew) This allows the Rust program to take more control of `std::io::Error`'s message field, by setting up thread ui language themselves before hand (which many programs already do).
remove redundant var rebindings
… r=b-naber const-eval: ensure we never const-execute a function marked rustc_do_not_const_check
clippy::perf stuff
@bors r+ rollup=never p=8 |
🌲 The tree is currently closed for pull requests below priority 100. This pull request will be tested once the tree is reopened. |
@bors treeclosed- I think I fixed the self-hosted runners... |
☀️ Test successful - checks-actions |
1 similar comment
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: 6ef7d16be0 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (f32ced6): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. 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: 633.449s -> 636.469s (0.48%) |
Successful merges:
FormatMessageW()
#114983 (Usage zero as language id forFormatMessageW()
)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup