| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Update to new ui_test crate
|
|
compiletest: complain about unknown flags
This would have avoided https://github.com/rust-lang/rust/issues/110102
|
|
|
|
|
|
Stabilize IsTerminal
FCP completed in https://github.com/rust-lang/rust/issues/98070 .
closes: https://github.com/rust-lang/rust/issues/98070
|
|
add memcpy/strcpy/strncpy shims
fix bug
add memcpy/strcpy/strncpy shims
add a test for strncpy
remove strncpy shim
|
|
|
|
|
|
Co-authored-by: Ben Kimock <kimockb@gmail.com>
|
|
Fixes https://github.com/rust-lang/miri/issues/2832.
|
|
|
|
The panic test is now counted as an error test; we encounter a Terminate
terminator, and emit an interpreter error, as opposed to just
terminating due to a panic. So this test should have broken with
https://github.com/rust-lang/rust/pull/102906 but wasn't because the Miri
test suite is currently broken in rust-lang/rust:
https://github.com/rust-lang/rust/issues/110102
|
|
|
|
closes: https://github.com/rust-lang/rust/issues/98070
|
|
|
|
|
|
|
|
Insert alignment checks for pointer dereferences when debug assertions are enabled
Closes https://github.com/rust-lang/rust/issues/54915
- [x] Jake tells me this sounds like a place to use `MirPatch`, but I can't figure out how to insert a new basic block with a new terminator in the middle of an existing basic block, using `MirPatch`. (if nobody else backs up this point I'm checking this as "not actually a good idea" because the code looks pretty clean to me after rearranging it a bit)
- [x] Using `CastKind::PointerExposeAddress` is definitely wrong, we don't want to expose. Calling a function to get the pointer address seems quite excessive. ~I'll see if I can add a new `CastKind`.~ `CastKind::Transmute` to the rescue!
- [x] Implement a more helpful panic message like slice bounds checking.
r? `@oli-obk`
|
|
|
|
|
|
|
|
Updates `interpret`, `codegen_ssa`, and `codegen_cranelift` to consume the new cast instead of the intrinsic.
Includes `CastTransmute` for custom MIR building, to be able to test the extra UB.
|
|
|
|
same speed as the host system.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This makes sure that the interface of `miri_host_to_target_path` is compatible with `CStr` for targets where `c_char` is unsigned (such as ARM). This commit changes the signature of `miri_host_to_target_path` in the README and in all test cases.
|
|
deletes code
|
|
|
|
|
|
|
|
This patch adds a few tests to assert the current behavior when passing
data across an await point. This will help to test out an upcoming fix
for the issue of arguments in async functions growing in size because of
the generator upvar that is generated when we desugar the async
function.
See https://github.com/rust-lang/rust/issues/62958
Also relates to https://github.com/rust-lang/rust/pull/107500
Co-authored-by: Ralf Jung <post@ralfj.de>
|
|
|
|
r=dtolnay
Stabilize feature `cstr_from_bytes_until_nul`
This PR seeks to stabilize `cstr_from_bytes_until_nul`.
Partially addresses #95027
This function has only been on nightly for about 10 months, but I think it is simple enough that there isn't harm discussing stabilization. It has also had at least a handful of mentions on both the user forum and the discord, so it seems like it's already in use or at least known.
This needs FCP still.
Comment on potential discussion points:
- eventual conversion of `CStr` to be a single thin pointer: this function will still be useful to provide a safe way to create a `CStr` after this change.
- should this return a length too, to address concerns about the `CStr` change? I don't see it as being particularly useful, and it seems less ergonomic (i.e. returning `Result<(&CStr, usize), FromBytesUntilNulError>`). I think users that also need this length without the additional `strlen` call are likely better off using a combination of other methods, but this is up for discussion
- `CString::from_vec_until_nul`: this is also useful, but it doesn't even have a nightly implementation merged yet. I propose feature gating that separately, as opposed to blocking this `CStr` implementation on that
Possible alternatives:
A user can use `from_bytes_with_nul` on a slice up to `my_slice[..my_slice.iter().find(|c| c == 0).unwrap()]`. However; that is significantly less ergonomic, and is a bit more work for the compiler to optimize compared the direct `memchr` call that this wraps.
## New stable API
```rs
// both in core::ffi
pub struct FromBytesUntilNulError(());
impl CStr {
pub const fn from_bytes_until_nul(
bytes: &[u8]
) -> Result<&CStr, FromBytesUntilNulError>
}
```
cc ```@ericseppanen``` original author, ```@Mark-Simulacrum``` original reviewer, ```@m-ou-se``` brought up some issues on the thin pointer CStr
```@rustbot``` modify labels: +T-libs-api +needs-fcp
|
|
|
|
|
|
See https://github.com/rust-lang/unsafe-code-guidelines/issues/381 for discussion.
|
|
Implement epoll_wait
This PR continues working on https://github.com/rust-lang/miri/issues/602.
This is an implementation for `sleep`, though admittedly not a good one. It just does busy waiting.
|
|
|
|
|
|
|
|
|
|
It was broken, and the fixed version actually fails...
|
|
|
