Fix performance and semantic problem when creating Modules and make Module::name mandatory

[ironcev]

The Namespace::enter_submodule method creates a new submodule by copying the entire content of the Namespace::init into it. init contains all the external modules with all their submodules, items, etc.

This causes an obvious performance issue because literally every internal module contains all the modules of all the external modules recursively. Even within a simple project depending only on std we will still have all the core modules copied as submodules of all the std modules. In a typical workspace this will be true for all the external dependencies blowing up the memory and slowing down the compilation time because of extensive copying of Modules.

Beside the performance problem, having all the external modules as submodules of each and every module also leads to nonsensical imports like these, which are currently all valid:

mod my_internal_mod;

use std::core::ops::Eq;
use std::hash::core::ops::Eq;
use my_internal_mod::my_submod::std::hash::core::ops::Eq;
use some_external_dependency::its_submodule::std::core::ops::Eq;
use my_internal_mod::my_submod::some_external_dependency::its_submodule::std::core::ops::Eq;
etc.

To fix this, we need to, obviously, stop copying the entire modules as submodules and refactor the way preludes are imported into namespace/module items.

As a part of that refactoring, one more point should be addressed. Currently, Module::names are Options which does not correspond to the semantics of the modules - we do not have nameless modules. Thus every module must have a name, and this is currently not enforced by the type system. On the contrary, have the name being Option<Ident> convey the message that we support nameless modules.

Also, the root module must have a name coming from the package name. Making sure that the name actually exists is done by the callers, e.g., tooling and with internal methods like the mentioned Namespace::enter_submodule. Still, we had places in tests where root modules are created without a name. Having a root module without a name makes absolute paths ambiguous, because we can have internal libraries with the same name as some external package and the same inner module structure. Currently are such two indistinguishable.

Why do we have then Module::names as Option in the first place? After going through the code, my conclusion is that it was done to support the Namespace::init being Module. Since it was not a real module, there was no sense to have a name for it.

IMO, Modulea must have name, visibility, and is_external set at creation.

To sum it up, fixing the overall issues with the namespaces and modules should:

• Make Module::name being Ident instead of Option<Ident>
• Remove Module::default() and introduce Module::new(name, visibility, is_external) and make these fields read-only, accessible through getters.
• Instead of the Namespace::init being Module containing all the external dependencies, introduce a mechanism to keep track of external dependencies and preludes and importing only the content of preludes into every new module.

[jjcnn]

As mentioned elsewhere this issue has blown up to an unmanageable size, and it's not helped by us not having documented the intended semantics of imports and their name resolution anywhere.

To get a feel for the intended semantics of our current implementation, I took at look at the tests we currently have in our test suite. I don't know where else to put them, but I would like for them to be somewhere we can all see them:

Failing tests

• should_fail/import_error_ambiguity: Importing non-existing item
• should_fail/import_non_item: Module import of single name (fails because of missing call path - should be allowed, but module imports 'use a::b` where be is a module may not be supported ATM)
• should_fail/item_used_without_import: Use item defined in submodule using simple name but without import.
• should_fail/recover_path_lib_import: Parser error - importing path without * or item name
• should_fail/resolve_local_items_that_shadow_imports: Item imports and local definitions share namespace
• should_fail/shadow_import: Item imports must have unique names/aliases, but may shadow star imports.
• should_fail/star_import_alias: Use of alias in star import

Passing tests:

• should_pass/resolve_local_items_that_shadow_imports: Star imports and local definitions live in different namespaces. Local definitions shadow star imports.
• should_pass/language/aliased_imports: Item-import with alias
• should_pass/language/enum_variant_imports: Import of enum type and variants.
• should_pass/language/import_method_from_other_file: Item-import imports implemented trait of imported type. Also imports implemented trait of type referred to by imported type, even though that type is not imported in main file (this looks incorrect)
• should_pass/language/import_trailing_comma: Parser test of trailing comma in import list.
• should_pass/language/import_with_different_callpaths: Star import of same item through multiple paths (via reexports), access using simple names and enum_type::enum_variant
• should_pass/language/multi_item_import: Parser test of combined callpaths
• should_pass/language/trait_import_with_star: Import u64 impl of user-defined trait, call implemented method.
• should_pass/language/typeinfo_custom_callpath_with_import: Use simple name and relative path to access imported enum, enum variant
• should_pass/language/use_absolute_path: Import items using absolute and package-relative paths
• should_pass/language/use_full_path_names: Import items using relative paths (no traits)

Missing tests:

• Pass: Star import of same item through multiple paths (via reexports), use full path to access (see should_pass/language/import_with_different_callpaths)
• Pass: Star import of different items with same name, but not used
• Fail: Star import of different items with same name, used as simple name
• Pass: Star import of different items with same name, used with full path
• Fail: Self imports (enums - not sure if we support import of modules without star) - name clashes, incorrect use, etc.
• Fail: Name clash between local definition and aliased item-import
• Pass: Name clash between local definition and name of item-import, but where item-import is aliased to non-clashing name.
• Pass: Use full path for imported name (item-import or star-import)
• Fail: Ambiguous path - absolute path coincides with relative path (probably does not cause an error ATM)
• Pass/Fail?: Import enum variant without importing enum type
• Fail: Use enum variant as simple name while only importing enum type
• Pass/Fail?: Star-import enum, are enum variants in scope as simple names?
• Fail: Attempt to use name defined in supermodule without importing it
• Pass: Use item defined in submodule without import but using relative path
• Pass: Use item defined in submodule without import using absolute path
• Fail: At present no failing tests for imported methods/impls
• Fail: No failing tests for type errors when using imported functions
• Pass: Import type X, which uses type Y, into module that has its own definition of type Y. (This currently fails)
• Pass/Fail: Call imported function that returns non-visible type, pass returned value to function imported from different module.
• Pass/Fail: Import unimplemented trait, use to implement for local type (see should_pass/language/use_absolute_path: no impl of local type, but otherwise ok - note no example of relative import path)
• Pass/Fail: Item-import unimplemented trait (test you can't call a trait function?)

In other words, we are missing about as many test cases as we actually have.

@IGI-111 , @tritao : For info.

[jjcnn]

@tritao: This is the one.

[jjcnn]

The following tests are currently disabled, but should be reenabled as part of this PR:

• should_pass/language/reexport/simple_path_access
• should_fail/language/reexport/simple_path_access
• test should_pass/language/reexport/reexport_paths (items cannot currently be imported via std::prelude)