Link MSVC default lib in core
## The Problem
On Windows MSVC, Rust invokes the linker directly. This means only the objects and libraries Rust explicitly passes to the linker are used. In short, this is equivalent to passing `-nodefaultlibs`, `-nostartfiles`, etc for gnu compilers.
To compensate for this [the libc crate links to the necessary libraries](a0f5b4b213/src/windows/mod.rs (L258-L261)). The libc crate is then linked from std, thus when you use std you get the defaults back.or integrate with C/C++.
However, this has a few problems:
- For `no_std`, users are left to manually pass the default lib to the linker
- Whereas `std` has the opposite problem, using [`/nodefaultlib`](https://learn.microsoft.com/en-us/cpp/build/reference/nodefaultlib-ignore-libraries?view=msvc-170) doesn't work as expected because Rust treats them as normal libs. This is a particular problem when you want to use e.g. the debug CRT libraries in their place or integrate with C/C++..
## The solution
This PR fixes this in two ways:
- moves linking the default lib into `core`
- passes the lib to the linker using [`/defaultlib`](https://learn.microsoft.com/en-us/cpp/build/reference/defaultlib-specify-default-library?view=msvc-170). This allows users to override it in the normal way (i.e. with [`/nodefaultlib`](https://learn.microsoft.com/en-us/cpp/build/reference/nodefaultlib-ignore-libraries?view=msvc-170)).
This is more or less equivalent to what the MSVC C compiler does. You can see what this looks like in my second commit, which I'll reproduce here for convenience:
```rust
// In library/core
#[cfg(all(windows, target_env = "msvc"))]
#[link(
name = "/defaultlib:msvcrt",
modifiers = "+verbatim",
cfg(not(target_feature = "crt-static"))
)]
#[link(name = "/defaultlib:libcmt", modifiers = "+verbatim", cfg(target_feature = "crt-static"))]
extern "C" {}
```
## Alternatives
- Add the above to `unwind` and `std` but not `core`
- The status quo
- Some other kind of compiler magic maybe
This bares some discussion so I've t-libs nominated it.
Add missing `unsafe` to some internal `std` functions
Adds `unsafe` to a few internal functions that have safety requirements but were previously not marked as `unsafe`. Specifically:
- `std::sys::pal::unix:🧵:min_stack_size` needs to be `unsafe` as `__pthread_get_minstack` might dereference the passed pointer. All callers currently pass a valid initialised `libc::pthread_attr_t`.
- `std:🧵:Thread::new` (and `new_inner`) need to be `unsafe` as it requires the passed thread name to be valid UTF-8, otherwise `Thread::name` will trigger undefined behaviour. I've taken the opportunity to split out the unnamed thread case into a separate `new_unnamed` function to make the safety requirement clearer. All callers meet the safety requirement now that #123505 has been merged.
OpenBSD fix long socket addresses
Original diff from ``@notgull`` in #118349, small changes from me.
on OpenBSD, getsockname(2) returns the actual size of the socket address, and not the len of the content. Figure out the length for ourselves. see https://marc.info/?l=openbsd-bugs&m=170105481926736&w=2Fixes#116523
Thread local updates for idiomatic examples
Update thread local examples to make more idiomatic use of `Cell` for `Copy` types, `RefCell` for non-`Copy` types.
Also shrink the size of `unsafe` blocks, add `SAFETY` comments, and fix `clippy::redundant_closure_for_method_calls`.
Update documentation of Path::to_path_buf and Path::ancestors
`Path::to_path_buf`
> Changes the example from using the qualified path of PathBuf with an import. This is what's done in all other Path/PathBuf examples and makes the code look a bit cleaner.
`Path::ancestors`
> If you take a quick glance at the documentation for Path::ancestors, the unwraps take the natural focus. Potentially indicating that ancestors might panic.
In the reworked version I've also moved the link with parent returning None and that the iterator will always yield &self to before the yield examples.
Feel free to cherry-pick the changes you like.
zkvm: fix path to cmath in zkvm module
I don't know why the original author decided to use relative paths.
I think it would be better to use `use crate::sys::cmath;`
The according issue can be found here https://github.com/risc0/risc0/issues/1647
Remove `sys_common::thread`
Part of #117276.
The stack size calculation isn't system-specific at all and can just live together with the rest of the spawn logic.
Move rare overflow error to a cold function
`scoped.spawn()` generates unnecessary inlined panic-formatting code for a branch that will never be taken.
Panic on overflow in `BorrowedCursor::advance`
Passing `usize::MAX` to `advance` clearly isn't correct, but the current assertion fails to detect this when overflow checks are disabled. This isn't unsound, but should probably be fixed regardless.
Avoid a panic in `set_output_capture` in the default panic handler
This avoid a panic in the default panic handler by not using `set_output_capture` as `OUTPUT_CAPTURE.with` may panic once `OUTPUT_CAPTURE` is dropped.
A new non-panicking `try_set_output_capture` variant of `set_output_capture` is added for use in the default panic handler.
Original diff from @notgull in #118349, small changes from me.
on OpenBSD, getsockname(2) returns the actual size of the socket address, and
not the len of the content. Figure out the length for ourselves.
see https://marc.info/?l=openbsd-bugs&m=170105481926736&w=2Fixes#116523
clean up docs for `File::sync_*`
* Clarify that `sync_all` also writes data and not just metadata.
* Clarify that dropping a file is not equivalent to calling `sync_all` and ignoring the result. `sync_all` the still the recommended way to detect errors before closing, because we don't have a dedicated method for that.
* Add a link from `sync_all` to `sync_data`, because that's what the user might want to use instead.
* Add doc aliases for `fsync` -> `sync_all` and `fdatasync` -> `sync_data`. Those are the POSIX standard names for these functions. I was trying to find out what we call `fsync` in Rust and had to search through the source code to find it, so this alias should help with that in the future.
Document restricted_std
This PR aims to pin down exactly what restricted_std is meant to achieve and what it isn't.
This commit fixes https://github.com/rust-lang/wg-cargo-std-aware/issues/87 by explaining why the error appears and what the choices the user has. The error describes how std cannot function without knowing about some form of OS/platform support. Any features of std that work without an OS should be moved to core/alloc (see https://github.com/rust-lang/rust/issues/27242https://github.com/rust-lang/rust/issues/103765).
Note that the message says "platform" and "environment" because, since https://github.com/rust-lang/rust/pull/120232, libstd can be built for some JSON targets. This is still unsupported (all JSON targets probably should be unstable https://github.com/rust-lang/wg-cargo-std-aware/issues/90), but a JSON target with the right configuration should hopefully have some partial libstd support.
I propose closing https://github.com/rust-lang/wg-cargo-std-aware/issues/69 as "Won't fix" since any support of std without properly configured os, vendor or env fields is very fragile considering future upgrades of Rust or dependencies. In addition there's no likely path to it being fixed long term (making std buildable for all targets being the only solution). This is distinct from tier 3 platforms with limited std support implemented (and as such aren't restricted_std) because these platforms can conceptually work in the future and std support should mainly improve over time.
The alternative to closing https://github.com/rust-lang/wg-cargo-std-aware/issues/69 is a new crate feature for std which escapes the restricted_std mechanism in build.rs. It could be used with the -Zbuild-std-features flag if we keep it permanently unstable, which I hope we can do anyway. A minor side-effect in this scenario is that std wouldn't be marked as unstable if documentation for it were generated with build-std.
cc ```@ehuss```
`f16` and `f128` step 4: basic library support
This is the next step after https://github.com/rust-lang/rust/pull/121926, another portion of https://github.com/rust-lang/rust/pull/114607
Tracking issue: https://github.com/rust-lang/rust/issues/116909
This PR adds the most basic operations to `f16` and `f128` that get lowered as LLVM intrinsics. This is a very small step but it seemed reasonable enough to add unopinionated basic operations before the larger modules that are built on top of them.
r? ```@Amanieu``` since you were pretty involved in the RFC
cc ```@compiler-errors```
```@rustbot``` label +T-libs-api +S-blocked +F-f16_and_f128
Rollup of 7 pull requests
Successful merges:
- #118391 (Add `REDUNDANT_LIFETIMES` lint to detect lifetimes which are semantically redundant)
- #123534 (Windows: set main thread name without re-encoding)
- #123659 (Add support to intrinsics fallback body)
- #123689 (Add const generics support for pattern types)
- #123701 (Only assert for child/parent projection compatibility AFTER checking that theyre coming from the same place)
- #123702 (Further cleanup cfgs in the UI test suite)
- #123706 (rustdoc: reduce per-page HTML overhead)
r? `@ghost`
`@rustbot` modify labels: rollup
The import is used once in this file, inside `posix_spawn`, so let's move the import into that function instead, to reduce the number of `cfg`s that need to be kept in sync.
If you take a quick glance at the documentation for Path::ancestors, the unwraps take the natural focus. Potentially indicating that ancestors might panic.
In the reworked version I've also moved the link with parent returning None and that the iterator will always yield &self to before the yield examples.
Specialize many implementations of `Read::read_buf_exact`
This makes all implementations of `Read` that have a specialized `read_exact` implementation also have one for `read_buf_exact`.
Changes the example from using the qualified path of PathBuf with an import. This is what's done in all other Path/PathBuf examples and makes the code look a bit cleaner.
Show mode_t as octal in std::fs Debug impls
Example:
```rust
fn main() {
println!("{:?}", std::fs::metadata("Cargo.toml").unwrap().permissions());
}
```
- Before: `Permissions(FilePermissions { mode: 33204 })`
- ~~After: `Permissions(FilePermissions { mode: 0o100664 })`~~
- After: `Permissions(FilePermissions { mode: 0o100664 (-rw-rw-r--) })`
~~I thought about using the format from `ls -l` (`-rw-rw-r--`, `drwxrwxr-x`) but I am not sure how transferable the meaning of the higher bits between different unix systems, and anyway starting the value with a leading negative-sign seems objectionable.~~
