The usize one gets used internally for things like
pattern matches. This is both more efficient (means
they don't have to do unnecessary casts) and also
less error-prone due to e.g. comparing length to
capacity, which is usize.
The bug reproduces if you go to the commit before this one;
seems to be the problem is importing an un-exposed value
as unqualified (possibly from a package, might be relevant)
Moves handling of ingested file imports from load to can, so that they
can be properly introduced in the scope they appear.
Example:
import "input.txt" as input : Str
image =
import "image.png" as bytes : List U8
# `bytes` is only available under `image`
decodePng bytes
...
Now that imports can be limited to smaller scopes than the entire module,
unused import warnings need to work like unused def warnings.
This commit moves unused import warnings discovery and reporting from load
to canonicalization where we can track their usage per scope.
This also fixes a longstanding bug where unused exposed names from an import
were not reported if they were only used in a qualified manner.
After parsing a module, we now recursively traverse the tree to find
all imports inside Defs, not just the top-level ones.
Previously, imported modules were available in the entire file,
but that's no longer the case. Therefore, Scope now keeps track of
imported modules and Env::qualified_lookup checks whether a module
is available in the provided scope.
Note: Unused import warnings are still global and need to be updated.
Previously, all imports were available in the header, so we could start
processing dependencies as soon as we parsed it. However, the new imports
are treated as defs, so we have to parse the whole module to find them.
This commit essentially moves the dependency resolution from the `LoadHeader`
phase to the `Parse` phase, and it updates canonicalization to introduce
module symbols into scope when a `ValueDef::ModuleImport` is encountered.
NOTE:
- The `imports` header still parses, but it's no longer wired up. I will remove
it in an upcoming commit.
- Ingested files and imports that appear in nested expressions are not
yet supported by load
A "late specialization" of a type is an ability specialization that
is not visible or needed until after type-specialization; i.e. during
monomorphization.
The `Inspect.toInspector` ability is special-cased for opaques that do
not claim or explicitly implement `Inspect`. In such cases, they are
treated as structural types, and given the immediate specialization of
`Inpect.inspectOpaque`.
However, prior to this commit, that special-casing would only be applied
during early specialiation (i.e. specializations visible during
generalized type inference). This commit applies the special case to
late specialization as well - the specialization decision for an opaque
type is always the specialization of the opaque type in the late case,
but now, when we go to look up the ambient lambda set of the
specialization, if it does not exist and corresponds to
`Inspect.toInspector`, we fall back to the immediate.
One concern I have here is that in a case like
```
Op := {}
x =
dbg (@Op {})
```
the specialization of `Inspect.toInspector` for `Op` should be known
early. Indeed, the program
```
Op := {}
x =
Inspect.toInspector (@Op {}) |> Inspect.apply (Inspect.init {}) |> Inspect.toDbgStr
```
Compiles fine without this change. This makes me suspect there is an
issue with the implementation of `dbg`'s desugaring. If possible, this
should be addressed sooner rather than later.
Closes#6127
