Rollup of 18 pull requests #120491
Merged
Rollup of 18 pull requests #120491
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
For consistency with normal functions.
Signed-off-by: onur-ozkan <[email protected]>
Signed-off-by: onur-ozkan <[email protected]>
Currently the documentation of `FileExt::seek_write` on Windows indicates that writes beyond the end of the file leave intermediate bytes uninitialized. This commentary dates back to the original inclusion of these functions in rust-lang#35704 (wow blast from the past!). At the time the functionality here was implemented using `WriteFile`, but nowadays the `NtWriteFile` method is used instead. The documentation for `NtWriteFile` explicitly states: > If Length and ByteOffset specify a write operation past the current > end-of-file mark, NtWriteFile automatically extends the file and updates > the end-of-file mark; any bytes that are not explicitly written between > such old and new end-of-file marks are defined to be zero. This commentary has had a downstream impact in the `system-interface` crate where it tries to handle this by explicitly writing zeros, but I don't believe that's necessary any more. I'm sending a PR upstream here to avoid future confusion and codify that zeros are written in the intermediate bytes matching what Windows currently provides.
Because it can be used for a lifetime or a label.
…r literal. Currently the parser will interpret any label/lifetime in certain positions as a mistyped char literal, on the assumption that the trailing single quote was accidentally omitted. This is reasonable for a something like 'a (because 'a' would be valid) but not reasonable for a something like 'abc (because 'abc' is not valid). This commit restricts this behaviour only to labels/lifetimes that would be valid char literals, via the new `could_be_unclosed_char_literal` function. The commit also augments the `label-is-actually-char.rs` test in a couple of ways: - Adds testing of labels/lifetimes with identifiers longer than one char, e.g. 'abc. - Adds a new match with simpler patterns, because the `recover_unclosed_char` call in `parse_pat_with_range_pat` was not being exercised (in this test or any other ui tests). Fixes rust-lang#120397, an assertion failure, which was caused by this behaviour in the parser interacting with some new stricter char literal checking added in rust-lang#120329.
Issue tests numbered 1920, 3668, 5997, 23302, 32122, 40510, 57741, 71676, and 76077 were moved to relevant better-named subdirectories. ISSUES_ENTRY_LIMIT was adjusted to match new number of files and FIXME note was expanded.
Because it's almost always static. This makes `impl IntoDiagnosticArg for DiagnosticArgValue` trivial, which is nice. There are a few diagnostics constructed in `compiler/rustc_mir_build/src/check_unsafety.rs` and `compiler/rustc_mir_transform/src/errors.rs` that now need symbols converted to `String` with `to_string` instead of `&str` with `as_str`, but that' no big deal, and worth it for the simplifications elsewhere.
Because the `&'a str` fields can be trivially converted to `String` without causing any extra allocations.
It's identical to the one in `rustc_errors`; use that instead. Also remove some `rustc_errors::` qualifiers.
Because it's always 'static.
Because it's always static. I'm surprised the compiler allowed this unused lifetime without any complaint.
…=Nilstrieb Add triagebot mentions entry for simd intrinsics Fixes rust-lang#119119 cc `@antoyo,` `@GuillaumeGomez,` `@rust-lang/project-portable-simd`
rustbot
added
O-windows
|
@bors r+ p=5 rollup=never |
bors
added
S-waiting-on-bors
|
going all in |
|
@Nilstrieb @GuillaumeGomez |
|
@Nilstrieb: No time to lose! 🚀 @chenyukang: Doing a retry like what was done. Not much else that can be done as far as I know... |
|
☀️ Test successful - checks-actions |
This was referenced Jan 30, 2024
|
📌 Perf builds for each rolled up PR:
previous master: c401f09979 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
This was referenced Jan 30, 2024
Merged
Merged
|
Finished benchmarking commit (5ad7454): 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.
CyclesResultsThis 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.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 660.86s -> 662.13s (0.19%) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup