| Age | Commit message (Collapse) | Author | Lines |
|---|
|
functions instead
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #131261 (Stabilize `UnsafeCell::from_mut`)
- #131405 (bootstrap/codegen_ssa: ship llvm-strip and use it for -Cstrip)
- #132077 (Add a new `wide-arithmetic` feature for WebAssembly)
- #132562 (Remove the `wasm32-wasi` target from rustc)
- #132660 (Remove unused errs.rs file)
Failed merges:
- #131721 (Add new unstable feature `const_eq_ignore_ascii_case`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Remove the `wasm32-wasi` target from rustc
This commit is the final step in the journey of renaming the historical `wasm32-wasi` target in the Rust compiler to `wasm32-wasip1`. Various steps in this journey so far have been:
* 2023-04-03: rust-lang/compiler-team#607 - initial proposal for this rename
* 2024-11-27: rust-lang/compiler-team#695 - amended schedule/procedure for rename
* 2024-01-29: rust-lang/rust#120468 - initial introduction of `wasm32-wasip1`
* 2024-06-18: rust-lang/rust#126662 - warn on usage of `wasm32-wasi`
* 2024-11-08: this PR - remove the `wasm32-wasi` target
The full transition schedule is in [this comment][comment] and is summarized with:
* 2024-05-02: Rust 1.78 released with `wasm32-wasip1` target
* 2024-09-05: Rust 1.81 released warning on usage of `wasm32-wasi`
* 2025-01-09: Rust 1.84 to be released without the `wasm32-wasi` target
This means that support on stable for the replacement target of `wasm32-wasip1` has currently been available for 6 months. Users have already seen warnings on stable for 2 months about usage of `wasm32-wasi` and stable users have another 2 months of warnings before the target is removed from stable.
This commit is intended to be the final step in this transition so the source tree should no longer mention `wasm32-wasi` except in historical reference to the older name of the `wasm32-wasip1` target.
[comment]: https://github.com/rust-lang/rust/pull/120468#issuecomment-1977878747
|
|
rustc_codegen_llvm: Add a new 'pc' option to branch-protection
Add a new 'pc' option to -Z branch-protection for aarch64 that enables the use of PC as a diversifier in PAC branch protection code.
When the pauth-lr target feature is enabled in combination with -Z branch-protection=pac-ret,pc, the new 9.5-a instructions (pacibsppc, retaasppc, etc) will be generated.
|
|
Rollup of 11 pull requests
Successful merges:
- #131153 (Improve duplicate derive Copy/Clone diagnostics)
- #132025 (fix suggestion for diagnostic error E0027)
- #132303 (More tests for non-exhaustive C-like enums in FFI)
- #132492 (remove support for extern-block const intrinsics)
- #132587 (Revert "Avoid nested replacement ranges" from #129346.)
- #132596 ([rustdoc] Fix `--show-coverage` when JSON output format is used)
- #132598 (Clippy: Move some attribute lints to be early pass (post expansion))
- #132601 (Update books)
- #132606 (Improve example of `impl Pattern for &[char]`)
- #132608 (document `type_implements_trait`)
- #132609 (docs: fix grammar in doc comment at unix/process.rs)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Support clobber_abi and vector registers (clobber-only) in PowerPC inline assembly
This supports `clobber_abi` which is one of the requirements of stabilization mentioned in #93335.
This basically does a similar thing I did in https://github.com/rust-lang/rust/pull/130630 to implement `clobber_abi` for s390x, but for powerpc/powerpc64/powerpc64le.
- This also supports vector registers (as `vreg`) as clobber-only, which need to support clobbering of them to implement `clobber_abi`.
- `vreg` should be able to accept `#[repr(simd)]` types as input/output if the unstable `altivec` target feature is enabled, but `core::arch::{powerpc,powerpc64}` vector types, `#[repr(simd)]`, and `core::simd` are all unstable, so the fact that this is currently a clobber-only should not be considered a blocker of clobber_abi implementation or stabilization. So I have not implemented it in this PR.
- See https://github.com/rust-lang/rust/pull/131551 (which is based on this PR) for a PR to implement this.
- (I'm not sticking to whether that PR should be a separate PR or part of this PR, so I can merge that PR into this PR if needed.)
Refs:
- PPC32 SysV: Section "Function Calling Sequence" in [System V Application Binary Interface PowerPC Processor Supplement](https://refspecs.linuxfoundation.org/elf/elfspec_ppc.pdf)
- PPC64 ELFv1: Section 3.2 "Function Calling Sequence" in [64-bit PowerPC ELF Application Binary Interface Supplement](https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#FUNC-CALL)
- PPC64 ELFv2: Section 2.2 "Function Calling Sequence" in [64-Bit ELF V2 ABI Specification](https://openpowerfoundation.org/specifications/64bitelfabi/)
- AIX: [Register usage and conventions](https://www.ibm.com/docs/en/aix/7.3?topic=overview-register-usage-conventions), [Special registers in the PowerPC®](https://www.ibm.com/docs/en/aix/7.3?topic=overview-special-registers-in-powerpc), [AIX vector programming](https://www.ibm.com/docs/en/aix/7.3?topic=concepts-aix-vector-programming)
- Register definition in LLVM: https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/PowerPC/PPCRegisterInfo.td#L189
If I understand the above four ABI documentations correctly, except for the PPC32 SysV's VR (Vector Registers) and 32-bit AIX (currently not supported by rustc)'s r13, there does not appear to be important differences in terms of implementing `clobber_abi`:
- The above four ABIs are consistent about FPR (0-13: volatile, 14-31: nonvolatile), CR (0-1,5-7: volatile, 2-4: nonvolatile), XER (volatile), and CTR (volatile).
- As for GPR, only the registers we are treating as reserved are slightly different
- r0, r3-r12 are volatile
- r1(sp, reserved), r14-31 are nonvolatile
- r2(reserved) is TOC pointer in PPC64 ELF/AIX, system-reserved register in PPC32 SysV (AFAIK used as thread pointer in Linux/BSDs)
- r13(reserved for non-32-bit-AIX) is thread pointer in PPC64 ELF, small data area pointer register in PPC32 SysV, "reserved under 64-bit environment; not restored across system calls[^r13]" in AIX)
- As for FPSCR, volatile in PPC64 ELFv1/AIX, some fields are volatile only in certain situations (rest are volatile) in PPC32 SysV/PPC64 ELFv2.
- As for VR (Vector Registers), it is not mentioned in PPC32 SysV, v0-v19 are volatile in both in PPC64 ELF/AIX, v20-v31 are nonvolatile in PPC64 ELF, reserved or nonvolatile depending on the ABI ([vec-extabi vs vec-default in LLVM](https://reviews.llvm.org/D89684), we are [using vec-extabi](https://github.com/rust-lang/rust/pull/131341#discussion_r1797693299)) in AIX:
> When the default Vector enabled mode is used, these registers are reserved and must not be used.
> In the extended ABI vector enabled mode, these registers are nonvolatile and their values are preserved across function calls
I left [FIXME comment about PPC32 SysV](https://github.com/rust-lang/rust/pull/131341#discussion_r1790496095) and added ABI check for AIX.
- As for VRSAVE, it is not mentioned in PPC32 SysV, nonvolatile in PPC64 ELFv1, reserved in PPC64 ELFv2/AIX
- As for VSCR, it is not mentioned in PPC32 SysV/PPC64 ELFv1, some fields are volatile only in certain situations (rest are volatile) in PPC64 ELFv2, volatile in AIX
We are currently treating r1-r2, r13 (non-32-bit-AIX), r29-r31, LR, CTR, and VRSAVE as reserved.
We are currently not processing anything about FPSCR and VSCR, but I feel those are things that should be processed by `preserves_flags` rather than `clobber_abi` if we need to do something about them. (However, PPCRegisterInfo.td in LLVM does not seem to define anything about them.)
Replaces #111335 and #124279
cc `@ecnelises` `@bzEq` `@lu-zero`
r? `@Amanieu`
`@rustbot` label +O-PowerPC +A-inline-assembly
[^r13]: callee-saved, according to [LLVM](https://github.com/llvm/llvm-project/blob/6a6af0246bd2d68291582e9aefc0543e5c6102fe/llvm/lib/Target/PowerPC/PPCCallingConv.td#L322) and [GCC](https://github.com/gcc-mirror/gcc/blob/a9173a50e7e346a218323916e4d3add8552529ae/gcc/config/rs6000/rs6000.h#L859).
|
|
|
|
This commit is the final step in the journey of renaming the historical
`wasm32-wasi` target in the Rust compiler to `wasm32-wasip1`. Various
steps in this journey so far have been:
* 2023-04-03: rust-lang/compiler-team#607 - initial proposal for this rename
* 2024-11-27: rust-lang/compiler-team#695 - amended schedule/procedure for rename
* 2024-01-29: rust-lang/rust#120468 - initial introduction of `wasm32-wasip1`
* 2024-06-18: rust-lang/rust#126662 - warn on usage of `wasm32-wasi`
* 2024-11-08: this PR - remove the `wasm32-wasi` target
The full transition schedule is in [this comment][comment] and is
summarized with:
* 2024-05-02: Rust 1.78 released with `wasm32-wasip1` target
* 2024-09-05: Rust 1.81 released warning on usage of `wasm32-wasi`
* 2025-01-09: Rust 1.84 to be released without the `wasm32-wasi` target
This means that support on stable for the replacement target of
`wasm32-wasip1` has currently been available for 6 months. Users have
already seen warnings on stable for 2 months about usage of
`wasm32-wasi` and stable users have another 2 months of warnings before
the target is removed from stable.
This commit is intended to be the final step in this transition so the
source tree should no longer mention `wasm32-wasi` except in historical
reference to the older name of the `wasm32-wasip1` target.
[comment]: https://github.com/rust-lang/rust/pull/120468#issuecomment-1977878747
|
|
People often parse `-vV` output to get to the host triple, which is
annoying to do. It's easier to just get it directly.
|
|
This changes the naming to the new naming, used by `--print
target-tuple`.
It does not change all locations, but many.
|
|
assembly
|
|
joshtriplett:style-guide-binop-heuristic-assignment-only, r=calebcartwright
style-guide: Only use the new binop heuristic for assignments
This avoids pathological cases where chains of binops get progressively
deeper.
|
|
Remove support for `-Zprofile` (gcov-style coverage instrumentation)
Tracking issue: #42524
MCP: https://github.com/rust-lang/compiler-team/issues/798
---
This PR removes the unstable `-Zprofile` flag, which enables ”gcov-style” coverage instrumentation, along with its associated `-Zprofile-emit` configuration flag.
(The profile flag predates and is almost entirely separate from the stable `-Cinstrument-coverage` flag.)
Notably, the `-Zprofile` flag:
- Is largely untested in-tree, having only one run-make test that does not check whether its output is correct or useful.
- Has no known maintainer.
- Has seen no push towards stabilization.
- Has at least one severe regression reported in 2022 that apparently remains unaddressed.
- #100125
- Is confusingly named, since it appears to be more about coverage than performance profiling, and has nothing to do with PGO.
- Is fundamentally limited by relying on counters auto-inserted by LLVM, with no knowledge of Rust beyond debuginfo.
|
|
|
|
Add a new 'pc' option to -Z branch-protection for aarch64 that
enables the use of PC as a diversifier in PAC branch protection code.
When the pauth-lr target feature is enabled in combination
with -Z branch-protection=pac-ret,pc, the new 9.5-a instructions
(pacibsppc, retaasppc, etc) will be generated.
|
|
|
|
This avoids pathological cases where chains of binops get progressively
deeper.
|
|
r=compiler-errors
Point to Fuchsia team in platform support docs
This consolidates our docs into a single source of truth for the current Fuchsia maintainers.
r? ```@tmandry```
|
|
r=workingjubilee
powerpc64-ibm-aix: update maintainters
Chaofan (`@ecnelises)` and Kai (`@bzEq)` will be passing over maintainership for the target over to David Tenty (`@daltenty)` and Chris Cambly (`@gilamn5tr)`
|
|
|
|
Chaofan and Kai will be passing over maintainership for the target over to David Tenty and Chris Cambly.
|
|
Updated for changes in the package server workflow.
|
|
This reverts commit 1239c81c145d2bfb96f32856f377cd741d5c7256.
Fix GH-132185 revert for now until early next year/FreeBSD 13.3
becomes EOL.
|
|
|
|
Update books
## rust-lang/edition-guide
7 commits in c7ebae25cb4801a31b6f05353f6d85bfa6feedd1..1f07c242f8162a711a5ac5a4ea8fa7ec884ee7a9
2024-10-21 14:29:49 UTC to 2024-10-19 19:08:20 UTC
- 2024: Add reserved syntax (rust-lang/edition-guide#326)
- Update stdout of `cargo new` (rust-lang/edition-guide#327)
- Don't run doctests on rustfmt ident sorting page
- add rustfmt raw identifer sorting doc (rust-lang/edition-guide#321)
- Add some tips for what to be careful of with rustdoc-doctests (rust-lang/edition-guide#323)
- Remove cargo-remove-implicit-features (rust-lang/edition-guide#324)
- Rename doctest standalone tag (rust-lang/edition-guide#325)
## rust-embedded/book
1 commits in f40a8b420ec4b4505d9489965e261f1d5c28ba23..ddbf1b4e2858fedb71b7c42eb15c4576517dc125
2024-10-13 19:53:37 UTC to 2024-10-13 19:53:37 UTC
- Add link to Cortex-M comparison to install.md (rust-embedded/book#378)
## rust-lang/reference
29 commits in c64e52a3d306eac0129f3ad6c6d8806ab99ae2e9..23ce619966541bf2c80d45fdfeecf3393e360a13
2024-10-05 00:33:03 +0000 to 2024-10-22 21:34:51 +0000
- Mention `--print cfg` under set configuration options (rust-lang/reference#1636)
- Fix `pat` fragment specifier to be the "current" edition (rust-lang/reference#1640)
- Add restriction for cfg_attr with crate_type and crate_name (rust-lang/reference#1649)
- Sort macro fragment specifiers (rust-lang/reference#1641)
- Document mixed-site hygiene (rust-lang/reference#1656)
- Clarify that "macro attributes" refers to proc macros (rust-lang/reference#1660)
- mdbook-spec: Fix Spec::new creation (rust-lang/reference#1658)
- Fix stdcall example broken by recent rustc change (rust-lang/reference#1659)
- Add spec identifiers to const_eval.md (rust-lang/reference#1569)
- Add identifier syntax to trait-bounds.md (rust-lang/reference#1631)
- Add identifier syntax to macro-ambiguity.md (rust-lang/reference#1634)
- Add spec identifier syntax to conditional-compilation.md (rust-lang/reference#1564)
- Add spec identifiers to behaviour-considered-undefined.md (rust-lang/reference#1562)
- Add test linking (rust-lang/reference#1646)
- Allow `deny` inside `forbid` as a no-op (rust-lang/reference#1655)
- Add identifier syntax to identifiers.md (rust-lang/reference#1583)
- Add spec identifiers to crates-and-source-files.md (rust-lang/reference#1570)
- Add identifier syntax to linkage.md (rust-lang/reference#1633)
- Add identifier syntax to type-coercions.md (rust-lang/reference#1632)
- Add identifiers to variables.md (rust-lang/reference#1626)
- Add identifier syntax to lexer chapters (rust-lang/reference#1620)
- Add spec identifier syntax to `unsafe-keyword.md` and `unsafety.md` (rust-lang/reference#1619)
- Add identifier syntax to types and subchapters. (rust-lang/reference#1618)
- Add identifier syntax to subtyping.md (rust-lang/reference#1613)
- Add identifier syntax to statements.md (rust-lang/reference#1611)
- Add identifier syntax to type-layout.md (rust-lang/reference#1614)
- Clarify definition of "immutable bytes" (rust-lang/reference#1637)
- Add preview artifacts in CI (rust-lang/reference#1647)
- trait bounds grammar: make `?` and `for<>` mutually exclusive (rust-lang/reference#1650)
## rust-lang/rustc-dev-guide
5 commits in 07bc9ca9eb1cd6d9fbbf758c2753b748804a134f..59d94ea75a0b157e148af14c73c2dd60efb7b60a
2024-10-21 02:30:07 UTC to 2024-10-07 21:12:09 UTC
- Add the WASM | WASI | Emscripten notification groups (rust-lang/rustc-dev-guide#2100)
- Update bootstrapping.md (rust-lang/rustc-dev-guide#1900)
- Rename `needs-profiler-support` to `needs-profiler-runtime` (rust-lang/rustc-dev-guide#2095)
- Document compiletest directives `ignore-coverage-map` and `ignore-coverage-run` (rust-lang/rustc-dev-guide#2094)
- Purge `run-pass-valgrind` mentions (rust-lang/rustc-dev-guide#2091)
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- #130991 (Vectorized SliceContains)
- #131928 (rustdoc: Document `markdown` module.)
- #131955 (Set `signext` or `zeroext` for integer arguments on RISC-V and LoongArch64)
- #131979 (Minor tweaks to `compare_impl_item.rs`)
- #132036 (Add a test case for #131164)
- #132039 (Specialize `read_exact` and `read_buf_exact` for `VecDeque`)
- #132060 ("innermost", "outermost", "leftmost", and "rightmost" don't need hyphens)
- #132065 (Clarify documentation of `ptr::dangling()` function)
- #132066 (Fix a typo in documentation of `pointer::sub_ptr()`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
These are all standard dictionary words and don't require hyphenation.
|
|
|
|
|
|
Rollup of 3 pull requests
Successful merges:
- #131918 (coverage: Make counter creation handle node/edge counters more uniformly)
- #132021 (nuttx.md: typo)
- #132029 (Subtree update of `rust-analyzer`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
rust_for_linux: -Zregparm=<N> commandline flag for X86 (#116972)
Command line flag `-Zregparm=<N>` for X86 (32-bit) for rust-for-linux: https://github.com/rust-lang/rust/issues/116972
Implemented in the similar way as fastcall/vectorcall support (args are marked InReg if fit).
|
|
Rollup of 7 pull requests
Successful merges:
- #130350 (stabilize Strict Provenance and Exposed Provenance APIs)
- #131737 (linkchecker: add a reminder on broken links to add new/renamed pages to `SUMMARY.md` for mdBooks)
- #131991 (test: Add test for trait in FQS cast, issue #98565)
- #131997 (Make `rustc_abi` compile on stable again)
- #131999 (Improve test coverage for `unit_bindings` lint)
- #132001 (fix coherence error for very large tuples™)
- #132003 (update ABI compatibility docs for new option-like rules)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
stabilize Strict Provenance and Exposed Provenance APIs
Given that [RFC 3559](https://rust-lang.github.io/rfcs/3559-rust-has-provenance.html) has been accepted, t-lang has approved the concept of provenance to exist in the language. So I think it's time that we stabilize the strict provenance and exposed provenance APIs, and discuss provenance explicitly in the docs:
```rust
// core::ptr
pub const fn without_provenance<T>(addr: usize) -> *const T;
pub const fn dangling<T>() -> *const T;
pub const fn without_provenance_mut<T>(addr: usize) -> *mut T;
pub const fn dangling_mut<T>() -> *mut T;
pub fn with_exposed_provenance<T>(addr: usize) -> *const T;
pub fn with_exposed_provenance_mut<T>(addr: usize) -> *mut T;
impl<T: ?Sized> *const T {
pub fn addr(self) -> usize;
pub fn expose_provenance(self) -> usize;
pub fn with_addr(self, addr: usize) -> Self;
pub fn map_addr(self, f: impl FnOnce(usize) -> usize) -> Self;
}
impl<T: ?Sized> *mut T {
pub fn addr(self) -> usize;
pub fn expose_provenance(self) -> usize;
pub fn with_addr(self, addr: usize) -> Self;
pub fn map_addr(self, f: impl FnOnce(usize) -> usize) -> Self;
}
impl<T: ?Sized> NonNull<T> {
pub fn addr(self) -> NonZero<usize>;
pub fn with_addr(self, addr: NonZero<usize>) -> Self;
pub fn map_addr(self, f: impl FnOnce(NonZero<usize>) -> NonZero<usize>) -> Self;
}
```
I also did a pass over the docs to adjust them, because this is no longer an "experiment". The `ptr` docs now discuss the concept of provenance in general, and then they go into the two families of APIs for dealing with provenance: Strict Provenance and Exposed Provenance. I removed the discussion of how pointers also have an associated "address space" -- that is not actually tracked in the pointer value, it is tracked in the type, so IMO it just distracts from the core point of provenance. I also adjusted the docs for `with_exposed_provenance` to make it clear that we cannot guarantee much about this function, it's all best-effort.
There are two unstable lints associated with the strict_provenance feature gate; I moved them to a new [strict_provenance_lints](https://github.com/rust-lang/rust/issues/130351) feature since I didn't want this PR to have an even bigger FCP. ;)
`@rust-lang/opsem` Would be great to get some feedback on the docs here. :)
Nominating for `@rust-lang/libs-api.`
Part of https://github.com/rust-lang/rust/issues/95228.
[FCP comment](https://github.com/rust-lang/rust/pull/130350#issuecomment-2395114536)
|
|
Revise arm platform notes regarding soft float
This PR updates the Arm microcontroller platform docs to recommend `-fpregs` instead of `+soft-float` as [discussed on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/.60-Ctarget-feature.3D.2Bsoft-float.60.20considered.20harmful)
|
|
|
|
r=RalfJung
Finish stabilization of `result_ffi_guarantees`
The internal linting has been changed, so all that is left is making sure we stabilize what we want to stabilize.
|
|
ci update freebsd version proposal, freebsd 12 being eol
raising to the lowest still active supported freebsd version.
From 13.1 (already eol too), freebsd introduces a cpu affinity layer
with linux. It also introduces a api compatible copy_file_range which
can be used like its linux's counterpart.
The former is essential to build https://github.com/rust-lang/rust/pull/120589, therefore breaks the backward
compatibility with the previous FreeBSD releases.
Blocked on https://github.com/rust-lang/rust/issues/130465
|
|
Co-authored-by: Jubilee <workingjubilee@gmail.com>
|
|
|
|
|
|
Add wasm32-unknown-emscripten platform support document
This PR adds the platform support document for wasm32-unknown-emscripten, and adds a warning about breaks in Emscripten ABI compatibility (see #131467).
I mostly based the document off the wasm32-unknown-unknown docs and some of the information may still be missing (e.g. who's the target maintainer) or outdated (e.g. the build requirements). I still hope that it provides a good starting point.
r? `@workingjubilee`
|
|
Co-authored-by: Hood Chatham <roberthoodchatham@gmail.com>
Co-authored-by: Alex Crichton <alex@alexcrichton.com>
Co-authored-by: Kleis Auke Wolthuizen <github@kleisauke.nl>
|
|
Signed-off-by: Emmanuel Ferdman <emmanuelferdman@gmail.com>
|
|
|
|
|
