Commit Graph

1190 Commits

Author SHA1 Message Date
Laurențiu Nicola
b7368d34a6 Bump pulldown-cmark-to-cmark 2021-12-04 15:21:04 +02:00
Laurențiu Nicola
076f2247f2 Bump miow 2021-12-04 15:17:30 +02:00
Laurențiu Nicola
f2a1082c84 Bump countme 2021-12-04 15:14:31 +02:00
Laurențiu Nicola
26aba38168 Bump chalk 2021-12-04 15:08:43 +02:00
Laurențiu Nicola
89a1256f9a Bump most deps 2021-12-04 15:08:37 +02:00
Lukas Wirth
92f7db447c minor: Lift out FxIndex{Map/Set} types into ide_db 2021-11-16 12:15:47 +01:00
Laurențiu Nicola
e98b072da7 Bump chalk 2021-11-09 20:05:04 +02:00
Laurențiu Nicola
eb879ee06c Bump libc and paste 2021-11-09 20:03:48 +02:00
Laurențiu Nicola
d18a379c7b Bump deps 2021-11-06 17:40:38 +02:00
Laurențiu Nicola
80f9afa1ec Bump object avoid a duplicate dependency 2021-10-30 09:02:45 +03:00
bors[bot]
103bef178c
Merge #10650
10650: minor: Bump deps r=lnicola a=lnicola



Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
2021-10-29 20:27:51 +00:00
Laurențiu Nicola
d0a99ad54e Bump chalk 2021-10-29 23:26:59 +03:00
Laurențiu Nicola
79d3f61590 Bump some deps 2021-10-29 23:26:58 +03:00
Lukas Wirth
ebd63ec1cf feat: Make unqualified derive attributes flyimportable 2021-10-29 14:51:26 +02:00
bors[bot]
11326a6847
Merge #10387
10387: Move `IdxRange` into la-arena r=Veykril a=arzg

Currently, `IdxRange` (named `IdRange`) is located in `hir_def::item_tree`, when really it isn’t specific to `hir_def` and could become part of la-arena. The rename from `IdRange` to `IdxRange` is to maintain consistency with the naming convention used throughout la-arena (`Idx` instead of `Id`, `RawIdx` instead of `RawId`). This PR also adds a few new APIs to la-arena on top of `IdxRange` for convenience, namely:

- indexing into an `Arena` by an `IdxRange` and getting a slice of values back
- creating an `IdxRange` from an inclusive range

Currently this PR also exposes a new `Arena::next_idx` method to make constructing inclusive`IdxRange`s using `IdxRange::new` easier; however, it would in my opinion be better to remove this as it allows for easy creation of out-of-bounds `Idx`s, when `IdxRange::new_inclusive` mostly covers the same use-case while being less error-prone.

I decided to bump the la-arena version to 0.3.0 from 0.2.0 because adding a new `Index` impl for `Arena` turned out to be a breaking change: I had to add a type hint in `crates/hir_def/src/body/scope.rs` when one wasn’t necessary before, since rustc couldn’t work out the type of a closure parameter now that there are multiple `Index` impls. I’m not sure whether this is the right decision, though. 

Co-authored-by: Aramis Razzaghipour <aramisnoah@gmail.com>
2021-10-20 20:54:36 +00:00
bors[bot]
dfa355b431
Merge #10588
10588: internal: Parse const trait bounds r=Veykril a=Veykril

Fixes https://github.com/rust-analyzer/rust-analyzer/issues/10582
bors r+

Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
2021-10-19 12:32:30 +00:00
Lukas Wirth
b219a4c465 internal: Parse const trait bounds 2021-10-19 14:20:00 +02:00
Laurențiu Nicola
edb03ad6f1 Pull in new lsp-types for VS compat 2021-10-18 12:03:49 +03:00
Jeremy Kolb
14ddc3353e Update crates 2021-10-15 07:12:30 -04:00
Aramis Razzaghipour
dce5c640f8
Move IdxRange into la_arena 2021-10-15 13:03:28 +11:00
bors[bot]
1cca1fa5bf
Merge #10525
10525: Regenerate lints and features r=Veykril a=Veykril

bors r+

Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
2021-10-12 07:56:00 +00:00
Lukas Wirth
ed7c2948b3 Move lint source generator 2021-10-12 08:59:39 +02:00
Alex Muscar
41856e2682 fix: make signature info response conform to spec
This addreses
https://github.com/rust-analyzer/rust-analyzer/issues/10464.

This patch picks up `lsp-types` 0.90.1, which serialises the
`SignatureInformation` and `ParameterInformation` with the right casing.
It also adds `activeSignature` field as part of the top-level signature
response. It keeps `activeParameter` at the top-level for backwards
compatibility.
2021-10-11 20:42:16 +01:00
Aleksey Kladov
afacdd612d internal: update expect 2021-10-09 17:17:16 +03:00
Jonas Schievink
f8acae7895 Support let...else 2021-10-07 17:06:24 +02:00
bors[bot]
f30b62b751
Merge #10479
10479: fix: fix "index out of bounds" panic in name resolution r=jonas-schievink a=jonas-schievink

Closes https://github.com/rust-analyzer/rust-analyzer/issues/10084
Closes https://github.com/rust-analyzer/rust-analyzer/issues/9163

This is really just a salsa update to a version that removes the problematic code (see https://github.com/rust-analyzer/rust-analyzer/issues/10084#issuecomment-934445711)

bors r+

Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
2021-10-06 20:54:27 +00:00
Jonas Schievink
cda9668289 Update salsa 2021-10-06 22:42:54 +02:00
Lukas Wirth
fb27c58a04 Update Cargo.lock 2021-10-06 22:34:55 +02:00
Lukas Wirth
454ecd167c Make multiple import edits work for completions 2021-10-04 21:44:33 +02:00
Laurențiu Nicola
035cb443aa Bump notify 2021-10-01 18:57:04 +03:00
Laurențiu Nicola
ffa8270f6a Bump memmap2 2021-10-01 18:55:52 +03:00
Laurențiu Nicola
34adcc800c Bump libc 2021-10-01 18:51:45 +03:00
Laurențiu Nicola
193a926d45 Bump deps 2021-10-01 18:50:52 +03:00
bors[bot]
ee12b0f173
Merge #10181
10181: Begining of lsif r=HKalbasi a=HKalbasi

This PR adds a `lsif` command to cli, which can be used as `rust-analyzer lsif /path/to/project > dump.lsif`. It now generates a valid, but pretty useless lsif (only supports folding ranges). The propose of this PR is to discussing about the structure of lsif generator, before starting anything serious.

cc `@matklad` #8696 #3098


Co-authored-by: hamidreza kalbasi <hamidrezakalbasi@protonmail.com>
2021-09-29 13:13:03 +00:00
Aleksey Kladov
2bf81922f7 internal: more reasonable grammar for blocks
Consider these expples

        { 92 }
  async { 92 }
    'a: { 92 }
   #[a] { 92 }

Previously the tree for them were

  BLOCK_EXPR
    { ... }

  EFFECT_EXPR
    async
    BLOCK_EXPR
      { ... }

  EFFECT_EXPR
    'a:
    BLOCK_EXPR
      { ... }

  BLOCK_EXPR
    #[a]
    { ... }

As you see, it gets progressively worse :) The last two items are
especially odd. The last one even violates the balanced curleys
invariant we have (#10357) The new approach is to say that the stuff in
`{}` is stmt_list, and the block is stmt_list + optional modifiers

  BLOCK_EXPR
    STMT_LIST
      { ... }

  BLOCK_EXPR
    async
    STMT_LIST
      { ... }

  BLOCK_EXPR
    'a:
    STMT_LIST
      { ... }

  BLOCK_EXPR
    #[a]
    STMT_LIST
      { ... }
2021-09-26 19:16:09 +03:00
hamidreza kalbasi
13d36e96c2 use crates io version 2021-09-26 10:39:23 +03:30
hamidreza kalbasi
70061d2b7e move lsif types to lsp types crate 2021-09-26 10:04:02 +03:30
Lukas Wirth
42eb4efb5b Cleanup 2021-09-23 16:28:03 +02:00
Lukas Wirth
a6dde501df Only strip derive attributes when preparing macro input 2021-09-19 23:38:38 +02:00
Giles Cope
15312aab58
removing seemingly unused dev deps. 2021-09-11 16:26:36 +01:00
Giles Cope
4ccd90af81
remove unused deps 2021-09-11 16:20:04 +01:00
Laurențiu Nicola
c930dcca13 Bump chalk 2021-09-09 21:12:38 +03:00
Laurențiu Nicola
968000ee96 Bump deps 2021-09-09 21:09:57 +03:00
Aleksey Kladov
dbb702cfc1 internal: remove accidental code re-use
FragmentKind played two roles:

* entry point to the parser
* syntactic category of a macro call

These are different use-cases, and warrant different types. For example,
macro can't expand to visibility, but we have such fragment today.

This PR introduces `ExpandsTo` enum to separate this two use-cases.

I suspect we might further split `FragmentKind` into `$x:specifier` enum
specific to MBE, and a general parser entry point, but that's for
another PR!
2021-09-05 22:36:36 +03:00
Jade
1857b2b5d6 Update dependency minor versions 2021-09-04 00:27:05 -07:00
Jonas Schievink
8969cbb22f Depend on both crates individually 2021-08-31 13:10:16 +02:00
Jonas Schievink
e6255356d2 Fix DNF construction, add proptest 2021-08-30 22:26:35 +02:00
Dezhi Wu
ba0947dded switch log crate to tracing 2021-08-30 15:11:42 +08:00
bors[bot]
10e9408d38
Merge #10066
10066: internal: improve compile times a bit r=matklad a=matklad

I wanted to *quickly* remove `smol_str = {features = "serde"}`, and figured out that the simplest way to do that is to replace our straightforward proc macro serialization with something significantly more obscure. 

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2021-08-28 20:38:58 +00:00
Aleksey Kladov
c639fe333f internal: improve compilation critical path a bit 2021-08-28 22:43:37 +03:00
Aleksey Kladov
0dabcf0044 remove unused serde feature from smol_str 2021-08-28 22:43:37 +03:00
Lukas Wirth
1195cb50c2 Add simple test for syntax_node_to_token_tree_censored 2021-08-25 19:57:18 +02:00
Lukas Wirth
d6134b6802 Don't mutate syntax trees when preparing proc-macro input 2021-08-25 18:57:24 +02:00
Lukas Wirth
d38380715a ⬆️ rowan 2021-08-23 23:22:31 +02:00
Aleksey Kladov
3f2add81fc ⬆️ rowan
This pulls in https://github.com/rust-analyzer/rowan/pull/111, which
fixes a bug in green node hash, making it more efficient.

On analysis stats, total memory goes from 1271mb to 1244mb, instructions
from 358ginstr to 353ginstr (not 100% clear on this one -- for some
reasons instruction counts are not stable for me anymore).

The counts are (before, than after):

rowan::green::node::GreenNode       11_490_596    2_357_063    2_233_347
rowan::green::token::GreenToken      5_010_401      994_281      991_920

rowan::green::node::GreenNode        9_738_085    1_988_164    1_890_549
rowan::green::token::GreenToken      3_353_409      687_333      685_831
                                         total     max_live         live
2021-08-23 21:15:44 +03:00
Laurențiu Nicola
e6d78834dd Bump deps 2021-08-23 13:25:59 +03:00
Aleksey Kladov
c044493434 ⬆️ rowan
Just so we don't live on a per-release
2021-08-23 12:10:49 +03:00
Aleksey Kladov
e86388689f internal: remove unreasonable crate dependency
Proc macro expansion shouldn't know about salsa at all.
2021-08-22 14:05:12 +03:00
Aleksey Kladov
881d71a489 internal: reduce crate interdependence
I don't think there's anything wrong with project_model depending on
proc_macro_api directly -- fundamentally, both are about gluing our pure
data model to the messy outside world.

However, it's easy enough to avoid the dependency, so why not.

As an additional consideration, `proc_macro_api` now pulls in `base_db`.
project_model should definitely not depend on that!
2021-08-22 13:32:00 +03:00
Alexander Sieg
7bf19f9842 rebuild Cargo.lock 2021-08-17 17:27:37 +02:00
Alexander Sieg
ca6a1d8c63 Revert "Downgrade notify and use RecommendedWatcher"
This reverts commit 5b0c86af7d.

The pre-5.0.12 release of notify fixed this issue.
2021-08-17 17:17:13 +02:00
Aleksey Kladov
92da7e9ffa internal: optimize compile time
cargo llvm-lines shows that path_to_error bloats the code. I don't think
I've needed this functionality recently, seems that we've fixed most of
the serialization problems. So let's just remove it. Should be easy to
add back if we ever need it, and it does make sense to keep the
`from_json` function around.
2021-08-15 13:24:37 +03:00
Jeremy Kolb
ddf23abfef cargo update 2021-08-13 11:08:24 -04:00
Jonas Schievink
d568e7686a Support if let match guards 2021-08-13 00:25:14 +02:00
Aleksey Kladov
3e5b155716 fix: avoid pathological macro expansions
Today, rust-analyzer (and rustc, and bat, and IntelliJ) fail badly on
some kinds of maliciously constructed code, like a deep sequence of
nested parenthesis.

"Who writes 100k nested parenthesis" you'd ask?

Well, in a language with macros, a run-away macro expansion might do
that (see the added tests)! Such expansion can be broad, rather than
deep, so it bypasses recursion check at the macro-expansion layer, but
triggers deep recursion in parser.

In the ideal world, the parser would just handle deeply nested structs
gracefully. We'll get there some day, but at the moment, let's try to be
simple, and just avoid expanding macros with unbalanced parenthesis in
the first place.

closes #9358
2021-08-09 16:15:02 +03:00
Florian Diebold
16ab75a83a Upgrade Chalk 2021-08-07 13:12:35 +02:00
bors[bot]
4b0c97668c
Merge #9772
9772: feat: filter out duplicate macro completions r=matklad a=matklad

bors r+
🤖

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2021-08-03 14:37:25 +00:00
Aleksey Kladov
2f9273633b feat: filter out duplicate macro completions
closes #9303
2021-08-03 17:36:06 +03:00
Laurențiu Nicola
5b0c86af7d Downgrade notify and use RecommendedWatcher 2021-08-03 14:33:37 +03:00
Laurențiu Nicola
90e05ba57e Bump deps 2021-07-31 11:25:03 +03:00
Aleksey Kladov
89d4b9a95a ⬆️ crates 2021-07-31 10:25:13 +03:00
Lukas Wirth
b537cb186e Use more strictly typed syntax nodes for analysis in extract_function assist 2021-07-29 17:26:37 +02:00
Laurențiu Nicola
d9ec9d95c5 Bump deps 2021-07-24 11:16:32 +03:00
bors[bot]
0bee7cb716
Merge #9453
9453: Add first-class limits. r=matklad,lnicola a=rbartlensky

Partially fixes #9286.

This introduces a new `Limits` structure which is passed as an input
to `SourceDatabase`. This makes limits accessible almost everywhere in
the code, since most places have a database in scope.

One downside of this approach is that whenever you query limits, you
essentially do an `Arc::clone` which is less than ideal.

Let me know if I missed anything, or would like me to take a different approach!

Co-authored-by: Robert Bartlensky <bartlensky.robert@gmail.com>
2021-07-22 10:33:05 +00:00
Aleksey Kladov
b0c4b776b5 internal: add simple smoke test for project model
Our project model code is rather complicated -- the logic for lowering
from `cargo metadata` to `CrateGraph` is fiddly and special-case. So
far, we survived without testing this at all, but this increasingly
seems like a poor option.

So this PR introduces a simple tests just to detect the most obvious
failures. The idea here is that, although we rely on external processes
(cargo & rustc), we are actually using their stable interfaces, so we
might just mock out the outputs.

Long term, I would like to try to virtualize IO here, so as to do such
mocking in a more principled way, but lets start simple.

Should we forgo the mocking and just call `cargo metadata` directly
perhaps? Touch question -- I personally feel that fast, in-process tests
are more important in this case than any extra assurance we get from
running the real thing.

Super-long term, we would probably want to extend our heavy tests to
cover more use-cases, but we should figure a way to do that without
slowing the tests down for everyone.

Perhaps we need two-tiered bors system, where we pull from `master` into
`release` branch only when an additional set of tests passes?
2021-07-20 16:23:57 +03:00
Aleksey Kladov
e20a1a4e4e minor: publish la_arena 2021-07-20 14:33:08 +03:00
bors[bot]
c595676f7e
Merge #9625
9625: internal: simplify handling of the build scripts r=matklad a=matklad



Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2021-07-19 15:28:36 +00:00
Robert Bartlensky
0b3d0cde8b Add Limit struct.
Fixes #9286.
2021-07-19 13:26:11 +01:00
bors[bot]
ea105f9396
Merge #9619
9619: Support GATs for associated type arg parsing r=Veykril a=Veykril

Fixes #9602

Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
2021-07-18 09:10:56 +00:00
Lukas Wirth
e7aa37c20a Support GATs for associated type arg parsing 2021-07-18 11:08:43 +02:00
Aleksey Kladov
f4de2ece0d internal: simplify handling of the build scripts 2021-07-18 11:29:22 +03:00
Aleksey Kladov
8d8c26e6f5 internal: a bit more of cwd safety for flycheck 2021-07-17 18:13:35 +03:00
Aleksey Kladov
8df38aa797 internal: make sure that proc macro machinery doesn't depend on cwd 2021-07-17 17:55:16 +03:00
Laurențiu Nicola
df729eda69 Bump chalk 2021-07-10 18:58:14 +03:00
Laurențiu Nicola
861f1e2a86 Bump rustc_lexer a little 2021-07-10 18:57:59 +03:00
Laurențiu Nicola
932d4183a1 Bump deps 2021-07-10 18:55:01 +03:00
kjeremy
35016c772c cargo_metadata 0.14
Removes the following dependent crates:
* semver-parser
* pest
* ucd-trie

Removes project_model's dependency on itertools
2021-07-09 11:01:55 -04:00
Aleksey Kladov
90e27d6289 internal: make xtask lighter
Moving tests to `rust-analyzer` crate allows removing walkdir dependency
from `xtask`. It does seem more reasonable to keep tidy tests outside of
the "build system" and closer to other integration tests.
2021-07-04 12:47:56 +03:00
Aleksey Kladov
58d2ece88a internal: overhaul code generation
* Keep codegen adjacent to the relevant crates.
* Remove codgen deps from xtask, speeding-up from-source installation.

This regresses the release process a bit, as it now needs to run the
tests (and, by extension, compile the code).
2021-07-03 22:11:03 +03:00
kjeremy
bf7651886e Cargo update and pull in the new rowan
This brings in the new hashbrown for better compile times.
2021-06-30 10:03:31 -04:00
kjeremy
5b6e168928 Update crates 2021-06-22 13:18:48 -04:00
kjeremy
a1aba2e8cc cargo update 2021-06-18 14:32:02 -04:00
Aleksey Kladov
06f5d6f640 internal: don't pull tracing via chalk 2021-06-14 20:41:08 +03:00
Aleksey Kladov
a91071b57b internal: cut deps between assists and diagnostics 2021-06-14 17:45:17 +03:00
Aleksey Kladov
1d2772c2c7 internal: move diagnostics to a new crate 2021-06-14 17:45:17 +03:00
Aleksey Kladov
3d2f0400a2 internal: start ide diagnostics crate 2021-06-14 17:45:17 +03:00
Aleksey Kladov
0463d76a1f internal: cross-crate cov-marks 2021-06-12 23:40:52 +03:00
Aleksey Kladov
6f0141a140 minor: optimize
We shouldn't be looking at the source map unless we actually have
diagnostics.
2021-06-12 17:49:41 +03:00
bors[bot]
409f5fb563
Merge #9204
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>
2021-06-11 22:00:23 +00:00
Jonas Schievink
74dc9bb0e9 Update libc 2021-06-11 23:55:27 +02:00