| Age | Commit message (Collapse) | Author | Lines |
|---|
|
(cherry picked from commit 5534cb0a4a3907db50956f7664ab2e5c3b2bc00a)
|
|
(cherry picked from commit 1be60b5d2b6ac569d51abd376e6f04e2fc07692c)
|
|
(cherry picked from commit 613155c96ab32daf12514e76476132e6b84adaf8)
|
|
(cherry picked from commit eae7a186b221bb2b4a4bedeb19d5aca658e91c25)
|
|
- Use if the implementation of [`Ord`] for `T`
language
- Link to total order wiki page
- Rework total order help and examples
- Improve language to be more precise and less
prone to misunderstandings.
- Fix usage of `sort_unstable_by` in `sort_by`
example
- Fix missing author mention
- Use more consistent example input for sort
- Use more idiomatic assert_eq! in examples
- Use more natural "comparison function" language
instead of "comparator function"
(cherry picked from commit afc404fdfc1559b4ba2846a054347e806bb8f465)
|
|
- Move panic information into # Panics section
- Fix mentions of T: Ord that should be compare
- Add missing information
(cherry picked from commit 00ce238885825e5e987dbcd4fef266e96157303d)
|
|
The new sort implementations have the ability to
detect Ord violations in many cases. This commit
improves the message in a way that should help
users realize what went wrong in their program.
(cherry picked from commit 644550f3de4805b3dec6ade4a60ecf48c1d2487b)
|
|
This reverts commit 31fe9628cf830a08e7194a446f66c668aaea86e9, reversing
changes made to f20307851ead9fbbb9fa88bbffb3258a069230a6.
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #127295 (CFI: Support provided methods on traits)
- #127814 (`C-cmse-nonsecure-call`: improved error messages)
- #127949 (fix: explain E0120 better cover cases when its raised)
- #127966 (Use structured suggestions for unconstrained generic parameters on impl blocks)
- #127976 (Lazy type aliases: Diagostics: Detect bivariant ty params that are only used recursively)
- #127978 (Avoid ref when using format! for perf)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Avoid ref when using format! for perf
Clean up a few minor refs in `format!` macro, as it has a performance cost. Apparently the compiler is unable to inline `format!("{}", &variable)`, and does a run-time double-reference instead (format macro already does one level referencing). Inlining format args prevents accidental `&` misuse.
|
|
Clean up a few minor refs in `format!` macro, as it has a tiny perf
cost. A few more minor related cleanups.
|
|
|
|
|
|
Use Option's discriminant as its size hint
I was looking at this in MIR after a question on discord, and noticed that it ends up with a switch in MIR (<https://rust.godbolt.org/z/3q4cYnnb3>), which it doesn't need because (as `Option::as_slice` uses) the discriminant is already the length.
|
|
ptr::metadata: avoid references to extern types
References to `extern types` are somewhat dubious entities, since generally we say that references must be dereferenceable for their size as determined via `size_of_val`, but with `extern type` that is an ill-defined statement. I'd like to make Miri warn for such cases since it interacts poorly with Stacked Borrows. To avoid warnings people can't fix, this requires not using references to `extern type` in the standard library, and I think `DynMetadata` is the only currently remaining use. so this changes `DynMetadata` to use a NonNull raw pointer instead. Given that the alignment was 1, this shouldn't really change anything meaningful.
I also updated a comment added by `@scottmcm` in https://github.com/rust-lang/rust/pull/125479, since I think the old comment is wrong. The `DynMetadata` type itself is not special, it is a normal aggregate. But computing field types for wide pointers (including references) is special.
|
|
Move a few intrinsics to Rust abi
Move a few more intrinsic functions to the convention added in #121192. In the second commit, I added documentation about their safety requirements. Let me know if you would like me to move the second commit to a different PR.
Note: I kept the same signature of `pref_align_of`, but I was wondering why this function is considered unsafe?
|
|
|
|
|
|
`impl Send + Sync` and override `count` for the `CStr::bytes` iterator
cc tracking issue #112115
|
|
Clean up more comments near use declarations
#125443 will reformat all use declarations in the repository. There are a few edge cases involving comments on use declarations that require care. This PR fixes them up so #125443 can go ahead with a simple `x fmt --all`. A follow-up to #126717.
r? ``@cuviper``
|
|
Skip fast path for dec2flt when optimize_for_size
Tracking issue: https://github.com/rust-lang/rust/issues/125612
Skip the fast algorithm when optimizing for size.
When compiling for https://github.com/quartiq/stabilizer I get these numbers:
Before
```
text data bss dec hex filename
192192 8 49424 241624 3afd8 dual-iir
```
After
```
text data bss dec hex filename
191632 8 49424 241064 3ada8 dual-iir
```
This saves 560 bytes.
|
|
Co-authored-by: Clar Fon <15850505+clarfonthey@users.noreply.github.com>
|
|
There are some comments describing multiple subsequent `use` items. When
the big `use` reformatting happens some of these `use` items will be
reordered, possibly moving them away from the comment. With this
additional level of formatting it's not really feasible to have comments
of this type. This commit removes them in various ways:
- merging separate `use` items when appropriate;
- inserting blank lines between the comment and the first `use` item;
- outright deletion (for comments that are relatively low-value);
- adding a separate "top-level" comment.
We also entirely skip formatting for four library files that contain
nothing but `pub use` re-exports, where reordering would be painful.
|
|
|
|
fix least significant digits of f128 associated constants
While the numbers are parsed to the correct value, the decimal numbers in the source were rounded to zero instead of to the nearest, making the literals different from the values shown in the documentation.
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #124921 (offset_from: always allow pointers to point to the same address)
- #127407 (Make parse error suggestions verbose and fix spans)
- #127684 (consolidate miri-unleashed tests for mutable refs into one file)
- #127729 (Stop using the `gen` identifier in the compiler)
- #127736 (Add myself to the review rotation)
- #127758 (coverage: Restrict `ExpressionUsed` simplification to `Code` mappings)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
offset_from: always allow pointers to point to the same address
This PR implements the last remaining part of the t-opsem consensus in https://github.com/rust-lang/unsafe-code-guidelines/issues/472: always permits offset_from when both pointers have the same address, no matter how they are computed. This is required to achieve *provenance monotonicity*.
Tracking issue: https://github.com/rust-lang/rust/issues/117945
### What is provenance monotonicity and why does it matter?
Provenance monotonicity is the property that adding arbitrary provenance to any no-provenance pointer must never make the program UB. More specifically, in the program state, data in memory is stored as a sequence of [abstract bytes](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#abstract-byte), where each byte can optionally carry provenance. When a pointer is stored in memory, all of the bytes it is stored in carry that provenance. Provenance monotonicity means: if we take some byte that does not have provenance, and give it some arbitrary provenance, then that cannot change program behavior or introduce UB into a UB-free program.
We care about provenance monotonicity because we want to allow the optimizer to remove provenance-stripping operations. Removing a provenance-stripping operation effectively means the program after the optimization has provenance where the program before the optimization did not -- since the provenance removal does not happen in the optimized program. IOW, the compiler transformation added provenance to previously provenance-free bytes. This is exactly what provenance monotonicity lets us do.
We care about removing provenance-stripping operations because `*ptr = *ptr` is, in general, (likely) a provenance-stripping operation. Specifically, consider `ptr: *mut usize` (or any integer type), and imagine the data at `*ptr` is actually a pointer (i.e., we are type-punning between pointers and integers). Then `*ptr` on the right-hand side evaluates to the data in memory *without* any provenance (because [integers do not have provenance](https://rust-lang.github.io/rfcs/3559-rust-has-provenance.html#integers-do-not-have-provenance)). Storing that back to `*ptr` means that the abstract bytes `ptr` points to are the same as before, except their provenance is now gone. This makes `*ptr = *ptr` a provenance-stripping operation (Here we assume `*ptr` is fully initialized. If it is not initialized, evaluating `*ptr` to a value is UB, so removing `*ptr = *ptr` is trivially correct.)
### What does `offset_from` have to do with provenance monotonicity?
With `ptr = without_provenance(N)`, `ptr.offset_from(ptr)` is always well-defined and returns 0. By provenance monotonicity, I can now add provenance to the two arguments of `offset_from` and it must still be well-defined. Crucially, I can add *different* provenance to the two arguments, and it must still be well-defined. In other words, this must always be allowed: `ptr1.with_addr(N).offset_from(ptr2.with_addr(N))` (and it returns 0). But the current spec for `offset_from` says that the two pointers must either both be derived from an integer or both be derived from the same allocation, which is not in general true for arbitrary `ptr1`, `ptr2`.
To obtain provenance monotonicity, this PR hence changes the spec for offset_from to say that if both pointers have the same address, the function is always well-defined.
### What further consequences does this have?
It means the compiler can no longer transform `end2 = begin.offset(end.offset_from(begin))` into `end2 = end`. However, it can still be transformed into `end2 = begin.with_addr(end.addr())`, which later parts of the backend (when provenance has been erased) can trivially turn into `end2 = end`.
The only alternative I am aware of is a fundamentally different handling of zero-sized accesses, where a "no provenance" pointer is not allowed to do zero-sized accesses and instead we have a special provenance that indicates "may be used for zero-sized accesses (and nothing else)". `offset` and `offset_from` would then always be UB on a "no provenance" pointer, and permit zero-sized offsets on a "zero-sized provenance" pointer. This achieves provenance monotonicity. That is, however, a breaking change as it contradicts what we landed in https://github.com/rust-lang/rust/pull/117329. It's also a whole bunch of extra UB, which doesn't seem worth it just to achieve that transformation.
### What about the backend?
LLVM currently doesn't have an intrinsic for pointer difference, so we anyway cast to integer and subtract there. That's never UB so it is compatible with any relaxation we may want to apply.
If LLVM gets a `ptrsub` in the future, then plausibly it will be consistent with `ptradd` and [consider two equal pointers to be inbounds](https://github.com/rust-lang/rust/pull/124921#issuecomment-2205795829).
|
|
Add classify and related methods for f16 and f128
Also constify some functions where that was blocked on classify being available.
r? libs
|
|
These constifications were blocked on classification functions being
added. Now that those methods are available, constify them.
This brings things more in line with `f32` and `f64`.
|
|
|
|
|
|
doc: Suggest `str::repeat` over `iter::repeat().take().collect()`
r? libs
|
|
r=Mark-Simulacrum
Remove memory leaks in doctests in `core`, `alloc`, and `std`
cc `@RalfJung` https://github.com/rust-lang/rust/issues/126067 https://github.com/rust-lang/miri/issues/3670
Should be no actual *documentation* changes[^1], all added/modified lines in the doctests are hidden with `#`,
This PR splits the existing memory leaks in doctests in `core`, `alloc`, and `std` into two general categories:
1. "Non-focused" memory leaks that are incidental to the thing being documented, and/or are easy to remove, i.e. they are only there because preventing the leak would make the doctest less clear and/or concise.
- These doctests simply have a comment like `# // Prevent leaks for Miri.` above the added line that removes the memory leak.
- [^2]Some of these would perhaps be better as part of the public documentation part of the doctest, to clarify that a memory leak can happen if it is not otherwise mentioned explicitly in the documentation (specifically the ones in `(A)Rc::increment_strong_count(_in)`).
2. "Focused" memory leaks that are intentional and documented, and/or are possibly fragile to remove.
- These doctests have a `# // FIXME` comment above the line that removes the memory leak, with a note that once `-Zmiri-disable-leak-check` can be applied at test granularity, these tests should be "un-unleakified" and have `-Zmiri-disable-leak-check` enabled.
- Some of these are possibly fragile (e.g. unleaking the result of `Vec::leak`) and thus should definitely not be made part of the documentation.
This should be all of the leaks currently in `core` and `alloc`. I only found one leak in `std`, and it was in the first category (excluding the modules `@RalfJung` mentioned in https://github.com/rust-lang/rust/issues/126067 , and reducing the number of iterations of [one test](https://github.com/rust-lang/rust/blob/master/library/std/src/sync/once_lock.rs#L49-L94) from 1000 to 10)
[^1]: assuming [^2] is not added
[^2]: backlink
|
|
Using ../../std syntax because of difficulty link alloc stuff to core.
|
|
Stabilize const unchecked conversion from u32 to char
Closes https://github.com/rust-lang/rust/issues/89259.
The functions in this PR were left out of the initial set of `feature(const_char_convert)` stabilizations in https://github.com/rust-lang/rust/pull/102470, but have since been unblocked by https://github.com/rust-lang/rust/pull/118979.
If `unsafe { from_u32_unchecked(u) }` is called in const with a value for which `from_u32(u)` returns None, we get the following compile error.
```rust
fn main() {
let _ = const { unsafe { char::from_u32_unchecked(0xd800) } };
}
```
```console
error[E0080]: it is undefined behavior to use this value
--> src/main.rs:2:19
|
2 | let _ = const { unsafe { char::from_u32_unchecked(0xd800) } };
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ constructing invalid value: encountered 0x0000d800, but expected a valid unicode scalar value (in `0..=0x10FFFF` but not in `0xD800..=0xDFFF`)
|
= note: The rules on what exactly is undefined behavior aren't clear, so this check might be overzealous. Please open an issue on the rustc repository if you believe it should not be considered undefined behavior.
= note: the raw bytes of the constant (size: 4, align: 4) {
00 d8 00 00 │ ....
}
note: erroneous constant encountered
--> src/main.rs:2:13
|
2 | let _ = const { unsafe { char::from_u32_unchecked(0xd800) } };
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
|
|
Improved slice documentation
Improve slice documentation to include assert_eq checks for all the cases where there were existing examples. I think it makes things more clear when the documentation explicitly checks against values and shows the reader what it does.
I also started a rust internals discussion about it here: https://internals.rust-lang.org/t/improve-slice-documentaion/21168
|
|
|
|
Since the libs and lang teams completed an FCP to allow for const
`strlen` ([1]), currently implemented with `const_eval_select`, there is
no longer any reason to avoid this specific function or use it only in
const.
Rename it to reflect this status change.
[1]: https://github.com/rust-lang/rust/issues/113219#issuecomment-2016939401
|
|
Stabilize const_cstr_from_ptr (CStr::from_ptr, CStr::count_bytes)
Completed the pair of FCPs https://github.com/rust-lang/rust/issues/113219#issuecomment-2016939401 + https://github.com/rust-lang/rust/issues/114441#issuecomment-2016942566.
`CStr::from_ptr` is covered by just the first FCP on its own. `CStr::count_bytes` requires the approval of both FCPs. The second paragraph of the first link and the last paragraph of the second link explain the relationship between the two FCPs. As both have been approved, we can proceed with stabilizing `const` on both of these already-stable functions.
|
|
A `rustc_const_stable` attribute by itself has nonintuitive purpose when
placed in a public module.
Separately, it would probably be okay to rename `const_strlen` to just
`strlen` to make it more clear this is our general-purpose
implementation of strlen now, not something specifically for const
(avoiding confusion like in PR 127444).
|
|
as_simd: fix doc comment to be in line with align_to
In #121201, the guarantees about `align_offset` and `align_to` were changed. This PR aims to correct the doc comment of `as_simd` to be in line with the new `align_to`.
Tagging #86656 for good measure.
|
|
Rename `lazy_cell_consume` to `lazy_cell_into_inner`
Name this something that is less confusable with an atomic consume API for `{Lazy,Once}Lock`.
|
|
core: Limit remaining f16 doctests to x86_64 linux
On s390x, every use of the f16 data type will currently ICE due to https://github.com/llvm/llvm-project/issues/50374, causing doctest failures on the platform.
Most doctests were already restricted to certain platforms, so fix this by likewise restricting the remaining five.
|
|
Suggest borrowing on fn argument that is `impl AsRef`
When encountering a move conflict, on an expression that is `!Copy` passed as an argument to an `fn` that is `impl AsRef`, suggest borrowing the expression.
```
error[E0382]: use of moved value: `bar`
--> f204.rs:14:15
|
12 | let bar = Bar;
| --- move occurs because `bar` has type `Bar`, which does not implement the `Copy` trait
13 | foo(bar);
| --- value moved here
14 | let baa = bar;
| ^^^ value used here after move
|
help: borrow the value to avoid moving it
|
13 | foo(&bar);
| +
```
Fix #41708
|
|
Name this something that is less confusable with an atomic consume API for
`{Lazy,Once}Lock`.
|
|
On s390x, every use of the f16 data type will currently ICE
due to https://github.com/llvm/llvm-project/issues/50374,
causing doctest failures on the platform.
Most doctests were already restricted to certain platforms,
so fix this by likewise restricting the remaining five.
|
|
impl FusedIterator and a size hint for the error sources iter
cc tracking issue #58520
|
|
std: Set `has_reliable_f16` to false for MIPS targets in build.rs
This PR makes std tests link for MIPS again (they broke with https://github.com/rust-lang/rust/pull/126608) by avoiding the following link errors. Step-by-step instructions on how to reproduce these errors in docker can be found below.
std.9e27ea-cgu.12:(.text._ZN3std3num8test_num17edc3E+0x38): undefined reference to `__gnu_f2h_ieee'
std.9e27ea-cgu.12:(.text._ZN3std3num8test_num17hdc3E+0x38): undefined reference to `__gnu_h2f_ieee'
This PR just adds one line of config in existing f16 infrastructure. It also disables four doctests that fails with the same link errors.
## Step-by-step to reproduce linking error
1. Prepare:
```sh
docker run -it ubuntu:24.10
apt update && apt install -y \
libc6-mips-cross \
libc6-mipsel-cross \
libc6-mips64-cross \
libc6-mips64el-cross \
gcc-mips-linux-gnu \
gcc-mipsel-linux-gnu \
gcc-mips64-linux-gnuabi64 \
gcc-mips64el-linux-gnuabi64 \
git curl python3 build-essential
git clone --depth 1 https://github.com/rust-lang/rust.git
cd rust
```
2. Try to link std tests for any of these 4 MIPS targets by running any one of these commands:
```sh
CC_mips_unknown_linux_gnu=mips-linux-gnu-gcc \
CARGO_TARGET_MIPS_UNKNOWN_LINUX_GNU_LINKER=mips-linux-gnu-gcc \
./x test library/std --target mips-unknown-linux-gnu
CC_mipsel_unknown_linux_gnu=mipsel-linux-gnu-gcc \
CARGO_TARGET_MIPSEL_UNKNOWN_LINUX_GNU_LINKER=mipsel-linux-gnu-gcc \
./x test library/std --target mipsel-unknown-linux-gnu
CC_mips64_unknown_linux_gnuabi64=mips64-linux-gnuabi64-gcc \
CARGO_TARGET_MIPS64_UNKNOWN_LINUX_GNUABI64_LINKER=mips64-linux-gnuabi64-gcc \
./x test library/std --target mips64-unknown-linux-gnuabi64
CC_mips64el_unknown_linux_gnuabi64=mips64el-linux-gnuabi64-gcc \
CARGO_TARGET_MIPS64EL_UNKNOWN_LINUX_GNUABI64_LINKER=mips64el-linux-gnuabi64-gcc \
./x test library/std --target mips64el-unknown-linux-gnuabi64
```
### Expected
No link error. After this PR there are no link errors.
### Actual
```
error: linking with `mips-linux-gnu-gcc` failed: exit status: 1
|
= note: LC_ALL="C" PATH="/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/bin:/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/bin:/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" VSLANG="1033" "mips-linux-gnu-gcc" "/tmp/rustcEtKsay/symbols.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.00.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.01.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.02.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.03.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.04.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.05.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.06.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.07.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.08.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.09.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.10.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.11.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.12.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.13.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.14.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.15.rcgu.o" "-Wl,--as-needed" "-L" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps" "-L" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/release/deps" "-L" "/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/mips-unknown-linux-gnu/lib" "-Wl,-Bstatic" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/librand_xorshift-deb32232a867c543.rlib" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/librand-5a391600dce9d98f.rlib" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/librand_core-a11cfba3d86c5298.rlib" "/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/mips-unknown-linux-gnu/lib/libtest-65b05caf5a9b99a4.rlib" "/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/mips-unknown-linux-gnu/lib/libgetopts-ba692b2f798aef60.rlib" "/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/mips-unknown-linux-gnu/lib/libunicode_width-20ec8b475126cb0b.rlib" "/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/mips-unknown-linux-gnu/lib/librustc_std_workspace_std-c17f739fee51cc86.rlib" "-L" "/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/mips-unknown-linux-gnu/lib" "-Wl,-Bdynamic" "-lstd-124ee57a4c00deda" "-Wl,-Bstatic" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/libcompiler_builtins-bd55a137b89bc81f.rlib" "-Wl,-Bdynamic" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl" "-lc" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-L" "/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/mips-unknown-linux-gnu/lib" "-o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-Wl,-O1" "-nodefaultlibs" "-Wl,-z,origin" "-Wl,-rpath,$ORIGIN/../lib"
= note: /usr/lib/gcc-cross/mips-linux-gnu/12/../../../../mips-linux-gnu/bin/ld: /rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.12.rcgu.o: in function `std::num::test_num':
std.9ee227e919a554fa-cgu.12:(.text._ZN3std3num8test_num17haed2ea710c1afdc3E+0x38): undefined reference to `__gnu_f2h_ieee'
/usr/lib/gcc-cross/mips-linux-gnu/12/../../../../mips-linux-gnu/bin/ld: std.9ee227e919a554fa-cgu.12:(.text._ZN3std3num8test_num17haed2ea710c1afdc3E+0x3c): undefined reference to `__gnu_f2h_ieee'
/usr/lib/gcc-cross/mips-linux-gnu/12/../../../../mips-linux-gnu/bin/ld: std.9ee227e919a554fa-cgu.12:(.text._ZN3std3num8test_num17haed2ea710c1afdc3E+0x44): undefined reference to `__gnu_h2f_ieee'
...
collect2: error: ld returned 1 exit status
error: could not compile `std` (lib test) due to 1 previous error
```
|
