Rollup of 8 pull requests #128278
Merged
Rollup of 8 pull requests #128278
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
Both these platforms have MSG_NOSIGNAL available, and we should set it for socket writes in the event that the SIGPIPE handler has been reset to SIG_DFL (i.e. terminate the process). I've verified via a quick program at https://github.com/sunshowers/msg-nosignal-test/ that even when the SIGPIPE handler is reset to SIG_DFL, writes to closed sockets now error out with EPIPE. (Under ordinary circumstances UDP writes won't cause MSG_NOSIGNAL.)
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Jump threading stores values as `u128` (`ScalarInt`) and does its comparisons for equality as integer comparisons. This works great for integers. Sadly, not everything is an integer. Floats famously have wonky equality semantcs, with `NaN!=NaN` and `0.0 == -0.0`. This does not match our beautiful integer bitpattern equality and therefore causes things to go horribly wrong. While jump threading could be extended to support floats by remembering that they're floats in the value state and handling them properly, it's signficantly easier to just disable it for now.
from_ref, from_mut: clarify documentation This was brought up [here](rust-lang#56604 (comment)). The domain of quantification is generally always constrained by the type in the type signature, and I am not sure it's always worth spelling that out explicitly as that makes things exceedingly verbose. But since this was explicitly brought up, let's clarify.
…r=Amanieu
improve error message when `global_asm!` uses `asm!` options
specifically, what was
error: expected one of `)`, `att_syntax`, or `raw`, found `preserves_flags`
--> $DIR/bad-options.rs:45:25
|
LL | global_asm!("", options(preserves_flags));
| ^^^^^^^^^^^^^^^ expected one of `)`, `att_syntax`, or `raw`
is now
error: the `preserves_flags` option cannot be used with `global_asm!`
--> $DIR/bad-options.rs:45:25
|
LL | global_asm!("", options(preserves_flags));
| ^^^^^^^^^^^^^^^ the `preserves_flags` option is not meaningful for global-scoped inline assembly
mirroring the phrasing of the [reference](https://doc.rust-lang.org/reference/inline-assembly.html#options).
This is also a bit of a refactor for a future `naked_asm!` macro (for use in `#[naked]` functions). Currently this sort of error can come up when switching from inline to global asm, or when a user just isn't that experienced with assembly. With `naked_asm!` added to the mix hitting this error is more likely.
…ouxu Remove logic to suggest clone of function output I can't exactly tell, but I believe that this suggestion is operating off of a heuristic that the lifetime of a function's input is correlated with the lifetime of a function's output in such a way that cloning would fix an error. I don't think that actually manages to hit the bar of "actually provides useful suggestions" most of the time. Specifically, I've hit false-positives due to this suggestion *twice* when fixing ICEs in the compiler, so I don't think it's worthwhile having this logic around. Neither of the two affected UI tests are actually fixed by the suggestion.
…mulacrum [illumos/solaris] set MSG_NOSIGNAL while writing to sockets Both these platforms have MSG_NOSIGNAL available, and we should set it for socket writes in the event that the SIGPIPE handler has been reset to SIG_DFL (i.e. terminate the process). I've verified via a quick program at https://github.com/sunshowers/msg-nosignal-test/ that even when the SIGPIPE handler is reset to SIG_DFL, writes to closed TCP sockets now error out with EPIPE. (Under ordinary circumstances UDP writes won't cause MSG_NOSIGNAL.) However, I couldn't find any existing tests which verified the MSG_NOSIGNAL behavior.
…hlin Delete `SimplifyArmIdentity` and `SimplifyBranchSame` tests These two passes have already been deleted in rust-lang#107256. I'm not sure why tidy didn't catch it. As regression tests, I didn't delete `tests/ui/mir/issue-66851.rs` and `tests/ui/mir/simplify-branch-same.rs`. r? compiler
…tolnay update `rust.channel` default value documentation self-explanatory Resolves rust-lang#128258 r? dtolnay
…otriddle Add rustdoc GUI test to check title with and without search Follow-up of rust-lang#128210. r? `@notriddle`
…-called-float-equality, r=compiler-errors Disable jump threading of float equality Jump threading stores values as `u128` (`ScalarInt`) and does its comparisons for equality as integer comparisons. This works great for integers. Sadly, not everything is an integer. Floats famously have wonky equality semantcs, with `NaN!=NaN` and `0.0 == -0.0`. This does not match our beautiful integer bitpattern equality and therefore causes things to go horribly wrong. While jump threading could be extended to support floats by remembering that they're floats in the value state and handling them properly, it's signficantly easier to just disable it for now. fixes rust-lang#128243
rustbot
added
O-unix
|
@bors r+ rollup=never p=5 |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: d9e1dea75e In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
|
Finished benchmarking commit (fbccf50): 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)Results (primary 2.4%)This 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: 770.643s -> 770.462s (-0.02%) |
|
A job failed! Check out the build log: (web) (plain) Click to see the possible cause of the failure (guessed by this bot) |
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:
global_asm!usesasm!options #128207 (improve error message whenglobal_asm!usesasm!options)SimplifyArmIdentityandSimplifyBranchSametests #128262 (DeleteSimplifyArmIdentityandSimplifyBranchSametests)rust.channeldefault value documentation #128266 (updaterust.channeldefault value documentation)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup