diff options
| author | Philip Herron <herron.philip@googlemail.com> | 2023-03-03 18:01:01 +0000 |
|---|---|---|
| committer | Philip Herron <philip.herron@embecosm.com> | 2023-03-03 19:27:24 +0000 |
| commit | 06e1d43c2f8a05af9fd862e6497c21741fce85c7 (patch) | |
| tree | 9953daf4e7b40619eeb2a8fbdad2c593dbcff7da /gcc/rust/hir | |
| parent | f71f25af741238e911d38874da18a5654fc836f7 (diff) | |
| download | gcc-06e1d43c2f8a05af9fd862e6497c21741fce85c7.zip gcc-06e1d43c2f8a05af9fd862e6497c21741fce85c7.tar.gz gcc-06e1d43c2f8a05af9fd862e6497c21741fce85c7.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')
0 files changed, 0 insertions, 0 deletions