| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Document s390x machine access via community cloud
|
|
|
|
Signed-off-by: longxiangqiao <longxiangqiao@qq.com>
|
|
Remove legacy bitcode for iOS
Follow #117364.
|
|
|
|
|
|
This target is tier 2, not tier 3, and I forgot to update this.
Closes #133206
|
|
Co-authored-by: Josh Stone <cuviper@gmail.com>
|
|
This adds documentation for the following existing targets:
s390x-unknown-linux-gnu (Tier 2 with host tools)
s390x-unknown-linux-musl (Tier 3)
I volunteer as maintainer for these targets going forward.
Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
|
|
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.
|
|
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.
|
|
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
|
|
|
|
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)
|
|
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
|
|
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>
|
|
|
|
|
|
|
|
|
|
Fix typo in csky-unknown-linux-gnuabiv2.md
|
|
Add x86_64-unknown-trusty as tier 3 target
This PR adds a third target for the Trusty platform, `x86_64-unknown-trusty`.
Please let me know if an MCP is required. https://github.com/rust-lang/compiler-team/issues/582 was made when adding the first two targets, I can make another one for the new target as well if needed.
# Target Tier Policy Acknowledgements
> A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.)
- Nicole LeGare (```@randomPoison)```
- Andrei Homescu (```@ahomescu)```
- Chris Wailes (chriswailes@google.com)
- As a fallback trusty-dev-team@google.com can be contacted
Note that this does not reflect the maintainers currently listed in [`trusty.md`](https://github.com/rust-lang/rust/blob/c52c23b6f44cd19718721a5e3b2eeb169e9c96ff/src/doc/rustc/src/platform-support/trusty.md). #130452 is currently open to update the list of maintainers in the documentation.
> Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier, so getting the name right is important even for a tier 3 target.
The new target `x86_64-unknown-trusty` follows the existing naming convention for similar targets.
> Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example, if the name of the target makes people extremely likely to form incorrect beliefs about what it targets, the name should be changed or augmented to disambiguate it.
👍
> Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.
There are no known legal issues or license incompatibilities.
> Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.
👍
> Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions.
This PR only adds the target. `std` support is being worked on and will be added in a future PR.
> The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running binaries, or running tests (even if they do not pass), the documentation must explain how to run such binaries or tests for the target, using emulation if possible or dedicated hardware if necessary.
👍
> Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via ```@)``` to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages.
👍
> Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.
👍
> Tier 3 targets must be able to produce assembly using at least one of rustc's supported backends from any host target. (Having support in a fork of the backend is not sufficient, it must be upstream.)
👍
|
|
|
|
|
|
Has the same effect, but turning off a feature matches the other flags better than turning on a feature (which actually turns off a feature).
|
|
These arrived in #125690, I think by mistake.
|
|
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 #120589, therefore breaks the backward
compatibility with the previous FreeBSD releases.
|
|
Add RISC-V vxworks targets
Risc-V 32 and RISC-V 64 targets are to be added in the target list.
|
|
Add new Tier-3 target: `loongarch64-unknown-linux-ohos`
MCP: https://github.com/rust-lang/compiler-team/issues/784
|
|
MCP: https://github.com/rust-lang/compiler-team/issues/784
Co-authored-by: WANG Rui <wangrui@loongson.cn>
|
|
|
|
|
|
|
