public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
* [gcc/devel/rust/master] Merge #1307
@ 2022-06-14  8:03 Thomas Schwinge
  0 siblings, 0 replies; only message in thread
From: Thomas Schwinge @ 2022-06-14  8:03 UTC (permalink / raw)
  To: gcc-cvs

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(-)


^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2022-06-14  8:03 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-14  8:03 [gcc/devel/rust/master] Merge #1307 Thomas Schwinge

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).