... 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.
* Make num::UpperHex private. I was unable to determine why this struct
is public. The num module itself is not public, and the UpperHex struct
is not referenced anywhere in the core::fmt module. (Only the UpperHex
trait is reference.) num::LowerHex is not public.
* Remove the suffix parameters from the macros that generate integral
display traits.
The code to print the Debug::fmt suffixes was removed when Show was
renamed to Debug. It was an intentional change. From RFC 0565:
* Focus on the *runtime* aspects of a type; repeating information such
as suffixes for integer literals is not generally useful since that
data is readily available from the type definition.
* Because Show was renamed to Debug, rename show! to debug!.
Fixing #21475. Right now this code can not be parsed:
```rust
use m::{START, END};
fn main() {
match 42u32 {
m::START...m::END => {}, // error: expected one of `::`, `=>`, or `|`, found `...`
_ => {},
}
}
mod m {
pub const START: u32 = 4;
pub const END: u32 = 14;
}
```
I fixed the parser and added test for this case, but now there are still problems with mixing literals and paths in interval:
```rust
match 42u32 {
0u32...m::END => {}, // mismatched types in range [E0031]
m::START...59u32 => {}, // mismatched types in range [E0031]
_ => {},
}
}
```
I'll try fix this problem and need review.
