Update libffi-sys to 2.0.1
Prior version of libffi [could not be cross-compiled to illumos](https://github.com/tov/libffi-rs/pull/59) due to host-triple complications. This should fix rustup builds of miri for the illumos platform.
Prior version of libffi could not be cross-compiled to illumos due to
host-triple complications. This should fix rustup builds of miri for
the illumos platform.
Use is_terminal to implement isatty
This means that Linux targets on Windows hosts should give a correct reply. We still don't have an implementation for Windows targets though, that requires some tracking of handles.
Fixes https://github.com/rust-lang/miri/issues/2419
Also restructure our `fs` tests a bit to test the parts that don't need libc separately.
`as_unix_host_fd` is now not used any more, but it could become useful again in the future so I kept it.
Mark `std::os::wasi::io::AsFd` etc. as stable.
io_safety was stabilized in Rust 1.63, so mark the io_safety exports in `std::os::wasi::io` as stable.
Fixes#103306.
Rollup of 9 pull requests
Successful merges:
- #103221 (Fix `SelfVisitor::is_self_ty` ICE)
- #103230 (Clarify startup)
- #103281 (Adjust `transmute{,_copy}` to be clearer about which of `T` and `U` is input vs output)
- #103288 (Fixed docs typo in `library/std/src/time.rs`)
- #103296 (+/- shortcut now only expand/collapse, not both)
- #103297 (fix typo)
- #103313 (Don't label `src/test` tests as `A-testsuite`)
- #103315 (interpret: remove an incorrect assertion)
- #103319 (Improve "`~const` is not allowed here" message)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
interpret: remove an incorrect assertion
This fixes an ICE in Miri, [reported](https://rust-lang.zulipchat.com/#narrow/stream/269128-miri/topic/SwitchInt.20with.20no.20targets.3F) by `@saethlin.` The faulty assertion was introduced by 432535da2b, when a previously correct assertion checking that the `otherwise` target exists got replaced by this assertion checking that at least one more target beyond `otherwise` exists.
Sadly we don't have a small reproducer so I don't think we can easily add a testcase.
Fixed docs typo in `library/std/src/time.rs`
* Changed comment from `Previous rust versions panicked when self was earlier than the current time.` to `Previous rust versions panicked when the current time was earlier than self.`
* Resolves#103282.
Adjust `transmute{,_copy}` to be clearer about which of `T` and `U` is input vs output
This is essentially a documentation-only change (although it does touch code in an irrelevant way).
linker: Fix weak lang item linking with combination windows-gnu + LLD + LTO
In https://github.com/rust-lang/rust/pull/100404 this logic was originally disabled for MSVC due to issues with LTO, but the same issues appear on windows-gnu with LLD because that LLD uses the same underlying logic as MSVC LLD, just with re-syntaxed command line options.
So this PR just disables it for LTO builds in general.
Magic functions for writing to stdout/stderr.
This enables I/O in no_std contexts (or, really, any Miri-specific OS-independent context). Combined with the `abort` intrinsic it should allow a reasonable test framework in no_std.
**Question for maintainers:** So, the `no_std` panic test needs work, for two reasons:
- First, its stdout includes Miri's whole message about the abort intrinsic having been used. I guess whatever panic handler you use in `std` contexts exits cleanly without triggering this message. Comparing the entire output with backtrace as golden seems fragile.
- Second, likely for the same reason, the test framework appears to expect the test to exit successfully, when in fact it exits with status 1 due to the abort. This means the test doesn't actually pass right now.
What shall I do there?
Fix the bug of next_point in source_map
There is a bug in `next_point`, the new span won't move to next position when be called in the first time.
For this reason, our current code is working like this:
1. When we really want to move to the next position, we called two times of `next_point`
2. Some code which use `next_point` actually done the same thing with `shrink_to_hi`
This fix make sure when `next_point` is called, span will move with the width at least 1, and also work correctly in the scenario of multiple bytes.
Ref: https://github.com/rust-lang/rust/pull/103140#discussion_r997710998
r? `@davidtwco`
rustdoc: remove no-op CSS `nav.sub { font-size: 1rem }`
This rule originated as a `font-size: 16px`, when body had `font-size: 13px` set in 4fd061c426.
It remained even when body's font size was bumped up to 16px, 4d5f4ff5e9, making the rule a no-op, and was carried forward when it was converted to 1rem in cc18120425.
