Automatic Rustup #4019
Merged
Automatic Rustup #4019
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
fix: do not assume rustup is installed in xtask codegen When formatting generated code the xtask crate attempts to run `rustup run stable rustfmt`, which fails if `rustup` is not installed. This results in test failures when another source manages the compiler toolchain, for example when using Nix (or any other distro-specific packaging solution): * xtask::codegen::grammar::test * xtask::codegen::assists_doc_tests::test With this PR xtask will first attempt to run `rustup run stable rustfmt`, and if that fails just plain `rustfmt`. It still validates a stable version is being used. This allows `cargo test` to pass on systems that do not use `rustup`.
feat: Implement object safety and its hovering hint Resolves #17779 - [x] Fill missing implementations - [x] Hover rendering - [x] Implement object safety's own test suite, like layout - [x] Add test cases (from rustc maybe) - [x] Clean up ugly codes - [x] Add doc string
Recategorize config classes
internal: Add doc comments to OpQueue I spent a while debugging some OpQueue behaviours and found the API slightly confusing, so I've added doc comments to clarify what each OpQueue method does.
internal: Sync from downstream
…avidbarsky internal: add tracing to project discovery and VFS loading With `"env RA_PROFILE=vfs_load|parallel_prime_caches|discover_command>500`, this results in the following output: ``` 21888ms discover_command 11627ms vfs_load @ total = 701 1503ms vfs_load @ total = 701 30211ms parallel_prime_caches ``` As a followup, I'd like to make hprof emit the information above as JSON.
minor: Stricter requirements for package wide flycheck Require the existence of a target and `check_workspace` to be false to restart package-wide flycheck. Fixes #18194 , #18104
…, r=Veykril
Building before a debugging session was restarted
# Background
Resolves #17901. It adds support for rebuilding after debugging a test was restarted. This means the test doesn't have to be aborted and manually re-ran again.
# How this is tested
First, all the Visual Studio Code extensions are loaded into an Extension Host window. Then, a sample test like below was ran and restarted to see if it was correctly rebuild.
```rust
#[test]
fn test_x() {
assert_eq!("1.1.1", "1.1.0");
}
```
internal: Send less data during `textDocument/completion` if possible Similar to rust-lang/rust-analyzer#15522, stops sending extra data during `textDocument/completion` if that data was set in the client completions resolve capabilities, and sends those only during `completionItem/resolve` requests. Currently, rust-analyzer sends back all fields (including potentially huge docs) for every completion item which might get large. Same as the other one, this PR aims to keep the changes minimal and does not remove extra computations for such fields — instead, it just filters them out before sending to the client. The PR omits primitive, boolean and integer, types such as `deprecated`, `preselect`, `insertTextFormat`, `insertTextMode`, etc. AND `additionalTextEdits` — this one looks very dangerous to compute for each completion item (as the spec says we ought to if there's no corresponding resolve capabilities provided) due to the diff computations and the fact that this code had been in the resolution for some time. It would be good to resolve this lazily too, please let me know if it's ok to do. When tested with Zed which only defines `documentation` and `additionalTextEdits` in its client completion resolve capabilities, rust-analyzer starts to send almost 3 times less characters: Request: ```json {"jsonrpc":"2.0","id":104,"method":"textDocument/completion","params":{"textDocument":{"uri":"file:///Users/someonetoignore/work/rust-analyzer/crates/ide/src/inlay_hints.rs"},"position":{"line":90,"character":14},"context":{"triggerKind":1}}} ``` <img width="1338" alt="image" src="https://github.com/user-attachments/assets/104f19b5-7095-4fc1-b008-5d829623b2e2"> Before: 381944 characters [before.json](https://github.com/user-attachments/files/17092385/before.json) After: 140503 characters [after.json](https://github.com/user-attachments/files/17092386/after.json) After Zed's [patch](zed-industries/zed#18212) to enable all resolving possible: 84452 characters [after-after.json](https://github.com/user-attachments/files/17092755/after-after.json)
fix: Fix bootstrap error message being incorrect precedence ...
internal: Filter out opaque tokens in some IDE feature macro descensions
minor: Sync from downstream
fix: Fix `prettify_macro_expansion()` when the node isn't the whole file Fixes #18238.
lsp: fix completion_item something_to_resolve not being a latch to true while looking at #18245 i noticed that `something_to_resolve` could technically flap between true -> false if some subsequent fields that were requested to be resolved were empty. this fixes that by using `|=` instead of `=` when assigning to `something_to_resolve` which will prevent it from going back to false once set. although some cases it's simply assigning to `true` i opted to continue to use `|=` there for uniformity sake. but happy to change those back to `=`'s. cc `@SomeoneToIgnore`
fix: include description in label details when detail field is marked for … Fixes rust-lang/rust-analyzer#18231. When omitting the autocomplete detail field, the autocomplete label details can still be returned. Currently the label details are missing the description field if the detail field is included in resolveSupport since it is being overwritten as None and opted to be sent with `completionItem/resolve`. Example completion capabilities. ``` completion = { completionItem = { commitCharactersSupport = true, deprecatedSupport = true, documentationFormat = { "markdown", "plaintext" }, insertReplaceSupport = true, insertTextModeSupport = { valueSet = { 1, 2 } }, labelDetailsSupport = true, preselectSupport = true, resolveSupport = { properties = { "documentation", "detail", "additionalTextEdits", "sortText", "filterText", "insertText", "textEdit", "insertTextFormat", "insertTextMode" } }, snippetSupport = true, tagSupport = { valueSet = { 1 } } } ```
Correctly parse `use` in generic parameters Fixes: #18225
…kril feat: Highlight exit points of async blocks Async blocks act similar to async functions in that the await keywords are related, but also act like functions where the exit points are related. Fixes #18147
fix: Comment out cast checks for unknown ptr kind Just like we don't check for types containing unknown. Fixes #18214. See also https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/Another.20case.20of.20.2318064.3F.
fix: Join rustfmt overrideCommand with project root When providing a custom rustfmt command, join it with the project root instead of the workspace root. This fixes rust-analyzer getting the wrong invocation path in projects containing subprojects. This makes the behaviour consistent with how a custom path provided in rust-analyzer.procMacro.server behaves already. Resolves issue #18222
internal: Don't resolve extern crates in import fix point resolution The fix point loop won't progress them given the potential extern crate candidates are set up at build time.
fix: Do not consider mutable usage of deref to `*mut T` as deref_mut Fixes #15799 We are doing some heuristics for deciding whether the given deref is deref or deref_mut here; https://github.com/rust-lang/rust-analyzer/blob/5982d9c420d0dc90739171829f0d2e9c80d98979/crates/hir-ty/src/infer/mutability.rs#L182-L200 But this heuristic is erroneous if we are dereferencing to a mut ptr and normally those cases are filtered out here as builtin; https://github.com/rust-lang/rust-analyzer/blob/5982d9c420d0dc90739171829f0d2e9c80d98979/crates/hir-ty/src/mir/lower/as_place.rs#L165-L177 Howerver, this works not so well if the given dereferencing is double dereferencings like the case in the #15799. ```rust struct WrapPtr(*mut u32); impl core::ops::Deref for WrapPtr { type Target = *mut u32; fn deref(&self) -> &Self::Target { &self.0 } } fn main() { let mut x = 0u32; let wrap = WrapPtr(&mut x); unsafe { **wrap = 6; } } ``` Here are two - outer and inner - dereferences here, and the outer dereference is marked as deref_mut because there is an assignment operation. And this deref_mut marking is propagated into the inner dereferencing. In the later MIR lowering, the outer dereference is filtered out as it's expr type is `*mut u32`, but the expr type in the inner dereference is an ADT, so this false-mutablility is not filtered out. This PR cuts propagation of this false mutablilty chain if the expr type is mut ptr. Since this happens before the resolve_all, it may have some limitations when the expr type is determined as mut ptr at the very end of inferencing, but I couldn't find simple fix for it 🤔
Add support for LLDB-DAP
minor: sync from downstream
Clamp Position::character to line length LSP says about Position::character > If the character value is greater than the line length it defaults back to the line length. but from_proto::offset() doesn't implement this. A client might for example request code actions for a whole line by sending Position::character=99999. I don't think there is ever a reason (besides laziness) why the client can't specify the line length instead but I guess we should not crash but follow protocol. Not sure how to update Cargo.lock (lib/README.md doesn't say how). Fixes #18240
internal: Fix editorconfig glob Had been testing Zed's editorconfig branch on r-a and noticed that something was odd with yaml files. https://spec.editorconfig.org/#glob-expressions > {s1,s2,s3} > any of the strings given (separated by commas, can be nested) (But {s1} only matches {s1} literally.)
Add wrap/unwrap return type in Option I pretty much just copied over the code and tests for wrapping/unwrapping return types in `Result` and then did a bunch of find and replace changes. I handled unwrapping statements returning `None` by just replacing `None` with the unit type, but I'm open to suggestions for more intuitive behavior here.
Subtree update of `rust-analyzer` r? `@ghost`
Support clobber_abi and vector registers (clobber-only) in PowerPC inline assembly This supports `clobber_abi` which is one of the requirements of stabilization mentioned in #93335. This basically does a similar thing I did in rust-lang/rust#130630 to implement `clobber_abi` for s390x, but for powerpc/powerpc64/powerpc64le. - This also supports vector registers (as `vreg`) as clobber-only, which need to support clobbering of them to implement `clobber_abi`. - `vreg` should be able to accept `#[repr(simd)]` types as input/output if the unstable `altivec` target feature is enabled, but `core::arch::{powerpc,powerpc64}` vector types, `#[repr(simd)]`, and `core::simd` are all unstable, so the fact that this is currently a clobber-only should not be considered a blocker of clobber_abi implementation or stabilization. So I have not implemented it in this PR. - See rust-lang/rust#131551 (which is based on this PR) for a PR to implement this. - (I'm not sticking to whether that PR should be a separate PR or part of this PR, so I can merge that PR into this PR if needed.) Refs: - PPC32 SysV: Section "Function Calling Sequence" in [System V Application Binary Interface PowerPC Processor Supplement](https://refspecs.linuxfoundation.org/elf/elfspec_ppc.pdf) - PPC64 ELFv1: Section 3.2 "Function Calling Sequence" in [64-bit PowerPC ELF Application Binary Interface Supplement](https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#FUNC-CALL) - PPC64 ELFv2: Section 2.2 "Function Calling Sequence" in [64-Bit ELF V2 ABI Specification](https://openpowerfoundation.org/specifications/64bitelfabi/) - AIX: [Register usage and conventions](https://www.ibm.com/docs/en/aix/7.3?topic=overview-register-usage-conventions), [Special registers in the PowerPC®](https://www.ibm.com/docs/en/aix/7.3?topic=overview-special-registers-in-powerpc), [AIX vector programming](https://www.ibm.com/docs/en/aix/7.3?topic=concepts-aix-vector-programming) - Register definition in LLVM: https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/PowerPC/PPCRegisterInfo.td#L189 If I understand the above four ABI documentations correctly, except for the PPC32 SysV's VR (Vector Registers) and 32-bit AIX (currently not supported by rustc)'s r13, there does not appear to be important differences in terms of implementing `clobber_abi`: - The above four ABIs are consistent about FPR (0-13: volatile, 14-31: nonvolatile), CR (0-1,5-7: volatile, 2-4: nonvolatile), XER (volatile), and CTR (volatile). - As for GPR, only the registers we are treating as reserved are slightly different - r0, r3-r12 are volatile - r1(sp, reserved), r14-31 are nonvolatile - r2(reserved) is TOC pointer in PPC64 ELF/AIX, system-reserved register in PPC32 SysV (AFAIK used as thread pointer in Linux/BSDs) - r13(reserved for non-32-bit-AIX) is thread pointer in PPC64 ELF, small data area pointer register in PPC32 SysV, "reserved under 64-bit environment; not restored across system calls[^r13]" in AIX) - As for FPSCR, volatile in PPC64 ELFv1/AIX, some fields are volatile only in certain situations (rest are volatile) in PPC32 SysV/PPC64 ELFv2. - As for VR (Vector Registers), it is not mentioned in PPC32 SysV, v0-v19 are volatile in both in PPC64 ELF/AIX, v20-v31 are nonvolatile in PPC64 ELF, reserved or nonvolatile depending on the ABI ([vec-extabi vs vec-default in LLVM](https://reviews.llvm.org/D89684), we are [using vec-extabi](rust-lang/rust#131341 (comment))) in AIX: > When the default Vector enabled mode is used, these registers are reserved and must not be used. > In the extended ABI vector enabled mode, these registers are nonvolatile and their values are preserved across function calls I left [FIXME comment about PPC32 SysV](rust-lang/rust#131341 (comment)) and added ABI check for AIX. - As for VRSAVE, it is not mentioned in PPC32 SysV, nonvolatile in PPC64 ELFv1, reserved in PPC64 ELFv2/AIX - As for VSCR, it is not mentioned in PPC32 SysV/PPC64 ELFv1, some fields are volatile only in certain situations (rest are volatile) in PPC64 ELFv2, volatile in AIX We are currently treating r1-r2, r13 (non-32-bit-AIX), r29-r31, LR, CTR, and VRSAVE as reserved. We are currently not processing anything about FPSCR and VSCR, but I feel those are things that should be processed by `preserves_flags` rather than `clobber_abi` if we need to do something about them. (However, PPCRegisterInfo.td in LLVM does not seem to define anything about them.) Replaces #111335 and #124279 cc `@ecnelises` `@bzEq` `@lu-zero` r? `@Amanieu` `@rustbot` label +O-PowerPC +A-inline-assembly [^r13]: callee-saved, according to [LLVM](https://github.com/llvm/llvm-project/blob/6a6af0246bd2d68291582e9aefc0543e5c6102fe/llvm/lib/Target/PowerPC/PPCCallingConv.td#L322) and [GCC](https://github.com/gcc-mirror/gcc/blob/a9173a50e7e346a218323916e4d3add8552529ae/gcc/config/rs6000/rs6000.h#L859).
…jubilee mark some target features as 'forbidden' so they cannot be (un)set with -Ctarget-feature The context for this is rust-lang/rust#116344: some target features change the way floats are passed between functions. Changing those target features is unsound as code compiled for the same target may now use different ABIs. So this introduces a new concept of "forbidden" target features (on top of the existing "stable " and "unstable" categories), and makes it a hard error to (un)set such a target feature. For now, the x86 and ARM feature `soft-float` is on that list. We'll have to make some effort to collect more relevant features, and similar features from other targets, but that can happen after the basic infrastructure for this landed. (These features are being collected in rust-lang/rust#131799.) I've made this a warning for now to give people some time to speak up if this would break something. MCP: rust-lang/compiler-team#780
make char::is_whitespace unstably const I am adding this to the existing rust-lang/rust#132241 feature gate, since `is_digit` and `is_whitespace` seem similar enough that one can group them together.
Suggest swapping LHS and RHS when RHS impls `PartialEq<lhs_ty>` Closes: #130495 r? `@fee1-dead`
Revert using `HEAP` static in Windows alloc Fixes #131468 This does the minimum to remove the `HEAP` static that was causing chromium issues. It would be worth having a more substantial look at this module but for now I think this addresses the immediate issue. cc `@danakj`
miri: update ABI compat checks to accept Option-like types This implements the t-lang decision described [here](rust-lang/rust#130628 (comment)). Fixes #3983
Implement `div_ceil` for `NonZero<unsigned>` ACP: rust-lang/libs-team#471
…-python-executable, r=jieyouxu fix(x): fix a regex used to find python executable Isn't the regex `^python[2-3]\.[0-9]\+$` wrong? It doesn't match, for example, with `python2.8`. There should be a plus sign at the end for a match, like `python2.8+`. I think `[0-9]+` is meant here instead of `[0-9]\+`. In that case a string like `python2.8` would match. This wasn't noticed because the script probably find and run the Python executable before this line.
Add --diagnostic-width to some tests failing after 1a0c5021838 Otherwise the tests would fail depending on the execution environment.
fix `LazyLock::get` and `LazyLock::get_mut` document
…h-name, r=tgross35 chore(issue-template): fix branch name It was renamed to "main" from "master". It might seem not important (actually it is not important) but I think there is no need to see this every time when we clicked this link:  And this way is faster I guess.
Rollup of 6 pull requests Successful merges: - #132057 (miri: update ABI compat checks to accept Option-like types) - #132665 (Implement `div_ceil` for `NonZero<unsigned>`) - #132694 (fix(x): fix a regex used to find python executable) - #132707 (Add --diagnostic-width to some tests failing after 1a0c5021838) - #132715 (fix `LazyLock::get` and `LazyLock::get_mut` document) - #132716 (chore(issue-template): fix branch name) r? `@ghost` `@rustbot` modify labels: rollup
unpin and update memchr I'm unable to build x86_64-pc-windows-gnu Rust due to some weird binutils bug, but thinlto issue seems to be no longer present. Let's give it a go on the CI. Possibly fixed by rust-lang/rust#129079 Fixes #127890
Basic inline assembly support for SPARC and SPARC64 This implements asm_experimental_arch (tracking issue rust-lang/rust#93335) for SPARC and SPARC64. This PR includes: - General-purpose registers `r[0-31]` (`reg` register class, LLVM/GCC constraint `r`) Supported types: i8, i16, i32, i64 (SPARC64-only) Aliases: `g[0-7]` (`r[0-7]`), `o[0-7]` (`r[8-15]`), `l[0-7]` (`r[16-23]`), `i[0-7]` (`r[24-31]`) - `y` register (clobber-only, needed for clobber_abi) - preserves_flags: Integer condition codes (`icc`, `xcc`) and floating-point condition codes (`fcc*`) The following are *not* included: - 64-bit integer support on SPARC-V8+'s global or out registers (`g[0-7]`, `o[0-7]`): GCC's `h` constraint (it seems that there is no corresponding constraint in LLVM?) - Floating-point registers (LLVM/GCC constraint `e`/`f`): I initially tried to implement this, but postponed it for now because there seemed to be several parts in LLVM that behaved differently than in the LangRef's description. - clobber_abi: Support for floating-point registers is needed. Refs: - LLVM - Reserved registers https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/Sparc/SparcRegisterInfo.cpp#L52 - Register definitions https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/Sparc/SparcRegisterInfo.td - Supported constraints https://llvm.org/docs/LangRef.html#supported-constraint-code-list - GCC - Reserved registers https://github.com/gcc-mirror/gcc/blob/63b6967b06b5387821c4e5f2c113da6aaeeae2b7/gcc/config/sparc/sparc.h#L633-L658 - Supported constraints https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html - SPARC ISA/ABI - (64-bit ISA) The SPARC Architecture Manual, Version 9 (32-bit ISA) The SPARC Architecture Manual, Version 8 (64-bit ABI) System V Application Binary Interface SPARC Version 9 Processor Supplement, Rev 1.35 (32-bit ABI) System V Application Binary Interface SPARC Processor Supplement, Third Edition The above docs can be downloaded from https://sparc.org/technical-documents - (32-bit V8+ ABI) The V8+ Technical Specification https://temlib.org/pub/SparcStation/Standards/V8plus.pdf cc `@thejpster` (sparc-unknown-none-elf target maintainer) (AFAIK, other sparc/sprac64 targets don't have target maintainers) r? `@Amanieu` `@rustbot` label +O-SPARC +A-inline-assembly
Tweak detection of multiple crate versions to be more encompassing
Previously, we only emitted the additional context if the type was in the same crate as the trait that appeared multiple times in the dependency tree. Now, we look at all traits looking for two with the same name in different crates with the same crate number, and we are more flexible looking for the types involved. This will work even if the type that implements the wrong trait version is from a different crate entirely.
```
error[E0277]: the trait bound `CustomErrorHandler: ErrorHandler` is not satisfied because the trait comes from a different crate version
--> src/main.rs:5:17
|
5 | cnb_runtime(CustomErrorHandler {});
| ^^^^^^^^^^^^^^^^^^^^^ the trait `ErrorHandler` is not implemented for `CustomErrorHandler`
|
note: there are multiple different versions of crate `c` in the dependency graph
--> /home/gh-estebank/testcase-rustc-crate-version-mismatch/c-v0.2/src/lib.rs:1:1
|
1 | pub trait ErrorHandler {}
| ^^^^^^^^^^^^^^^^^^^^^^ this is the required trait
|
::: src/main.rs:1:5
|
1 | use b::CustomErrorHandler;
| - one version of crate `c` is used here, as a dependency of crate `b`
2 | use c::cnb_runtime;
| - one version of crate `c` is used here, as a direct dependency of the current crate
|
::: /home/gh-estebank/testcase-rustc-crate-version-mismatch/b/src/lib.rs:1:1
|
1 | pub struct CustomErrorHandler {}
| ----------------------------- this type doesn't implement the required trait
|
::: /home/gh-estebank/testcase-rustc-crate-version-mismatch/c-v0.1/src/lib.rs:1:1
|
1 | pub trait ErrorHandler {}
| ---------------------- this is the found trait
= note: two types coming from two different versions of the same crate are different types even if they look the same
= help: you can use `cargo tree` to explore your dependency tree
```
Fix #89143.
…c functions instead
remove support for rustc_safe_intrinsic attribute; use rustc_intrinsic functions instead This brings us one step closer towards removing support for `extern "rust-intrinsic"` blocks, in favor of `#[rustc_intrinsic]` functions. Also move `#[rustc_intrinsic]` under the `intrinsics` feature gate, to match the `extern "rust-intrinsic"` style.
Clippy subtree update r? `@Manishearth`
Drop "gnu" in the target env for FreeBSD armv6/7 FreeBSD is not a GNU system
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Please close and re-open this PR to trigger CI, then enable auto-merge.