mirror of
https://github.com/enso-org/enso.git
synced 2024-12-23 22:01:42 +03:00
d59714a29d
This change allows for importing modules using a qualified name and deals with any conflicts on the way. Given a module C defined at `A/B/C.enso` with ``` type C type C a ``` it is now possible to import it as ``` import project.A ... val x = A.B.C 10 ``` Given a module located at `A/B/C/D.enso`, we will generate intermediate, synthetic, modules that only import and export the successor module along the path. For example, the contents of a synthetic module B will look like ``` import <namespace>.<pkg-name>.A.B.C export <namespace>.<pkg-name>.A.B.C ``` If module B is defined already by the developer, the compiler will _inject_ the above statements to the IR. Also removed the last elements of some lowercase name resolution that managed to survive recent changes (`Meta.Enso_Project` would now be ambiguous with `enso_project` method). Finally, added a pass that detects shadowing of the synthetic module by the type defined along the path. We print a warning in such a situation. Related to https://www.pivotaltracker.com/n/projects/2539304 # Important Notes There was an additional request to fix the annoying problem with `from` imports that would always bring the module into the scope. The changes in stdlib demonstrate how it is now possible to avoid the workaround of ``` from X.Y.Z as Z_Module import A, B ``` (i.e. `as Z_Module` part is almost always unnecessary). |
||
|---|---|---|
| .. | ||
| Base/0.0.0-dev | ||
| Database/0.0.0-dev | ||
| Examples/0.0.0-dev | ||
| Geo/0.0.0-dev | ||
| Google_Api/0.0.0-dev | ||
| Image/0.0.0-dev | ||
| Searcher/0.0.0-dev | ||
| Table/0.0.0-dev | ||
| Test/0.0.0-dev | ||
| Visualization/0.0.0-dev | ||