| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Run clippy for rustc_codegen_gcc on CI
Requested on [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/Run.20clippy.20for.20rustc_codegen_gcc.20in.20the.20Rust.20CI).
Opening as a draft, since it's not clear which rules should be applied to it.
r? `@ghost`
|
|
The licensing story is unclear, it makes the archive much larger, and we should not need it for building anything in the tarballs (yet).
|
|
RUSTC_IF_UNCHANGED_ALLOWED_PATHS
fixes https://github.com/rust-lang/rust/issues/135650
|
|
Helps to provide 1:1 build experience between git-managed and tarball sources.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
bootstrap: still require `COMPILETEST_FORCE_STAGE0` for `./x test rustdoc-js --stage 0`
This PR reverts #135375, because through some more testing I found out `./x test rustdoc-js --stage 0` does not in fact build rustdoc, and all the tests fail. This can't be intended behavior, so at least require `COMPILETEST_FORCE_STAGE0` to make it less likely to run `rustdoc-js --stage 0` by accident.
The problem that `--stage 0` is not working at all for this rustdoc-js test suite is tracked over at #135603.
cc `@lolbinarycat`
r? bootstrap
|
|
--stage 0`
|
|
Add license-metadata.json to rustc-src tarball.
Adds a license-metadata.json to the source tarball.
This file was reported as missing as a comment on #133461, and it prevents you building the compiler from the source tarball (unless you re-generate it yourself, which is non-obvious and requires `reuse` to be installed).
r? Kobzol
|
|
resolve symlinks of LLVM tool binaries before copying them
There is a chance that these tools are being installed from an external LLVM and we have no control over them. If any of these tools use symlinks, they will fail during tarball distribution. This change makes copying process to resolve symlinks just before placing them into the destination path.
Fixes https://github.com/rust-lang/rust/issues/135554
|
|
|
|
There is a chance that these tools are being installed from an external LLVM
and we have no control over them. If any of these tools use symlinks, they will
fail during tarball distribution. This change makes copying process to resolve
symlinks just before placing them into the destination path.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Rollup of 6 pull requests
Successful merges:
- #132654 (std: lazily allocate the main thread handle)
- #135003 (deprecate `std::intrinsics::transmute` etc, use `std::mem::*` instead)
- #135428 (rustdoc: Remove `AttributesExt` trait magic that added needless complexity)
- #135498 (Prefer lower `TraitUpcasting` candidates in selection)
- #135507 (TRPL: incorporate all backward-compatible Edition changes)
- #135529 (remove outdated FIXME)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Add COPYRIGHT-*.html files to distribution and update `COPYRIGHT`
* Updates the `COPYRIGHT` file to describe how we actually do things now, and removes the licence text from it as they are stored elsewhere.
* dist tarballs get all of the files in `LICENSES/*`.
* This folder is managed by `reuse` and each file exists because we refer to the licence somewhere in our tree. We should be supplying these licence texts to anyone who obtains a copy of the source code and now we do.
* The binary rust tarball gets `COPYRIGHT.html` and `COPYRIGHT-library.html`, which are auto-generated files that describe the licence information for both the in-tree source files used to build the Rust toolchain, and the out-of-tree dependencies we used to build the toolchain.
* The other binary tarballs are unchanged, for now. In future you need to make a call whether to ship multiple version of COPYRIGHT.html, or whether to try and make, for example, a cargo-specific COPYRIGHT.html file.
* The `LICENSE-MIT` file now includes a blanket copyright statement, as the text indicates that it should and because users will expect to know who owns the copyright of the material they have been given (even if the answer is 'lots of people').
try-job: x86_64-fuchsia
|
|
remove outdated FIXME
https://github.com/rust-lang/rust/pull/134967 already fixed this.
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
bootstrap: do not rely on LIBRARY_PATH env variable
Closes https://github.com/rust-lang/rust/issues/134811
try-job: test-various
try-job: armhf-gnu
try-job: x86_64-apple-1
try-job: x86_64-apple-2
try-job: aarch64-apple
try-job: x86_64-msvc
try-job: i686-msvc
try-job: x86_64-mingw-1
try-job: x86_64-mingw-2
try-job: i686-mingw
|
|
|
|
|
|
bootstrap: fix outdated feature name in comment
Follow-up to https://github.com/rust-lang/rust/pull/135391#discussion_r1912826594.
I guess I updated everything else **except** the comment right next to the actual dependencies 💀
r? bootstrap
|
|
|
|
It has been a bit of a pain trying to keep the lints in sync across
the submodule repositories, so the just turns it off.
|
|
bootstrap: Implement conditional `tracing` infra
Add a conditional `tracing` setup that is gated behind `BOOTSTRAP_TRACING` env var. This `tracing` infra is implemented by:
- Introducing an optional `tracing` cargo feature in bootstrap.
- Added optional `tracing*` dependencies which are gated behind the `tracing` cargo feature.
- When `BOOTSTRAP_TRACING` is set, `bootstrap.py` will build bootstrap with `--features=tracing`.
There is a small trick here to share `BOOTSTRAP_TRACING` env var without having to add a separate env var:
- `BOOTSTRAP_TRACING=1` is not a registered `tracing` filter target, so that can be used to enable the `tracing` cargo feature yet not actually enable any tracing logs (useful for editor r-a setups without actually outputting any tracing logs).
- `BOOTSTRAP_TRACING=TRACE` and such are actually valid `tracing` filters, but that sets `BOOTSTRAP_TRACING` anyway.
Example usage: https://github.com/rust-lang/rust/pull/135299 (that experimental PR is not conditionally gated)
This PR is intentionally kept minimal to focus on the infra itself. To get actual mileage, instrumentations will need to be added to individual `Step`s and such.
r? `@onur-ozkan` (or reroll)
|
|
clean up code related to the rustdoc-js test suite
r? `@jieyouxu`
|
|
ci: added test log format for ci
This PR adds a new test render format specifically for ci.
The goal as stated in #134910 is to make reviewing test failures in CI easier.
See the new test output format in the CI for this PR ([here](https://github.com/rust-lang/rust/actions/runs/12723914643/job/35469515397?pr=135355))
closes #134910 cc: `@jyn514`
|
|
Clang will not respect this value in cross configurations.
|
|
`BOOTSTRAP_TRACING` env var is set
|
|
|
|
|
|
Deny various clippy lints
Almost all of these clippy lints have zero occurrences. Two of them have one each, and this PR fixes those.
|
|
centralize build stamp logic
This PR brings all the stamp file handling into one place inside `build_stamp` module, which takes care of everything related to build stamps. By doing this, we cut down on duplicated code and types and keep the codebase easier to maintain and more consistent.
Main goals are:
- Make stamp handling stricter so we don't have to pass `Path`s around and manually `join` on arbitrary directories
- Keep all stamp-related logic in one place
- Make it easier to test and debug
- Avoid duplication
- Keep things simple and well-documented
Resolves #134962
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
r=jieyouxu
allow rustdoc-js tests to be run at stage0
this mirrors the behavior of rustdoc-js-std tests.
previously this required COMPILETEST_FORCE_STAGE0.
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
