| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Migrate `run-make/rustdoc-with-out-dir-option` to new `rmake.rs`
Part of https://github.com/rust-lang/rust/issues/121876.
r? `@jieyouxu`
|
|
Rollup of 5 pull requests
Successful merges:
- #123694 (expand: fix minor diagnostics bug)
- #125171 (Rename `flatten(_mut)` → `as_flattened(_mut)`)
- #125181 (set `rust.channel` properly in source tarballs)
- #125186 (Remove duplicate word from addr docs)
- #125191 (Report better WF obligation leaf obligations in new solver)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Report better WF obligation leaf obligations in new solver
r? lcnr
|
|
Remove duplicate word from addr docs
This PR simply removes a duplicate word from the addr docs for *mut T.
|
|
set `rust.channel` properly in source tarballs
This change sets the appropriate channel by default when using nightly, beta or stable source tarballs.
Fixes #124618
|
|
Rename `flatten(_mut)` → `as_flattened(_mut)`
As requested by libs-api in https://github.com/rust-lang/rust/issues/95629#issuecomment-2113081194
(This is just the rename, not the stabilization, so can land without waiting on the FCP in that other issue.)
|
|
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 default value changes on `x86_64-unknown-linux-gnu`, and semantics kinda
as it will impact the target's default linker
|
|
|
|
|
|
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
|
|
This is used to notify we want to use rust-lld as the default linker in
a target.
|
|
This change sets the appropriate channel by default when using nightly,
beta or stable source tarballs.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Rollup of 5 pull requests
Successful merges:
- #124871 (Don't ICE because recomputing overflow goals during find_best_leaf_obligation causes inference side-effects)
- #125018 (Update linker-plugin-lto.md to include LLVM 18)
- #125130 (rustdoc-json-types: Document `Id`)
- #125170 (Uplift `FnSig` into `rustc_type_ir` (redux))
- #125172 (Fix assertion when attempting to convert `f16` and `f128` with `as`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
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.
|
|
Uplift `FnSig` into `rustc_type_ir` (redux)
Since the last one got so messed up with `try` build.
https://github.com/rust-lang/rust/pull/125157#issuecomment-2113158408
r? lcnr
|
|
rustdoc-json-types: Document `Id`
Inspired by finding [someone looking into the internals of an id](https://github.com/rust-lang/rust/issues/91609#issuecomment-2110994540), I realized we only document the fact that these are opaque on [the rfc](https://rust-lang.github.io/rfcs/2963-rustdoc-json.html#id).
r? `@GuillaumeGomez`
|
|
Update linker-plugin-lto.md to include LLVM 18
I did this manually not via provided script.
|
|
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 #124834
Fixes #124845
r? lcnr
|
|
find_best_leaf_obligation causes inference side-effects
|
|
|
|
|
|
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
|
|
r=fmease
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.
|
|
workingjubilee:macro-metavar-expr-with-a-shorter-len, r=c410-f3r,joshtriplett,joshtriplett
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`
|
|
Rollup of 5 pull requests
Successful merges:
- #125003 (avoid using aligned_alloc; posix_memalign is better-behaved)
- #125142 (Migrate `run-make/rustdoc-themes` to new rmake.rs)
- #125146 (Migrate `run-make/panic-impl-transitive` to `rmake`)
- #125154 (Small improvements to the documentaion of FnAbi )
- #125159 (Meta: Allow unauthenticated users to modify `L-*`, `PG-*` and `-Z*` labels)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
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.
|
|
Migrate `run-make/panic-impl-transitive` 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 itself is quite simple, but the "handle panics by entering infinite loop" part is strange.
|
|
Migrate `run-make/rustdoc-themes` to new rmake.rs
Part of https://github.com/rust-lang/rust/issues/121876.
r? `@jieyouxu`
|
|
avoid using aligned_alloc; posix_memalign is better-behaved
Also there's no reason why wasi should be different than all the other Unixes here.
|
