Dummy std lib

[g-r-a-n-t]

What was wrong?

We don't have a standard library.

How was it fixed?

A library ingot named std gets added to the global scope during compilation. It currently contains dummy code, which we'll replace once low-level intrinsics are supported.

To-Do

• OPTIONAL: Update Spec if applicable
• Add entry to the release notes (may forgo for trivial changes)
• Clean up commit history

[codecov-commenter]

Codecov Report

Merging #601 (c14701e) into master (98967b5) will increase coverage by 0.04%.
The diff coverage is 86.44%.

@@            Coverage Diff             @@
##           master     #601      +/-   ##
==========================================
+ Coverage   86.55%   86.60%   +0.04%     
==========================================
  Files          96       96              
  Lines        8229     8371     +142     
==========================================
+ Hits         7123     7250     +127     
- Misses       1106     1121      +15     

Impacted Files	Coverage Δ
crates/analyzer/src/db.rs	100.00% <ø> (ø)
crates/parser/src/ast.rs	88.75% <ø> (ø)
crates/analyzer/src/namespace/scopes.rs	76.31% <50.00%> (-1.24%)	⬇️
crates/analyzer/src/db/queries/module.rs	90.60% <83.87%> (+2.23%)	⬆️
crates/analyzer/src/namespace/items.rs	81.29% <84.53%> (+2.36%)	⬆️
crates/analyzer/src/db/queries/ingots.rs	97.91% <96.66%> (+1.14%)	⬆️
crates/analyzer/src/traversal/expressions.rs	82.11% <100.00%> (+0.02%)	⬆️
crates/common/src/files.rs	86.56% <100.00%> (+2.93%)	⬆️
crates/driver/src/lib.rs	73.49% <100.00%> (-2.34%)	⬇️
crates/lowering/src/ast_utils.rs	84.06% <100.00%> (ø)
... and 3 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 98967b5...c14701e. Read the comment docs.

[g-r-a-n-t]

@sbillig lint is failing on some new conditions, but everything else is good, so feel free to take a look. Ill fix the clippy stuff before merging

[sbillig]

@g-r-a-n-t I'm trying to build on this, and running into trouble. If I add files to library/std/src, they get picked up in the Dir file list, but don't become child items of std.

Eg. added library/std/src/evm.fe and library/std/src/foo/bar.fe; use std::evm::self_balance and use std::foo:bar::baz fail with "unresolved path item" on evm and foo respectively

[g-r-a-n-t]

@sbillig huh, Ill look into it later today. I think it might be related to a change in the ingot_all_modules query

[sbillig]

    pub fn items(&self, db: &dyn AnalyzerDb) -> Rc<IndexMap<String, Item>> {
        match self {
            Item::Ingot(ingot) => ingot
                .lib_module(db)
                .expect("ingot is missing a lib file")
                .items(db),

A lib ingot is just the contents of lib.fe right now; the rest of the files are ignored.

[g-r-a-n-t]

A lib ingot is just the contents of lib.fe right now; the rest of the files are ignored.

good catch. things are a bit tangled, but I think I know how to clean it up

[g-r-a-n-t]

Ok, I think items need to be teased apart into a few separate categories:

• defined: all code definitions (including sub modules)
• global: dep ingots and the prelude map
• used: items defined in use statements (looks inside of global and defined items)
• internal: items visible when inside of a module (defined, global, and used)
• external: items visible outside of the module (defined and used)

notes:

• when resolving a use path, we start by looking at global and defined items, then continue on looking at external items
• when resolving a type desc or expr, we start by looking at internal items, then continue looking at external items
• the point of having external items is to avoid things like use my_module::address

[g-r-a-n-t]

Alright @sbillig, this is ready for another review. I basically did what was described in my previous comment and fixed the issue you initially pointed out.

As mentioned before, I didn't overhaul the item map queries yet, so it's possible to have cycles on use paths. I don't think this a blocker for real std lib stuff, tho.

[g-r-a-n-t]

For clarity, cycles occur when two modules contain use paths that point at each other.
e.g.

foo.fe
---
use ingot::bar::... # must resolve all items in bar

bar.fe
---
use ingot::foo::... # must resolve all items in foo. cycles.

[sbillig]

👨‍🍳 👍