9204: feat: more accurate memory usage info on glibc Linux r=jonas-schievink a=jonas-schievink
This adds support for the new `mallinfo2` API added in glibc 2.33. It addresses a shortcoming in the `mallinfo` API where it was unable to handle memory usage of more than 2 GB, which we sometimes exceed.
Blocked on https://github.com/rust-lang/libc/pull/2228
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9192: internal: Build test-macros in a build script r=jonas-schievink a=jonas-schievink
This build the test-proc-macros in `proc_macro_test` in a build script, and copies the artifact to `OUT_DIR`. This should make it available throughout all of rust-analyzer at no cost other than depending on `proc_macro_test`, fixing https://github.com/rust-analyzer/rust-analyzer/issues/9067.
This hopefully will let us later write inline tests that utilize proc macros, which makes my life fixing proc macro bugs easier.
Opening this as a sort of RFC, because I'm not totally sure this approach is the best.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
8866: Update salsa r=matklad a=jonas-schievink
This updates salsa to include https://github.com/salsa-rs/salsa/pull/265, and removes all cancellation-related code from rust-analyzer
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
According to the spec we should return ServerNotInitialized if the server is waiting for an initialize request and something else comes in.
Upgrading to lsp-server 0.5.1 will do this and retry until the initialize request comes in.
Fixes#8581
8570: Flycheck tries to parse both Cargo and Rustc messages. r=rickvanprim a=rickvanprim
This change allows non-Cargo build systems to be used for Flycheck provided they call `rustc` with `--error-format=json` and emit those JSON messages to `stdout`.
Co-authored-by: James Leitch <rickvanprim@gmail.com>
reading both stdout & stderr is a common gotcha, you need to drain them
concurrently to avoid deadlocks. Not sure why I didn't do the right
thing from the start. Seems like I assumed the stderr is short? That's
not the case when cargo spams `compiling xyz` messages
Bitflags is generally a good dependency -- it's lightweight, well
maintained and embraced by the ecosystem.
I wonder, however, do we really need it? Doesn't feel like it adds much
to be honest.
