Inline CStr::from_bytes_with_nul_unchecked::rt_impl
Currently `CStr::from_bytes_with_nul_unchecked::rt_impl` is not being inlined. The following function:
```rust
pub unsafe fn from_bytes_with_nul_unchecked(bytes: &[u8]) {
CStr::from_bytes_with_nul_unchecked(bytes);
}
```
Outputs the following assembly on current nightly
```asm
example::from_bytes_with_nul_unchecked:
jmp qword ptr [rip + _ZN4core3ffi5c_str4CStr29from_bytes_with_nul_unchecked7rt_impl17h026f29f3d6a41333E@GOTPCREL]
```
Meanwhile on beta this provides the following assembly:
```asm
example::from_bytes_with_nul_unchecked:
ret
```
This pull request adds `#[inline]` annotation to`rt_impl` to fix a code generation regression for `CStr::from_bytes_with_nul_unchecked`.
Fixes bootstrap panic when running x fmt --check
closes#100258 wherein bootstrap panics when running x fmt --check. Fixed by replacing resume_unwind in #98994. with process::exit.
Add support for link-flavor rust-lld for macOS
Also refactor iOS, watchOS and tvOS common code.
The ``-arch`` argument was moved to the ``apple_base`` module instead of the target definitions for macOS.
As ld64 requires ``-syslibroot`` to be passed, ``add_apple_sdk`` was modified accordingly.
compiletest: use target cfg instead of hard-coded tables
This changes compiletest to use `rustc --print=cfg` to dynamically determine the properties of a target when matching `ignore` and `only` rules instead of using hard-coded tables or target-triple parsing (which don't always follow the `<arch><sub>-<vendor>-<sys>-<abi>` pattern). The benefit here is that it will more accurately match the target properties, and not require maintaining these extra tables.
This also adds matching the `target_family` in ignore rules. The primary benefit here is so that `ignore-wasm` works as expected (matching all wasm-like targets). There were already several tests that had `ignore-wasm` in them (which previously had no effect), so it is evident that some people expected that to work. This also adds `ignore-unix/only-unix`.
There is some risk that this changes the behavior from before since the tables aren't quite the same as the target properties. However, I did fairly extensive comparisons to see what would be different. https://gist.github.com/ehuss/5bf7ab347605160cefb6f84ba5ea5f6b contains a full list of differences for all targets for all tests. I do not think any of the affected target/test combinations are things that are actually tested in CI. I tested several of the more unusual test images (test-various, dist-various-1, wasm32), and they seem fine.
A summary of most of the reasons behind the differences:
- wasm64-unknown-unknown wasm32-wasi now match "wasm"
- Targets now match "gnu" because they have target_env=gnu
- aarch64-wrs-vxworks
- armv7-wrs-vxworks-eabihf
- i686-wrs-vxworks
- powerpc-wrs-vxworks
- powerpc64-wrs-vxworks
- x86_64-wrs-vxworks
- wasm64-unknown-unknown now matches wasm64
- x86_64-unknown-none-linuxkernel no longer matches "linux", but will match "gnu" and "none"
- Various arm targets now match "aarch64" or "arm":
- arm64_32-apple-watchos
- armebv7r-none-eabi
- armv6-unknown-freebsd
- armv6-unknown-netbsd-eabihf
- armv6k-nintendo-3ds
- armv7-wrs-vxworks-eabihf
- armv7a-kmc-solid_asp3-eabi
- armv7a-kmc-solid_asp3-eabihf
- armv7a-none-eabi
- armv7a-none-eabihf
- armv7k-apple-watchos
- armv7r-none-eabi
- armv7r-none-eabihf
- Now matches "thumb" and "arm"
- thumbv4t-none-eabi
- thumbv6m-none-eabi
- thumbv7a-pc-windows-msvc
- thumbv7a-uwp-windows-msvc
- thumbv7em-none-eabi
- thumbv7em-none-eabihf
- thumbv7m-none-eabi
- thumbv7neon-linux-androideabi
- thumbv7neon-unknown-linux-gnueabihf
- thumbv7neon-unknown-linux-musleabihf
- thumbv8m.base-none-eabi
- thumbv8m.main-none-eabi
- asmjs-unknown-emscripten now matches "wasm32" because that it is its defined arch
- avr-unknown-gnu-atmega328 now matches "none" (because target_os="none")
- now matches 64bit:
- bpfeb-unknown-none
- bpfel-unknown-none
- sparcv9-sun-solaris
- now matches endian-big:
- m68k-unknown-linux-gnu
- now matches 16bit:
- msp430-none-elf
- now matches 32bit:
- arm64_32-apple-watchos
- now matches riscv32 (and needs-asm-support):
- riscv32gc-unknown-linux-gnu
- riscv32gc-unknown-linux-musl
- riscv32i-unknown-none-elf
- riscv32im-unknown-none-elf
- riscv32imac-unknown-none-elf
- riscv32imac-unknown-xous-elf
- riscv32imc-esp-espidf
- riscv32imc-unknown-none-elf
- riscv64imac-unknown-none-elf
Resolves all of issue #93240
Reproduces a similar change as #99086, but with improvements
In particular, this PR inlcludes:
* redesigning the crate-search selector so the background color matches its surroundings
* decrease the font of the dropdown menu to a reaonable size
* add a hover effect
* make the color of the arrow theme-dependent, using a surrounding div, with :after pseudo-element
that can then be transformed using CSS filters to approximate the desired color
* fix the text "in" to match the title font
* remove the "for xyz" in the "Results for xyz in [All crates]" title when
searching for search term "xyz"; you can already see what you're searching for
as it's typed in the search bar!
* in line with #99086, handle super-long crate names appropriately without a long <select>
element escaping the screen area; the improvement is that we also keep the title
within a single line now; uses some flex layout shenanigans...
* the margins / paddings are adjusted so the selected label of the <select> fits within
the rest of that title nicely; also some inconsistency in the way that Firefox renders
a <select> with "appearance: none" (roughly 4px more padding left and right of the text
than e.g. Chrome) is worked around, and it now produces a result that looks (essentially)
identical to Chrome
* the color of the help menu and settings menu border in light theme is made to match with
the color of the corresponding buttons, like they do (match) in the ayu theme
* the casing of "All crates" changes to "all crates"
* the new tests from #99086 are temporarily disabled, until they can be adapted later
If a primary bundle doesn't contain a message then the fallback bundle
is used. However, if the primary bundle's message is broken (e.g. it
refers to a interpolated variable that the compiler isn't providing)
then this would just result in a compiler panic. While there aren't any
primary bundles right now, this is the type of issue that could come up
once translation is further along.
Signed-off-by: David Wood <david.wood@huawei.com>
Rollup of 8 pull requests
Successful merges:
- #99573 (Stabilize backtrace)
- #100069 (Add error if link_ordinal used with unsupported link kind)
- #100086 (Add more `// unit-test`s to MIR opt tests)
- #100332 (Rename integer log* methods to ilog*)
- #100334 (Suggest a missing semicolon before an array)
- #100340 (Iterate generics_def_id_map in reverse order to fix P-critical issue)
- #100345 (docs: remove repetition in `is_numeric` function docs)
- #100352 (Update cargo)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Update cargo
7 commits in 4fd148c47e733770c537efac5220744945d572ef..ce40690a5e4e315d3dab0aae1eae69d0252c52ac
2022-08-03 15:03:52 +0000 to 2022-08-09 22:32:17 +0000
- Make the `rust-version` error recommend `cargo update --precise -p crate@ver` (rust-lang/cargo#10891)
- resolver docs: link to version requirements syntax full explanation (rust-lang/cargo#10946)
- Bump os_info to 3.5.0 (rust-lang/cargo#10943)
- Mark --timings=html unstable in the document (rust-lang/cargo#10941)
- Mention that aliases are recursive (rust-lang/cargo#10935)
- Test if reserved filenames are allowed in Windows (rust-lang/cargo#10322)
- improve error message for `no such subcommand` (rust-lang/cargo#10924)
docs: remove repetition in `is_numeric` function docs
In https://github.com/rust-lang/rust/pull/99628 we introduce new docs for the `is_numeric` function, and this is a follow-up PR that removes some unnecessary repetition that may be introduced by some rebasing.
`@rustbot` r? `@joshtriplett`
Add more `// unit-test`s to MIR opt tests
I only changed things which are hopefully completely uninteresting. I plan to submit more PRs that cover more files, but those cases will need some more complicated (and hence possibly controversial) changes, so I'll try and submit those in reasonably sized batches.
r? rust-lang/wg-mir-opt
Add error if link_ordinal used with unsupported link kind
The `link_ordinal` attribute only has an affect if the `raw-dylib` link kind is used, so add an error if it is used with any other link kind.
Stabilize backtrace
This PR stabilizes the std::backtrace module. As of #99431, the std::Error::backtrace item has been removed, and so the rest of the backtrace feature is set to be stabilized.
Previous discussion can be found in #72981, #3156.
Stabilized API summary:
```rust
pub mod std {
pub mod backtrace {
pub struct Backtrace { }
pub enum BacktraceStatus {
Unsupported,
Disabled,
Captured,
}
impl fmt::Debug for Backtrace {}
impl Backtrace {
pub fn capture() -> Backtrace;
pub fn force_capture() -> Backtrace;
pub const fn disabled() -> Backtrace;
pub fn status(&self) -> BacktraceStatus;
}
impl fmt::Display for Backtrace {}
}
}
```
`@yaahc`
For some reason, adding some text to match against makes this test pass.
Before, when it was *more* general, it was failing!
This seems very likely to be a bug in htmldocck, which I'm going to
investigate.
Rollup of 14 pull requests
Successful merges:
- #98775 (rustdoc: improve scroll locking in the rustdoc mobile sidebars)
- #99479 (rustdoc-json: Remove doc FIXME for Import::id and explain)
- #100040 (Error on broken pipe but do not backtrace or ICE)
- #100072 (linker-plugin-lto.md: Correct the name of example c file)
- #100098 (Some "this expression has a field"-related fixes)
- #100226 (Do not manually craft a span pointing inside a multibyte character.)
- #100240 (Fail gracefully when const pattern is not structural match.)
- #100256 (Add some high-level docs to `FnCtxt` and `ItemCtxt`)
- #100261 (Set tainted errors bit before emitting coerce suggestions.)
- #100275 (also update anyhow in codegen_cranelift)
- #100281 (Remove more Clean trait implementations)
- #100314 (Mention `unit-test` in MIR opt test README)
- #100319 (Remove more Clean trait implementations)
- #100323 ([rustdoc] Don't render impl blocks with doc comment if they only contain private items by default)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Split render_with_highlighting, which took many optional parameters, into three
functions for specific purposes, which each take a smaller number of mostly
required parameters.
Remove some plumbing to pass through an "edition" parameter, which was used
solely to avoid highlighting some 2021 Edition keywords in non-2021 code.
