bors[bot] [Wed, 12 May 2021 14:49:43 +0000 (14:49 +0000)]
Merge #8799
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?
bors[bot] [Wed, 12 May 2021 14:42:01 +0000 (14:42 +0000)]
Merge #8802
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.
bors[bot] [Wed, 12 May 2021 13:22:23 +0000 (13:22 +0000)]
Merge #8812
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.
bors[bot] [Tue, 11 May 2021 23:05:07 +0000 (23:05 +0000)]
Merge #8808
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>
bors[bot] [Tue, 11 May 2021 17:47:45 +0000 (17:47 +0000)]
Merge #8796
8796: internal: rewrite `#[derive]` removal to be based on AST (take 2) r=jonas-schievink a=jonas-schievink
Second attempt of https://github.com/rust-analyzer/rust-analyzer/pull/8443, this uses syntactical attribute offsets in `hir_expand`, and changes `attr.rs` to make those easy to derive.
This will make it easy to add similar attribute removal for attribute macros, unblocking them.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
Jade [Tue, 11 May 2021 12:06:33 +0000 (05:06 -0700)]
Add basic support for array lengths in types
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?
bors[bot] [Mon, 10 May 2021 20:10:59 +0000 (20:10 +0000)]
Merge #8794
8794: Give MergeBehaviour variants better names r=Veykril a=Veykril
I never really liked the variant names I gave this enum from the beginning and then I found out about rustfmt's `imports_granularity` config:
> imports_granularity
>
> How imports should be grouped into use statements. Imports will be merged or split to the configured level of granularity.
>
> Default value: Preserve
> Possible values: Preserve, Crate, Module, Item
> Stable: No
I personally prefer using `crate` over `full` and `module` over last, they seem more descriptive. Keeping these similar between tooling also seems like a good plus point to me.
We might even wanna take over the entire enum at some point if we have a `format/cleanup imports` assists in the future which would probably want to also have the `preserve` and `item` options.
Aleksey Kladov [Sun, 9 May 2021 16:51:06 +0000 (19:51 +0300)]
internal: introduce `ast::make::ext` module with common shortcuts
There's a tension between keeping a well-architectured minimal
orthogonal set of constructs, and providing convenience functions.
Relieve this pressure by introducing an dedicated module for
non-orthogonal shortcuts.
This is inspired by the django.shortcuts module which serves a similar
purpose architecturally.
bors[bot] [Sun, 9 May 2021 14:40:49 +0000 (14:40 +0000)]
Merge #8776
8776: fix: fix unnecessary recomputations due to macros r=jonas-schievink a=jonas-schievink
This computes a macro's fragment kind eagerly (when the calling file is still available in parsed form) and stores it in the `MacroCallLoc`. This means that during expansion we no longer have to reparse the file containing the macro call, avoiding the unnecessary salsa dependencies (https://github.com/rust-analyzer/rust-analyzer/pull/8746#issuecomment-834776349).
Marking as draft until I manage to find a test for this problem, since for some reason `typing_inside_a_function_should_not_invalidate_expansions` does not catch this (which might indicate that I misunderstand the problem).
I've manually confirmed that this fixes the issue described in https://github.com/rust-analyzer/rust-analyzer/pull/8746#issuecomment-834776349:
Implements `cargo/.config` build target and cfg access by using unstable cargo options:
- `cargo config get` to read the target triple out of the config to pass to `cargo metadata` --filter-platform
- `cargo rustc --print` to read out the `rustc_cfgs`, this causes us to honor `rustflags` and the like.
If those commands fail, due to not having a nightly toolchain present for example, they will fall back to invoking rustc directly as we currently do.
I personally think it should be fine to use these unstable options as they are unlikely to change(even if they did it shouldn't be a problem due to the fallback) and don't burden the user if they do not have a nightly toolchain at hand since we fall back to the previous behaviour.
cc #8741
Closes #6604, Closes #5904, Closes #8430, Closes #8480
projects / rust.git / log