public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Thomas Schwinge <tschwinge@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc/devel/rust/master] Merge #1307 Date: Tue, 14 Jun 2022 08:03:46 +0000 (GMT) [thread overview] Message-ID: <20220614080346.061BC383F97D@sourceware.org> (raw) https://gcc.gnu.org/g:1c679d7f42834a72956d6fb39c8d298dd6dc4b4e commit 1c679d7f42834a72956d6fb39c8d298dd6dc4b4e Merge: 25974baf19c 7ca7362602d Author: bors[bot] <26634292+bors[bot]@users.noreply.github.com> Date: Tue Jun 14 07:17:11 2022 +0000 Merge #1307 1307: Handle super and crate in path resolution r=CohenArthur a=philberty This patch completely reimplements our name resolution process for Paths in general. This patch gets rid of the old Resolver::Definition structures which were used so that we can map patterns back to LetStmts and establish an hierarchy of nodes. This was not nessecary and complicated name/type resolution. TypePaths and PathInExpression are similar but have a slightl tweak in the order they lookup the relevant scopes for types. But overall work the same. There are several cases of paths you must consider in type resolution: - i32 (simple type path) - Self::A (associated type reference) - mod::foo::impl_item() (reference to impl item) - super::foo (reference to item) - crate::foo - T::bound() In name resolution we cannot always fully resolve a path but have to rely on the type-resolution to fully resolve a path as it may require careful thought. For example a path like: mod::foo::item() might be for a generic foo<T>(), which might have two specialized impl blocks so the best the name resolution can do is resolve mod::foo then leave it up to the type resolution to figure out which item this is. We might have i32 which is just a simple lookup. Apart from that this patch introduces a module parent child hierachy so that on paths such as super::foo we resolve super to be our parent module scope then foo can be resolved with the lookup in the items for that module. More over this patch gets rid of some but not all of the awkward name canonicalization to try and patch paths directly. More cleanup is still needed here to make the name resolution step easier to read. This was notable in the Qualified path handling where we can now rely on the type resolver to setup the associated types properly rather than the name resolver requiring us to resolve this directly. Fixes #1251 #1230 Addresses #1227 #1153 Co-authored-by: Philip Herron <philip.herron@embecosm.com> Diff: gcc/rust/ast/rust-ast.h | 12 +- gcc/rust/ast/rust-path.h | 54 ++- gcc/rust/backend/rust-compile-base.cc | 56 ++- gcc/rust/backend/rust-compile-expr.cc | 10 - gcc/rust/backend/rust-compile-expr.h | 4 +- gcc/rust/backend/rust-compile-resolve-path.cc | 18 +- gcc/rust/backend/rust-compile-stmt.h | 8 +- gcc/rust/backend/rust-compile-var-decl.h | 70 +-- gcc/rust/hir/rust-ast-lower.cc | 2 +- gcc/rust/lint/rust-lint-marklive.cc | 23 +- gcc/rust/privacy/rust-visibility-resolver.cc | 6 - gcc/rust/resolve/rust-ast-resolve-base.h | 6 +- gcc/rust/resolve/rust-ast-resolve-expr.cc | 13 - gcc/rust/resolve/rust-ast-resolve-implitem.h | 30 +- gcc/rust/resolve/rust-ast-resolve-item.cc | 8 +- gcc/rust/resolve/rust-ast-resolve-path.cc | 533 +++++++++++----------- gcc/rust/resolve/rust-ast-resolve-path.h | 14 - gcc/rust/resolve/rust-ast-resolve-pattern.cc | 4 +- gcc/rust/resolve/rust-ast-resolve-pattern.h | 11 +- gcc/rust/resolve/rust-ast-resolve-stmt.h | 6 - gcc/rust/resolve/rust-ast-resolve-toplevel.h | 55 +-- gcc/rust/resolve/rust-ast-resolve-type.cc | 186 +++++++- gcc/rust/resolve/rust-ast-resolve-type.h | 94 +--- gcc/rust/resolve/rust-ast-resolve.cc | 47 +- gcc/rust/resolve/rust-name-resolver.cc | 54 ++- gcc/rust/resolve/rust-name-resolver.h | 67 +-- gcc/rust/rust-session-manager.cc | 3 + gcc/rust/typecheck/rust-hir-type-check-expr.h | 27 +- gcc/rust/typecheck/rust-hir-type-check-path.cc | 147 +++--- gcc/rust/typecheck/rust-hir-type-check-pattern.cc | 6 + gcc/rust/typecheck/rust-hir-type-check-pattern.h | 2 + gcc/rust/typecheck/rust-hir-type-check-stmt.h | 34 +- gcc/rust/typecheck/rust-hir-type-check-type.cc | 92 ++-- gcc/rust/typecheck/rust-tycheck-dump.h | 2 +- gcc/rust/util/rust-hir-map.cc | 40 ++ gcc/rust/util/rust-hir-map.h | 4 + gcc/testsuite/rust/compile/complex-path1.rs | 18 + gcc/testsuite/rust/compile/issue-1251.rs | 14 + 38 files changed, 953 insertions(+), 827 deletions(-)
reply other threads:[~2022-06-14 8:03 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20220614080346.061BC383F97D@sourceware.org \ --to=tschwinge@gcc.gnu.org \ --cc=gcc-cvs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).