nr: Add modules to types NS#4404
Conversation
CohenArthur
force-pushed
the
add-modules-to-types-ns
branch
3 times, most recently
from
c5fe830 to
ad025f2
Compare
| // is that valid? | ||
| rust_assert (inserted); | ||
| // TODO: Are reinsertions okay? | ||
| // rust_assert (inserted); |
There was a problem hiding this comment.
Problem is, a lot of reinsertions aren't reinsertions so much as "we have multiple nodes sharing the same node id" (though we should really have another pass checking for that). Failing that, resolutions theoretically shouldn't be changing over time, even though the specific use case you're going for makes sense. Could you add a map_usage_unsafe method instead?
|
I think I'm going to try to add backtracking to the resolver, as I don't think the type prelude will work quite right otherwise. |
what do you mean by backtracking? |
Backtracking in the sense that resolution doesn't commit to certain segment resolutions until it succeeds, and can retry with a different namespace/starting location (type prelude vs not type prelude) with fewer issues. |
CohenArthur
force-pushed
the
add-modules-to-types-ns
branch
from
ad025f2 to
381b4ff
Compare
CohenArthur
force-pushed
the
add-modules-to-types-ns
branch
from
381b4ff to
6e37b04
Compare
CohenArthur
force-pushed
the
add-modules-to-types-ns
branch
from
6e37b04 to
9f5bfe5
Compare
| } | ||
| } | ||
| } | ||
| // else |
There was a problem hiding this comment.
Should we clean this up instead of using comments ?
CohenArthur
force-pushed
the
add-modules-to-types-ns
branch
from
9f5bfe5 to
24ba15f
Compare
CohenArthur
force-pushed
the
add-modules-to-types-ns
branch
from
24ba15f to
7003544
Compare
gcc/rust/ChangeLog: * util/rust-hir-map.cc (Mappings::insert_module_id): New function. (Mappings::is_module): Likewise. * util/rust-hir-map.h: Store a set of AST modules, declare functions for adding and retrieving them. * resolve/rust-toplevel-name-resolver-2.0.cc (TopLevel::visit): Insert modules in the type namespace and store them in mappings. * resolve/rust-late-name-resolver-2.0.cc (resolve_type_path_like): Error out when an expected type resolves to a module. * resolve/rust-name-resolution.h: Add empty Definition constructor. * resolve/rust-resolve-builtins.cc (find_builtin_node_id): New function. * resolve/rust-resolve-builtins.h: Declare it. gcc/testsuite/ChangeLog: * rust/compile/mod_in_types_ns.rs: New test. * rust/compile/mod_in_types_ns2.rs: New test.
Remove the previous hack that was used for resolver module names in the Types NS. Modules now get properly inserted, and this hack causes conflicts when a module and value share the same name. gcc/rust/ChangeLog: * resolve/rust-name-resolution-context.hxx: Remove hacks. gcc/testsuite/ChangeLog: * rust/compile/issue-4563.rs: New test.
Type definition conflicts are allowed in the case of builtin types. This is used in the `core` crate to add some more functionality to the builtin types. The consequence of this is that we need to special case the resolution of types in the case that their name could refer to a module or to a builtin type. gcc/rust/ChangeLog: * typecheck/rust-hir-type-check-type.cc (TypeCheckType::resolve_root_path): Add special casing for resolving to the builtin type definition if the found type has the same name and is a module. gcc/testsuite/ChangeLog: * rust/compile/type-with-builtin-type-name.rs: New test.
3 participants
gcc/rust/ChangeLog:
gcc/testsuite/ChangeLog:
Fixes #4403
Fixes #4563