expand: fix minor diagnostics bug
The error mentions `///`, when it's actually `//!`:
```
error[E0658]: attributes on expressions are experimental
--> test.rs:4:9
|
4 | //! wah
| ^^^^^^^
|
= note: see issue https://github.com/rust-lang/rust/issues/15701 <https://github.com/rust-lang/rust/issues/15701> for more information
= help: add `#![feature(stmt_expr_attributes)]` to the crate attributes to enable
= help: `///` is for documentation comments. For a plain comment, use `//`.
```
Enable `rust-lld` on nightly `x86_64-unknown-linux-gnu`
We believe we have done virtually all the internal work and tests we could to prepare for using `lld` as the default linker (at least on Linux). We're IMHO at a point where we'd need to expand testing and coverage in order to make progress on this effort.
Therefore, for further testing and gathering real-world feedback, unexpected issues and use-cases, this PR enables `rust-lld` as the default linker:
- on nightly only (and dev channel)
- on `x86_64-unknown-linux-gnu` only
- when not using an external LLVM (except `download-ci-llvm`), so that distros are not impacted
as described in more detail in this [zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Enabling.20.60rust-lld.60.20on.20nightly.20.60x86_64-unknown-linux-gnu.60/near/433709343).
In case any issues happen to users, as e.g. lld is not bug-for-bug compatible with GNU ld, it's easy to disable with `-Zlinker-features=-lld` to revert to using the system's default linker.
---
I don't know who should review this kind of things, as it's somewhat of a crosscutting effort. Compiler contributor, compiler performance WG and infra member sounds perfect, so r? `@Mark-Simulacrum.`
The last crater run encountered a low number (44) of mainly avoidable issues, like small incompatibilities, user errors, and a difference between the two linkers about which default to use with `--gc-sections`. [Here's the triage report](https://hackmd.io/OAJxlxc6Te6YUot9ftYSKQ?view), categorizing the issues, with some analyses and workarounds. I'd appreciate another set of eyes looking at these results.
The changes in this PR have been test-driven for CI changes, try builds with tests enabled, rustc-perf with bootstrapping, in PR #113382.
For infra, about the CI change: this PR forces `rust.lld` to false on vanilla LLVM builders, just to make sure we have coverage without `rust-lld`. Though to be clear, just using an external LLVM is already enough to keep `rust.lld` to false, in turn reverting everything to using the system's default linker.
cc `@rust-lang/bootstrap` for the bootstrap and config change
cc `@petrochenkov` for the small compiler change
cc `@rust-lang/wg-compiler-performance`
The blog post announcing the change, that we expect to merge around the same time as we merge this PR, is open [on the blog repo](https://github.com/rust-lang/blog.rust-lang.org/pull/1319).
Bootstrap change history: this PR changes the default of a config option on `x86_64-unknown-linux-gnu`. It's, however, not expected to cause issues, or require any changes to existing configurations. It's a big enough change that people should at least know about it, in case it causes unexpected problems. If that happens, set `rust.lld = false` in your `config.toml` (and open an issue).
Uplift `Goal` to `rustc_type_ir`
r? lcnr
This also renames `ToPredicate` to `Uplift`, which is conceptually a helper trait for `Into`-like operations for things that need a `TyCtxt`. This name is based off of the same named trait from a-mir-formality.
feat: update stdarch submodule for intrinsics on ARM
Submodule update for stdarch library
10 commits in c0257c1660e78c80ad1b9136fcc5555b14da5b4c..df3618d9f35165f4bc548114e511c49c29e1fd9b
2024-04-22 01:24:03 +0200 to 2024-05-14 15:52:07 +0200
- feat: stabilization for stdarch_aarch64_crc32
- Add vec_insert and vec_extract
- Remove libc dependency on Windows by using Win32 to get env vars
- Add vec_orc
- Simplify vec_andc implementation
- Silence unexpected-cfgs
- Add vec_mul
- Remove `#![feature(inline_const)]`
- Add `#[cfg_attr(miri, ignore)]` to tests of intrinsics that cannot be supported by Miri
- Implement ARM `__ssat` and `__usat` functions
r? Amanieu
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.
