| Age | Commit message (Collapse) | Author | Lines |
|---|
|
The link for UNIX was pointing to the Cloud ABI docs. It should have
been pointing to the clock_gettime docs instead. The table is repeated
in the docs for SystemTime, but there the UNIX entry was already correct.
|
|
Inline some conversion methods around OsStr
Diff on the assembly of this snippet before and after this PR: https://www.diffchecker.com/NeGMjaJ2
```rust
use std::env;
use std::io;
use std::path::{Path, PathBuf};
pub fn cargo_home_with_cwd(cwd: &Path) -> io::Result<PathBuf> {
match env::var_os("CARGO_HOME").filter(|h| !h.is_empty()) {
Some(home) => {
let home = PathBuf::from(home);
if home.is_absolute() {
Ok(home)
} else {
Ok(cwd.join(&home))
}
}
_ => env::home_dir()
.map(|p| p.join(".cargo"))
.ok_or_else(|| io::Error::new(io::ErrorKind::Other, "could not find cargo home dir")),
}
}
```
|
|
make use of pointer::is_null
r? @Mark-Simulacrum
|
|
build-std compatible sanitizer support
### Motivation
When using `-Z sanitizer=*` feature it is essential that both user code and
standard library is instrumented. Otherwise the utility of sanitizer will be
limited, or its use will be impractical like in the case of memory sanitizer.
The recently introduced cargo feature build-std makes it possible to rebuild
standard library with arbitrary rustc flags. Unfortunately, those changes alone
do not make it easy to rebuild standard library with sanitizers, since runtimes
are dependencies of std that have to be build in specific environment,
generally not available outside rustbuild process. Additionally rebuilding them
requires presence of llvm-config and compiler-rt sources.
The goal of changes proposed here is to make it possible to avoid rebuilding
sanitizer runtimes when rebuilding the std, thus making it possible to
instrument standard library for use with sanitizer with simple, although
verbose command:
```
env CARGO_TARGET_X86_64_UNKNOWN_LINUX_GNU_RUSTFLAGS=-Zsanitizer=thread cargo test -Zbuild-std --target x86_64-unknown-linux-gnu
```
### Implementation
* Sanitizer runtimes are no long packed into crates. Instead, libraries build
from compiler-rt are used as is, after renaming them into `librusc_rt.*`.
* rustc obtains runtimes from target libdir for default sysroot, so that
they are not required in custom build sysroots created with build-std.
* The runtimes are only linked-in into executables to address issue #64629.
(in previous design it was hard to avoid linking runtimes into static
libraries produced by rustc as demonstrated by sanitizer-staticlib-link
test, which still passes despite changes made in #64780).
cc @kennytm, @japaric, @firstyear, @choller
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add HashSet::get_or_insert_owned
This is an extension for tracking issue #60896. The more-general `get_or_insert_with` has potential for misuse, so we might remove it, but I think `get_or_insert_owned` covers most use cases.
|
|
|
|
|
|
Use matches macro in libcore and libstd
This PR replaces matches like
```rust
match var {
value => true,
_ => false,
}
```
with use of `matches!` macro.
r? @Centril
|
|
Remove insignificant notes from CStr documentation
The to_str and to_string_lossy methods contain a note about the behavior possibly changing in the future. But those notes are referring to a distinction that is not observable in the API. Whether or not the UTF-8 check knows the string length ahead of time, these methods require linear time.
|
|
Updates for VxWorks
r? @alexcrichton
|
|
|
|
|
|
These notes are about a distinction that is not going to be observable
in the API. Whether or not the UTF-8 check knows the string length ahead
of time, these methods require linear time.
|
|
Missing module std in example.
|
|
Add an unstable conversion from thread ID to u64
We see multiple cases inside rustc and ecosystem code where ThreadId is
transmuted to u64, exploiting the underlying detail. This is suboptimal
(can break unexpectedly if we change things in std).
It is unlikely that ThreadId will ever need to be larger than u64 --
creating even 2^32 threads over the course of a program is quite hard,
2^64 is even harder. As such, we do not choose to return a larger sized
type (e.g. u128). If we choose to shrink ThreadId in the future, or
otherwise change its internals, it is likely that a mapping to u64 will
still be applicable (though may become more complex).
I will file a tracking issue as soon as this is loosely approved.
|
|
|
|
Standard library support for riscv64gc-unknown-linux-gnu
Add std support for RISC-V 64-bit GNU/Linux and update libc for RISC-V support.
r? @alexcrichton
|
|
|
|
|
|
|
|
We see multiple cases inside rustc and ecosystem code where ThreadId is
transmuted to u64, exploiting the underlying detail. This is suboptimal
(can break unexpectedly if we change things in std).
It is unlikely that ThreadId will ever need to be larger than u64 --
creating even 2^32 threads over the course of a program is quite hard,
2^64 is even harder. As such, we do not choose to return a larger sized
type (e.g. u128). If we choose to shrink ThreadId in the future, or
otherwise change its internals, it is likely that a mapping to u64 will
still be applicable (though may become more complex).
|
|
Remove negative number check from float sqrt
It hasn't been UB to pass negative numbers to sqrt since https://reviews.llvm.org/D28797 which was included in LLVM 5.
|
|
It hasn't been UB to pass negative numbers to sqrt since https://reviews.llvm.org/D28797 which was included in LLVM 5.
|
|
libstd uses `core::panic::Location` where possible.
cc @eddyb
|
|
|
|
|
|
Remove unused `#[link_name = "m"]` attributes
These were perhaps supposed to be `#[link(name = "m")]` but linking libm should be handled by the libc crate anyway.
They should have triggered a compile error: #47725
|
|
These were perhaps supposed to be `#[link(name = "m")]` but linking libm should be handled by the libc crate anyway.
|
|
Rollup of 10 pull requests
Successful merges:
- #67450 (Allow for setting a ThinLTO import limit during bootstrap)
- #67595 (Suggest adding a lifetime constraint for opaque type)
- #67636 (allow rustfmt key in [build] section)
- #67736 (Less-than is asymmetric, not antisymmetric)
- #67762 (Add missing links for insecure_time)
- #67783 (Warn for bindings named same as variants when matching against a borrow)
- #67796 (Ensure that we process projections during MIR inlining)
- #67807 (Use drop instead of the toilet closure `|_| ()`)
- #67816 (Clean up err codes)
- #67825 (Minor: change take() docs grammar to match other docs)
Failed merges:
r? @ghost
|
|
Use drop instead of the toilet closure `|_| ()`
|
|
|
|
|
|
This reverts commit f35517ee861dc012ccc26083dd4520045e2c4f6f.
|
|
|
|
Some keyword documentation.
I thought about going into detail, but I'd much rather route them to the async book asap.
|
|
|
|
|
|
tidy: change msdn links to newer locations
see accouncement at https://docs.microsoft.com/welcome-to-docs
The script that I used: https://gist.github.com/lzutao/1449c9210ad91899841d62e0058d2caa
|
|
Stabilize the `matches!` macro
Fixes https://github.com/rust-lang/rust/issues/65721
FCP: https://github.com/rust-lang/rust/issues/65721#issuecomment-569118119
|
|
Document safety of Path casting
I would personally feel more comfortable making the relevant (internal anyway) types repr(transparent) and then documenting that we can make these casts because of that, but I believe this is a more minimal PR, so posting it first.
Resolves #45910.
|
|
Convert collapsed to shortcut reference links
|
|
Remove redundant link texts
Most of these links are followed by a parenthesized expression. I think that the redundant link texts were added to prevent interpretation as an inline link. This is unnecessary since the closing square bracket and opening parenthesis are separated by whitespace.
|
