Commit graph

3786 commits

Author SHA1 Message Date
Sergey Parilin
993abedd77 apply T! macro where it is possible 2019-05-15 15:35:47 +03:00
Sergey Parilin
d77175ce28 fixed macro for brackets 2019-05-15 12:34:48 +03:00
bors[bot]
64ab5ab10d Merge #1273
1273: show current function in analysis-stats progress bar r=matklad a=matklad



Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2019-05-14 06:59:09 +00:00
Aleksey Kladov
d4b1e958c5 show current function in analysis-stats progress bar 2019-05-14 09:58:41 +03:00
bors[bot]
c417c77b68 Merge #1267
1267: Macro expand to r=edwin0cheng a=matklad

closes #1264 

The core problem this PR is trying to wrangle is that macros can expand to different stuffs, depending on context. 

That is, `foo!()` on the top-level expands to a list of items, but the same `foo!()` in expression position expands to expression.

Our current `hir_parse(HirFileId) -> TreeArc<SourceFile>` does not really support this. 

So, the plan is to change `hir_parse` to untyped inreface (`TreeArc<Syntaxnode>`), and add `expands_to` field to `MacroCallLoc`, such that the *target* of macro expansion is selected by the calling code and is part of macro id. 

This unfortunately looses some type-safety :( 


Moreover, this doesn't really fix #1264 by itself, because we die due to some other error inside macro expansion: expander fails to produce a tree with a single root, which trips assert inside rowan.

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2019-05-14 06:12:09 +00:00
Aleksey Kladov
caa8663c08 allow expanding expressions 2019-05-14 09:03:43 +03:00
Aleksey Kladov
16c7405262 expand to syntax node 2019-05-14 09:03:43 +03:00
Aleksey Kladov
101b3abfd7 store macro kind in HirFileId 2019-05-14 09:03:43 +03:00
bors[bot]
ee0ab7c00b Merge #1272
1272: Error out non single root token tree conversion r=matklad a=edwin0cheng

This PR add a check to prevent non single root token tree conversion between token trees and syntax tree.

It should prevent the assert produced in #1267.

Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
2019-05-14 05:41:23 +00:00
Edwin Cheng
10ecb11ff5 Error out non single root token tree conversion 2019-05-14 07:59:28 +08:00
bors[bot]
bebc5c7166 Merge #1271
1271: make AstId untyped r=matklad a=matklad



Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2019-05-13 21:04:04 +00:00
bors[bot]
d7a4ae43f9 Merge #1270
1270: Increase Chalk solver max_size back to 4 r=flodiebold a=flodiebold

Reducing it to 2 was just a failed attempt to see whether that would help fix
some slow cases; in fact, it can create new slow cases by replacing concrete
types by variables.

Co-authored-by: Florian Diebold <flodiebold@gmail.com>
2019-05-13 20:23:09 +00:00
Florian Diebold
c29a692137 Increase Chalk solver max_size back to 4
Reducing it to 2 was just a failed attempt to see whether that would help fix
some slow cases; in fact, it can create new slow cases by replacing concrete
types by variables.
2019-05-13 22:20:39 +02:00
Aleksey Kladov
549728bba8 make AstId untyped 2019-05-13 19:39:06 +03:00
bors[bot]
033a32f349 Merge #1257
1257: Implemented tkn! macro for syntax kinds r=matklad a=pasa

Implementation of #1248

Co-authored-by: Sergey Parilin <sergey.parilin@fxdd.com>
2019-05-13 13:49:14 +00:00
Sergey Parilin
57bb618fd3 Implemented T! macro for syntax kinds 2019-05-13 15:19:57 +03:00
bors[bot]
b22614f0b5 Merge #1268
1268: simplify r=matklad a=matklad



Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2019-05-12 20:05:45 +00:00
Aleksey Kladov
9cba67b2ad simplify 2019-05-12 23:03:37 +03:00
Aleksey Kladov
98531dc785 simplify 2019-05-12 22:51:03 +03:00
bors[bot]
0f57564f78 Merge #1266
1266: Chalk integration / method resolution fixes r=matklad a=flodiebold

 - fix impl blocks with unresolved target trait being treated as inherent impls
 - add traits from prelude for method resolution, and deduplicate them
 - blacklist some traits from being considered in where clauses, namely `Send`, `Sync`, `Sized`, and the `Fn` traits. We don't handle these correctly yet for several reasons, and this makes us much less likely to run into cases where Chalk gets very slow (because these usually only happen if there is no solution, and that's more likely to happen for these traits).
 - when there's an errored where clause, return just that one (since it will be always false anyway). This also makes things easier on Chalk ;)

Co-authored-by: Florian Diebold <flodiebold@gmail.com>
2019-05-12 18:36:36 +00:00
Florian Diebold
bc59f83991 Use traits from prelude for method resolution 2019-05-12 20:25:26 +02:00
Florian Diebold
7fda874dd4 Blacklist some traits from being considered in where clauses
For Send/Sync/Sized, we don't handle auto traits correctly yet and because they
have a lot of impls, they can easily lead to slowdowns. In the case of
Fn/FnMut/FnOnce, we don't parse the special Fn notation correctly yet and don't
handle closures yet, so we are very unlikely to find an impl.
2019-05-12 20:23:57 +02:00
Florian Diebold
c8b85891b0 Fix impl blocks with unresolved target trait being treated as inherent impls 2019-05-12 20:21:45 +02:00
bors[bot]
02ba107bbf Merge #1265
1265: drop obsolete render test subcommand r=matklad a=matklad



Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2019-05-12 18:01:28 +00:00
Aleksey Kladov
8ee2926aa2 drop obsolete render test subcommand 2019-05-12 21:00:04 +03:00
Aleksey Kladov
915489714b allow to specify path in analysis-stats 2019-05-12 20:54:44 +03:00
bors[bot]
1944fc2c2b Merge #1262
1262: Where clauses and other Chalk improvements r=matklad a=flodiebold

This adds support for where clauses to the Chalk integration; it also adds FnDef lowering and partly handles auto traits.

One thing I'm not sure about is the error handling -- what do we do if we can't
resolve a trait reference in a where clause? For impls, I think it's clear we
need to disregard the impl for trait solving. I've solved this for now by
introducing an 'unknown trait' that has no impls, so if we encounter an unknown
trait we can use that and basically get a where clause that's always false. (The
alternative would be somehow not returning the impl to Chalk at all, but we
would need to know that we need to do that in `impls_for_trait` already, and we
don't resolve anything there.)

A bit surprisingly, this has almost no impact on the type inference stats for RA, probably because of missing edge cases. Probably impl Trait support and closure support will do more.

Co-authored-by: Florian Diebold <flodiebold@gmail.com>
2019-05-12 17:45:34 +00:00
Florian Diebold
cbe75676b9 Add support for inline bounds
E.g. impl<T: Clone> Foo for T.
2019-05-11 16:56:36 +02:00
Florian Diebold
d6dc75f9f2 Handle auto traits & negative impls
We don't pass field types to Chalk yet though, so the auto trait inference won't
be correct.
2019-05-11 16:21:20 +02:00
Florian Diebold
7744cd41e2 Reduce Chalk max_size parameter, add test for slow case 2019-05-11 16:21:20 +02:00
Florian Diebold
d8cd0e36f5 Handle Chalk conversion for FnDef 2019-05-11 16:21:20 +02:00
Florian Diebold
58b68966bf Handle resolution errors in where clauses
This is slightly hacky, but maybe more elegant than alternative solutions: We
just use a hardcoded Chalk trait ID which we special-case to have no impls.
2019-05-11 16:21:20 +02:00
Florian Diebold
50bbf9eb09 Handle where clauses in trait solving 2019-05-11 16:21:20 +02:00
bors[bot]
940c538ecf Merge #1258
1258: cargo update r=matklad a=kjeremy



Co-authored-by: Jeremy Kolb <kjeremy@gmail.com>
2019-05-11 14:06:59 +00:00
bors[bot]
f7f64cf24e Merge #1261
1261: add manual installation instructions r=matklad a=matklad



Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2019-05-11 11:23:14 +00:00
Aleksey Kladov
2c0f4172e4 add manual installation instructions 2019-05-11 14:22:44 +03:00
Jeremy Kolb
e2b3862c0b cargo update 2019-05-09 08:45:01 -04:00
bors[bot]
6ceaea9e95 Merge #1255
1255: switch to once_cell from lazy_static r=matklad a=matklad



Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2019-05-07 17:54:57 +00:00
Aleksey Kladov
1667b5cf52 switch to once_cell from lazy_static 2019-05-07 20:54:33 +03:00
bors[bot]
70cd5ffbf5 Merge #1251
1251: Chalk integration improvements r=matklad a=flodiebold

A few improvements that came up while working on where clause support:
 - turn `implements` into a query again to improve performance
 - allow skipping to a specific function with `analysis-stats`, e.g. `ra_cli analysis-stats --only world_symbols`
 - deduplicate impls in impls_for_trait -- previously many impls e.g. from std where repeated many times, this should help performance as well...
 - add a `HirDisplay` implementation for TraitRef (not used here anywhere, but useful for debugging)

Co-authored-by: Florian Diebold <flodiebold@gmail.com>
2019-05-07 17:37:47 +00:00
bors[bot]
d3efedb752 Merge #1253
1253: Share literal validation logic with compiler r=matklad a=matklad

This is neat: the unescape module is literary what compiler is using right now:

c6ac575648/src/libsyntax/parse/unescape.rs

So, yeah, code sharing via copy-paste!



Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2019-05-07 16:43:10 +00:00
Aleksey Kladov
313314e14b share literal validation logic with compiler 2019-05-07 19:41:59 +03:00
Florian Diebold
530b3047ed Deduplicate impls in impls_for_trait
This was duplicating impls in dependencies a lot...
2019-05-07 13:45:29 +02:00
Florian Diebold
880ef25a9e Allow targeting a specific function with analysis-stats
This can be useful for debugging.
2019-05-07 13:45:29 +02:00
Florian Diebold
4083caa233 Add a HirDisplay implementation for TraitRef 2019-05-07 13:45:29 +02:00
Florian Diebold
a78228a39c Turn implements into a query again 2019-05-07 13:45:29 +02:00
bors[bot]
ef782adc29 Merge #1163
1163: fill struct fields diagnostic r=matklad a=pasa

implementation of #1095

Co-authored-by: Sergey Parilin <sergey.parilin@fxdd.com>
2019-05-06 14:27:34 +00:00
Sergey Parilin
12f8472d28 removed duplicating fill_struct_fields assist 2019-05-06 17:26:09 +03:00
Sergey Parilin
26ed925685 fill struct fields diagnostic 2019-05-06 17:16:11 +03:00
bors[bot]
32db5884ad Merge #1247
1247: Remove collect r=matklad a=kjeremy

Might help with perf

Co-authored-by: Jeremy Kolb <kjeremy@gmail.com>
2019-05-05 17:32:18 +00:00