modify ensure_version_or_cargo_install to check existing binary

2025-09-28T08:46:20+00:00

Current implementation uses bin_name to check if it exists, but it should use tool_root_dir/tool_bin_dir/bin_name instead. Otherwise the check fails every time, hence the function falls back to install the binary.

Rollup merge of #145973 - vexide:vex-std, r=tgross35

2025-09-25T10:31:53+00:00

Add `std` support for `armv7a-vex-v5` This PR adds standard library support for the VEX V5 Brain (`armv7a-vex-v5` target). It is more-or-less an updated version of the library-side work done in rust-lang/rust#131530. This was a joint effort between me, `@lewisfm,` `@max-niederman,` `@Gavin-Niederman` and several other members of the [`vexide` project](https://github.com/vexide/). ## Background VEXos is a fairly unconventional operating system, with user code running in a restricted enviornment with regards to I/O capabilities and whatnot. As such, several OS-dependent APIs are unsupported or have partial support (such as `std::net`, `std::process`, and most of `std::thread`). A more comprehensive list of what does or doesn't work is outlined in the [updated target documentation](https://github.com/vexide/rust/blob/vex-std/src/doc/rustc/src/platform-support/armv7a-vex-v5.md). Despite these limitations, we believe that `libstd` support on this target still has value to users, especially given the popular use of this hardware for educational purposes. For some previous discussion on this matter, see [this comment](https://github.com/rust-lang/rust/pull/131530#issuecomment-2432856841). ## SDK Linkage VEXos doesn't really ship with an official `libc` or POSIX-style platform API (and though it does port newlib, these are stubbed on top of the underlying SDK). Instead, VEX provides their own SDK for calling platform APIs. Their official SDK is kept proprietary (with public headers), though open-source implementations exist. Following the precedent of the `armv6k-nintendo-3ds` team's work in rust-lang/rust#95897, we've opted not to directly link `libstd` to any SDK with the expectation that users will provide their own with one of the following options: - [`vex-sdk-download`](https://github.com/vexide/vex-sdk/tree/main/packages/vex-sdk-download), which downloads an official proprietary SDK from VEX using a build script. - [`vex-sdk-jumptable`](https://crates.io/crates/vex-sdk-jumptable), which is a compatible, open-source reimplementation of the SDK using firmware jumps. - [`vex-sdk-pros`](https://github.com/vexide/vex-sdk/tree/main/packages/vex-sdk-pros), which uses the [PROS kernel](https://github.com/purduesigbots/pros) as a provider for SDK functions. - Linking their own implementation or stubbing the functions required by libstd. The `vex-sdk` crate used in the VEXos PAL provides `libc`-style FFI bindings for any compatible system library, so any of these options *should* work fine. A functional demo project using `vex-sdk-download` can be found [here](https://github.com/vexide/armv7a-vex-v5-demo/tree/main). ## Future Work This PR implements virtually everything we are currently able to implement given the current capabilities of the platform. The exception to this is file directory enumeration, though the implementation of that is sufficiently [gross enough](https://github.com/vexide/vexide/blob/c6c5bad11e035cf4e51d429dca7e427210185ed4/packages/vexide-core/src/fs/mod.rs#L987) to drive us away from supporting this officially. Additionally, I have a working branch implementing the `panic_unwind` runtime for this target, which is something that would be nice to see in the future, though given the volume of compiler changes i've deemed it out-of-scope for this PR.

std: add support for armv7a-vex-v5 target

2025-09-24T17:10:15+00:00

Co-authored-by: Lewis McClelland

Rollup merge of #146784 - dpaoliello:findmsvc, r=wesleywiser

2025-09-23T16:13:53+00:00

[win] Use find-msvc-tools instead of cc to find the linker and rc on Windows `find-msvc-tools` was factored out from `cc` to allow updating the use in `rustc_codegen_ssa` (finding the linker when running the Rust compiler) and `rustc_windows_rc` (finding the Windows Resource Compiler when running the Rust compiler) to be separate from the use in `rustc_llvm` (building LLVM as part of building the Rust compiler).

Fix modification check of `rustdoc-json-types`

2025-09-22T12:14:48+00:00

Implement output of colored messages with optional check context

2025-09-21T13:15:31+00:00

Migrate the remaining tidy checks to diagnostics

2025-09-21T13:15:31+00:00

Add `CheckId`, migrate the `alphabetical` check to diagnostics

2025-09-21T13:13:01+00:00

Add diagnostics context and migrate the `style` check to it