about summary refs log tree commit diff
path: root/src/libstd
AgeCommit message (Collapse)AuthorLines
2019-11-30Rollup merge of #66705 - pitdicker:atomic_mut_ptr, r=KodrAusMazdak Farrokhzad-5/+6
Atomic as_mut_ptr I encountered the following pattern a few times: In Rust we use some atomic type like `AtomicI32`, and an FFI interface exposes this as `*mut i32` (or some similar `libc` type). It was not obvious to me if a just transmuting a pointer to the atomic was acceptable, or if this should use a cast that goes through an `UnsafeCell`. See https://github.com/rust-lang/rust/issues/66136#issuecomment-557802477 Transmuting the pointer directly: ```rust let atomic = AtomicI32::new(1); let ptr = &atomic as *const AtomicI32 as *mut i32; unsafe { ffi(ptr); } ``` A dance with `UnsafeCell`: ```rust let atomic = AtomicI32::new(1); unsafe { let ptr = (&*(&atomic as *const AtomicI32 as *const UnsafeCell<i32>)).get(); ffi(ptr); } ``` Maybe in the end both ways could be valid. But why not expose a direct method to get a pointer from the standard library? An `as_mut_ptr` method on atomics can be safe, because only the use of the resulting pointer is where things can get unsafe. I documented its use for FFI, and "Doing non-atomic reads and writes on the resulting integer can be a data race." The standard library could make use this method in a few places in the WASM module. cc @RalfJung as you answered my original question.
2019-11-30Auto merge of #66887 - dtolnay:rollup-uxowp8d, r=Centrilbors-5378/+6081
Rollup of 4 pull requests Successful merges: - #66818 (Format libstd/os with rustfmt) - #66819 (Format libstd/sys with rustfmt) - #66820 (Format libstd with rustfmt) - #66847 (Allow any identifier as format arg name) Failed merges: r? @ghost
2019-11-29Rollup merge of #66820 - dtolnay:fmt3, r=Dylan-DPCDavid Tolnay-2660/+2897
Format libstd with rustfmt (Same strategy as #66691.) This commit applies rustfmt with rust-lang/rust's default settings to files in src/libstd *that are not involved in any currently open PR* to minimize merge conflicts, and are not part of libstd/os (#66818) or libstd/sys (#66819). The list of files involved in open PRs was determined by querying GitHub's GraphQL API [with this script](https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8). With the list of files from the script in outstanding_files, the relevant commands were: $ find src/libstd -name '*.rs' \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ rg libstd outstanding_files | xargs git checkout -- Repeating this process several months apart should get us coverage of most of the rest of libstd. To confirm no funny business: $ git checkout $THIS_COMMIT^ $ git show --pretty= --name-only $THIS_COMMIT \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ git diff $THIS_COMMIT # there should be no difference
2019-11-29Rollup merge of #66819 - dtolnay:fmt2, r=kennytmDavid Tolnay-2285/+2527
Format libstd/sys with rustfmt (Same strategy as #66691.) This commit applies rustfmt with rust-lang/rust's default settings to files in src/libstd/sys *that are not involved in any currently open PR* to minimize merge conflicts. The list of files involved in open PRs was determined by querying GitHub's GraphQL API [with this script](https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8). With the list of files from the script in outstanding_files, the relevant commands were: $ find src/libstd/sys -name '*.rs' \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ rg libstd/sys outstanding_files | xargs git checkout -- Repeating this process several months apart should get us coverage of most of the rest of the files. To confirm no funny business: $ git checkout $THIS_COMMIT^ $ git show --pretty= --name-only $THIS_COMMIT \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ git diff $THIS_COMMIT # there should be no difference
2019-11-29Format libstd with rustfmtDavid Tolnay-2660/+2897
This commit applies rustfmt with rust-lang/rust's default settings to files in src/libstd *that are not involved in any currently open PR* to minimize merge conflicts. THe list of files involved in open PRs was determined by querying GitHub's GraphQL API with this script: https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8 With the list of files from the script in outstanding_files, the relevant commands were: $ find src/libstd -name '*.rs' \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ rg libstd outstanding_files | xargs git checkout -- Repeating this process several months apart should get us coverage of most of the rest of libstd. To confirm no funny business: $ git checkout $THIS_COMMIT^ $ git show --pretty= --name-only $THIS_COMMIT \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ git diff $THIS_COMMIT # there should be no difference
2019-11-29Format libstd/sys with rustfmtDavid Tolnay-2285/+2527
This commit applies rustfmt with rust-lang/rust's default settings to files in src/libstd/sys *that are not involved in any currently open PR* to minimize merge conflicts. THe list of files involved in open PRs was determined by querying GitHub's GraphQL API with this script: https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8 With the list of files from the script in outstanding_files, the relevant commands were: $ find src/libstd/sys -name '*.rs' \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ rg libstd/sys outstanding_files | xargs git checkout -- Repeating this process several months apart should get us coverage of most of the rest of the files. To confirm no funny business: $ git checkout $THIS_COMMIT^ $ git show --pretty= --name-only $THIS_COMMIT \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ git diff $THIS_COMMIT # there should be no difference
2019-11-29Format libstd/os with rustfmtDavid Tolnay-433/+657
This commit applies rustfmt with rust-lang/rust's default settings to files in src/libstd/os *that are not involved in any currently open PR* to minimize merge conflicts. THe list of files involved in open PRs was determined by querying GitHub's GraphQL API with this script: https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8 With the list of files from the script in outstanding_files, the relevant commands were: $ find src/libstd/os -name '*.rs' \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ rg libstd/os outstanding_files | xargs git checkout -- Repeating this process several months apart should get us coverage of most of the rest of the files. To confirm no funny business: $ git checkout $THIS_COMMIT^ $ git show --pretty= --name-only $THIS_COMMIT \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ git diff $THIS_COMMIT # there should be no difference
2019-11-30Auto merge of #66873 - RalfJung:miri-args, r=dtolnaybors-1/+7
really_init cmdline args on Miri r? @joshtriplett Closes #66862.
2019-11-29Rollup merge of #66766 - RalfJung:panic-comments, r=SimonSapinRalf Jung-22/+28
Panic machinery comments and tweaks This is mostly more comments, but I also renamed some things: * `BoxMeUp::box_me_up` is not terribly descriptive, and since this is a "take"-style method (the argument is `&mut self` but the return type is fully owned, even though you can't tell from the type) I chose a name involving "take". * `continue_panic_fmt` was very confusing as it was entirely unclear what was being continued -- for some time I thought "continue" might be the same as "resume" for a panic, but that's something entirely different. So I renamed this to `begin_panic_handler`, matching the `begin_panic*` theme of the other entry points. r? @Dylan-DPC @SimonSapin
2019-11-29really_init cmdline args on MiriRalf Jung-1/+7
2019-11-29Auto merge of #66547 - leo60228:procfs-fallback, r=dtolnaybors-1/+39
Fallback to .init_array when no arguments are available on glibc Linux Linux is one of the only platforms where `std::env::args` doesn't work in a cdylib.
2019-11-26Fix spelling typosBrian Wignall-4/+4
2019-11-26rename update_count_then_panic -> rust_panic_without_hookRalf Jung-4/+5
2019-11-26explain why __rust_start_panic does not take a BoxRalf Jung-0/+2
2019-11-26expand commentRalf Jung-3/+4
2019-11-26abort on BoxMeUp misuseRalf Jung-2/+3
2019-11-26panic_handler -> begin_panic_handler (and more comments)Ralf Jung-4/+7
2019-11-25more panicking commentsRalf Jung-1/+3
2019-11-25Rollup merge of #66694 - RalfJung:panic-comments, r=Dylan-DPCPietro Albini-2/+4
Add some comments to panic runtime
2019-11-25Rollup merge of #66512 - jsgf:process-argv0, r=Dylan-DPCPietro Albini-10/+35
Add unix::process::CommandExt::arg0 This allows argv[0] to be overridden on the executable's command-line. This also makes the program executed independent of argv[0]. Does Fuchsia have the same semantics? I'm assuming so. Addresses: #66510
2019-11-25better comment and rename BoxMeUp::box_me_up to take_boxRalf Jung-4/+5
2019-11-25Rename continue_panic_fmt to panic_handler, and make it the #[panic_handler] ↵Ralf Jung-10/+5
directly The "continue" in the name was really confusing; it sounds way too much like "resume" which is a totally different concept around panics.
2019-11-24Use as_mut_ptr instead of castsPaul Dicker-5/+6
2019-11-24expand type info on __rust_start_panicRalf Jung-0/+2
2019-11-24Auto merge of #66393 - ssomers:hash_benches, r=dtolnaybors-15/+50
introduce benchmarks of HashSet operations To avoid goofs such as corrected by #66280, I added benchmarks of binary HashSet operations. Due to the fact x.py keeps recompiling the whole shebang (or at least a big part of it) whenever you touch the test code, and because piling up all tests in one file does not strike me as future proof, I tried moving the hash benches to the separate place they are for liballoc/collections/btree. But it turns out that, in a cleaned checkout, x.py still recompiles the whole shebang whenever you touch the test code (PS or when you add or delete any irrelevant file). So I'm not going to add more tests, and I doubt others will, and these tests have proven their point already, so this PR is kind of pointless
2019-11-24panicking commentsRalf Jung-2/+2
2019-11-22Make std::sys::unix::args::init a no-op on glibc Linuxleo60228-2/+8
2019-11-22Add documentation to `std::env::args[_os]`leo60228-0/+10
2019-11-22Document ARGV_INIT_ARRAYleo60228-0/+2
2019-11-22Set .init_array priorityleo60228-1/+1
I'm not entirely sure *why*, but this fixed a problem I was having.
2019-11-22Use .init_array section on glibcleo60228-0/+20
2019-11-21Redefine `core::convert::Infallible` as `!`.Mazdak Farrokhzad-7/+0
2019-11-21Stabilize the `never_type`, written `!`.Mazdak Farrokhzad-5/+3
2019-11-20Rollup merge of #66553 - hermitcore:hermit, r=rkruppeMazdak Farrokhzad-1/+1
remove HermitCore leftovers from sys/unix HermitCore support is already moved to the directory "sys/hermit". => remove leftovers
2019-11-19HermitCore support is moved to sys/hermit, remove obsolete statement in sys/unixStefan Lankes-1/+1
2019-11-19Add unix::process::CommandExt::arg0Jeremy Fitzhardinge-10/+35
This allows argv[0] to be overridden on the executable's command-line. This also makes the program executed independent of argv[0]. Does Fuchsia have the same semantics? Addresses: #66510
2019-11-19Rollup merge of #66538 - dingelish:master, r=CentrilMazdak Farrokhzad-1/+0
Remove compiler_builtins_lib feature from libstd Test if we can close #66368 by this patch.
2019-11-19Rollup merge of #66511 - haraldh:error_chain_nocopy, r=dtolnayMazdak Farrokhzad-1/+1
std::error::Chain: remove Copy remove Copy from Iterator as per comment https://github.com/rust-lang/rust/issues/58520#issuecomment-553682166 Tracker: #58520
2019-11-18Remove compiler_builtins_lib feature from libstdYu Ding-1/+0
2019-11-18std::error::Chain: remove CopyHarald Hoyer-1/+1
remove Copy from Iterator as per comment https://github.com/rust-lang/rust/issues/58520#issuecomment-553682166
2019-11-17Rollup merge of #66465 - mulimoen:fix_lifetime_elision_not_shown, r=rkruppeYuki Okushi-1/+1
add missing 'static lifetime in docs
2019-11-17Rollup merge of #66395 - jplatte:centralize-panic-docs, r=Dylan-DPCYuki Okushi-47/+1
Centralize panic macro documentation This is just the main commit from #61511 (which got closed because the author didn't reply) cherry-picked on the current master. Building `core` and `std` on this branch in stage 1 succeeded, which I thinks means the issues from the previous PR should be gone (but let's see what CI says).
2019-11-16add missing 'static lifetime in docsMagnus Ulimoen-1/+1
The example refers to a static lifetime parameter that can be elided. This parameter is not included, meaning lifetime elision is not shown.
2019-11-15Rollup merge of #66350 - hermitcore:hermit, r=rkruppeMazdak Farrokhzad-0/+3
protect creation of destructors by a mutex - add on HermitCore an additional lock to protect static data
2019-11-15Rollup merge of #66398 - sfackler:no-async-nesting, r=CentrilYuki Okushi-33/+12
Remove some stack frames from `.async` calls The `Context` argument is currently smuggled through TLS for async-generated futures. The current infrastructure is closure-based, and results in an extra 6 stack frames when .awaiting an async-generated future! ``` 12: foo::async_b::{{closure}} at src/main.rs:10 13: <std::future::GenFuture<T> as core::future::future::Future>::poll::{{closure}} at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:43 14: std::future::set_task_context at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:79 15: <std::future::GenFuture<T> as core::future::future::Future>::poll at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:43 16: std::future::poll_with_tls_context::{{closure}} at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:121 17: std::future::get_task_context at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:111 18: std::future::poll_with_tls_context at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:121 19: foo::async_a::{{closure}} at src/main.rs:6 ``` While the long (medium?) term solution is to remove the use of TLS entirely, we can improve things a bit in the meantime. In particular, this commit does 2 things: 1. `get_task_context` has been inlined into `poll_with_tls_context`, removing 2 frames (16 and 17 above). 2. `set_task_context` now returns a guard type that resets the TLS rather than taking a closure, removing 2 frames (13 and 14 above). We can also remove frame 18 by removing `poll_with_tls_context` in favor of a `get_task_context` function which returns a guard, but that requires adjusting the code generated for .await, so I've left that off for now.
2019-11-15Rollup merge of #65557 - haraldh:error_iter_rename, r=sfacklerYuki Okushi-80/+12
rename Error::iter_chain() and remove Error::iter_sources() ~~Rename~~ * ~~Error::iter_chain() -> Error::chained()~~ * ~~Error::iter_sources() -> Error::ancestors()~~ * ~~ErrorIter -> Chained and Ancestors~~ according to https://github.com/rust-lang/rust/issues/58520#issuecomment-527704110 Tracker: https://github.com/rust-lang/rust/issues/58520 Edit: Rename * Error::iter_chain() -> Error::chained() * ErrorIter -> Chain So, it seems, that even Path::ancestors() includes itself. So, to avoid confusion and simplify it more, I reduced PR #65557 to only have `chained` and `Chain`. Rationale: 1. Such iterators are helpful. They should better be stabilized sooner than later. 1. self should be included. It is easy to .skip(1) it. Not including self is harmful because it is harder to add self to the iterator than to remove it. 1. The chosen name should be telling and reflect the fact that self is included. `.chained()` was chosen in honor of error-chain and because the iterator iterates over the chain of errors that is somehow included in self. 1. The resulting iterator is named `Chain` because the `error::Chain` is what we want to have.
2019-11-14introduce benchmarks of HashSet operationsStein Somers-15/+50
2019-11-14Auto merge of #66378 - rkruppe:revert-pr-65134, r=pnkfelixbors-4/+0
Revert #65134 To stop giving people on nightly reasons to `allow(improper_ctypes)` while tweaks to the lint are being prepared. cc #66220
2019-11-14Rollup merge of #66372 - ogham:patch-2, r=jonas-schievinkYuki Okushi-2/+2
Fix broken links in Ipv4Addr::is_benchmarking docs [The documentation for `Ipv4Addr::is_benchmarking`](https://doc.rust-lang.org/nightly/std/net/struct.Ipv4Addr.html#method.is_benchmarking) is correct — it has the right RFC number — but the Markdown links are broken. Looks like a copy-and-paste error and a typo. This PR fixes the links to make them clickable.
2019-11-13Remove some stack frames from `.async` callsSteven Fackler-33/+12
The `Context` argument is currently smuggled through TLS for async-generated futures. The current infrastructure is closure-based, and results in an extra 6 stack frames when .awaiting an async-generated future! ``` 12: foo::async_b::{{closure}} at src/main.rs:10 13: <std::future::GenFuture<T> as core::future::future::Future>::poll::{{closure}} at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:43 14: std::future::set_task_context at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:79 15: <std::future::GenFuture<T> as core::future::future::Future>::poll at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:43 16: std::future::poll_with_tls_context::{{closure}} at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:121 17: std::future::get_task_context at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:111 18: std::future::poll_with_tls_context at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:121 19: foo::async_a::{{closure}} at src/main.rs:6 ``` While the long (medium?) term solution is to remove the use of TLS entirely, we can improve things a bit in the meantime. In particular, this commit does 2 things: 1. `get_task_context` has been inlined into `poll_with_tls_context`, removing 2 frames (16 and 17 above). 2. `set_task_context` now returns a guard type that resets the TLS rather than taking a closure, removing 2 frames (13 and 14 above). We can also remove frame 18 by removing `poll_with_tls_context` in favor of a `get_task_context` function which returns a guard, but that requires adjusting the code generated for .await, so I've left that off for now.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-28 12:43:06 +0000