| Age | Commit message (Collapse) | Author | Lines |
|
`std::time::Duration`: improve _precision_ of terminology in docs
Changed wording of docs on `std::time::Duration` for better clarity w.r.t. the contents of the type and the purpose of its methods. (Specifically, removed the use of the word "precision" to describe the fractional part of the `Duration` because "precision" is more properly used to describe how _precise_ a value is, i.e. its granularity in this case.)
|
|
|
|
|
|
Changed wording of docs on `std::time::Duration` for better clarity
w.r.t. the contents of the type and the purpose of its methods.
|
|
fn Path::new<S: AsRef ...>(s: &S) -> &Path
Signed-off-by: NODA, Kai <nodakai@gmail.com>
|
|
Stabilize float_bits_conv for Rust 1.21
Stabilizes the `float_bits_conv` lib feature for the 1.20 release of Rust. I've initially implemented the feature in #39271 and later made PR #43025 to output quiet NaNs even on platforms with different encodings, which seems to have been the only unresolved issue of the API.
Due to PR #43025 being only applied to master this stabilisation can't happen for Rust 1.19 through the usual "stabilisation on beta" system that is being done for library APIs.
r? @BurntSushi
closes #40470.
|
|
The docs for Instant::duration_since has a confusing section on panicking. It's
much more clear without the second two sentences of description.
|
|
Rollup of 8 pull requests
- Successful merges: #43074, #43145, #43159, #43202, #43222, #43228, #43229, #43240
- Failed merges:
|
|
support pub(restricted) in thread_local! (round 2)
Resurrected #40984 now that the issue blocking it was fixed. Original description:
`pub(restricted)` was stabilized in #40556 so let's go!
Here is a [playground](https://play.rust-lang.org/?gist=f55f32f164a6ed18c219fec8f8293b98&version=nightly&backtrace=1).
I changed the interface of `__thread_local_inner!`, which is supposedly unstable but this is not checked for macros (#34097 cc @petrochenkov @jseyfried), so this may be an issue.
|
|
r=steveklabnik
Fix minor typo in std::path documentation.
Fix minor typo in `std::path` documentation.
Replace all `'C' as u8` with `b'C'`.
|
|
Fix backtrace on Redox
This fixes sys::backtrace on Redox
|
|
windows::fs::symlink_dir: fix example to actually use symlink_dir
I don't have a windows machine, so I couldn't test if this doctest still works -- but it looks trivial enough. (I know, famous last words.)
|
|
Fix sys::redox::net::tcp
A change to the upper level API needed to be filtered down
|
|
|
|
Replace all `'C' as u8` with `b'C'`.
|
|
|
|
Implement fs::rename in sys::redox
This uses a simple implementation of copy + unlink. Redox does not have a rename or link system call for a faster implementation.
|
|
Remove obsolete oom handler from sys::redox
Alloc no longer has set_oom_handler.
|
|
Document what happens on failure in path ext is_file is_dir
r? @steveklabnik
Also, what other ways could there be an error that gets discarded and returns false? Should we list them all? Should we say that any errors trying to access the metadata at that path causes it to return false, even if there might be a file or directory there?
Should I add a See also link to the original functions that do return Results?
|
|
Thread local try with
https://github.com/rust-lang/rfcs/pull/2030 was turned into this PR (the RFC was closed, but it looks like just a PR should be good).
See also: state stabilization issue: #27716
`try_with` is used in two places in std: stdio and thread_info. In stdio, it would be better if the result was passed to the closure, but in thread_info, it's better as is where the result is returned from the function call. I'm not sure which is better, but I prefer the current way as it better represents the scope.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Correct some stability attributes
These show up in rustdoc so need to be correct.
|
|
Add warning to BufWriter documentation
When using `BufWriter`, it is very easy to unintentionally ignore errors, because errors which occur when flushing buffered data when the `BufWriter` is dropped are ignored. This has been noted in a couple places: #32677, #37045.
There has been some discussion about how to fix this problem in #32677, but no solution seems likely to land in the near future. For now, anyone who wishes to have robust error handling must remember to manually call `flush()` on a `BufWriter` before it is dropped. Until a permanent fix is in place, it seems worthwhile to add a warning to that effect to the documentation.
|
|
Redox: add stat methods(); support is_symlink()
|
|
Add hint about the return code of panic!
I hope the link works on all cases, since the `unreachable` doc is copied to `std::` as well.
|
|
Allow setting the limit on std::io::Take.
Fixes https://github.com/rust-lang/rust/issues/27269.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
These show up in rustdoc so need to be correct.
|
|
|
|
Redox: Fix Condvar.wait(); do not lock mutex twice
The atomic_xchg() loop locks the mutex, so the call to mutex_lock is
incorrect, and blocks.
|
|
Fix Rustbuild linking on Illumos
Illumos (an OpenSolaris fork) expects to get several extra library references for some system functions used by Rust standard library. This commit adds required linker options to rustbuild, which is currently doesn't work on Illumos-based operating systems.
|
|
Skip the main thread's manual stack guard on Linux
Linux doesn't allocate the whole stack right away, and the kernel has its own stack-guard mechanism to fault when growing too close to an existing mapping. If we map our own guard, then the kernel starts enforcing a rather large gap above that, rendering much of the possible stack space useless.
Instead, we'll just note where we expect rlimit to start faulting, so our handler can report "stack overflow", and trust that the kernel's own stack guard will work.
Fixes #43052.
r? @alexcrichton
### Kernel compatibility:
Strictly speaking, Rust claims support for Linux kernels >= 2.6.18, and stack guards were only added to mainline in 2.6.36 for [CVE-2010-2240]. But since that vulnerability was so severe, the guards were backported to many stable branches, and Red Hat patched this all the way back to RHEL3's 2.4.21! I think it's reasonable for us to assume that any *supportable* kernel should have these stack guards.
At that time, the kernel only enforced one page of padding between the stack and other mappings, but thanks to [Stack Clash] that padding is now much larger, causing #43052. The kernel side of those fixes are in [CVE-2017-1000364], which Red Hat has backported to at least RHEL5's 2.6.18 so far.
[CVE-2010-2240]: https://access.redhat.com/security/cve/CVE-2010-2240
[CVE-2017-1000364]: https://access.redhat.com/security/cve/CVE-2017-1000364
[Stack Clash]: https://access.redhat.com/security/vulnerabilities/stackguard
|
|
remove associated_consts feature gate
Currently struggling to run tests locally (something about jemalloc target missing).
cc #29646
|
|
Linux doesn't allocate the whole stack right away, and the kernel has
its own stack-guard mechanism to fault when growing too close to an
existing mapping. If we map our own guard, then the kernel starts
enforcing a rather large gap above that, rendering much of the possible
stack space useless.
Instead, we'll just note where we expect rlimit to start faulting, so
our handler can report "stack overflow", and trust that the kernel's own
stack guard will work.
Fixes #43052.
|
|
The atomic_xchg() loop locks the mutex, so the call to mutex_lock is
incorrect, and blocks.
|
|
Add annotations to the resize fn #39791
This adds the `inline(never)` and `cold` annotations to the
HashMap::resize function.
|