diff options
| author | Philip Herron <herron.philip@googlemail.com> | 2023-03-03 18:01:01 +0000 |
|---|---|---|
| committer | Arthur Cohen <arthur.cohen@embecosm.com> | 2024-01-16 18:21:08 +0100 |
| commit | 9e369c3577eaf0e755a2d6da0597a352a4c21a54 (patch) | |
| tree | 5b19917b031b644fc1e540478592a25ab631a205 /gcc/rust/hir/tree/rust-hir.h | |
| parent | 10c4a2ce03c99c1394e9d610c0f38ce990284181 (diff) | |
| download | gcc-9e369c3577eaf0e755a2d6da0597a352a4c21a54.zip gcc-9e369c3577eaf0e755a2d6da0597a352a4c21a54.tar.gz gcc-9e369c3577eaf0e755a2d6da0597a352a4c21a54.tar.bz2 | |
gccrs: Fix name-resolution to be permissive and carry on
There are a few edge cases when resolving TypePaths that we cannot fully
resolve to an explicit node_id and this is expected. So for example
<A as B>::foo
A and B are simple Type paths and thats 100% but the segment foo cannot be
100% resolved to an explicit node id as this requires type-resolution to
find the correct path. So when we have complex paths such as:
<<A as B>::foo as C>
The ::foo part will return UNKNOWN_NODEId and we return early and think its
a failure case but its not necessarily a failure but we need to make sure
to name resolve C so when we do type-resolution we can resolve C properly.
Addresses #1524
Signed-off-by: Philip Herron <herron.philip@googlemail.com>
gcc/rust/ChangeLog:
* resolve/rust-ast-resolve-type.cc (ResolveRelativeQualTypePath::resolve_qual_seg): fix
gcc/testsuite/ChangeLog:
* rust/compile/parse_associated_type_as_generic_arg3.rs: remove -fsyntax-only
Diffstat (limited to 'gcc/rust/hir/tree/rust-hir.h')
0 files changed, 0 insertions, 0 deletions