8819: Use package root as `cargo check` working directory r=matklad a=bcully
Cargo commands are affected by the `.cargo/config` files above
their working directory. If cargo is invoked from above the directory
holding `Cargo.toml`, it may not pick up important settings like
registry replacements, causing it to behave differently or even fail.
Most cargo invocations are currently setting their working directories
to the directory containing `Cargo.toml`, but a couple of paths remain
in which cargo is invoked from the default workspace root instead.
This change fixes that, resolving some cargo check failures that I
experienced in a multi-root workspace in which packages used different
registries.
Co-authored-by: Brendan Cully <brendan@cully.org>
Fix#2922: add unknown length as a condition for a type having unknown.
Incorporate reviews:
* Extract some of the const evaluation workings into functions
* Add fixmes on the hacks
* Add tests for impls on specific array lengths (these work!!! 😁)
* Add tests for const generics (indeed we don't support it yet)
Cargo commands are affected by the `.cargo/config` files above
their working directory. If cargo is invoked from above the directory
holding `Cargo.toml`, it may not pick up important settings like
registry replacements, causing it to behave differently or even fail.
Most cargo invocations are currently setting their working directories
to the directory containing `Cargo.toml`, but a couple of paths remain
in which cargo is invoked from the default workspace root instead.
This change fixes that, resolving some cargo check failures that I
experienced in a multi-root workspace in which packages used different
registries.
8799: Add basic support for array lengths in types r=flodiebold a=lf-
This recognizes `let a = [1u8, 2, 3]` as having type `[u8; 3]` instead
of the previous `[u8; _]`. Byte strings and `[0u8; 2]` kinds of range
array declarations are unsupported as before.
I don't know why a bunch of our rustc tests had single quotes inside
strings un-escaped by `UPDATE_EXPECT=1 cargo t`, but I don't think it's
bad? Maybe something in a nightly?
Co-authored-by: Jade <software@lfcode.ca>
8802: Keep comments and attrs when extracting struct from enum variant r=Veykril a=DropDemBits
Fixes#6730
Still unsure if existing visibilities of fields should be forced to pub (which is what was previously done), or if it's okay to keep it in the extracted struct.
Co-authored-by: DropDemBits <r3usrlnd@gmail.com>
8812: fix: fix dependencies of build scripts r=jonas-schievink a=jonas-schievink
Previously, we added a dependency for all targets in a package to the package's library target. This is correct for most targets, except build scripts, which run before the library crate is built. This PR removes the incorrect dependency on the library target.
We also used to treat all dependencies the same, which led to build scripts being able to use regular dependencies as well as dev-dependencies. This is also fixed by this PR, and build scripts only depend on build-dependencies.
Incorrect dependency graph:
Fixed graph after this PR:
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
8808: fix: Fix fn proc macro input again r=jonas-schievink a=jonas-schievink
https://github.com/rust-analyzer/rust-analyzer/pull/8806 broke the `TokenMap`, so none of the tokens in fn-like proc macro inputs could be related to the output (presumably this is because of the `clone_for_update`).
This PR instead just sets `delimiter = None;` after the `TokenMap` and `Subtree` are already created.
We should probably have more tests for fn-like proc macros, and consider making the behavior consistent with MBE (which *require* the delimiters to be present).
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
8806: fix: Strip delimiter from fn-like macro invocations r=jonas-schievink a=jonas-schievink
This broke in https://github.com/rust-analyzer/rust-analyzer/pull/8796 (again), the fix is easy though
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
