Re-add `From<f16> for f64`
This impl was originally added in #122470 before being removed in #123830 due to #123831. However, the issue only affects `f32` (which currently only has one `From<{float}>` impl, `From<f32>`) as `f64` already has two `From<{float}>` impls (`From<f32>` and `From<f64>`) and is also the float literal fallback type anyway. Therefore it is safe to re-add `From<f16> for f64`.
This PR also updates the FIXME link to point to the open issue #123831 rather than the closed issue #123824.
Tracking issue: #116909
`@rustbot` label +F-f16_and_f128 +T-libs-api
the `rust.lld` config enables rustc's `CFG_USE_SELF_CONTAINED_LINKER` env var, and we:
- set the linker-flavor to use lld
- enable the self-contained linker
this makes the target use the rust-lld linker by default
`x86_64-unknown-linux-gnu` has switched to using the self-contained linker
by default (unless asked not to), so we have to build rust-lld:
- when we build our own llvm
- when we use download-ci-llvm
- otherwise, when using an external llvm we can't enable it
Fix assertion when attempting to convert `f16` and `f128` with `as`
These types are currently rejected for `as` casts by the compiler. Remove this incorrect check and add codegen tests for all conversions involving these types.
Don't ICE because recomputing overflow goals during find_best_leaf_obligation causes inference side-effects
See the comments for more info. Reprocessing overflowed obligations may cause *other* goals to go from ambig -> pass/fail, causing an ICE. This suppresses that error, but makes all the overflow obligations messages back to their root obl. That kinda sucks, but 🤷Fixes#124834Fixes#124845
r? lcnr
Refactor examples and enhance documentation in result.rs
- Replaced `map` with `map_err` in the error handling example for correctness
- Reordered example code to improve readability and logical flow
- Added assertions to examples to demonstrate expected outcomes
Include line tables in compiler profile
This profile has only undergone minimal tweaks since it was originally drafted. I asked a number of compiler contributors and they said they set rust.debug explicitly. This was even true for one contributor that set `rust.debug = false`! Almost everyone seems slightly surprised that `rust.debug = true` is not the default.
However, adding full debuginfo at this level costs multiple gigabytes! We can still get much better profiling and such by setting `rust.debuginfo-level = "line-tables-only"` at the cost of only 150~200 MB on the weight of a fresh build dir from `./x.py check`.
These types are currently rejected for `as` casts by the compiler.
Remove this incorrect check and add codegen tests for all conversions
involving these types.
This profile has only undergone minimal tweaks since it was originally
drafted. I asked a number of compiler contributors and they said they
set rust.debug explicitly. This was even true for one contributor that
set `rust.debug` = false! Almost everyone seems slightly surprised that
`rust.debug = true` is not the default.
However, adding full debuginfo at this level costs multiple gigabytes!
We can still get much better debuginfo by setting "line-tables-only"
at the cost of only 150~200 MB.
Rename `${length()}` to `${len()}`
Implements the rename suggested in https://github.com/rust-lang/rust/pull/122808#issuecomment-2047722187
> I brought this up in the doc PR but it belongs here – `length` should probably be renamed `len` before stabilization. The latter is de facto standard in the standard library, whereas the former is only used in a single unstable API. These metafunctions aren’t library items of course, but should presumably still be consistent with established names.
r? `@c410-f3r`
Meta: Allow unauthenticated users to modify `L-*`, `PG-*` and `-Z*` labels
Complements: rust-lang/rust-forge#744.
1. `L-*`: Issues and PRs concerning specific lints
2. `PG-*`: Issues and PRs concerning specific project groups
3. `-Z*`: Issues and PRs concerning specific unstable `-Z` compiler options
These are safe to expose. Allows unauthenticated users greater leeway in triaging issues.
We have a lot of such people <3 and I want to support them as much as possible.
r? jieyouxu (you get assigned a lot these days :P) or compiler
Small improvements to the documentaion of FnAbi
I have updated the documentation of `FnAbi`.
The `arg` and `ret` fields are no longer LLVM types, but Rust types(`ArgAbi` contains a `TyAndLayout` and a `PassMode`), so I changed the documentation to reflect that.
Besides that, I also added documentation to other fields, and added a clarification about the differences between `FnAbi` and `FnSig`, since this is not something that is immediately obvious.
rustdoc: Negative impls are not notable
In #124097, we add `impl !Iterator for [T]` for coherence reasons, and since `Iterator` is a [notable trait](8387315ab3/library/core/src/iter/traits/iterator.rs (L40)), this means that all `-> &[_]` now are tagged with a `!Iterator` impl as a notable trait.
I "fixed" the failing tests in that PR with 6cbbb8b709a43482847243484ed67131e372ba71, where I just blessed the tests, since I didn't want to mix these changes with that PR; however, don't believe negative impls are notable, and this PR aims to prevent these impls from being mentioned.
In the standard library, we use negative impls purely to guide coherence. They're not really a signal of anything useful to the end-user. If there ever is a case that we want negative impls to be mentioned as notable, this really should be an opt-in feature.
MIR operators: clarify Shl/Shr handling of negative offsets
"made unsigned" was not fully clear (made unsigned how? by using `abs`? no), so let's say "re-interpreted as an unsigned value of the same size" instead.
r? `@scottmcm`
Migrate `run-make/no-cdylib-as-rdylib` to `rmake`
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
> "the test will fail if the cdylib is picked, because it doesn't export any rust symbols"
Is that true? Is there a way to verify?
I suggest maybe extending the test with: (after cleaning the directory)
```rust
rustc()
.input("bar.rs")
.crate_type("cdylib")
.run();
rustc()
.input("foo.rs")
.prefer_dynamic()
.run();
fail();
```
to make sure we're actually testing something here.
Invert comparison in `uN::checked_sub`
After #124114, LLVM no longer combines the comparison and subtraction in `uN::checked_sub` when either operand is a constant (demo: https://rust.godbolt.org/z/MaeoYbsP1). The difference is more pronounced when the expression is slightly more complex (https://rust.godbolt.org/z/4rPavsYdc).
This is due to the use of `>=` here:
ee97564e3a/library/core/src/num/uint_macros.rs (L581-L593)
For constant `C`, LLVM eagerly converts `a >= C` into `a > C - 1`, but the backend can only combine `a < C` with `a - C`, not `C - 1 < a` and `a - C`: e586556e37/llvm/lib/CodeGen/CodeGenPrepare.cpp (L1697-L1742)
This PR[^1] simply inverts the `>=` into `<` to restore the LLVM magic, and somewhat align this with the implementation of `uN::overflowing_sub` from #103299.
When the result is stored as an `Option` (rather than being branched/cmoved on), the discriminant is `self >= rhs`. This PR doesn't affect the codegen (and relevant tests) of that since LLVM will negate `self < rhs` to `self >= rhs` when necessary.
[^1]: Note to `self`: My very first contribution to publicly-used code. Hopefully like what I should learn to always be, tiny and humble.
