Drop MIPS glibc 2.23 patches that reside in crosstool-ng now
These patches were added to crosstool-ng in https://github.com/crosstool-ng/crosstool-ng/commit/b88d3385162415294cba57e7b4cecc03259548fb and are therefore duplicate and fail to apply, breaking builds of `dist-mips*-linux`.
I have compile tested `dist-mipsel-linux`, I assume the other targets will work just as fine now.
Rollup of 7 pull requests
Successful merges:
- #133700 (const-eval: detect more pointers as definitely not-null)
- #135290 (Encode constraints that hold at all points as logical edges in location-sensitive polonius)
- #135478 (Run clippy for rustc_codegen_gcc on CI)
- #135583 (Move `std::pipe::*` into `std::io`)
- #135612 (Include x scripts in tarballs)
- #135624 (ci: mirror buildkit image to ghcr)
- #135661 (Stabilize `float_next_up_down`)
r? `@ghost`
`@rustbot` modify labels: rollup
Update cargo
13 commits in 088d496082726091024f1689c124a0c3dccbd775..045bf21b36a2e1f3ed85e38278d1c3cc4305e134
2025-01-10 20:10:21 +0000 to 2025-01-17 14:59:36 +0000
- created a function for user defined aliases (rust-lang/cargo#15076)
- took the functionality of the third party subcommand from the list_commands function (rust-lang/cargo#15075)
- fix: wrong concat and field name (rust-lang/cargo#15074)
- fix(publish): Report all unpublishable packages (rust-lang/cargo#15070)
- docs(cargo-clippy): correct typo (rust-lang/cargo#15072)
- docs(cargo-package): alwasy include the lockfile (rust-lang/cargo#15067)
- docs(ref): Deprecate 'package.authors' (rust-lang/cargo#15068)
- fix(build-std): parse as comma-separated list (rust-lang/cargo#15065)
- Fix benchsuite issue with newer versions of git (rust-lang/cargo#15069)
- Document that cargo automatically registers variables used in env! macro to trigger rebuilds (rust-lang/cargo#15062)
- perf(cargo-package): match certain path prefix with pathspec (rust-lang/cargo#14997)
- Clarify note in example (rust-lang/cargo#15054)
- chore(deps): update msrv (3 versions) to v1.82 (rust-lang/cargo#15050)
Make tidy warn on unrecognized directives
This PR makes it so tidy warns on unrecognized directives, as recommended on [the discussion of #130984](https://github.com/rust-lang/rust/issues/130984#issuecomment-2589284620). This is edited from the previous version of this PR, which only warned on "tidy-ignore" and no other tidy directive typos.
Fixes#130984.
``@rustbot`` label A-tidy C-enhancement
This advances Fuchsia to a checkout from 2025-01-13, which corresponds
to a recent Rust roll, and hopefully avoids #135667, where a repository
used by the older version of Rust was accidentally archived and broke
checking out the prior version.
try-job: x86_64-fuchsia
Treat other items as functions for the purpose of type-based search
specifically, constants and statics are nullary functions, and struct fields are unary functions.
fixes#130204
r? ``@notriddle``
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
constants and statics are nullary functions, and struct fields are unary functions.
functions (along with methods and trait methods) are prioritized over other
items, like fields and constants.
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
Update docs for `-Clink-dead-code` to discourage its use
The `-Clink-dead-code` flag was originally added way back in #31368, apparently to help improve the output of some older forms of code coverage measurement, and also to address some use-cases for wanting to suppress linker flags like `-dead_strip` and `--gc-section`.
In the past it might have also been useful in conjunction with `-Cinstrument-coverage`, but subsequent improvements to coverage instrumentation have made it unnecessary there.
[It is also currently used by cargo-fuzz by default](https://github.com/rust-fuzz/cargo-fuzz/issues/391), for reasons that are possibly no longer relevant.
---
The flag currently does more than its name suggests, affecting not just linker flags, but also monomorphization decisions. It has also contributed to ICEs (e.g. #135515) that would not have occurred without link-dead-code.
---
For now, this PR just updates the documentation to be more realistic about what the flag does, and when it should be used (approximately never). In the future, it might be worth looking into properly deprecating this flag, and perhaps making it a no-op if feasible.
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>
tests: Port `extern-fn-reachable` to rmake.rs
Part of #121876.
## Summary
This PR ports `tests/run-make/extern-fn-reachable` to use `rmake.rs`. Notable changes:
- We now use the `object` crate and look at the exported symbols specifically.
- This test's coverage regressed against windows-msvc back in [replace dynamic library module with libloading #90716](https://github.com/rust-lang/rust/pull/90716), but since we use `object` now, we're able to claw the test coverage back.
- The checks are now stricter:
1. It no longer looks for substring symbol matches in `nm` textual outputs, it inspects the symbol names precisely.
2. We now also explicitly check for the presence of leading underscore in exported symbol names on apple vs non-apple targets.
- Added another case of `#[no_mangle] fn fun6() {}` (note the lack of `pub`) to check that Rust nameres visibility is orthogonal to symbol visibility in dylib.
## History
- Test was initially introduced as a run-pass[^run-pass] test as part of [Don't mark reachable extern fns as internal #10539](https://github.com/rust-lang/rust/pull/10539).
- Test re-introduced as a run-make test in https://github.com/rust-lang/rust/pull/13741.
- Later, the test coverage regressed in https://github.com/rust-lang/rust/pull/90716.
[^run-pass]: no longer a thing nowadays
Supersedes #128314.
Co-authored with `@lolbinarycat.`
try-job: x86_64-msvc
try-job: i686-msvc
try-job: i686-mingw
try-job: x86_64-mingw-1
try-job: x86_64-apple-1
try-job: aarch64-apple
try-job: test-various
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
TRPL: incorporate all backward-compatible Edition changes
This incorporates all the backwards-compatible changes for the 2024 Edition on stable. There will also be a follow-on PR to land revisions to the new chapter on async so it can be as ready as possible when officially released with 1.85 and the 2024 Edition.
Additionally, there are a few other, non-backward-compatible, changes (largely around `use<..>`) we can only land using the stable edition, which we may or may not be able to land in 1.85 by using the beta toolchain in the example code. Those may or may not be ported over, depending on how that does or does not play with the infrastructure.
There is also an accompanying PR, #135508, to land these changes on `beta` so they can go out with 1.85 and the Edition release.
rustdoc: Remove `AttributesExt` trait magic that added needless complexity
The new code is more explicit and avoids trait magic that added needless
complexity to this part of rustdoc.
deprecate `std::intrinsics::transmute` etc, use `std::mem::*` instead
The `rustc_allowed_through_unstable_modules` attribute lets users call `std::mem::transmute` as `std::intrinsics::transmute`. The former is a reexport of the latter, and for a long time we didn't properly check stability for reexports, so making this a hard error now would be a breaking change for little gain. But at the same time, `std::intrinsics::transmute` is not the intended path for this function, so I think it is a good idea to show a deprecation warning when that path is used. This PR implements that, for all the functions in `std::intrinsics` that carry the attribute.
I assume this will need ``@rust-lang/libs-api`` FCP.
Treat safe target_feature functions as unsafe by default [less invasive variant]
This unblocks
* #134090
As I stated in https://github.com/rust-lang/rust/pull/134090#issuecomment-2541332415 I think the previous impl was too easy to get wrong, as by default it treated safe target feature functions as safe and had to add additional checks for when they weren't. Now the logic is inverted. By default they are unsafe and you have to explicitly handle safe target feature functions.
This is the less (imo) invasive variant of #134317, as it doesn't require changing the Safety enum, so it only affects FnDefs and nothing else, as it should.
Rollup of 7 pull requests
Successful merges:
- #132397 (Make missing_abi lint warn-by-default.)
- #133807 (ci: Enable opt-dist for dist-aarch64-linux builds)
- #134143 (Convert `struct FromBytesWithNulError` into enum)
- #134338 (Use a C-safe return type for `__rust_[ui]128_*` overflowing intrinsics)
- #134678 (Update `ReadDir::next` in `std::sys::pal::unix::fs` to use `&raw const (*p).field` instead of `p.byte_offset().cast()`)
- #135424 (Detect unstable lint docs that dont enable their feature)
- #135520 (Make sure we actually use the right trivial lifetime substs when eagerly monomorphizing drop for ADTs)
r? `@ghost`
`@rustbot` modify labels: rollup
Detect unstable lint docs that dont enable their feature
Makes sure that we detect cases where unstable lint's docs don't enable the corresponding feature.
r? ehuss
ci: Enable opt-dist for dist-aarch64-linux builds
Move the CI dist-aarch64-linux job to an aarch64 runner and enable optimised dist builds with the opt-dist pipeline.
For the time being, disable bolt on aarch64 due to upstream bolt bugs.
r? `@Kobzol`
cc `@lqd`
try-job: dist-aarch64-linux
Matthias Krüger