rust/library/std/src, branch 1.62.0https://github.com/rust-lang/rust
http://git.dreamy.place/mirrors/rust/atom?h=1.62.02022-05-17T22:40:37+00:00Revert "Add `set_inheritable` for Windows `Handle`s"2022-05-17T22:40:37+00:00Mark Rousskovmark.simulacrum@gmail.com2022-05-17T22:40:37+00:00urn:sha1:61aebf7570fa2b270a1689482884f90a57185491
This reverts commit b89b0567427932fe37851a314610d795258f1834.
Revert "Windows: Make stdin pipes synchronous"2022-05-17T22:40:35+00:00Mark Rousskovmark.simulacrum@gmail.com2022-05-17T22:40:35+00:00urn:sha1:79256566a9da361793eba86ff1a40caf1560903d
This reverts commit 949b978ec9d63b0eea23d89bad16c6f022ac34a3.
Revert "Note the importance of using sync pipes"2022-05-17T22:40:34+00:00Mark Rousskovmark.simulacrum@gmail.com2022-05-17T22:40:34+00:00urn:sha1:fba04fdb141461aefb58d0ffb15857cfc146758f
This reverts commit 1e7c15634d3b81b595d669382e45e6e136c730e1.
Auto merge of #95356 - coolreader18:exitstatus-exit-method, r=<try>2022-05-13T18:29:13+00:00borsbors@rust-lang.org2022-05-13T18:29:13+00:00urn:sha1:9ad4bde042cfaf56f7579160c60ebd8550a720ab
ExitCode::exit_process() method
cc `@yaahc` / #93840
(eeek, hit ctrl-enter before I meant to and right after realizing the branch name was wrong. oh, well)
I feel like it makes sense to have the `exit(ExitCode)` function as a method or at least associated function on ExitCode, but maybe that would hurt discoverability? Probably not as much if it's at the top of the `process::exit()` documentation or something, but idk. Also very unsure about the name, I'd like something that communicates that you are exiting with *this* ExitCode, but with a method name being postfix it doesn't seem to flow. `code.exit_process_with()` ? `.exit_process_with_self()` ? Blech. Maybe it doesn't matter, since ideally just `code.exit()` or something would be clear simply by the name and single parameter but :shrug:
Also I'd like to touch up the `ExitCode` docs (which I did a bit here), but that would probably be good in a separate PR, right? Since I think the beta deadline is coming up.
Guarantee less in docs2022-05-13T18:28:24+00:00Noacoolreader18@gmail.com2022-05-12T04:29:51+00:00urn:sha1:a9e29d204e0d666b2a7724c15ffa24f988066eebAdd ExitCode::exit_process example2022-05-13T18:28:22+00:00Noacoolreader18@gmail.com2022-05-11T02:56:20+00:00urn:sha1:688dcc68fe2a4bcd781c24b36cfd101fb20a5a50Rollup merge of #96932 - sunfishcode:sunfishcode/document-borrowed-handle, r=joshtriplett2022-05-13T03:33:10+00:00Matthias Krügermatthias.krueger@famsik.de2022-05-13T03:33:10+00:00urn:sha1:f38b7ff3b690a0720506250f421c5983d4f4f9ef
Clarify what values `BorrowedHandle`, `OwnedHandle` etc. can hold.
Reword the documentation to clarify that when `BorrowedHandle`, `OwnedHandle`, or `HandleOrNull` hold the value `-1`, it always means the current process handle, and not `INVALID_HANDLE_VALUE`.
`-1` should only mean `INVALID_HANDLE_VALUE` after a call to a function documented to return that to report errors, which should lead I/O functions to produce errors rather than succeeding and producing `OwnedHandle` or `BorrowedHandle` values. So if a consumer of an `OwnedHandle` or `BorrowedHandle` ever sees them holding a `-1`, it should always mean the current process handle.
Fix comment syntax.2022-05-12T04:11:49+00:00Dan Gohmandev@sunfishcode.online2022-05-12T04:11:49+00:00urn:sha1:275812ad2cb0a5a9a8de88151438d1319a6f0704Relax the wording about the meaning of -1.2022-05-12T03:50:07+00:00Dan Gohmandev@sunfishcode.online2022-05-12T03:50:07+00:00urn:sha1:516a7fa6934c561e9fc1b357a57eb5f0adb89739HandleOrNull can hold null, and HandleOrInvalid can hold INVALID_HANDLE_VALUE.2022-05-11T13:40:52+00:00Dan Gohmandev@sunfishcode.online2022-05-11T13:36:54+00:00urn:sha1:2f75b4aaa64fb8bfb9635a879c1af52a5d68f662