| Age | Commit message (Collapse) | Author | Lines |
|---|
|
A type with escaping bound vars cannot be wrapped in a dummy binder
during size computation.
Fixes rust-lang/rust-clippy#15429
changelog: [`zero_sized_hashmap_values`]: fix ICE in types with escaping
lifetimes
r? Jarcho
<!-- TRIAGEBOT_START -->
<!-- TRIAGEBOT_SUMMARY_START -->
### Summary Notes
- [Beta
nomination](https://github.com/rust-lang/rust-clippy/pull/15434#issuecomment-3164866684)
by [samueltardieu](https://github.com/samueltardieu)
*Managed by `@rustbot`—see
[help](https://forge.rust-lang.org/triagebot/note.html) for details*
<!-- TRIAGEBOT_SUMMARY_END -->
<!-- TRIAGEBOT_END -->
|
|
We are moving away from `x86_64-apple-darwin`, so soon these docs
won't be available.
(cherry picked from commit 36a38206db1757dcf899644f758e6fc5a04141ad)
|
|
Revert <https://github.com/rust-lang/rust/pull/143031> and
<https://github.com/rust-lang/rust/pull/140772> due to the issue with host
tools reported in <https://github.com/rust-lang/rust/issue/144533>.
This reverts commits 508021aa4320f1feb4c7a783ee16c2feebc9249a and
d577b39c5a39796e911f885c9a354074b52c25ab.
The decision was made in
<https://github.com/rust-lang/rust/pull/144659#issuecomment-3182163412>.
Tracking issue: <https://github.com/rust-lang/rust/issue/145435>
|
|
Update cargo
3 commits in a7fcef21feb4d835d1fee83b3f93b4aef86d5545..840b83a10fb0e039a83f4d70ad032892c287570a
2025-07-13 02:25:52 +0000 to 2025-07-30 13:59:19 +0000
- chore: fix some minor issues in comments (rust-lang/cargo#15787)
- feat(schema): Expose `IndexPackage`, the description of a package within a Registry Index (rust-lang/cargo#15770)
- chore: update toml/toml_edit to latest (rust-lang/cargo#15779)
r? ghost
|
|
Add correct dynamic_lib_extension for aix
AIX uses `.a` for static and shared libraries, this fixes a number of `run-make` tests on AIX
|
|
Extend `is_case_difference` to handle digit-letter confusables
This PR extends `is_case_difference` to handle digit-letter confusables
Add support for detecting 0/O, 1/l, 5/S, 8/B, 9/g confusables in error suggestions.
r? `@estebank`
|
|
|
|
merge rustc_attr_data_structures into rustc_hir
this move was discussed on zulip: [#t-compiler > attribute parsing rework @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/attribute.20parsing.20rework/near/528530091)
Many PRs in the attribute rework depend on this move.
|
|
Deduplicate `IntTy`/`UintTy`/`FloatTy`.
There are identical definitions in `rustc_type_ir` and `rustc_ast`. This commit removes them and places a single definition in `rustc_ast_ir`. This requires adding `rust_span` as a dependency of `rustc_ast_ir`, but means a bunch of silly conversion functions can be removed.
r? `@fmease`
|
|
Uniform `enter_trace_span!` and add documentation
1. The latest changes to `enter_trace_span!` were ported from Miri (see https://github.com/rust-lang/miri/pull/4452#discussion_r2204958019), so now both the `rustc_const_eval` and the Miri macro accept the same syntax. Furthermore, the Miri macro was changed to just call rustc_const_eval`'s, to avoid duplication.
2. I made the `layout_of` (& friends) calls use that new syntax, e.g. `enter_trace_span!(layouting::layout_of, ...)`
3. I made sure the macro specifies all types/traits/macros it refers to using `$crate::`, so the macro works anywhere independently of which types/traits/macros are imported in the context it is used in.
4. I added documentation, examples and tips to the macro's doc. To make the rustdoc compile I had to add some hidden lines (`#`), but now it acts as a compilation test which will avoid reintroducing issue 3. in the future. I will also create a documentation file with everything one needs to know about tracing at a later point, but I figured adding some of that info directly on the tracing macro makes it more discoverable.
5. In `stack.rs` I made it so that the `"frame"` span has a field named "frame" (instead of "message") with the data about the frame. This field used to be called "message" (tracing's default) since it was previously formatted using `"{}", instance`, and now I replaced it with `frame = %instance`.
|
|
|
|
|
|
|
|
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#136840 (Fix linker-plugin-lto only doing thin lto)
- rust-lang/rust#144053 (Remove install Rust script from CI)
- rust-lang/rust#144297 (Make `libtest::ERROR_EXIT_CODE` const public to not redefine it in rustdoc)
- rust-lang/rust#144721 (`std_detect`: Linux 6.16 support for RISC-V)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Fix linker-plugin-lto only doing thin lto
When rust provides LLVM bitcode files to lld and the bitcode contains
function summaries as used for thin lto, lld defaults to using thin lto.
This prevents some optimizations that are only applied for fat lto.
We solve this by not creating function summaries when fat lto is
enabled. The bitcode for the module is just directly written out.
An alternative solution would be to set the `ThinLTO=0` module flag to
signal lld to do fat lto.
The code in clang that sets this flag is here:
https://github.com/llvm/llvm-project/blob/560149b5e3c891c64899e9912e29467a69dc3a4c/clang/lib/CodeGen/BackendUtil.cpp#L1150
The code in LLVM that queries the flag and defaults to thin lto if not
set is here:
https://github.com/llvm/llvm-project/blob/e258bca9505f35e0a22cb213a305eea9b76d11ea/llvm/lib/Bitcode/Writer/BitcodeWriter.cpp#L4441-L4446
try-job: x86_64-gnu-debug
try-job: aarch64-gnu-debug
|
|
There are identical definitions in `rustc_type_ir` and `rustc_ast`. This
commit removes them and places a single definition in `rustc_ast_ir`.
This requires adding `rust_span` as a dependency of `rustc_ast_ir`, but
means a bunch of silly conversion functions can be removed.
The one annoying wrinkle is that the old version had differences in
their `Debug` impls, e.g. one printed `u32` while the other printed
`U32`. Some compiler error messages rely on the former (yuk), and some
clippy output depends on the latter. So the commit also changes clippy
to not rely on `Debug` and just implement what it needs itself.
|
|
When rust provides LLVM bitcode files to lld and the bitcode contains
function summaries as used for thin lto, lld defaults to using thin lto.
This prevents some optimizations that are only applied for fat lto.
We solve this by not creating function summaries when fat lto is
enabled. The bitcode for the module is just directly written out.
An alternative solution would be to set the `ThinLTO=0` module flag to
signal lld to do fat lto.
The code in clang that sets this flag is here:
https://github.com/llvm/llvm-project/blob/560149b5e3c891c64899e9912e29467a69dc3a4c/clang/lib/CodeGen/BackendUtil.cpp#L1150
The code in LLVM that queries the flag and defaults to thin lto if not
set is here:
https://github.com/llvm/llvm-project/blob/e258bca9505f35e0a22cb213a305eea9b76d11ea/llvm/lib/Bitcode/Writer/BitcodeWriter.cpp#L4441-L4446
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
It's identical to `TyCtxt::get_all_attrs` except it takes `DefId`
instead of `impl Into<DefIf>`.
|
|
The macro was uniformed between rustc_const_eval and miri
|
|
Reject running `compiletest` self-tests against stage 0 rustc unless explicitly allowed
Currently, in `pr-check-1`, we run `python3 ../x.py test --stage 0 src/tools/compiletest`, which is `compiletest` self-tests against stage 0 rustc. This makes it very annoying for PRs wanting to change target spec JSON format, which `compiletest` depends on for target information, as otherwise `compiletest` would have to know how to handle 2 different target spec JSON formats and know when to pick which.
Instead of doing that, we change `compiletest` self-tests to reject running against stage 0 `rustc` *unless* explicitly allowed with `build.compiletest-allow-stage0=true`. `build.compiletest-allow-stage0` is a proper bootstrap config option in favor of the ad-hoc `COMPILETEST_FORCE_STAGE0` env var. This means that:
- `./x test src/tools/compiletest --stage=0` is not allowed, unless `build.compiletest-allow-stage0=true` is set. In this scenario, `compiletest` self-tests should be expected to fail unless the stage 0 `rustc` as provided is like codegen_cranelift where it's *actually* built from in-tree `rustc` sources.
- In CI, we change `./x test src/tools/compiletest --stage=0` to `./x test src/tools/compiletest --stage=1`, and move it to `pr-check-2`. Yes, this involves building the stage 1 compiler, but `pr-check-2` already has to build stage 1 compiler to test stage 1 library crates.
- Crucially, this means that **`compiletest` is only intended to support one target spec JSON format**, namely the one corresponding to the in-tree `rustc`.
- This should preserve the `compiletest-use-stage0-libtest` UX optimization where changing `compiler/` tree should still not require rebuilding `compiletest` as long as `build.compiletest-use-stage0-libtest=true`, as that should remain orthogonal. This is completely unlike my previous attempt at https://github.com/rust-lang/rust/pull/144563 that tries to do a way more invasive change which would cause the rebuild problem.
Best reviewed commit-by-commit.
---
r? `@Kobzol`
|
|
`build.compiletest-allow-stage0`
|
|
compiletest: Move directive names back into a separate file
This list no longer needs to be included in multiple crates, but having the list in its own file makes it easier to find and update when necessary.
As discussed at https://github.com/rust-lang/rust/pull/143850#issuecomment-3130307023.
|
|
Verify llvm-needs-components are not empty and match the --target value
I recently discovered a test with an empty `llvm-needs-components` entry (fixed in rust-lang/rust#143979) which meant that it didn't work correctly when building Rust with a limited set of LLVM targets.
This change makes a pair of improvements to prevent this issue from creeping in again:
* When parsing directives with values, `compiletest` will now raise an error if there is an empty value.
* Improved the `target_specific_tests` tidy checker to map targets to LLVM components, to verify that any existing `llvm-needs-components` contains the target being used.
I also fixed all the issues flagged by the improved tidy checker.
|
|
This list no longer needs to be included in multiple crates, but having it in
its own file makes it easier to find and update when necessary.
|
|
|
|
|
|
|
|
|
|
|
|
miri subtree update
Subtree update of `miri` to https://github.com/rust-lang/miri/commit/fc4d9a2720d38f815d3e20627b805b4a379e5c8b.
Created using https://github.com/rust-lang/josh-sync.
r? `@ghost`
|
|
tidy: increase performance of auto extra checks feature
Removes the repeated calls to git diff.
Halves the overhead of the tidy extra checks feature from 0.1 seconds to 0.05 on my machine, but probably will be more significant on systems on slow disks or less memory for i/o cache.
r? ``@Kobzol``
|
|
Add `--link-targets-dir` argument to linkchecker
In my release notes API list tool (rust-lang/rust#143053) I want to check whether all links generated by the tool are actually valid, and using linkchecker seems to be the most sensible choice.
Linkchecker currently has a fairly big limitation though: it can only check a single directory, it checks *all* of the files within it, and link targets must point inside that same directory. This works great when checking the whole documentation package, but in my case I only need to check that one file contains valid links to the standard library docs.
To solve that, this PR adds a new `--link-targets-dir` flag to linkchecker. Directories passed to it will be valid link targets (with lower priority than the root being checked), but links within them will not be checked.
I'm not that happy with the name of the flag, happy for it to be bikeshedded.
|
|
Weekly `cargo update`
Automation to keep dependencies in `Cargo.lock` current.
r? dep-bumps
The following is the output from `cargo update`:
```txt
compiler & tools dependencies:
Locking 3 packages to latest compatible versions
Updating ipc-channel v0.20.0 -> v0.20.1
Updating rand v0.9.1 -> v0.9.2
Updating redox_syscall v0.5.13 -> v0.5.16
note: pass `--verbose` to see 37 unchanged dependencies behind latest
library dependencies:
Locking 1 package to latest compatible version
Updating rand v0.9.1 -> v0.9.2
note: pass `--verbose` to see 2 unchanged dependencies behind latest
rustbook dependencies:
Locking 1 package to latest compatible version
Updating redox_syscall v0.5.13 -> v0.5.16
```
|
|
`rust-analyzer` subtree update
Subtree update of `rust-analyzer` to https://github.com/rust-lang/rust-analyzer/commit/511c999bea1c3c129b8eba713bb9b809a9003d00.
Created using https://github.com/rust-lang/josh-sync.
r? `@ghost`
|
|
Co-authored-by: Jakub Beránek <berykubik@gmail.com>
|
|
Rustc pull update
|
|
|
|
|
|
|
|
|
|
fix: Fix runnables extra env not substituting env vars
|
|
Don't show '$saved_file' literally in IDE status updates
|
|
lookup_link_section: support arrays of function pointers
|
|
|
|
Migrate path transform
|
|
We've had a few users get confused when VS Code shows `my_custom_check
--args $saved_file`, as it looks like substitution didn't occur.
Instead, show `my_custom_check --args ...` in the display output. This
is also shorter, and the VS Code status bar generally works best with
short text.
|
|
|
|
|
|
|
