No C global state in modules

[mascarenhas]

This PR removes most of the C global state in Titan modules, the only thing that is left is a cache for tags. We are passing all the tests that we currently have, but I still need to write tests for functionality that this PR enables, such as loading the same Titan module from two distinct Lua states (their module variables will be local to the state, as it should be), or linking module B inside module A.so, while having a separate B.so, and having the B that A imports and the other B require'd by Lua refer to the same module instance.

The canonical module instances for each Lua state, as well the canonical tags and metatables for record types, are kept in the Lua registry, but we only need to hit the registry at module initialization, no accesses to the registry are done on normal execution of Titan code.

One thing that we lose is the ability to leverage GCC's constant propagation to propagate local module variables that have numeric values that can be know at compile-time, but we can add a constant propagation AST->AST pass later on.

[codecov-io]

Codecov Report

Merging #233 into primitives will increase coverage by <.01%. The diff coverage is 100%.

Impacted Files	Coverage Δ
titan-compiler/coder.lua	96.25% <100%> (ø)	:arrow_up:

---

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 2784c32...b7461d1. Read the comment docs.

[mascarenhas]

One thing that I also did in this PR was to make the code that runs only once in module initialization to be as well-behaved as possible in terms of using the Lua API instead of the internals, which hopefully will make decrease the surface area for changes between one Lua version to the other.

[hishamhm]

I am going to try to rebase this PR on top of master without the primitives branch, so this can be merged without being held back by the discussion that is going to be necessary there.

On Thu, May 17, 2018, 22:41 Fabio Mascarenhas notifications@github.com wrote:

One thing that I also did in this PR was to make the code that runs only once in module initialization to be as well-behaved as possible in terms of using the Lua API instead of the internals, which hopefully will make decrease the surface area for changes between one Lua version to the other.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/titan-lang/titan/pull/233#issuecomment-390068425, or mute the thread https://github.com/notifications/unsubscribe-auth/AAO_daCd8UCS8K6ke93rD09ttZ-rVg6Lks5tzibPgaJpZM4UDzX- .

[mascarenhas]

I am going to try to rebase this PR on top of master without the primitives branch, so this can be merged without being held back by the discussion that is going to be necessary there.

The easiest way to this is probably to do a new commit to this branch that removes the foreign functions, then squashing the the commits from both branches together and applying then on master...

But the objection was to foreign functions exposed to the programmer, not to the concept itself, so I can just not expose then for now. If I do this on the primitives branch we can probably merge both branches cleanly without losing history.

[mascarenhas]

Ok, now this is a dead-end branch, closing this PR and killing the branch. Thanks for all the fish!