about summary refs log tree commit diff
path: root/library/std/src
AgeCommit message (Collapse)AuthorLines
2021-05-29Add has_data_left() to BufReadYuhanLiin-0/+41
2021-05-29Add IoSlice(Mut)::advanceThomas de Zeeuw-2/+54
Advance the internal cursor of a single slice.
2021-05-29Rename IoSlice(Mut)::advance to advance_sliceThomas de Zeeuw-28/+27
To make way for a new IoSlice(Mut)::advance function that advances a single slice. Also changes the signature to accept a `&mut &mut [IoSlice]`, not returning anything. This will better match the future IoSlice::advance function.
2021-05-28Refactor windows sockets impl methodsMichael-133/+173
2021-05-28Auto merge of #85745 - veber-alex:panic_any, r=m-ou-sebors-0/+1
Add #[track_caller] to panic_any Report the panic location from the user code. ```rust use std::panic; use std::panic::panic_any; fn main() { panic::set_hook(Box::new(|panic_info| { if let Some(location) = panic_info.location() { println!( "panic occurred in file '{}' at line {}", location.file(), location.line(), ); } else { println!("panic occurred but can't get location information..."); } })); panic_any(42); } ```` Before: `panic occurred in file '/rustc/ff2c947c00f867b9f012e28ba88cecfbe556f904/library/std/src/panic.rs' at line 59` After: `panic occurred in file 'src/main.rs' at line 17`
2021-05-27Possible errors when reading file metadata are platform specificChris Denton-9/+9
In particular the `is_dir`, `is_file` and `exists` functions says that querying a file requires querying the directory. On Windows this is not normally true.
2021-05-27Review fixes + doc-featuresMax Wase-6/+8
2021-05-27Document `From` impls in path.rsDeadbeef-0/+24
2021-05-27Tracking issue add.Max Wase-2/+2
2021-05-27Fix `is_symlink()` method for `Path` using added `is_symlink()` method for ↵Max Wase-3/+26
`Metadata`
2021-05-27Add `is_symlink()` method for `Path`.Max Wase-0/+26
2021-05-27Add #[track_caller] to panic_anyAlex Veber-0/+1
2021-05-26Rename opensbd to openbsdAlbert Ford-3/+3
2021-05-27Rollup merge of #85719 - elichai:cstring-into_inner-inline, r=m-ou-seDylan DPC-0/+1
Add inline attr to CString::into_inner so it can optimize out NonNull checks It seems that currently if you convert any of the standard library's container to a pointer and then to a NonNull pointer, all will optimize out the NULL check except `CString`(https://godbolt.org/z/YPKW9G5xn), because for some reason `CString::into_inner` isn't inlined even though it's a private function that should compile into a simple `mov` instruction. Adding a simple `#[inline]` attribute solves this, code example: ```rust use std::ffi::CString; use std::ptr::NonNull; pub fn cstring_nonull(mut n: CString) -> NonNull<i8> { NonNull::new(CString::into_raw(n)).unwrap() } ``` assembly before: ```asm __ZN3wat14cstring_nonull17h371c755bcad76294E: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset %rbp, -16 movq %rsp, %rbp .cfi_def_cfa_register %rbp callq __ZN3std3ffi5c_str7CString10into_inner17h28ece07b276e2878E testq %rax, %rax je LBB0_2 popq %rbp retq LBB0_2: leaq l___unnamed_1(%rip), %rdi leaq l___unnamed_2(%rip), %rdx movl $43, %esi callq __ZN4core9panicking5panic17h92a83fa9085a8f73E .cfi_endproc .section __TEXT,__const l___unnamed_1: .ascii "called `Option::unwrap()` on a `None` value" l___unnamed_3: .ascii "wat.rs" .section __DATA,__const .p2align 3 l___unnamed_2: .quad l___unnamed_3 .asciz "\006\000\000\000\000\000\000\000\006\000\000\000(\000\000" ``` Assembly after: ```asm __ZN3wat14cstring_nonull17h9645eb9341fb25d7E: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset %rbp, -16 movq %rsp, %rbp .cfi_def_cfa_register %rbp movq %rdi, %rax popq %rbp retq .cfi_endproc ``` (Related discussion on zulip: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/NonNull.20From.3CBox.3CT.3E.3E)
2021-05-26Add inline attr to private CString::into_innerElichai Turkel-0/+1
2021-05-26Rollup merge of #85672 - CDirkx:ip, r=Mark-SimulacrumYuki Okushi-8/+17
Move stability attribute for items under the `ip` feature The `#[unstable]` attribute for items under the `ip` feature is currently located on the `std::net::ip` module itself. This is unusual, and less readable. This has sidetracked discussion about these items numerous times (https://github.com/rust-lang/rust/pull/60145#issuecomment-498016572, https://github.com/rust-lang/rust/pull/76098#discussion_r530463543, https://github.com/rust-lang/rust/pull/76098#discussion_r558067755, https://github.com/rust-lang/rust/pull/75019#discussion_r467464300, https://github.com/rust-lang/rust/pull/75019#issuecomment-672888727) and lead to incorrect assumptions about which items are actually stable (https://github.com/rust-lang/rust/pull/60145#issuecomment-485970669, https://github.com/rust-lang/rust/pull/76098#discussion_r530444275). This PR moves the attribute from the module to the items themselves.
2021-05-26Rollup merge of #85529 - tlyu:trylock-errors, r=JohnTitorYuki Okushi-9/+28
doc: clarify Mutex::try_lock, etc. errors Clarify error returns from Mutex::try_lock, RwLock::try_read, RwLock::try_write to make it more obvious that both poisoning and the lock being already locked are possible errors.
2021-05-25Add tracking issue for edition-specific preludes.Mara Bos-7/+7
2021-05-25Fix documentation style inconsistenciesChristiaan Dirkx-26/+26
2021-05-25Move stability attribute for methods under the `ip` feature from the module ↵Christiaan Dirkx-8/+17
to the methods themselves
2021-05-25Auto merge of #84985 - pietroalbini:bootstrap-1.54, r=Mark-Simulacrumbors-13/+6
Bump bootstrap compiler to beta 1.53.0 This PR bumps the bootstrap compiler to version 1.53.0 beta, as part of our usual release process (this was supposed to be Wednesday's step, but creating the beta release took longer than expected). The PR also includes the "Bootstrap: skip rustdoc fingerprint for building docs" commit, see the reasoning [on Zulip](https://zulip-archive.rust-lang.org/241545trelease/88450153betabootstrap.html). r? `@Mark-Simulacrum`
2021-05-24Rollup merge of #85271 - th1000s:master, r=JohnTitorGuillaume Gomez-2/+2
Fix indentation in move keyword documentation See (at the time of writing) the second example code block with `create_fn()` at https://doc.rust-lang.org/std/keyword.move.html
2021-05-24remove cfg(bootstrap)Pietro Albini-13/+6
2021-05-24minor rewording after reviewTaylor Yu-6/+6
Use "the `WouldBlock` error" instead of "the error `WouldBlock`", etc.
2021-05-23Auto merge of #85490 - CDirkx:fix-vxworks, r=dtolnaybors-5/+31
Fix `vxworks` Some PRs made the `vxworks` target not build anymore. This PR fixes that: - #82973: copy `ExitStatusError` implementation from `unix`. - #84716: no `libc::chroot` available on `vxworks`, so for now don't implement `os::unix::fs::chroot`.
2021-05-23Rollup merge of #85334 - r00ster91:patch-8, r=dtolnayDylan DPC-0/+3
Add doc aliases to `unit` I think it makes sense for `unit` to have the same doc aliases as `tuple` does.
2021-05-23Rollup merge of #85288 - Geal:clarify-std-io-read, r=dtolnayDylan DPC-1/+7
add an example to explain std::io::Read::read returning 0 in some cases I have always found the explanation about `Read::read` returning 0 to indicate EOF but not indefinitely, so here's more info using Linux as example. I can also add example code if necessary
2021-05-23Rollup merge of #84758 - ChrisDenton:dllimport, r=dtolnayDylan DPC-166/+168
MSVC: Avoid using jmp stubs for dll function imports Windows import libraries contain two symbols for every function: `__imp_FunctionName` and `FunctionName` (where `FunctionName` is the name of the function to be imported). `__imp_FunctionName` contains the address of the imported function. This will be filled in by the Windows executable loader at runtime. `FunctionName` contains a jmp stub that simply jumps to the address given by `__imp_FunctionName`. E.g. it's a function that solely contains a single jmp instruction: ```asm jmp __imp_FunctionName ``` When using an external DLL function in Rust, by default the linker will link to FunctionName, causing a bit of indirection at runtime. In Microsoft's C++ it's possible to instead tell it to insert calls to the address in `__imp_FunctionName` by using the `__declspec(dllimport)` attribute. In Rust it's possible to get effectively the same behaviour using the `#[link]` attribute on `extern` blocks. ---- The second commit also merges multiple `extern` blocks into one block. This is because otherwise Rust will currently create duplicate linker arguments for each block. In this case having duplicates shouldn't matter much other than the noise when displaying the linker command.
2021-05-21Add std::os::unix::fs::DirEntryExt2::file_name_ref(&self) -> &OsStrAaron Rennow-0/+42
DirEntryExt2 is a new trait with the same purpose as DirEntryExt, but sealed
2021-05-21Auto merge of #85060 - ChrisDenton:win-file-exists, r=yaahcbors-8/+72
Windows implementation of feature `path_try_exists` Draft of a Windows implementation of `try_exists` (#83186). The first commit reorganizes the code so I would be interested to get some feedback on if this is a good idea or not. It moves the `Path::try_exists` function to `fs::exists`. leaving the former as a wrapper for the latter. This makes it easier to provide platform specific implementations and matches the `fs::metadata` function. The other commit implements a Windows specific variant of `exists`. I'm still figuring out my approach so this is very much a first draft. Eventually this will need some more eyes from knowledgable Windows people.
2021-05-20doc: clarify Mutex::try_lock, etc. errorsTaylor Yu-9/+28
Clarify error returns from Mutex::try_lock, RwLock::try_read, RwLock::try_write to make it more obvious that both poisoning and the lock being already locked are possible errors.
2021-05-20Auto merge of #85521 - alexcrichton:less-tls-inline, r=Mark-Simulacrumbors-13/+13
std: Don't inline TLS accessor on MinGW This is causing [issues] on Cargo's own CI for MinGW and given the original investigation there's no reason that MinGW should work when MSVC doesn't, this this tweaks the MSVC exception to being a Windows exception. [issues]: https://github.com/rust-lang/cargo/runs/2626676503?check_suite_focus=true#step:9:2453
2021-05-20std: Don't inline TLS accessor on MinGWAlex Crichton-13/+13
This is causing [issues] on Cargo's own CI for MinGW and given the original investigation there's no reason that MinGW should work when MSVC doesn't, this this tweaks the MSVC exception to being a Windows exception. [issues]: https://github.com/rust-lang/cargo/runs/2626676503?check_suite_focus=true#step:9:2453
2021-05-20Rollup merge of #85275 - CDirkx:memchr, r=m-ou-seGuillaume Gomez-8/+10
Move `std::memchr` to `sys_common` `std::memchr` is a thin abstraction over the different `memchr` implementations in `sys`, along with documentation and tests. The module is only used internally by `std`, nothing is exported externally. Code like this is exactly what the `sys_common` module is for, so this PR moves it there.
2021-05-20Auto merge of #85486 - RalfJung:rollup-4ibcxuu, r=RalfJungbors-0/+1
Rollup of 8 pull requests Successful merges: - #84717 (impl FromStr for proc_macro::Literal) - #85169 (Add method-toggle to <details> for methods) - #85287 (Expose `Concurrent` (private type in public i'face)) - #85315 (adding time complexity for partition_in_place iter method) - #85439 (Add diagnostic item to `CStr`) - #85464 (Fix UB in documented example for `ptr::swap`) - #85470 (Fix invalid CSS rules for a:hover) - #85472 (CTFE Machine: do not expose Allocation) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
2021-05-20Auto merge of #84697 - CDirkx:util, r=m-ou-sebors-46/+34
Introduce `sys_common::rt::rtprintpanic!` to replace `sys_common::util` functionality This PR introduces a new macro `rtprintpanic!`, similar to `sys_common::util::dumb_print` and uses that macro to replace all `sys_common::util` functionality.
2021-05-20Not implement `os::unix::fs::chroot` for `vxworks`Christiaan Dirkx-2/+2
2021-05-20Add `ExitStatusError` for `vxworks`Christiaan Dirkx-3/+29
2021-05-19Windows implementation of `fs::try_exists`Chris Denton-1/+30
2021-05-19Move the implementation of `Path::exists` to `sys_common::fs` so platforms ↵Chris Denton-8/+43
can specialize it Windows implementation of `fs::try_exists`
2021-05-19Windows `Command` environment variables are case-preservingChris Denton-9/+128
But comparing is case-insensitive.
2021-05-20Rollup merge of #85439 - mgacek8:add_diagnostic_item_to_CStr_type, r=davidtwcoRalf Jung-0/+1
Add diagnostic item to `CStr` Required for clippy issue: https://github.com/rust-lang/rust-clippy/issues/7145
2021-05-19Auto merge of #84876 - alexcrichton:inline-thread-locals-cross-crate, ↵bors-0/+24
r=Mark-Simulacrum std: Attempt again to inline thread-local-init across crates Issue #25088 has been part of `thread_local!` for quite some time now. Historical attempts have been made to add `#[inline]` to `__getit` in #43931, #50252, and #59720, but these attempts ended up not landing at the time due to segfaults on Windows. In the interim though with `const`-initialized thread locals AFAIK this is the only remaining bug which is why you might want to use `#[thread_local]` over `thread_local!`. As a result I figured it was time to resubmit this and see how it fares on CI and if I can help debugging any issues that crop up. Closes #25088
2021-05-19Rename `rterr` to `rtprintpanic`Christiaan Dirkx-11/+12
2021-05-19Replace `sys_common::util::dumb_print` with `rterr!`Christiaan Dirkx-18/+6
2021-05-19Replace `sys_common::util::report_overflow` with `rterr!`Christiaan Dirkx-14/+10
2021-05-19Remove `sys_common::util::abort`Christiaan Dirkx-11/+6
2021-05-19Introduce `sys_common::rt::rterr!`Christiaan Dirkx-1/+9
2021-05-19Auto merge of #85458 - jackh726:rollup-zvvybmt, r=jackh726bors-1/+1
Rollup of 8 pull requests Successful merges: - #83366 (Stabilize extended_key_value_attributes) - #83767 (Fix v0 symbol mangling bug) - #84883 (compiletest: "fix" FileCheck with --allow-unused-prefixes) - #85274 (Only pass --[no-]gc-sections if linker is GNU ld.) - #85297 (bootstrap: build cargo only if requested in tools) - #85396 (rustdoc: restore header sizes) - #85425 (Fix must_use on `Option::is_none`) - #85438 (Fix escape handling) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
2021-05-18Rollup merge of #83366 - jyn514:stabilize-key-value-attrs, r=petrochenkovJack Huey-1/+1
Stabilize extended_key_value_attributes Closes https://github.com/rust-lang/rust/issues/44732. Closes https://github.com/rust-lang/rust/issues/78835. Closes https://github.com/rust-lang/rust/issues/82768 (by making it irrelevant). # Stabilization report ## Summary This stabilizes using macro expansion in key-value attributes, like so: ```rust #[doc = include_str!("my_doc.md")] struct S; #[path = concat!(env!("OUT_DIR"), "/generated.rs")] mod m; ``` See Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455) for alternatives that were considered and rejected ("why accept no more and no less?") This has been available on nightly since 1.50 with no major issues. ## Notes ### Accepted syntax The parser accepts arbitrary Rust expressions in this position, but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g., `#[doc]`). Note that decorators and the like may be able to observe other expression forms. ### Expansion ordering Expansion of macro expressions in "inert" attributes occurs after decorators have executed, analogously to macro expressions appearing in the function body or other parts of decorator input. There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion, that can work). ## Test cases - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs The feature has also been dogfooded extensively in the compiler and standard library: - https://github.com/rust-lang/rust/pull/83329 - https://github.com/rust-lang/rust/pull/83230 - https://github.com/rust-lang/rust/pull/82641 - https://github.com/rust-lang/rust/pull/80534 ## Implementation history - Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412 - Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121 - Preliminary work to restrict expansion that would conflict with this feature: https://github.com/rust-lang/rust/pull/77271 - Initial implementation: https://github.com/rust-lang/rust/pull/78837 - Fix for an ICE: https://github.com/rust-lang/rust/pull/80563 ## Unresolved Questions ~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns, but they have been resolved as of this final report.~~ ## Additional Information There are two workarounds that have a similar effect for `#[doc]` attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons: ```rust macro_rules! forward_inner_docs { ($e:expr => $i:item) => { #[doc = $e] $i }; } forward_inner_docs!(include_str!("lib.rs") => struct S {}); ``` This also works for other attributes (like `#[path = concat!(...)]`). The other is to use `doc(include)`: ```rust #![feature(external_doc)] #[doc(include = "lib.rs")] struct S {} ``` The first works, but is non-trivial for people to discover, and difficult to read and maintain. The second is a strange special-case for a particular use of the macro. This generalizes it to work for any use case, not just including files. I plan to remove `doc(include)` when this is stabilized (https://github.com/rust-lang/rust/pull/82539). The `forward_inner_docs` workaround will still compile without warnings, but I expect it to be used less once it's no longer necessary.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-22 17:52:52 +0000