alexfertel
commented
6 months ago This looks very promising! Thanks for such an effort.
Reading the code made me realize that we might be able to do something simpler: What if we parallelized the inner phases? That is, we currently roughly have the following compiler pipeline:
.tree -> &str -> scaffold entrypoint -> tokenize & parse -> semantic analysis -> HIR -> PT -> emit The above works for one (1) tree. Would you be willing to try feeding each separate tree to the pipeline? You would only touch two points in the pipeline:
.tree -> &str -> split input -> scaffold entrypoint -> ... -> HIR -> Combine -> PT -> emit
^^^^^^^^^^^ ^^^^^^^Which ends up looking like:
scaffold entrypoint -> ... -> Hir
/ \
.tree -> &str -> split input -> scaffold entrypoint -> ... -> Hir -> Combine -> PT -> emit
\ /
scaffold entrypoint -> ... -> Hir Where the split is a simple:
let trees = tree.split("\n\n").collect::<Vec<_>>();And the Combine phase looks similar to what you have.
If this makes sense to you I think it would simplify a lot. Wdyt?
On the other hand, I think the combine step is a good place for verifying that all the trees have the same contract name 👌🏻
giovannidisiena
codecov[bot]
WIP attempt at handling multiple trees per
.treefile. Currently, it appears I have broken some of the existing tests but I'm not yet sure how/why.Steps taken:
TokenKind::Root.hir::translatewhencheck::context::Contextis created since check mostly works with parse trees derived from HIRs.@alexfertel it would be great to get some initial feedback here, when you get some time please, to make sure I'm not completely barking up the wrong tree or making too much of a mess. I have left a few
follow-upcomments for both my and your benefit - I'm sure there's lots here that could be improved or otherwise written in a more idiomatic fashion so please do let me know where that is the case as I'm definitely still getting to grips with Rust!Partially closes #50.