This commits blanket marks the API of the `std::process` module as `#[stable]`.
The module's API is very similar to the old `std::old_io::process` API and has
generally had quite a bit of time to bake both before and after the new module
landed.
Remove the synthetic \"region bound\" from closures and instead update how
type-outlives works for closure types so that it ensures that all upvars
outlive the region in question. This gives the same guarantees but
without introducing artificial regions (and gives better error messages
to boot). This is refactoring towards #3696.
r? @pnkfelix
type-outlives works for closure types so that it ensures that all upvars
outlive the region in question. This gives the same guarantees but
without introducing artificial regions (and gives better error messages
to boot).
This is an implementation of RFC 899 and adds stdio functionality to the new
`std::io` module. Details of the API can be found on the RFC, but from a high
level:
* `io::{stdin, stdout, stderr}` constructors are now available. There are also
`*_raw` variants for unbuffered and unlocked access.
* All handles are globally shared (excluding raw variants).
* The stderr handle is no longer buffered.
* All handles can be explicitly locked (excluding the raw variants).
The `print!` and `println!` machinery has not yet been hooked up to these
streams just yet. The `std::fmt::output` module has also not yet been
implemented as part of this commit.
This commits blanket marks the API of the `std::process` module as `#[stable]`.
The module's API is very similar to the old `std::old_io::process` API and has
generally had quite a bit of time to bake both before and after the new module
landed.
The one modification made to the API is that `Stdio::capture` is now named
`stdio::piped`.
[breaking-change]
... objects
For method calls through trait objects, we currently generate the llvm
function argument attributes using the non-opaque method signature that
still has the trait object fat pointer for the self pointer. This leads
to attributes that are plain wrong, e.g. noalias. As we don't know
anything about the concrete type of the underlying object, we must
replace the self argument with an opaque i8 pointer before applying the
attributes.
this is the same problem as openbsd (#22792).
without the patch, liblibc don't build.
@mneumann please comment.
I have encountered this problem while building some rust libs with `target=x86_64-unknown-dragonfly` (while working on #22794)
Check for unbounded recursion during dropck.
Such recursion can be introduced by the erroneous use of non-regular types (aka types employing polymorphic recursion), which Rust does not support.
Fix#22443
For method calls through trait objects, we currently generate the llvm
function argument attributes using the non-opaque method signature that
still has the trait object fat pointer for the self pointer. This leads
to attributes that are plain wrong, e.g. noalias. As we don't know
anything about the concrete type of the underlying object, we must
replace the self argument with an opaque i8 pointer before applying the
attributes.
Count recursion across phantom data separately from all recursion,
and treat `Box<T>` just as if it were carrying `PhantomData<T>`.
(Regression tests are in followup commit.)
The practical effect of this is just to increment the `xref_depth`
counter, the same way that `Vec` and other types carrying
`PhantomData` do.
This is an implementation of RFC 899 and adds stdio functionality to the new
`std::io` module. Details of the API can be found on the RFC, but from a high
level:
* `io::{stdin, stdout, stderr}` constructors are now available. There are also
`*_raw` variants for unbuffered and unlocked access.
* All handles are globally shared (excluding raw variants).
* The stderr handle is no longer buffered.
* All handles can be explicitly locked (excluding the raw variants).
The `print!` and `println!` machinery has not yet been hooked up to these
streams just yet. The `std::fmt::output` module has also not yet been
implemented as part of this commit.
static_assert is documented as working on static with type `bool`, but
we currently accept it on any const static and crash when the const has
an non-integral type.
This is a breaking-change for anyone who used static_assert on types
likes i32, which happened to work but seems like an unintended
consequence of the missing error checking.
[breaking-change]
Fixes#22056
some commits in OpenBSD OS have corrected a problem of stack position.
Now, we can adjust more accurately the page guard in rust.
@dhuseby I am not sure that bitrig have already integrated these changes (the `$OpenBSD$` header in sys/kern/kern_exec.c is too old). But when they do, you may want this patch too.
