Hubert Plociniczak d59714a29d Support module imports using a qualified name (#3608) ... 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).		2022-07-29 14:19:07 +00:00
..
src	Support module imports using a qualified name (#3608)	2022-07-29 14:19:07 +00:00
package.yaml	Nightly proccess preparations: Setting Enso version through the environment (#3241)	2022-02-07 15:14:32 +01:00