about summary refs log tree commit diff
path: root/src/tools
AgeCommit message (Collapse)AuthorLines
2025-01-24Explicitly add buildfiles when constructing ProjectFoldersDavid Richey-21/+38
2025-01-24Rollup merge of #135950 - Kobzol:tidy-python-improvements, r=onur-ozkanMatthias Krüger-56/+85
Tidy Python improvements Fixes display of Python formatting diffs in tidy, and refactors the code to make it simpler and more robust. Also documents Python formatting and linting in the Rustc dev guide. Fixes: https://github.com/rust-lang/rust/issues/135942 r? `@onur-ozkan`
2025-01-24Rollup merge of #135926 - jieyouxu:needs-subprocess-thread, r=oli-obkMatthias Krüger-2/+21
Implement `needs-subprocess` directive, and cleanup a bunch of tests to use `needs-{subprocess,threads}` ### Summary Closes #128295. - Implements `//@ needs-subprocess` directive in compiletest as requested in #128295. However, compiletest is a host tool, so we can't just try to spawn process because that spawns the process on *host*, not the *target*, under cross-compilation scenarios. - The short-term solution is to add *Yet Another* list of allow-list targets. - The long-term solution is to first check if a `$target` supports std, then try to run a binary to do run-time capability detection *on the target*. But that is tricky because you have to build-and-run a binary *for the target*. - This PR picks the short-term solution, because the long-term solution is highly non-trivial, and it's already an improvement over individual `ignore-*`s all over the place. - Opened an issue about the long-term solution in #135928. - Documents `//@ needs-subprocess` in rustc-dev-guide. - Replace `ignore-{wasm,wasm32,emscripten,sgx}` with `needs-{subprocess,threads}` where suitable in tests. - Some drive-by test changes as I was trying to figure out if I could use `needs-{subprocess,threads}` and found some bits needlessly distracting. Count of tests that use `ignore-{wasm,wasm32,emscripten,sgx}` before and after this PR: | State | `ignore-sgx` | `ignore-wasm` | `ignore-emscripten` | | - | - | - | - | | Before this PR | 96 | 88 | 207 | | After this PR | 36 | 38 | 61 | <details> <summary>Commands used to find out locally</summary> ``` --- before [17:40] Joe:rust (fresh) | rg --no-ignore -l "ignore-sgx" tests | wc -l 96 [17:40] Joe:rust (fresh) | rg --no-ignore -l "ignore-wasm" tests | wc -l 88 [17:40] Joe:rust (fresh) | rg --no-ignore -l "ignore-emscripten" tests | wc -l 207 --- after [17:39] Joe:rust (needs-subprocess-thread) | rg --no-ignore -l "ignore-sgx" tests | wc -l 36 [17:39] Joe:rust (needs-subprocess-thread) | rg --no-ignore -l "ignore-wasm" tests | wc -l 38 [17:39] Joe:rust (needs-subprocess-thread) | rg --no-ignore -l "ignore-emscripten" tests | wc -l 61 ``` </details> ### Review advice - Best reviewed commit-by-commit. - Non-trivial test changes (not mechanically simple replacements) are split into individual commits to help with review. Their individual commit messages give some basic description of the changes. - I *could* split some test changes out into another PR, but I found that I needed to change some tests to `needs-threads`, some to `needs-subprocess`, and some needed to use *both*, so they might conflict and become very annoying. --- r? ``@ghost`` (need to run try jobs) try-job: x86_64-msvc-1 try-job: i686-msvc-1 try-job: i686-mingw try-job: x86_64-mingw-1 try-job: x86_64-apple-1 try-job: aarch64-apple try-job: aarch64-gnu try-job: test-various try-job: armhf-gnu
2025-01-24Merge pull request #19018 from Veykril/push-wxqqunxwrplyLukas Wirth-95/+112
internal: Record the use tree index in glob imports
2025-01-24Merge pull request #18991 from Veykril/push-rmqmnrymwmozLukas Wirth-322/+433
Keep already computed inlay hint properties instead of late resolving them
2025-01-24Lazily compute location links in type hints againLukas Wirth-9/+18
2025-01-24Record the use tree index in glob importsLukas Wirth-95/+112
2025-01-24Add a new failing test that overflows stackShoyu Vanilla-0/+37
2025-01-24Merge pull request #19012 from ShoyuVanilla/arbitrary-selfLukas Wirth-26/+129
feat: Implement `arbitrary-self-types`
2025-01-24feat: Implement `arbitrary-self-types`Shoyu Vanilla-26/+129
2025-01-24Merge pull request #19017 from Veykril/push-uktrsknwmsvyLukas Wirth-10/+26
fix: Fix flycheck panicking with "once" invocation strategy
2025-01-24Merge pull request #18993 from ChayimFriedman2/iter-configLukas Wirth-56/+111
feat: Provide a config to control auto-insertion of `await` and `iter()`
2025-01-24Merge pull request #18994 from Wilfred/failed_rustc_cfg_as_warningLukas Wirth-1/+1
internal: Treat cfg fetching failures as a warning
2025-01-24Merge pull request #19016 from Veykril/push-moqnsytyrupuLukas Wirth-208/+234
fix: Fix `ItemScope` not recording glob imports
2025-01-24fix: Fix flycheck panicking with "once" invocation strategyLukas Wirth-10/+26
We only ever have one flycheck runner no matter the number of workspaces, so just kick off flycheck for it immediately
2025-01-24Fix `ItemScope` not recording glob importsLukas Wirth-208/+234
This caused us other code to incorrectly assume in dealing with a declaration when in fact it was dealing with a glob imported definition
2025-01-24Rename test to `unresolvable-upvar-issue-87987.rs`Zalathar-1/+0
This also suppresses an irrelevant warning, to avoid having to re-bless the output snapshot.
2025-01-24Auto merge of #135272 - BoxyUwU:generic_arg_infer_reliability_2, ↵bors-171/+168
r=compiler-errors Forbid usage of `hir` `Infer` const/ty variants in ambiguous contexts The feature `generic_arg_infer` allows providing `_` as an argument to const generics in order to infer them. This introduces a syntactic ambiguity as to whether generic arguments are type or const arguments. In order to get around this we introduced a fourth `GenericArg` variant, `Infer` used to represent `_` as an argument to generic parameters when we don't know if its a type or a const argument. This made hir visitors that care about `TyKind::Infer` or `ConstArgKind::Infer` very error prone as checking for `TyKind::Infer`s in `visit_ty` would find *some* type infer arguments but not *all* of them as they would sometimes be lowered to `GenericArg::Infer` instead. Additionally the `visit_infer` method would previously only visit `GenericArg::Infer` not *all* infers (e.g. `TyKind::Infer`), this made it very easy to override `visit_infer` and expect it to visit all infers when in reality it would only visit *some* infers. --- This PR aims to fix those issues by making the `TyKind` and `ConstArgKind` types generic over whether the infer types/consts are represented by `Ty/ConstArgKind::Infer` or out of line (e.g. by a `GenericArg::Infer` or accessible by overiding `visit_infer`). We then make HIR Visitors convert all const args and types to the versions where infer vars are stored out of line and call `visit_infer` in cases where a `Ty`/`Const` would previously have had a `Ty/ConstArgKind::Infer` variant: API Summary ```rust enum AmbigArg {} enum Ty/ConstArgKind<Unambig = ()> { ... Infer(Unambig), } impl Ty/ConstArg { fn try_as_ambig_ty/ct(self) -> Option<Ty/ConstArg<AmbigArg>>; } impl Ty/ConstArg<AmbigArg> { fn as_unambig_ty/ct(self) -> Ty/ConstArg; } enum InferKind { Ty(Ty), Const(ConstArg), Ambig(InferArg), } trait Visitor { ... fn visit_ty/const_arg(&mut self, Ty/ConstArg<AmbigArg>) -> Self::Result; fn visit_infer(&mut self, id: HirId, sp: Span, kind: InferKind) -> Self::Result; } // blanket impl'd, not meant to be overriden trait VisitorExt { fn visit_ty/const_arg_unambig(&mut self, Ty/ConstArg) -> Self::Result; } fn walk_unambig_ty/const_arg(&mut V, Ty/ConstArg) -> Self::Result; fn walk_ty/const_arg(&mut V, Ty/ConstArg<AmbigArg>) -> Self::Result; ``` The end result is that `visit_infer` visits *all* infer args and is also the *only* way to visit an infer arg, `visit_ty` and `visit_const_arg` can now no longer encounter a `Ty/ConstArgKind::Infer`. Representing this in the type system means that it is now very difficult to mess things up, either accessing `TyKind::Infer` "just works" and you won't miss *some* type infers- or it doesn't work and you have to look at `visit_infer` or some `GenericArg::Infer` which forces you to think about the full complexity involved. Unfortunately there is no lint right now about explicitly matching on uninhabited variants, I can't find the context for why this is the case :woman_shrugging: I'm not convinced the framing of un/ambig ty/consts is necessarily the right one but I'm not sure what would be better. I somewhat like calling them full/partial types based on the fact that `Ty<Partial>`/`Ty<Full>` directly specifies how many of the type kinds are actually represented compared to `Ty<Ambig>` which which leaves that to the reader to figure out based on the logical consequences of it the type being in an ambiguous position. --- tool changes have been modified in their own commits for easier reviewing by anyone getting cc'd from subtree changes. I also attempted to split out "bug fixes arising from the refactoring" into their own commit so they arent lumped in with a big general refactor commit Fixes #112110
2025-01-24Update Python 3 versions in tidyJakub Beránek-2/+10
Python 3.13 has been released a few months ago.
2025-01-24Make virtualenv creation in tidy more robustJakub Beránek-6/+24
2025-01-24Refactor Python linting and formatting in tidyJakub Beránek-48/+51
Unify the logic under a simple function to make it harder to cause mistakes.
2025-01-24Rollup merge of #135865 - zachs18:maybe_report_similar_assoc_fn_more, ↵Matthias Krüger-1/+0
r=compiler-errors For E0223, suggest associated functions that are similar to the path, even if the base type has multiple inherent impl blocks. Currently, the "help: there is an associated function with a similar name `from_utf8`" suggestion for `String::from::utf8` is only given if `String` has exactly one inherent `impl` item. This PR makes the suggestion be emitted even if the base type has multiple inherent `impl` items. Example: ```rust struct Foo; impl Foo { fn bar_baz() {} } impl Foo {} // load-bearing fn main() { Foo::bar::baz; } ``` Nightly/stable output: ```rust error[E0223]: ambiguous associated type --> f.rs:7:5 | 7 | Foo::bar::baz; | ^^^^^^^^ | help: if there were a trait named `Example` with associated type `bar` implemented for `Foo`, you could use the fully-qualified path | 7 | <Foo as Example>::bar::baz; | ~~~~~~~~~~~~~~~~~~~~~ error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0223`. ``` Output with this PR, or without the load-bearing empty impl on nightly/stable: ```rust error[E0223]: ambiguous associated type --> f.rs:7:5 | 7 | Foo::bar::baz; | ^^^^^^^^ | help: there is an associated function with a similar name: `bar_baz` | 7 | Foo::bar_baz; | ~~~~~~~ error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0223`. ``` Ideally, this suggestion would also work for non-ADT types like ~~`str::char::indices`~~ (edit: latest commit makes this work with primitives) or `<dyn Any>::downcast::mut_unchecked`, but that seemed to be a harder change. `@rustbot` label +A-diagnostics
2025-01-24Rollup merge of #135799 - aDotInTheVoid:skrrt-skrrt-revrrt, r=GuillaumeGomezMatthias Krüger-2/+2
rustdoc-json: Rename `Path::name` to `path`, and give it the path again. Closes: #135600. Reverts #134880 (Effectively, but not actually, as the `FORMAT_VERSION` needs to be bumped, changed docs/tests). CC `@AS1100K.` Also CC `@obi1kenobi` `@LukeMathWalker` Still needs before being merge-ready: - [x] Tests for cross-crate paths - [x] (Maybe) Document what the field does. - [x] Decide if the field rename is good (https://github.com/rust-lang/rust/pull/135799#issuecomment-2605937831) - [ ] Squash commits. r? `@GuillaumeGomez`
2025-01-24fmtThe Miri Cronjob Bot-1/+1
2025-01-24Merge from rustcThe Miri Cronjob Bot-27/+33
2025-01-24Preparing for merge from rustcThe Miri Cronjob Bot-1/+1
2025-01-24Reword "crate not found" resolve messageEsteban Küber-3/+5
``` error[E0432]: unresolved import `some_novel_crate` --> file.rs:1:5 | 1 | use some_novel_crate::Type; | ^^^^^^^^^^^^^^^^ use of unresolved module or unlinked crate `some_novel_crate` ``` On resolve errors where there might be a missing crate, mention `cargo add foo`: ``` error[E0433]: failed to resolve: use of unresolved module or unlinked crate `nope` --> $DIR/conflicting-impl-with-err.rs:4:11 | LL | impl From<nope::Thing> for Error { | ^^^^ use of unresolved module or unlinked crate `nope` | = help: if you wanted to use a crate named `nope`, use `cargo add nope` to add it to your `Cargo.toml` ```
2025-01-23Check cfg when collecting macro defsDavid Richey-0/+6
2025-01-23Give E0223 similar-item suggestion test more descriptive name.Zachary S-1/+0
2025-01-23Rollup merge of #135880 - bjorn3:misc_driver_refactors, r=oli-obkMatthias Krüger-27/+10
Get rid of RunCompiler The various `set_*` methods that have been removed can be replaced by setting the respective fields in the `Callbacks::config` implementation. `set_using_internal_features` was often forgotten and it's equivalent is now done automatically.
2025-01-23Rollup merge of #135073 - joshtriplett:bstr, r=BurntSushiMatthias Krüger-0/+23
Implement `ByteStr` and `ByteString` types Approved ACP: https://github.com/rust-lang/libs-team/issues/502 Tracking issue: https://github.com/rust-lang/rust/issues/134915 These types represent human-readable strings that are conventionally, but not always, UTF-8. The `Debug` impl prints non-UTF-8 bytes using escape sequences, and the `Display` impl uses the Unicode replacement character. This is a minimal implementation of these types and associated trait impls. It does not add any helper methods to other types such as `[u8]` or `Vec<u8>`. I've omitted a few implementations of `AsRef`, `AsMut`, and `Borrow`, when those would be the second implementation for a type (counting the `T` impl), to avoid potential inference failures. We can attempt to add more impls later in standalone commits, and run them through crater. In addition to the `bstr` feature, I've added a `bstr_internals` feature for APIs provided by `core` for use by `alloc` but not currently intended for stabilization. This API and its implementation are based *heavily* on the `bstr` crate by Andrew Gallant (`@BurntSushi).` r? `@BurntSushi`
2025-01-23Update toolstate maintainersEric Huss-5/+11
This updates the toolstate maintainers to more closely match who is still active. I am adding myself to ensure these get resolved if they break, since otherwise it causes other problems.
2025-01-23Remove rustc-dev-guideEric Huss-3/+0
This is not tracked in toolstate.
2025-01-23tests: move `tests/ui/issues/issue-39175.rs` under `suggestions/` and rename许杰友 Jieyou Xu (Joe)-2/+1
2025-01-23compiletest: implement `needs-subprocess` directive许杰友 Jieyou Xu (Joe)-0/+20
2025-01-23Rephrase commentLaurențiu Nicola-3/+3
2025-01-23Remove RunCompilerbjorn3-4/+4
It has become nothing other than a wrapper around run_compiler.
2025-01-23Remove the need to manually call set_using_internal_featuresbjorn3-26/+9
2025-01-23make `hir::Ty/ConstArg` methods generic where applicableBoxy-2/+2
2025-01-23`visit_x_unambig`Boxy-12/+12
2025-01-23The clipper :3cBoxy-168/+165
2025-01-23Make `hir::TyKind::TraitObject` use tagged ptrBoxy-5/+5
2025-01-22fix no-std-smoke testRalf Jung-0/+1
2025-01-23Auto merge of #135461 - jieyouxu:migrate-jobserver-errors, r=Noratriebbors-1/+66
tests: Port `jobserver-error` to rmake.rs Part of #121876. This PR ports `tests/run-make/jobserver-error` to rmake.rs, and is basically #128789 slightly adjusted. The complexity involved here is mostly how to get `/dev/null/` piping to fd 3 working with std `Command`, whereas with a shell this is much easier (as is evident with the `Makefile` version). Supersedes #128789. This PR is co-authored with `@Oneirical` and `@coolreader18.` try-job: aarch64-gnu try-job: i686-gnu-1 try-job: x86_64-gnu-debug try-job: x86_64-gnu-llvm-18-1
2025-01-23fmtThe Miri Cronjob Bot-4/+2
2025-01-23Merge from rustcThe Miri Cronjob Bot-3310/+9388
2025-01-23Preparing for merge from rustcThe Miri Cronjob Bot-1/+1
2025-01-23Auto merge of #135164 - Kobzol:run-make-test-glibc-symbols, r=jieyouxubors-1/+15
Add test for checking used glibc symbols This test checks that we do not use too new glibc symbols in the compiler on x64 GNU Linux, in order not to break our [glibc promises](https://blog.rust-lang.org/2022/08/01/Increasing-glibc-kernel-requirements.html). One thing that isn't solved in the PR yet is to make sure that this test will only run on `dist` CI, more specifically on the `dist-x86_64-linux` runner, in the opt-dist post-optimization tests (it can fail elsewhere, that doesn't matter). Any suggestions on how to do that are welcome. Fixes: https://github.com/rust-lang/rust/issues/134037 r? `@jieyouxu`
2025-01-22Auto merge of #135896 - matthiaskrgr:rollup-g6rv7za, r=matthiaskrgrbors-1/+3
Rollup of 9 pull requests Successful merges: - #132983 (Edit dangling pointers ) - #135409 (Fix ICE-133117: multiple never-pattern arm doesn't have false_edge_start_block) - #135557 (Point at invalid utf-8 span on user's source code) - #135596 (Properly note when query stack is being cut off) - #135794 (Detect missing fields with default values and suggest `..`) - #135814 (ci: use ghcr buildkit image) - #135826 (Misc. `rustc_resolve` cleanups) - #135837 (Remove test panic from File::open) - #135856 (Library: Finalize dyn compatibility renaming) r? `@ghost` `@rustbot` modify labels: rollup
2025-01-22increase `AUTODEREF_RECURSION_LIMIT` to 20Teodor Tanasoaia-2/+2
The limit was introduced in https://github.com/rust-lang/rust-analyzer/pull/1408#discussion_r294059044 to avoid infinite cycles but it effectively caps the number of derefs to 10. Types like `ID3D12Device14` from the `windows` crate run into this because it derefs to `ID3D12Device13`, 13 to 12 and so on. Increasing it to 20 is a quick fix; a better cycle detection method would be nicer long term.