summary refs log tree commit diff
path: root/library/std
AgeCommit message (Collapse)AuthorLines
2021-10-15Also note tool expectations of fork vs clone3Josh Stone-0/+2
Co-authored-by: Josh Triplett <josh@joshtriplett.org>
2021-10-15Update another comment on fork vs. clone3Josh Stone-2/+2
2021-10-15Only use `clone3` when needed for pidfdJosh Stone-1/+5
In #89522 we learned that `clone3` is interacting poorly with Gentoo's `sandbox` tool. We only need that for the unstable pidfd extensions, so otherwise avoid that and use a normal `fork`.
2021-10-04Auto merge of #89144 - sexxi-goose:insig_stdlib, r=nikomatsakisbors-0/+1
2229: Mark insignificant dtor in stdlib I looked at all public [stdlib Drop implementations](https://doc.rust-lang.org/stable/std/ops/trait.Drop.html#implementors) and categorized them into Insigificant/Maybe/Significant Drop. Reasons are noted here: https://docs.google.com/spreadsheets/d/19edb9r5lo2UqMrCOVjV0fwcSdS-R7qvKNL76q7tO8VA/edit#gid=1838773501 One thing missing from this PR is tagging HashMap as insigificant destructor as that needs some discussion. r? `@Mark-Simulacrum` cc `@nikomatsakis`
2021-10-04Auto merge of #88587 - bdbai:fix/uwpio, r=joshtriplettbors-4/+7
Fix WinUWP std compilation errors due to I/O safety I/O safety for Windows has landed in #87329. However, it does not cover UWP specific parts and prevents all UWP targets from building. See https://github.com/YtFlow/Maple/issues/18. This PR fixes these compile errors when building std for UWP targets.
2021-09-03Update primitive docs for rust 2021.Mara Bos-7/+11
2021-09-02Auto merge of #88596 - m-ou-se:rollup-cidzt4v, r=m-ou-sebors-2/+1
Rollup of 12 pull requests Successful merges: - #88177 (Stabilize std::os::unix::fs::chroot) - #88505 (Use `unwrap_unchecked` where possible) - #88512 (Upgrade array_into_iter lint to include Deref-to-array types.) - #88532 (Remove single use variables) - #88543 (Improve closure dummy capture suggestion in macros.) - #88560 (`fmt::Formatter::pad`: don't call chars().count() more than one time) - #88565 (Add regression test for issue 83190) - #88567 (Remove redundant `Span` in `QueryJobInfo`) - #88573 (rustdoc: Don't panic on ambiguous inherent associated types) - #88582 (Implement #88581) - #88589 (Correct doc comments inside `use_expr_visitor.rs`) - #88592 (Fix ICE in const check) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
2021-09-02Rollup merge of #88177 - joshtriplett:stabilize-chroot, r=m-ou-seMara Bos-2/+1
Stabilize std::os::unix::fs::chroot I've verified that this works as documented, and I've tested it in (a nightly build of) production software as a replacement for an unsafe call to `libc::chroot`. It's been available in nightly for a few releases. I think it's ready to stabilize. --- Tracking issue: https://github.com/rust-lang/rust/issues/84715
2021-09-02Auto merge of #87580 - ChrisDenton:win-arg-parse-2008, r=m-ou-sebors-123/+201
Update Windows Argument Parsing Fixes #44650 The Windows command line is passed to applications [as a single string](https://docs.microsoft.com/en-us/archive/blogs/larryosterman/the-windows-command-line-is-just-a-string) which the application then parses to get a list of arguments. The standard rules (as used by C/C++) for parsing the command line have slightly changed over the years, most recently in 2008 which added new escaping rules. This PR implements the new rules as [described on MSDN](https://docs.microsoft.com/en-us/cpp/cpp/main-function-command-line-args?view=msvc-160#parsing-c-command-line-arguments) and [further detailed here](https://daviddeley.com/autohotkey/parameters/parameters.htm#WIN). It has been tested against the behaviour of C++ by calling a C++ program that outputs its raw command line and the contents of `argv`. See [my repo](https://github.com/ChrisDenton/winarg/tree/std) if anyone wants to reproduce my work. For an overview of how this PR changes argument parsing behavior and why we feel it is warranted see https://github.com/rust-lang/rust/pull/87580#issuecomment-893833893. For some examples see: https://github.com/rust-lang/rust/pull/87580#issuecomment-894299249
2021-09-02Auto merge of #83342 - Count-Count:win-console-incomplete-utf8, r=m-ou-sebors-14/+90
Allow writing of incomplete UTF-8 sequences to the Windows console via stdout/stderr # Problem Writes of just an incomplete UTF-8 byte sequence (e.g. `b"\xC3"` or `b"\xF0\x9F"`) to stdout/stderr with a Windows console attached error with `io::ErrorKind::InvalidData, "Windows stdio in console mode does not support writing non-UTF-8 byte sequences"` even though further writes could complete the codepoint. This is currently a rare occurence since the [linewritershim](https://github.com/rust-lang/rust/blob/2c56ea38b045624dc8b42ec948fc169eaff1206a/library/std/src/io/buffered/linewritershim.rs) implementation flushes complete lines immediately and buffers up to 1024 bytes for incomplete lines. It can still happen as described in #83258. The problem will become more pronounced once the developer can switch stdout/stderr from line-buffered to block-buffered or immediate when the changes in the "Switchable buffering for Stdout" pull request (#78515) get merged. # Patch description If there is at least one valid UTF-8 codepoint all valid UTF-8 is passed through to the extracted `write_valid_utf8_to_console()` fn. The new code only comes into play if `write()` is being passed a short byte slice comprising an incomplete UTF-8 codepoint. In this case up to three bytes are buffered in the `IncompleteUtf8` struct associated with `Stdout` / `Stderr`. The bytes are accepted one at a time. As soon as an error can be detected `io::ErrorKind::InvalidData, "Windows stdio in console mode does not support writing non-UTF-8 byte sequences"` is returned. Once a complete UTF-8 codepoint is received it is passed to the `write_valid_utf8_to_console()` and the buffer length is set to zero. Calling `flush()` will neither error nor write anything if an incomplete codepoint is present in the buffer. # Tests Currently there are no Windows-specific tests for console writing code at all. Writing (regression) tests for this problem is a bit challenging since unit tests and UI tests don't run in a console and suddenly popping up another console window might be surprising to developers running the testsuite and it might not work at all in CI builds. To just test the new functionality in unit tests the code would need to be refactored. Some guidance on how to proceed would be appreciated. # Public API changes * `std::str::verifications::utf8_char_width()` would be exposed as `std::str::utf8_char_width()` behind the "str_internals" feature gate. # Related issues * Fixes #83258. * PR #78515 will exacerbate the problem. # Open questions * Add tests? * Squash into one commit with better commit message?
2021-09-01Rollup merge of #88551 - inquisitivecrystal:unsafe_cell_raw_get, r=m-ou-seMara Bos-1/+0
Stabilize `UnsafeCell::raw_get()` This PR stabilizes the associated function `UnsafeCell::raw_get()`. The FCP has [already completed](https://github.com/rust-lang/rust/issues/66358#issuecomment-899095068). While there was some discussion about the naming after the close of the FCP, it looks like people have agreed on this name. Still, it would probably be best if a `libs-api` member had a look at this and stated whether more discussion is needed. While I was at it, I added some tests for `UnsafeCell`, because there were barely any. Closes #66358.
2021-09-01Rollup merge of #88542 - tavianator:readdir_r-errno, r=jyn514Mara Bos-2/+3
Use the return value of readdir_r() instead of errno POSIX says: > If successful, the readdir_r() function shall return zero; otherwise, > an error number shall be returned to indicate the error. But we were previously using errno instead of the return value. This led to issue #86649.
2021-08-31Stabilize `UnsafeCell::raw_get()`inquisitivecrystal-1/+0
2021-08-31Use the return value of readdir_r() instead of errnoTavian Barnes-2/+3
POSIX says: > If successful, the readdir_r() function shall return zero; otherwise, > an error number shall be returned to indicate the error. But we were previously using errno instead of the return value. This led to issue #86649.
2021-08-31Rollup merge of #88524 - soenkehahn:master, r=jyn514Mara Bos-1/+1
Remove unnecessary `mut` from udp doctests I don't think this `mut` is necessary, since both `recv_from` and `send_to` take `&self`.
2021-08-31Rollup merge of #88495 - ibraheemdev:tcp-linger, r=joshtriplettMara Bos-1/+165
Add `TcpStream::set_linger` and `TcpStream::linger` Adds methods for getting/setting the `SO_LINGER` option on TCP sockets. Behavior is consistent across Unix and Windows. r? `@joshtriplett` (I noticed you've been reviewing net related PRs)
2021-08-31disable `tcp_linger` feature in `std`Ibraheem Ahmed-1/+0
Co-authored-by: Mara Bos <m-ou.se@m-ou.se>
2021-08-31Rollup merge of #88465 - marcospb19:master, r=joshtriplettMara Bos-6/+25
Adding examples to docs of `std::time` module And adding missing link to `Duration` from `Instant`.
2021-08-31Rollup merge of #88394 - ChrisDenton:patch-1, r=joshtriplettMara Bos-0/+3
Document `std::env::current_exe` possible rename behaviour It might not be obvious that the "path of the current running executable" may (or may not) imply "at the time it was loaded". This came up recently in chat so I thought it might be worth documenting.
2021-08-30Remove unnecessary `mut` from udp doctestsSönke Hahn-1/+1
2021-08-30clean up `c::linger` conversionibraheemdev-2/+2
2021-08-30add `TcpStream::set_linger` and `TcpStream::linger`ibraheemdev-1/+166
2021-08-29Adding examples to docs of std::time moduleJoão M. Bezerra-6/+25
And adding missing link to Duration from Instant
2021-08-29Rollup merge of #88381 - rtzoeller:dfly_stack_t_ss_sp_void, r=dtolnayGuillaume Gomez-14/+0
Handle stack_t.ss_sp type change for DragonFlyBSD stack_t.ss_sp is now c_void on DragonFlyBSD, like the rest of the BSDs. Changed in https://github.com/rust-lang/libc/commit/02922ef7504906589d02c2e4d97d1172fa247cc3.
2021-08-28Auto merge of #87921 - kellerkindt:master, r=kennytmbors-0/+4
Add Saturating type (based on Wrapping type) Tracking #87920 ### Unresolved Questions <!-- Include any open questions that need to be answered before the feature can be stabilised. --> - [x] ~`impl Div for Saturating<T>` falls back on inner integer division - which seems alright?~ - [x] add `saturating_div`? (to respect division by `-1`) - [x] There is no `::saturating_shl` and `::saturating_shr`. (How to) implement `Shl`, `ShlAssign`, `Shr` and `ShrAssign`? - [naively](3f7d2ce28f8cf4dec56bf65fa2e6da0cf329ec55) - [x] ~`saturating_neg` is only implemented on [signed integer types](https://doc.rust-lang.org/std/?search=saturating_n)~ - [x] Is the implementation copied over from the `Wrapping`-type correct for `Saturating`? - [x] `Saturating::rotate_left` - [x] `Saturating::rotate_right` - [x] `Not` - [x] `BitXorOr` and `BitXorOrAssign` - [x] `BitOr` and `BitOrAssign` - [x] `BitAnd` and `BitAndAssign` - [x] `Saturating::swap_bytes` - [x] `Saturating::reverse_bits`
2021-08-27Handle stack_t.ss_sp type change for DragonFlyBSDRyan Zoeller-14/+0
stack_t.ss_sp is now c_void on DragonFlyBSD, so the specialization is no longer needed. Changed in https://github.com/rust-lang/libc/commit/02922ef7504906589d02c2e4d97d1172fa247cc3.
2021-08-27Document `std::env::current_exe` rename behaviourChris Denton-0/+3
It might not be obvious that the "path of the current running executable" may (or may not) mean "at the time it was loaded".
2021-08-27Auto merge of #88371 - Manishearth:rollup-pkkjsme, r=Manishearthbors-0/+14
Rollup of 11 pull requests Successful merges: - #87832 (Fix debugger stepping behavior with `match` expressions) - #88123 (Make spans for tuple patterns in E0023 more precise) - #88215 (Reland #83738: "rustdoc: Don't load all extern crates unconditionally") - #88216 (Don't stabilize creation of TryReserveError instances) - #88270 (Handle type ascription type ops in NLL HRTB diagnostics) - #88289 (Fixes for LLVM change 0f45c16f2caa7c035e5c3edd40af9e0d51ad6ba7) - #88320 (type_implements_trait consider obligation failure on overflow) - #88332 (Add argument types tait tests) - #88340 (Add `c_size_t` and `c_ssize_t` to `std::os::raw`.) - #88346 (Revert "Add type of a let tait test impl trait straight in let") - #88348 (Add field types tait tests) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
2021-08-26Rollup merge of #88340 - thomcc:c_size_t, r=joshtriplettManish Goregaokar-0/+14
Add `c_size_t` and `c_ssize_t` to `std::os::raw`. Apparently these aren't guaranteed to be the same, and are merely "always the same in practice" (see https://rust-lang.zulipchat.com/#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/.60usize.60.20vs.20.60size_t.60). This is a big footgun, but I suspect it can be alleviated if we expose this and start migrating people to it in advance of any platforms that ever have this as different. I'll file a tracking issue after this gets some traction.
2021-08-26Auto merge of #87194 - eddyb:const-value-mangling, r=michaelwoerister,oli-obkbors-1/+1
rustc_symbol_mangling: support structural constants and &str in v0. This PR should unblock #85530 (except for float `const` generics, which AFAIK should've never worked). (cc `@tmiasko` could the https://github.com/rust-lang/rust/pull/85530#issuecomment-857855379 failures be retried with a quick crater "subset" run of this PR + changing the default to `v0`? Just to make sure I didn't miss anything other than the floats) The encoding is the one suggested before in e.g. https://github.com/rust-lang/rust/issues/61486#issuecomment-878932102, tho this PR won't by itself finish #61486, before closing that we'd likely want to move to `@oli-obk's` "valtrees" (i.e. #83234 and other associated work). <hr> **EDITs**: 1. switched unit/tuple/braced-with-named-fields `<const-fields>` prefixes from `"u"`/`"T"`/`""` to `"U"`/`"T"`/`"S"` to avoid the ambiguity reported by `@tmiasko` in https://github.com/rust-lang/rust/pull/87194#issuecomment-884279921. 2. `rustc-demangle` PR: https://github.com/alexcrichton/rustc-demangle/pull/55 3. RFC amendment PR: https://github.com/rust-lang/rfcs/pull/3161 * also removed the grammar changes included in that PR, from this description 4. added tests (temporarily using my fork of `rustc-demangle`) <hr> r? `@michaelwoerister`
2021-08-25Reference tracking issueThom Chiovoloni-2/+2
2021-08-25Add `c_size_t` and `c_ssize_t` to `std::os::raw`.Thom Chiovoloni-0/+14
2021-08-25Rollup merge of #88299 - ijackson:bufwriter, r=Mark-SimulacrumLéo Lanteri Thauvin-10/+8
Stabilise BufWriter::into_parts The FCP for this has already completed, in #80690. This was just blocked on #85901 (which changed the name), which is now merged. The original stabilisation MR was #84770 but that has a lot of noise in it, and I also accidentally deleted the branch while trying to tidy up. So here is a new MR. Sorry for the noise. Closes #80690
2021-08-25Rollup merge of #88298 - ijackson:errorkind-reorder, r=dtolnayLéo Lanteri Thauvin-22/+30
Errorkind reorder I was doing a bit more work in this area and the untidiness of these two orderings bothered me. The commit messages have the detailed rationale. For your convenience, I c&p them here: ``` io::ErrorKind: rationalise ordering in main enum It is useful to keep some coherent structure to this ordering. In particular, Other and Uncategorized should be next to each other, at the end. Also it seems to make sense to treat UnexpectedEof and OutOfMemory specially, since they are not like the other errors (despite OutOfMemory also being generatable by some OS errors). So: * Move Other to the end, just before Uncategorized * Move Unsupported to between Interrupted and UnexpectedEof * Add some comments documenting where to add things ``` ``` io::Error: alphabeticise the match in as_str() There was no rationale for the previous ordering. ``` r? kennytm since that's who rust-highfive picked before, in #88294 which I accidentally closed.
2021-08-24Stabilise BufWriter::into_partsIan Jackson-10/+8
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-08-24Update rustc-demangle to 0.1.21.Eduard-Mihai Burtescu-1/+1
2021-08-24Fix tidyIan Jackson-2/+2
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-08-24io::ErrorKind: rationalise ordering in main enumIan Jackson-17/+24
It is useful to keep some coherent structure to this ordering. In particular, Other and Uncategorized should be next to each other, at the end. Also it seems to make sense to treat UnexpectedEof and OutOfMemory specially, since they are not like the other errors (despite OutOfMemory also being generatable by some OS errors). So: * Move Other to the end, just before Uncategorized * Move Unsupported to between Interrupted and UnexpectedEof * Add some comments documenting where to add things Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-08-24io::Error: alphabeticise the match in as_str()Ian Jackson-5/+6
There was no rationale for the previous ordering. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-08-24Fix typo “a Rc” → “an Rc”Frank Steffahn-2/+2
2021-08-23Rollup merge of #88230 - steffahn:a_an, r=oli-obkMara Bos-26/+26
Fix typos “a”→“an” Fix typos in comments; found using a regex to find some easy instance of incorrect usage of a vs. an. While automation was used to find these, every change was checked manually. Changes in submodules get separate PRs: * https://github.com/rust-lang/stdarch/pull/1201 * https://github.com/rust-lang/cargo/pull/9821 * https://github.com/rust-lang/miri/pull/1874 * https://github.com/rust-lang/rls/pull/1746 * https://github.com/rust-analyzer/rust-analyzer/pull/9984 _folks @ rust-analyzer are fast at merging…_ * https://github.com/rust-analyzer/rust-analyzer/pull/9985 * https://github.com/rust-analyzer/rust-analyzer/pull/9987 * https://github.com/rust-analyzer/rust-analyzer/pull/9989 _For `clippy`, I don’t know if the changes should better better be moved to a PR to the original repo._ <hr> This has some overlap with #88226, but neither is a strict superset of the other. If you want multiple commits, I can split it up; in that case, make sure to suggest a criterion for splitting.
2021-08-23Auto merge of #88220 - sunfishcode:sunfishcode/unix-listener-io-safety, ↵bors-1/+25
r=joshtriplett Implement `AsFd` etc. for `UnixListener`. Implement `AsFd`, `From<OwnedFd>`, and `Into<OwnedFd>` for `UnixListener`. This is a follow-up to #87329. r? `@joshtriplett`
2021-08-23Auto merge of #87598 - ccqpein:master, r=yaahcbors-2/+10
Add doctests for HashMap's into_values and into_keys methods Fixes #87591
2021-08-22Remove redundant conversions.Dan Gohman-2/+2
2021-08-22Fix typos “an”→“a” and a few different ones that appeared in the ↵Frank Steffahn-6/+6
same search
2021-08-22Fix more “a”/“an” typosFrank Steffahn-4/+4
2021-08-22Fix typos “a”→“an”Frank Steffahn-17/+17
2021-08-22Add doctests for 's into_values and into_keys methodsccQpein-2/+10
2021-08-22Auto merge of #85166 - mbhall88:file-prefix, r=dtolnaybors-90/+372
add file_prefix method to std::path This is an initial implementation of `std::path::Path::file_prefix`. It is effectively a "left" variant of the existing [`file_stem`](https://doc.rust-lang.org/std/path/struct.Path.html#method.file_stem) method. An illustration of the difference is ```rust use std::path::Path; let path = Path::new("foo.tar.gz"); assert_eq!(path.file_stem(), Some("foo.tar")); assert_eq!(path.file_prefix(), Some("foo")); ``` In my own development, I generally find I almost always want the prefix, rather than the stem, so I thought it might be best to suggest it's addition to libstd. Of course, as this is my first contribution, I expect there is probably more work that needs to be done. Additionally, if the libstd team feel this isn't appropriate then so be it. There has been some [discussion about this on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/file_lstem/near/238076313) and a user there suggested I open a PR to see whether someone in the libstd team thinks it is worth pursuing.
2021-08-21Implement `AsFd` etc. for `UnixListener`.Dan Gohman-1/+25
Implement `AsFd`, `From<OwnedFd>`, and `Into<OwnedFd>` for `UnixListener`. This is a follow-up to #87329.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-04-26 19:03:27 +0000