⚠ This page is served via a proxy. Original site: https://github.com
This service does not collect credentials or authentication data.
Skip to content

Conversation

@stevenfontanella
Copy link
Member

@stevenfontanella stevenfontanella commented Jan 1, 2026

Resolves the TODO is global-get-init.wast. Previously if a global was imported it would stop us from evaluating almost anything (?). After this change, an imported global doesn't prevent us from optimizing as long as the global isn't referenced in the constructor that we're targeting.

Part of #8180.

@stevenfontanella stevenfontanella force-pushed the allow-global-imports branch 2 times, most recently from 084a2f8 to 15ed8c6 Compare January 1, 2026 02:08
stevenfontanella added a commit that referenced this pull request Jan 7, 2026
Add an ImportResolver interface with some implementations to handle the
spec interpreter and ctor-eval

* Removes coupling of imported names from the module they come from.
This will allows us to provide special imports like the spec test module
better which have some 'magic' e.g. for printing functions which can't
be implemented in Wasm (globals remain the same because they still come
from a real module which is better).
* Removes pointer chasing logic when resolving imported globals in both
cases.
* Also allows us to relax ctor-eval and allow programs that import
globals to be optimized more (as long as they don't try to evaluate
imports) #8168
* Fixes #8167
* Part of #8180
Base automatically changed from global-import to main January 7, 2026 21:09
@stevenfontanella stevenfontanella changed the title Try allowing globals to be imported in ctor eval Ctor-eval: Don't stop evaluating when an imported global isn't used Jan 10, 2026
@stevenfontanella stevenfontanella marked this pull request as ready for review January 10, 2026 22:53
// passes import validation.
Literals* getGlobalOrNull(ImportNames name, Type type) const override {
throw FailToEvalException("Accessed imported global");
auto [it, _] = stubLiterals.try_emplace(type, Literals({Literal(type)}));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not every type has a default value, so this Literal constructor will only work for some types of globals. For example this will fail if the type of the global is a non-nullable reference to e.g. a struct.

We could either use this solution and have it work for only defaultable types, or we could do something like add a way to deliberately create an invalid Literal that has whatever type we need.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants