about summary refs log tree commit diff
path: root/library/std/src
AgeCommit message (Collapse)AuthorLines
2021-07-05Rollup merge of #86864 - GuillaumeGomez:example-write-vectored, r=JohnTitorYuki Okushi-0/+21
Add missing code example for Write::write_vectored
2021-07-04Add missing code example for Write::write_vectoredGuillaume Gomez-0/+21
2021-07-04Auto merge of #86833 - crlf0710:remove-std-raw-mod, r=SimonSapinbors-4/+0
Remove the deprecated `core::raw` and `std::raw` module. A few months has passed since #84207. I think now it's time for the final removal. Closes #27751. r? `@m-ou-se`
2021-07-04Auto merge of #85270 - ChrisDenton:win-env-case, r=m-ou-sebors-9/+147
When using `process::Command` on Windows, environment variable names must be case-preserving but case-insensitive When using `Command` to set the environment variables, the key should be compared as uppercase Unicode but when set it should preserve the original case. Fixes #85242
2021-07-03stdio_locked: add tracking issueTaylor Yu-7/+7
2021-07-03Auto merge of #86799 - tlyu:stdio-locked, r=joshtriplettbors-1/+337
add owned locked stdio handles Add stderr_locked, stdin_locked, and stdout_locked free functions to obtain owned locked stdio handles in a single step. Also add into_lock methods to consume a stdio handle and return an owned lock. These methods will make it easier to use locked stdio handles without having to deal with lifetime problems or keeping bindings to the unlocked handles around. Fixes #85383; enables #86412. r? `@joshtriplett` `@rustbot` label +A-io +C-enhancement +D-newcomer-roadblock +T-libs-api
2021-07-03Remove the deprecated `core::raw` and `std::raw` module.Charles Lew-4/+0
2021-07-03Auto merge of #79965 - ijackson:moreerrnos, r=joshtriplettbors-109/+2107
More ErrorKinds for common errnos From the commit message of the main commit here (as revised): ``` There are a number of IO error situations which it would be very useful for Rust code to be able to recognise without having to resort to OS-specific code. Taking some Unix examples, `ENOTEMPTY` and `EXDEV` have obvious recovery strategies. Recently I was surprised to discover that `ENOSPC` came out as `ErrorKind::Other`. Since I am familiar with Unix I reviwed the list of errno values in https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/errno.h.html Here, I add those that most clearly seem to be needed. `@CraftSpider` provided information about Windows, and references, which I have tried to take into account. This has to be insta-stable because we can't sensibly have a different set of ErrorKinds depending on a std feature flag. I have *not* added these to the mapping tables for any operating systems other than Unix and Windows. I hope that it is OK to add them now for Unix and Windows now, and maybe add them to other OS's mapping tables as and when someone on that OS is able to consider the situation. I adopted the general principle that it was usually a bad idea to map two distinct error values to the same Rust error code. I notice that this principle is already violated in the case of `EACCES` and `EPERM`, which both map to `PermissionDenied`. I think this was probably a mistake but it would be quite hard to change now, so I don't propose to do anything about that. However, for Windows, there are sometimes different error codes for identical situations. Eg there are WSA* versions of some error codes as well as ERROR_* ones. Also Windows seems to have a great many more erorr codes. I don't know precisely what best practice would be for Windows. ``` <strike> ``` Errno values I wasn't sure about so *haven't* included: EMFILE ENFILE ENOBUFS ENOLCK: These are all fairly Unix-specific resource exhaustion situations. In practice it seemed not very likely to me that anyone would want to handle these differently to `Other`. ENOMEM ERANGE EDOM EOVERFLOW Normally these don't get exposed to the Rust callers I hope. They don't tend to come out of filesystem APIs. EILSEQ Hopefully Rust libraries open files in binary mode and do the converstion in Rust. So Rust code ought not to be exposed to EILSEQ. EIO The range of things that could cause this is troublesome. I found it difficult to describe. I do think it would be useful to add this at some point, because EIO on a filesystem operation is much more serious than most other errors. ENETDOWN I wasn't sure if this was useful or, indeed, if any modern systems use it. ENOEXEC It is not clear to me how a Rust program could respond to this. It seems rather niche. EPROTO ENETRESET ENODATA ENOMSG ENOPROTOOPT ENOSR ENOSTR ETIME ENOTRECOVERABLE EOWNERDEAD EBADMSG EPROTONOSUPPORT EPROTOTYPE EIDRM These are network or STREAMS related errors which I have never in my own Unix programming found the need to do anything with. I think someone who understands these better should be the one to try to find good Rust names and descriptions for them. ENOTTY ENXIO ENODEV EOPNOTSUPP ESRCH EALREADY ECANCELED ECHILD EINPROGRESS These are very hard to get unless you're already doing something very Unix-specific, in which case the raw_os_error interface is probably more suitable than relying on the Rust ErrorKind mapping. EFAULT EBADF These would seem to be the result of application UB. ``` </strike> <i>(omitted errnos are discussed below, especially in https://github.com/rust-lang/rust/pull/79965#issuecomment-810468334)
2021-07-03Move `os_str_bytes` to `sys::unix` and reuse it on other platforms.Christiaan Dirkx-14/+12
2021-07-02stdio_locked: updates based on feedbackTaylor Yu-74/+14
Rename methods to `into_locked`. Remove type aliases for owned locks.
2021-07-03Rollup merge of #86807 - tversteeg:patch-1, r=bjorn3Yuki Okushi-1/+0
Fix double import in wasm thread The `unsupported` type is imported two times, as `super::unsupported` and as `crate::sys::unsupported`, throwing an error. Remove `super::unsupported` in favor of the other. As reported in #86802. Fix #86802
2021-07-03Rollup merge of #86803 - ↵Yuki Okushi-2/+2
xfix:remove-unnecessary-ampersand-from-command-args-calls, r=joshtriplett Remove & from Command::args calls in documentation Now that arrays implement `IntoIterator`, using `&` is no longer necessary. This makes examples easier to understand.
2021-07-03Rollup merge of #85001 - CDirkx:bytestring, r=JohnTitorYuki Okushi-50/+28
Merge `sys_common::bytestring` back into `os_str_bytes` `bytestring` contains code for correctly debug formatting a byte slice (`[u8]`). This functionality is and has historically only been used to provide the debug formatting of byte-based os-strings (on unix etc.). Having this functionality in the separate `bytestring` module was useful in the past to reduce duplication, as [when it was added](https://github.com/rust-lang/rust/pull/46798) `os_str_bytes` was still split into `sys::{unix, redox, wasi, etc.}::os_str`. However, now that is no longer the case, there is not much reason for the `bytestring` functionality to be separate from `os_str_bytes`; I don't think it is very likely that another part of std will need to handle formatting byte strings that are not os-strings in the future (everything should be `utf8`). This is why this PR merges the functionality of `bytestring` directly into the debug implementation in `os_str_bytes`.
2021-07-02Remove unstable `Cursor::remaining`Sören Meier-26/+0
2021-07-02Fix double import in wasm threadThomas Versteeg-1/+0
The `unsupported` type is imported two times, as `super::unsupported` and as `crate::sys::unsupported`, throwing an error. Remove `super::unsupported` in favor of the other.
2021-07-02Remove & from Command::args calls in documentationKonrad Borowski-2/+2
Now that arrays implement `IntoIterator`, using `&` is no longer necessary. This makes examples easier to understand.
2021-07-02Auto merge of #85746 - m-ou-se:io-error-other, r=joshtriplettbors-73/+96
Redefine `ErrorKind::Other` and stop using it in std. This implements the idea I shared yesterday in the libs meeting when we were discussing how to handle adding new `ErrorKind`s to the standard library: This redefines `Other` to be for *user defined errors only*, and changes all uses of `Other` in the standard library to a `#[doc(hidden)]` and permanently `#[unstable]` `ErrorKind` that users can not match on. This ensures that adding `ErrorKind`s at a later point in time is not a breaking change, since the user couldn't match on these errors anyway. This way, we use the `#[non_exhaustive]` property of the enum in a more effective way. Open questions: - How do we check this change doesn't cause too much breakage? Will a crate run help and be enough? - How do we ensure we don't accidentally start using `Other` again in the standard library? We don't have a `pub(not crate)` or `#[deprecated(in this crate only)]`. cc https://github.com/rust-lang/rust/pull/79965 cc `@rust-lang/libs` `@ijackson` r? `@dtolnay`
2021-07-01add owned locked stdio handlesTaylor Yu-1/+397
Add stderr_locked, stdin_locked, and stdout_locked free functions to obtain owned locked stdio handles in a single step. Also add into_lock methods to consume a stdio handle and return an owned lock. These methods will make it easier to use locked stdio handles without having to deal with lifetime problems or keeping bindings to the unlocked handles around.
2021-07-01Stabilize `Seek::rewind`Aris Merchant-2/+5
2021-07-02Rollup merge of #86783 - mark-i-m:mutex-drop-unsized, r=XanewokYuki Okushi-20/+20
Move Mutex::unlock to T: ?Sized r? ``@mbrubeck`` cc https://github.com/rust-lang/rust/issues/81872
2021-07-01Document iteration order of `retain` functionsJanik Rabe-0/+2
For `HashSet` and `HashMap`, this simply copies the comment from `BinaryHeap::retain`. For `BTreeSet` and `BTreeMap`, this adds an additional guarantee that wasn't previously documented. I think that because these data structures are inherently ordered and other functions guarantee ordered iteration, it makes sense to provide this guarantee for `retain` as well.
2021-07-01Move Mutex::unlock to T: ?SizedMark Mansi-20/+20
2021-06-30impl From<[(K, V); N]> for std::collectionsbstrie-21/+108
2021-06-30Remove "length" doc aliasesAmanieu d'Antras-3/+0
2021-06-30Remove "delete" doc aliasesAmanieu d'Antras-5/+0
2021-06-30impl Default, Copy, Clone for std::io::Sink and EmptyIan Jackson-0/+2
The omission of Sink: Default is causing me a slight inconvenience in a test harness. There seems little reason for this and Empty not to be Clone and Copy too. I have made all three of these insta-stable, because: AIUI Copycan only be derived, and I was not able to find any examples of how to unstably derive it. I think it is probably not possible. I hunted through the git history for precedent and found 79b8ad84c84481a43704213cd0948d2ba0ea63b4 Implement `Copy` for `IoSlice` https://github.com/rust-lang/rust/pull/69403 which was also insta-stable. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-06-29Use diagnostic items to check for Send, UnwindSafe and RefUnwindSafe traitsRoxane Fruytier-2/+2
2021-06-29Remove lang items Send, UnwindSafe and RefUnwindSafeRoxane Fruytier-2/+2
2021-06-28Update to new bootstrap compilerMark Rousskov-3/+2
2021-06-28Auto merge of #82624 - ojeda:rwlock-example-deadlock, r=JohnTitorbors-1/+13
RWLock: Add deadlock example Suggested in https://github.com/rust-lang/rust/pull/82596 but it was a bit too late. `@matklad` `@azdavis` `@sfackler`
2021-06-26Auto merge of #86586 - Smittyvb:https-everywhere, r=petrochenkovbors-14/+14
Use HTTPS links where possible While looking at #86583, I wondered how many other (insecure) HTTP links were in `rustc`. This changes most other `http` links to `https`. While most of the links are in comments or documentation, there are a few other HTTP links that are used by CI that are changed to HTTPS. Notes: - I didn't change any to or in licences - Some links don't support HTTPS :( - Some `http` links were dead, in those cases I upgraded them to their new places (all of which used HTTPS)
2021-06-26Auto merge of #86637 - ehuss:spellings, r=dtolnaybors-4/+4
Fix a few misspellings.
2021-06-25Fix a few misspellings.Eric Huss-4/+4
2021-06-25Restore original ordering of `ErrorKind::Other`.Mara Bos-8/+9
2021-06-25Add Integer::{log,log2,log10} variantsYoshua Wuyts-0/+1
2021-06-26Rollup merge of #86592 - jhpratt:non_exhaustive, r=JohnTitorYuki Okushi-12/+9
Use `#[non_exhaustive]` where appropriate Due to the std/alloc split, it is not possible to make `alloc::collections::TryReserveError::AllocError` non-exhaustive without having an unstable, doc-hidden method to construct (which negates the benefits from `#[non_exhaustive]`). `@rustbot` label +C-cleanup +T-libs +S-waiting-on-review
2021-06-24Auto merge of #86467 - ChrisDenton:win-env-clear, r=JohnTitorbors-0/+15
Windows: Fix `Command::env_clear` so it works if no variables are set Previously, it would error unless at least one new environment variable was added. The missing null presumably meant that Windows was reading random memory in that case. See: [CreateProcessW](https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessw) (scroll down to `lpEnvironment`). Essentially the environment block is a null terminated list of null terminated strings and an empty list is `\0\0` and not `\0`. EDIT: Oh, [CreateEnvironmentBlock](https://docs.microsoft.com/en-gb/windows/win32/api/userenv/nf-userenv-createenvironmentblock) states this much more explicitly. Fixes #31259
2021-06-24Test that `env_clear` works on WindowsChris Denton-0/+9
2021-06-24Use `#[non_exhaustive]` where appropriateJacob Pratt-12/+9
Due to the std/alloc split, it is not possible to make `alloc::collections::TryReserveError::AllocError` non-exhaustive without having an unstable, doc-hidden method to construct (which negates the benefits from `#[non_exhaustive]`.
2021-06-24make docs clearer about how hidden files are dealt withMichael Hall-5/+19
2021-06-24change return signature for split_file_at_dotMichael Hall-6/+8
2021-06-23Use HTTPS links where possibleSmitty-14/+14
2021-06-22Auto merge of #84910 - eopb:stabilize_int_error_matching, r=yaahcbors-7/+1
stabilize `int_error_matching` closes #22639 > It has been over half a year since https://github.com/rust-lang/rust/pull/77640#pullrequestreview-511263516, and the indexing question is rejected in https://github.com/rust-lang/rust/pull/79728#pullrequestreview-633030341, so I guess we can submit another stabilization attempt? 😉 _Originally posted by `@kennytm` in https://github.com/rust-lang/rust/issues/22639#issuecomment-831738266_
2021-06-22postpone stabilizaton by one releaseEthan Brierley-1/+1
2021-06-22Auto merge of #86527 - JohnTitor:rollup-cbu78g4, r=JohnTitorbors-177/+277
Rollup of 11 pull requests Successful merges: - #85054 (Revert SGX inline asm syntax) - #85182 (Move `available_concurrency` implementation to `sys`) - #86037 (Add `io::Cursor::{remaining, remaining_slice, is_empty}`) - #86114 (Reopen #79692 (Format symbols under shared frames)) - #86297 (Allow to pass arguments to rustdoc-gui tool) - #86334 (Resolve type aliases to the type they point to in intra-doc links) - #86367 (Fix comment about rustc_inherit_overflow_checks in abs().) - #86381 (Add regression test for issue #39161) - #86387 (Remove `#[allow(unused_lifetimes)]` which is now unnecessary) - #86398 (Add regression test for issue #54685) - #86493 (Say "this enum variant takes"/"this struct takes" instead of "this function takes") Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
2021-06-22Rollup merge of #86114 - JDuchniewicz:feat/panic-frame-fmt, r=yaahcYuki Okushi-3/+2
Reopen #79692 (Format symbols under shared frames) Reopening #79692.
2021-06-22Rollup merge of #86037 - soerenmeier:cursor_remaining, r=yaahcYuki Okushi-4/+85
Add `io::Cursor::{remaining, remaining_slice, is_empty}` Tracking issue: #86369 I came across an inconvenience when answering the following [Stack Overflow](https://stackoverflow.com/questions/67831170) question. To get the remaining slice you have to call `buff.fill_buf().unwrap()`. Which in my opinion doesn't really tell you what is returned (in the context of Cursor). To improve readability and convenience when using Cursor i propose adding the method `remaining`. The next thing i found inconvenient (unnecessary long) was detecting if the cursor reached the end. There are a few ways this can be achieved right now: - `buff.fill_buf().unwrap().is_empty()` - `buff.position() >= buff.get_ref().len()` - `buff.bytes().next().is_none()` Which all seem a bit unintuitive, hidden in trait documentations or just a bit long for such a simple task. Therefor i propose another method called `is_empty`, maybe with another name, since this one may leave room for interpretation on what really is empty (the underlying slice, the remaining slice or maybe the position). Since it seemed easier to create this PR instead of an RFC i did that, if an RFC is wanted, i can close this PR and write an RFC first.
2021-06-22Rollup merge of #85182 - CDirkx:available_concurrency, r=JohnTitorYuki Okushi-162/+182
Move `available_concurrency` implementation to `sys` This splits out the platform-specific implementation of `available_concurrency` to the corresponding platforms under `sys`. No changes are made to the implementation. Tidy didn't lint against this code being originally added outside of `sys` because of a bug (see #84677), this PR also reverts the exclusion that was introduced in that bugfix. Tracking issue of `available_concurrency`: #74479
2021-06-22Rollup merge of #85054 - jethrogb:jb/sgx-inline-asm, r=AmanieuYuki Okushi-8/+8
Revert SGX inline asm syntax This was erroneously changed in #83387
2021-06-21Auto merge of #86383 - shamatar:slice_len_lowering, r=bjorn3bors-1/+1
Add MIR pass to lower call to `core::slice::len` into `Len` operand During some larger experiment with range analysis I've found that code like `let l = slice.len()` produces different MIR then one found in bound checks. This optimization pass replaces terminators that are calls to `core::slice::len` with just a MIR operand and Goto terminator. It uses some heuristics to remove the outer borrow that is made to call `core::slice::len`, but I assume it can be eliminated, just didn't find how. Would like to express my gratitude to `@oli-obk` who helped me a lot on Zullip
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-23 08:52:12 +0000