Pin stabilization
This implements the changes suggested in https://github.com/rust-lang/rust/issues/55766#issue-378417538 and stabilizes the `pin` feature. @alexcrichton also listed several "blockers" in that issue, but then in [this comment](https://github.com/rust-lang/rust/issues/55766#issuecomment-445074980) mentioned that they're more "TODO items":
> In that vein I think it's fine for a stabilization PR to be posted at any time now with FCP lapsed for a week or so now. The final points about self/pin/pinned can be briefly discussed there (if even necessary, they could be left as the proposal above).
Let's settle these last bits here and get this thing stabilized! :)
r? @alexcrichton
cc @withoutboats
Fix feature gate to point to 1.32.0 for `path_from_str`
When the feature has been added back (#55148) the feature gate has not
been adjusted accordingly. We have it enabled for 1.32.0, currently in
Beta, so adjust it.
Refs: #44431.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Adding unwinding support for x86_64_fortanix_unknown_sgx target.
Unwinding support is provided by our port of LLVM's libunwind which is available from https://github.com/fortanix/libunwind/tree/release_50.
libunwind requires support for rwlock and printing to stderr, which is only provided by `std` for this target. This poses two problems: 1) how to expose the `std` functionality to C and 2) dependency inversion.
### Exposing `std`
For exposing the functionality we chose to expose the following symbols:
* __rust_rwlock_rdlock
* __rust_rwlock_wrlock
* __rust_rwlock_unlock
* __rust_print_err
* __rust_abort
Also, the following are needed from `alloc`:
* __rust_alloc
* __rust_dealloc
#### Rust RWLock in C
In `libunwind`, RWLock is initialized as a templated static variable:
```c
pthread_rwlock_t DwarfFDECache<A>::_lock = PTHREAD_RWLOCK_INITIALIZER;
```
I don't know of a good way to use the Rust sys::rwlock::RWLock type and initializer there. We could have a static global variable in Rust, but that doesn't work with the templating. The variable needs to be initialized statically, since this target doesn't support the .init section. Currently, I just used a byte array and standard C array initialization. The mapping between this C type and the Rust type needs to be manually maintained. There is a compile-time check and a unit test to make sure the Rust versions of these C definitions match the actual Rust type. If any reviewer knows of a better solution, please do tell.
### Dependency inversion issue
`std` depends on `panic_unwind` which depends on `libunwind`, and `libunwind` depends on `std`. This is not normally supported by Rust's linking system. Therefore we use raw C exports from `std` *and* `libunwind.a` is linked last in the target `post_link_objects` instead of being built as part of the Rust `libunwind`. Currently, all C exports are defined in `src/libstd/sys/sgx/rwlock.rs` to overcome LTO issues. Only the `__rust_rwlock_*` definitions *need* to live there for privacy reasons. Once again, if any reviewer knows of a better solution, please do tell.
r? @alexcrichton
deny intra-doc link resolution failures in libstd
Fixes#56693.
Until we land a fix for the underlying issue (#56922), we can at least fix the failures in libstd so they don't propagate to downstream crates.
rename div_euc -> div_euclid, and mod_euc -> rem_euclid
logic is written up in #49048
Also, update the documentation slightly.
cc @alexcrichton @clarcharr @varkor
Remove pin::Unpin reexport and add Unpin to the prelude.
Change Pin associated functions to methods.
Rename get_mut_unchecked_ to get_unchecked_mut
Remove impl Unpin for Pin
Mark Pin repr(transparent)
On musl targets assume certain symbols exist (like pipe2 and accept4).
This fixes#56675.
I don't know if this is the best solution, or if I should also add some tests so I'm waiting for some feedback.
Thanks!
When the feature has been added back (#55148) the feature gate has not
been adjusted accordingly. We have it enabled for 1.32.0, currently in
Beta, so adjust it.
Refs: #44431.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Defactored Bytes::read
Removed unneeded refactoring of read_one_byte, which removed the unneeded dynamic dispatch (`dyn Read`) used by that function.
This function is only used in one place in the entire Rust codebase; there doesn't seem to be a reason for it to exist (and there especially doesn't seem to be a reason for it to use dynamic dispatch)
Fix doc of `std::fs::canonicalize`
Point out that the final component of the path name might be a filename
(and not a directory name). Previously, the doc said that all components
of the path must be directory names, when it actually only ment all but
the final one.
Fixes#54056.
std: Use `rustc_demangle` from crates.io
No more need to duplicate the demangling routine between crates.io and
the standard library, we can use the exact same one!
Point out that the final component of the path name might be a filename
(and not a directory name). Previously, the doc said that all components
of the path must be directory names, when it actually only ment all but
the final one.
Fixes#54056.
Fix docs path to PermissionsExt
Couldn't test the link yet, since I didn't figure out how to build std rustdocs without building the entire compiler itself 🙂
Update panic message to be clearer about env-vars
Esteban Kuber requested that the panic message make it clear
that `RUST_BACKTRACE=1` is an environment variable. This change
makes that clear.
I understand that this may simply be closed if the concept isn't accepted, and I'd be fine with that :-)
Fixes#56734
Add checked_add method to Instant time type
Appending functionality to the already opened topic of `checked_add` on time types over at #55940.
Doing checked addition between an `Instant` and a `Duration` is important to reliably determine a future instant. We could use this in the `parking_lot` crate to compute an instant when in the future to wake a thread up without risking a panic.
Esteban Kuber requested that the panic message make it clear
that `RUST_BACKTRACE=1` is an environment variable. This change
makes that clear. Wording provided in part by David Tolnay.
* Update bootstrap compiler
* Update version to 1.33.0
* Remove some `#[cfg(stage0)]` annotations
Actually updating the version number is blocked on updating Cargo
Ever since we added a Cargo-based build system for the compiler the
standard library has always been a little special, it's never been able
to depend on crates.io crates for runtime dependencies. This has been a
result of various limitations, namely that Cargo doesn't understand that
crates from crates.io depend on libcore, so Cargo tries to build crates
before libcore is finished.
I had an idea this afternoon, however, which lifts the strategy
from #52919 to directly depend on crates.io crates from the standard
library. After all is said and done this removes a whopping three
submodules that we need to manage!
The basic idea here is that for any crate `std` depends on it adds an
*optional* dependency on an empty crate on crates.io, in this case named
`rustc-std-workspace-core`. This crate is overridden via `[patch]` in
this repository to point to a local crate we write, and *that* has a
`path` dependency on libcore.
Note that all `no_std` crates also depend on `compiler_builtins`, but if
we're not using submodules we can publish `compiler_builtins` to
crates.io and all crates can depend on it anyway! The basic strategy
then looks like:
* The standard library (or some transitive dep) decides to depend on a
crate `foo`.
* The standard library adds
```toml
[dependencies]
foo = { version = "0.1", features = ['rustc-dep-of-std'] }
```
* The crate `foo` has an optional dependency on `rustc-std-workspace-core`
* The crate `foo` has an optional dependency on `compiler_builtins`
* The crate `foo` has a feature `rustc-dep-of-std` which activates these
crates and any other necessary infrastructure in the crate.
A sample commit for `dlmalloc` [turns out to be quite simple][commit].
After that all `no_std` crates should largely build "as is" and still be
publishable on crates.io! Notably they should be able to continue to use
stable Rust if necessary, since the `rename-dependency` feature of Cargo
is soon stabilizing.
As a proof of concept, this commit removes the `dlmalloc`,
`libcompiler_builtins`, and `libc` submodules from this repository. Long
thorns in our side these are now gone for good and we can directly
depend on crates.io! It's hoped that in the long term we can bring in
other crates as necessary, but for now this is largely intended to
simply make it easier to manage these crates and remove submodules.
This should be a transparent non-breaking change for all users, but one
possible stickler is that this almost for sure breaks out-of-tree
`std`-building tools like `xargo` and `cargo-xbuild`. I think it should
be relatively easy to get them working, however, as all that's needed is
an entry in the `[patch]` section used to build the standard library.
Hopefully we can work with these tools to solve this problem!
[commit]: 28ee12db81
