Update wasm-related dependencies in CI
* Update to wasi-sdk-29 released today
* Update to Wasmtime 38.0.4 which was released a week or so ago
This is the same as rust-lang/rust#148611, except with wasi-sdk-29 to fixup some issues found in wasi-sdk-28.
Inherent const impl
Some constifications are annoying because we need to repeat `T: Trait` bounds from an impl block on the individual constified `const fn`s as `T: [const] Trait`. We've brainstormed solutions before, and one would be to have separate `const impl` blocks or sth. However the final syntax will look, I decided to just impl this syntax and either have sth nice on nightly to work with or at least move the discussion along.
Also interacts with the discussion around `impl const Trait for Type` vs `const impl Trait for Type`, as we may want to use the latter to keep inherent and trait impls in sync (unless we come up with even another scheme).
* [ ] rustdoc + tests
* [ ] macro stability /regression tests
r? `@fee1-dead`
cc `@traviscross` `@rust-lang/project-const-traits`
debug-assert FixedSizeEncoding invariant
Something like this? It asserts during encoding that for that type, decoding 0 would give the default.
Preferably, I'd either somehow statically/in const assert it once, instead of every time, but I see no easy way to do so. It'd require us to iterate all types that implement the trait or something. Let me know what you think
No types currently violate this invariant.
r? `@oli-obk`
repr(transparent) check: do not compute check_unsuited more than once
`field_infos` is an iterator that we execute multiple times. However, we usually ignore the `unsuited` field -- we only need it in the last iteration. So move the computation of that field to that iteration to avoid computing it multiple times. Computing `unsuited` involves a recursive traversal over the types of all non-trivial fields, so there can be non-trivial amounts of work here.
(I benchmarked this in https://github.com/rust-lang/rust/pull/148243 and saw no changes, probably because we don't have a benchmark with many repr(transparent) types. But still, computing this each time just seemed silly.)
Improve the documentation of atomic::fence
Attempt to "fix" two flaws of the current documentation:
1. The over-emphasis of fence - fence synchronization, relegating atomic - fence and fence - atomic synchronization to second fiddle.
2. The lack of explanation as to how to properly perform atomic - fence and fence - atomic synchronization.
It does so by first making it clear that there are 3 different ways to use an atomic fence, then presenting a full example for each usecase, noting the particular position of the fence with regard to the atomic operation, and rounding up with generic notes.
Replace OffsetOf by an actual sum of calls to intrinsic.
This PR changes the way we compute the value of the `offset_of!` macro in MIR. The current implementation uses a dedicated MIR rvalue.
This PR proposes to replace it by an inline constant which sums calls to a new intrinsic `offset_of(variant index, field index)`. The desugaring is done at THIR building time, easier that doing it on MIR.
The new intrinsic is only meant to be used by const-eval. LLVM codegen will refuse to generate code for it.
We replace:
```rust
a = offset_of!(T, Variant1.Field1.Variant2.Field2);
```
By:
```rust
a = const {constant#n};
{constant#n}: usize = {
_1 = offset_of::<T>(index of Variant1, index of Field1);
_2 = offset_of::<U>(index of Variant2, index of Field2); // Where T::Variant1::Field1 has type U
_0 = _1 + _2
}
```
The second commit modifies intrinsic const checking to take `allow_internal_unstable` into account. The new intrinsic should only be called from stable `offset_of!` macro. The intrinsic itself is unstable, const-unstable, but `rustc_intrinsic_const_stable_indirect`.
Fixesrust-lang/rust#123959Fixesrust-lang/rust#125680Fixesrust-lang/rust#129425Fixesrust-lang/rust#136175
r? `@ghost`
Build with -Zannotate-moves by default (non-stage-0 only)
Build rustc and tools with -Zannotate-moves by default, both to exercise the feature and because could be useful for doing performance measurement on rustc and its tools. This has no effect on generated code, it just adds extra debug info in
the form of some new inlined functions.
This also adds bootstrap.toml config options
```
# rust.annotate-moves = true
# rust.annotate-moves-size-limit = 65
```
to allow this to be controlled locally.
This is only added for stage 1 and later. Stage 0 (the bootstrap compiler) doesn't yet support -Zannotate-moves.
doc: fix `strict_provenance_lints` tracking issue link
This PR is a follow-up on 56ee492a6e and fixes the link to the `strict_provenance_lints` tracking issue.
I am not sure whether we should touch this line too:
66bc5a43e5/compiler/rustc_lint_defs/src/builtin.rs (L2537)
r? `@RalfJung`
rust-installer/install-template.sh: improve efficiency, step 1.
This round replaces repetitive pattern matching in the inner loop of this script using grep (which causes a `fork()` for each test) with built-in pattern matching in the Bourne shell using the `case` / `esac` construct.
This in reference to
https://github.com/rust-lang/rust/issues/80684
and is a separated-out request from
https://github.com/rust-lang/rust-installer/pull/111
which apparently never got any review.
The forthcoming planned "step 2" change builds on top of this change, and replaces the inner-loops needless uses of `sed` (which again causes a `fork()` for each instance) with the suffix removal constructs from the Bourne shell. Since this change touches lots of the same lines this change does, that pull request cannot be submitted before this one is accepted.
Hopefully this first step is less controversial than the latter change.
Remove `rustc_inherit_overflow_checks` from `position()` in slice iterators
This method implementation can never cause an overflow, since `i` can never go over the slice's length.
rustdoc: quality of life changes
- Support `=` shortcut (alongside `+`) to expand all sections. Already support `s` and `S`, `Shift` or not.
- ~~Fix search-input's placeholder. The input is auto focused, any key press will be accepted as input not shortcut, current placeholder is missleading.~~
Implement the MCP 932: Promote riscv64a23-unknown-linux-gnu to Tier 2
Implement the [MCP 932](https://github.com/rust-lang/compiler-team/issues/932): Promote riscv64a23-unknown-linux-gnu to Tier 2 without host tools.
Closesrust-lang/rust#148353.
Changes:
- Update target tier from 3 to 2 in target specification
- Update platform documentation
- Add CI/CD support for automatic building and distribution via rustup
r? jieyouxu
cc `@davidtwco` `@Noratrieb`
Encode cfg trace, not its early counterpart to fix cross-crate `doc(auto_cfg)`
Fixesrust-lang/rust#141301.
<details><summary>Rambling about <code>target_feature</code> which I didn't touch here</summary>
Regarding https://github.com/rust-lang/rust/issues/141301#issuecomment-3390100259 (`#[target_feature(enable = …)]` on inlined cross-crate re-exports), it has the same underlying cause (namely, we neither encode `target_feature` nor `AttributeKind::TargetFeature` in the crate metadata). However, I didn't make that change because I first want to experiment with querying `TyCtxt::codegen_fn_attrs` in rustdoc instead which already works cross-crate (and also use to it for reconstructing `no_mangle`, `export_name`, `link_section` to avoid encoding these attributes unnecessarily (basically reverting rust-lang/rust#144050) as suggested in https://github.com/rust-lang/rust/issues/144004#issuecomment-3077725837).
</details>
r? GuillaumeGomez
mgca: Add ConstArg representation for const items
tracking issue: rust-lang/rust#132980fixesrust-lang/rust#131046fixesrust-lang/rust#134641
As part of implementing `min_generic_const_args`, we need to distinguish const items that can be used in the type system, such as in associated const equality projections, from const items containing arbitrary const code, which must be kept out of the type system. Specifically, all "type consts" must be either concrete (no generics) or generic with a trivial expression like `N` or a path to another type const item.
To syntactically distinguish these cases, we require, for now at least, that users annotate all type consts with the `#[type_const]` attribute. Then, we validate that the const's right-hand side is indeed eligible to be a type const and represent it differently in the HIR.
We accomplish this representation using a new `ConstItemRhs` enum in the HIR, and a similar but simpler enum in the AST. When `#[type_const]` is **not** applied to a const (e.g. on stable), we represent const item right-hand sides (rhs's) as HIR bodies, like before. However, when the attribute is applied, we instead lower to a `hir::ConstArg`. This syntactically distinguishes between trivial const args (paths) and arbitrary expressions, which are represented using `AnonConst`s. Then in `generics_of`, we can take advantage of the existing machinery to bar the `AnonConst` rhs's from using parent generics.
Update memchr to 2.7.6
memchr 2.7.6 contains a bugfix for aarch64_be.
Note: I'm not sure about how dependency updates are managed in rust.git. If something should go through another branch or will happen automatically, please let me know.
Liveness: Cache the set of string constants for suggestions.
Even on a slow diagnostic path, listing all the constants in MIR can be expensive, so cache it.
