| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Fix GDB `OsString` provider on Windows
It would throw an exception due to trying to look up `Wtf8Buf.__0`. The field it actually wants is called [`bytes`](https://github.com/rust-lang/rust/blob/b605c65b6eb5fa71783f8e26df69975f9f1680ee/library/std/src/sys_common/wtf8.rs#L134).
|
|
|
|
|
|
This reverts commit f5577a8174685aca342b9189e625648f25a23a20.
|
|
Use python built in type annotations in LLDB visualizer scripts
Replaces type annotation comments with python's built-in type annotations.
Built-in type annotations were added in python 3.5. LLDB [currently recommends (and as of LLVM 21, will enforce)](https://github.com/llvm/llvm-project/pull/114807) a minimum python version of 3.8. Rust's test suite also requires python 3.10.
|
|
|
|
Signed-off-by: ericlehong <193237094+ericlehong@users.noreply.github.com>
|
|
|
|
|
|
Don't use a SyntheticProvider for literally every type
Replaces a glob regex with individualized imports for each standard library type. This improves debugger performance by quite a bit when populating lots of values with lots of fields
With the glob, afaik every single value of every single type that the debugger renders is run through a python function that does quite a few string comparisons (i plan to fix those next) to determine the SyntheticProvider to use. It looks like DefaultSyntheticProvider's functions internally call the liblldb c++ functions, which ends up with identical behavior to not using a SyntheticProvider at all, except you have extra python round trips slowing things down.
These sample vidoes were run on x86-64-pc-windows-gnu. `vect` is a 1000 element `Vec<Big>`, `Big` contains a dozen or so `Small`, and `Small` contains a dozen or so `[i32; 5]`
Before:
https://github.com/user-attachments/assets/07c31fe7-e126-4c2e-8ae9-cfe36e351d3f
After:
https://github.com/user-attachments/assets/6c0d1a45-1ffe-46de-95a0-5dbe59a173b5
---
try-job: aarch64-apple
|
|
|
|
|
|
|
|
|
|
Fix broken url
|
|
|
|
|
|
Signed-off-by: wangjingcun <wangjingcun@aliyun.com>
|
|
|
|
rust_analyzer_helix.toml: add library/ manifest
|
|
|
|
Also, sort list
|
|
|
|
|
|
Fix missing rustfmt in msi installer #101993
# Context
- Fixed missing `rustfmt`, `clippy`, `miri` and `rust-analyzer` in msi installer
- Fixed missing `rustfmt` for apple darwin installer
- Closes #101993
r? `@jyn514`
- Please let me know if I should request from someone else instead. I divided the changes into 3 separate commits for the ease of review. The refactoring commit `fbdfd5c03c3c979bcf105ccdd05ff4ab9f37a763` is a bit more involved, but I think it helps in the long term for readability and to avoid bugs.
- I changed `build-manifest` to `build_manifest` in order to invoke it as a library. Not sure if this is gonna break any upstream processes. I checked `generate-manifest-list` and `generate-release` but didn't find any obvious reference
- Will push fixes for linting later
|
|
|
|
|
|
Consolidate LSP setup for different editors into one `./x setup editor`.
|
|
|
|
|
|
Add support for automatically setting up the recommended
LSP config for Emacs.
Additionally, refactor setup.rs to make it easier to add support
for more editors in the future.
|
|
etc: Add sample rust-analyzer configs for eglot & helix
LSP configuration in editors like Emacs (eglot) and helix does not
use the same JSON format as vscode and vim do. It is not obvious
how to set up LSP for rustc in those editors and the dev guide currently
does not cover them. Adding sample configuration files for those editors
alongside the currently existing JSON one would be helpful.
I figured having those included in the repo like the JSON one might save
someone some time and frustration otherwise spent on trying to get the
more niche editors' LSP to work properly. I'll add a section in the dev
guide too.
|
|
LSP configuration in editors like Emacs (eglot) and helix does not
use the same JSON format as vscode and vim do. It is not obvious
how to set up LSP for rustc in those editors and the dev guide currently
does not cover them. Adding sample configuration files for those editors
alongside the currently existing JSON one would be helpful.
|
|
Add the library workspace to the suggested rust-analyzer config
|
|
|
|
|
|
|
|
Running `cargo update` changed completion output. Regenerate them here.
|
|
to pick up changes to `./x miri` and `./x test` commands
|
|
|
|
|
|
|
|
The existing implementation uses Python to launch a set of Rust-written
binaries. Unfortunately, this is currently broken; it seems that some
updates meant it no longer compiles.
There is also a problem that support for more float types (`f16`,
`f128`) would be difficult to add since this is very specialized to
`f32` and `f64`.
Because of these sortcomings, migrate to a version written in Rust. This
version should be significantly faster; test generators can execute in
parallel, and test cases are chunked and parallelized. This should also
resolve the preexisting "... the worker processes are leaked and stick
around forever" comment.
This change also introduces genericism over float types and properties,
meaning it will be much easier to extend support to newly added types.
`num::BigRational` is used in place of Python's fractions for
infinite-precision calculations.
|
|
|
|
Add Natvis visualiser and debuginfo tests for `f16`
To render `f16`s in debuggers on MSVC targets, this PR changes the compiler to output `f16`s as `struct f16 { bits: u16 }`, and includes a Natvis visualiser that manually converts the `f16`'s bits to a `float` which is can then be displayed by debuggers. `gdb`, `lldb` and `cdb` tests are also included for `f16` .
`f16`/`f128` MSVC debug info issue: #121837
Tracking issue: #116909
|
|
|
|
|
|
|
