| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Add some APIs to ptr::NonNull and fix `since` attributes
This is a follow-up to its stabilization in https://github.com/rust-lang/rust/pull/46952. Tracking issue: https://github.com/rust-lang/rust/issues/27730.
* These trait impls are insta-stable: `Hash`, `PartialEq`, `Eq`, `PartialOrd` and `Ord`.
* The new `cast<U>() -> NonNull<U>` method is `#[unstable]`. It was proposed in https://github.com/rust-lang/rust/pull/46952#issuecomment-359220010.
|
|
Document std::os::raw.
This adds a brief explanation to each type and its definition according to C. This also helps clarify that the definitions of the types, as described by rustdoc, are not necessarily the same from platform to platform.
|
|
|
|
Make wording around 0-cost casts more precise
|
|
Remove 'the this' in doc comments.
|
|
Clarify shared file handler behavior of File::try_clone.
Fixes https://github.com/rust-lang/rust/issues/46578.
|
|
Use a range to identify SIGSEGV in stack guards
Previously, the `guard::init()` and `guard::current()` functions were
returning a `usize` address representing the top of the stack guard,
respectively for the main thread and for spawned threads. The `SIGSEGV`
handler on `unix` targets checked if a fault was within one page below that
address, if so reporting it as a stack overflow.
Now `unix` targets report a `Range<usize>` representing the guard memory,
so it can cover arbitrary guard sizes. Non-`unix` targets which always
return `None` for guards now do so with `Option<!>`, so they don't pay any
overhead.
For `linux-gnu` in particular, the previous guard upper-bound was
`stackaddr + guardsize`, as the protected memory was *inside* the stack.
This was a glibc bug, and starting from 2.27 they are moving the guard
*past* the end of the stack. However, there's no simple way for us to know
where the guard page actually lies, so now we declare it as the whole range
of `stackaddr ± guardsize`, and any fault therein will be called a stack
overflow. This fixes #47863.
|
|
|
|
Fixes https://github.com/rust-lang/rust/issues/46578.
|
|
for 180/π in to_degrees The current `f32|f64.to_degrees` implementation uses a division to calculate `180/π`, which causes a loss of precision. Using a constant is still not perfect (implementing a maximally-precise algorithm would come with a high performance cost), but improves precision with a minimal change. As per the discussion in #29944, this fixes #29944 (the costs of improving the precision further would not outweigh the gains).
|
|
Implement extensible syscall interface for wasm
Currently it's possible to run tests with the native wasm target, but it's not possible to tell whether they pass or to capture the output, because libstd throws away stdout, stderr and the exit code. While advanced libstd features should probably require more specific targets (eg. wasm-unknown-web) I think even the unknown target should at least support basic I/O.
Any solution is constrained by these factors:
- It must not be javascript specific
- There must not be too strong coupling between libstd and the host environment (because it's an "unknown" target)
- WebAssembly does not allow "optional" imports - all imports *must* be resolved.
- WebAssembly does not support calling the host environment through any channel *other* than imports.
The best solution I could find to these constraints was to give libstd a single required import, and implement a syscall-style interface through that import. Each syscall is designed such that a no-op implementation gives the most reasonable fallback behaviour. This means that the following import table would be perfectly valid:
```javascript
imports.env = { rust_wasm_syscall: function(index, data) {} }
```
Currently I have implemented these system calls:
- Read from stdin
- Write to stdout/stderr
- Set the exit code
- Get command line arguments
- Get environment variable
- Set environment variable
- Get time
It need not be extended beyond this set if being able to run tests for this target is the only goal.
edit:
As part of this PR I had to make a further change. Previously, the rust entry point would be automatically called when the webassembly module was instantiated. This was problematic because from the javascript side it was impossible to call exported functions, access program memory or get a reference to the instance.
To solve this, ~I changed the default behaviour to not automatically call the entry point, and added a crate-level attribute to regain the old behaviour. (`#![wasm_auto_run]`)~ I disabled this behaviour when building tests.
|
|
The current `f32|f64.to_degrees` implementation uses a division to calculate 180/π, which causes a loss of precision. Using a constant is still not perfect (implementing a maximally-precise algorithm would come with a high performance cost), but improves precision with a minimal change.
|
|
Previously, the `guard::init()` and `guard::current()` functions were
returning a `usize` address representing the top of the stack guard,
respectively for the main thread and for spawned threads. The `SIGSEGV`
handler on `unix` targets checked if a fault was within one page below
that address, if so reporting it as a stack overflow.
Now `unix` targets report a `Range<usize>` representing the guard
memory, so it can cover arbitrary guard sizes. Non-`unix` targets which
always return `None` for guards now do so with `Option<!>`, so they
don't pay any overhead.
For `linux-gnu` in particular, the previous guard upper-bound was
`stackaddr + guardsize`, as the protected memory was *inside* the stack.
This was a glibc bug, and starting from 2.27 they are moving the guard
*past* the end of the stack. However, there's no simple way for us to
know where the guard page actually lies, so now we declare it as the
whole range of `stackaddr ± guardsize`, and any fault therein will be
called a stack overflow. This fixes #47863.
|
|
std: use more portable error number in from_raw_os_error docs
On MIPS, error number 98 is not `EADDRINUSE` (it is `EPROTOTYPE`). To fix the resulting test failure this causes, use a more portable error number in the example documentation. `EINVAL` shold be more reliable because it was defined in the original Unix as 22 so hopefully most derivatives have defined it the same way.
|
|
Move Duration to libcore
Fixes #46520; should be merged after #46508.
|
|
|
|
On MIPS, error number 98 is not EADDRINUSE (it is EPROTOTYPE). To fix the
resulting test failure this causes, use a more portable error number in
the example documentation. EINVAL shold be more reliable because it was
defined in the original Unix as 22 so hopefully most derivatives have
defined it the same way.
|
|
Document that `Index` ops can panic on `HashMap` & `BTreeMap`.
Fixes https://github.com/rust-lang/rust/issues/47011.
|
|
implement Send for process::Command on unix
closes https://github.com/rust-lang/rust/issues/47751
|
|
|
|
|
|
|
|
|
|
Fixes https://github.com/rust-lang/rust/issues/47011.
|
|
|
|
|
|
Implementing Send for a specific field rather than the whole struct is
safer: if a field is changed/modified and becomes non-Send, we can catch
it.
|
|
|
|
closes https://github.com/rust-lang/rust/issues/47751
|
|
Stabilized `#[repr(align(x))]` attribute (RFC 1358)
Stabilzed `#[repr(align(x))]` with attr_literal syntax as proposed by @eddyb https://github.com/rust-lang/rust/issues/33626#issuecomment-348467804
|
|
r=alexcrichton
Makes the constructors of Duration const fns.
This affects `Duration::new`, `Duration::from_secs`, `Duration::from_millis`, `Duration::from_micros`, and `Duration::from_nanos`.
|
|
Make core::ops::Place an unsafe trait
Consumers of `Place` would reasonably expect that the `pointer` function returns a valid pointer to memory that can actually be written to.
|
|
Expose float from_bits and to_bits in libcore.
These methods have no dependencies on libm and thus should be offered in libcore.
|
|
|
|
Only link res_init() on GNU/*nix
To workaround a bug in glibc <= 2.26 lookup_host() calls res_init() based on the glibc version detected at runtime. While this avoids calling res_init() on platforms where it's not required we will still end up linking against the symbol.
This causes an issue on macOS where res_init() is implemented in a separate library (libresolv.9.dylib) from the main libc. While this is harmless for standalone programs it becomes a problem if Rust code is statically linked against another program. If the linked program doesn't already specify -lresolv it will cause the link to fail. This is captured in issue #46797
Fix this by hooking in to the glibc workaround in `cvt_gai` and only activating it for the "gnu" environment on Unix This should include all glibc platforms while excluding musl, windows-gnu, macOS, FreeBSD, etc.
This has the side benefit of removing the #[cfg] in sys_common; only unix.rs has code related to the workaround now.
Before this commit:
```shell
> cat main.rs
use std::net::ToSocketAddrs;
#[no_mangle]
pub extern "C" fn resolve_test() -> () {
let addr_list = ("google.com.au", 0).to_socket_addrs().unwrap();
println!("{:?}", addr_list);
}
> rustc --crate-type=staticlib main.rs
> clang libmain.a test.c -o combined
Undefined symbols for architecture x86_64:
"_res_9_init", referenced from:
std::net::lookup_host::h93c17fe9ad38464a in libmain.a(std-826c8d3b356e180c.std0.rcgu.o)
ld: symbol(s) not found for architecture x86_64
clang-5.0: error: linker command failed with exit code 1 (use -v to see invocation)
```
Afterwards:
```shell
> rustc --crate-type=staticlib main.rs
> clang libmain.a test.c -o combined
> ./combined
IntoIter([V4(172.217.25.131:0)])
```
Fixes #46797
|
|
|
|
Update BTreeMap recommendation
Focus on the ordering / range(instead of all) benefit as it's the most important feature.
|
|
Add some edge cases to the documentation of `Path`
Affected methods are `starts_with` and `strip_prefix`.
|
|
Deprecate std::net::lookup_host
We intended to do this quite a while ago but it snuck through.
r? @alexcrichton
|
|
zackmdavis:and_the_case_of_the_needlessly_parenthesized_arguments, r=petrochenkov
in which the unused-parens lint comes to cover function and method args
Resolves #46137.
|
|
|
|
|
|
`Shared` is now a deprecated `type` alias.
CC https://github.com/rust-lang/rust/issues/27730#issuecomment-352800629
|
|
Focus on the ordering/range benefit.
|
|
Resolves #46137.
|
|
We intended to do this quite a while ago but it snuck through.
|
|
Affected methods are `starts_with` and `strip_prefix`.
|
|
Use File::metadata instead of fs::metadata to choose buffer size
This replaces a `stat` syscall with `fstat` or similar, which can be faster. Fixes #47519.
|
|
This replaces a `stat` syscall with `fstat` or similar, which can be
faster. Fixes #47519.
|
|
To workaround a bug in glibc <= 2.26 lookup_host() calls res_init()
based on the glibc version detected at runtime. While this avoids
calling res_init() on platforms where it's not required we will still
end up linking against the symbol.
This causes an issue on macOS where res_init() is implemented in a
separate library (libresolv.9.dylib) from the main libc. While this is
harmless for standalone programs it becomes a problem if Rust code is
statically linked against another program. If the linked program doesn't
already specify -lresolv it will cause the link to fail. This is
captured in issue #46797
Fix this by hooking in to the glibc workaround in `cvt_gai` and only
activating it for the "gnu" environment on Unix This should include all
glibc platforms while excluding musl, windows-gnu, macOS, FreeBSD, etc.
This has the side benefit of removing the #[cfg] in sys_common; only
unix.rs has code related to the workaround now.
|
