-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crate system #14
Comments
Implementation sketch: pub struct Session {
options: Options, // compilation flags coming from CLI or similar: unstable options, etc.
crates: IndexVec<CrateIndex, Crate>, // `Crate` formerly `CrateScope`, now also contains crate metadata (version, …)
map: SourceMap, // maybe
errors: RefCell<Diagnostics>, // maybe, depends on our error handling strategy here
warnings: RefCell<Diagnostics>, // leave out for now
lowering: LoweringSession, // or similar: parallel lexing, parsing and lowering: contains queue of SourceFiles
} Also, I'd like to have methods/"queries" for Additionally, I'd like to see a more centralized error handling infrastructure like an |
Since crates won't be compilation boundaries for now, crates are just a new kind of entity for the name resolver (not totally since
There's a good chance that the index examples above are very error-prone since parts of the name resolver might access and use |
The package system of lushui.
extern
instead of crate declarations #49CrateIndex
should be renamed since with a crate system, it might get confused with numeric identifiers of cratesSuggestions:
DeclarationIndex
,DefinitionIndex
,ModuleLevelIndex
(which is what I intended them to be). So we should have a distinction between local and global indices or just use
global indices which consist of the index of the crate (the new
CrateIndex
) and a crate-local index (maybeDeclarationIndex
) namedGlobalDeclarationIndex
(maybe)crates separately since we cannot compile at all right now (no working byte code and no working compiler yet),
which means crates are not compilation units/boundaries (yet). Should we have multiple
CrateScope
s and put the intoa
Session
orProjectScope
? The way we register foreign and inherent bindings needs to change, too.new CLI-option--link <path>
which either links to a lushui file (in which case the dependency is a "single file/simple crate"and we assign it some default meta data i.e. its name (name of the file), its version (
0.0.0
?)) or to a folder with a config file init. We somehow need a way/design to refer to known locations (as env variables prob.) for example the equivalent of
target/
ornode_modules/
or the shared dependency folder$HOME/.lushui/shared-deps/
(…)Compilation making it the a unit of compilation (memory reduction)(only once we actually have a compilation mechanism, Bytecode backend #4)core
a package--unlink-core
libraries/core/
libs/core/
in this repositoryrenamesrc/
tocompiler/
The text was updated successfully, but these errors were encountered: