Start item tree #3720
Start item tree #3720
Conversation
|
Looks like this can subsume our |
|
Data-driven design) |
crates/ra_hir_def/src/item_tree.rs
Outdated
| } | ||
|
|
||
| pub struct Static { | ||
| /// const _: () = (); |
matklad
force-pushed
the
item-tree
branch
2 times, most recently
from
6a7fdc1 to
9cbae00
Compare
|
One thing I am unsure about is how to add handle children. The first way is struct Tree {
structs: Arena<Struct>,
}
struct Struct {
fields: Arena<Field>
}The second way is struct Tree {
structs: Arena<Struct>,
fields: Arena<Field>,
}
struct Struct {
fields: Range<Idx<Field>>
}The advantage of the first approach is that the id of field is local to struct. Adding a new field does not shift other structs. The second scheme is the opposite. However, the second scheme seems to be simpler and more efficient (if we discount potential incrementality benefits). In particular, handling sources would be easier. 9cbae00 implements the first version, but I think I'll switch it to the second one. |
|
@flodiebold do you have any thoughts on #3720 (comment) ? |
|
Hmm I'd have thought the incrementality benefits are kind of important... But I guess it really only makes a difference in the moment where one adds a new field somewhere, so it probably doesn't matter that much. And I like the uniformity of the second approach. |
Yeah, that's why I've started with a nested approach... OTOH, I think incrementality should not really matter in this case: for crate def map, we'll need projection query anyway, for individual items the recompute should not be too bad. Also, super-long term I actually want to see only single global vector for all entities, and using interning to achieve stable indexes ... somehow. |
| pub is_macro_use: bool, | ||
| } | ||
|
|
||
| pub struct Function { |
There was a problem hiding this comment.
Shouldn't we store unsafety and asynchrony modifiers for Function and unsafety for Trait and Impl?
| pub export: bool, | ||
| pub builtin: bool, |
There was a problem hiding this comment.
I'd suggest unifying the booleans naming, e.g. in Import we use is_*, but here we don't
|
|
||
| fn desugar_future_path(orig: TypeRef) -> Path { | ||
| let path = path![std::future::Future]; | ||
| let mut generic_args: Vec<_> = std::iter::repeat(None).take(path.segments.len() - 1).collect(); |
There was a problem hiding this comment.
| let mut generic_args: Vec<_> = std::iter::repeat(None).take(path.segments.len() - 1).collect(); | |
| let mut generic_args = vec![None; path.segments.len() - 1]; |
matklad
force-pushed
the
item-tree
branch
2 times, most recently
from
1a1cf63 to
d4908d5
Compare
|
Status update: got sidetracked :( |
|
Closing due to inactivity, although this is something we absolutely have to do eventually ;-( My current plan is to nerd-snipe @jonas-schievink into taking over this :-) |
Fix libc::read shim: make it write to a buffer correct amount of bytes. Add tests for new behavior libc::read shim had a bug: if underlying real call libc::read(fd, buf, N) returns M, then libc::read shim writes N bytes to buf instead of M. Remaining N - M bytes are filled with zeros. This commit fixes this bug and adds tests for new behavior
No description provided.