From: Pierre-Emmanuel Patry <[email protected]>
This path was not documented and usually unexpected. It lead to various
headache during debugging sessions as the nullopt return value look
out of place.
gcc/rust/ChangeLog:
* resolve/rust-name-resolution-context.hxx: Document non glob container
path.
Signed-off-by: Pierre-Emmanuel Patry <[email protected]>
---
This change was merged into the gccrs repository and is posted here for
upstream visibility and potential drive-by review, as requested by GCC
release managers.
Each commit email contains a link to its details on github from where you can
find the Pull-Request and associated discussions.
Commit on github:
https://github.com/Rust-GCC/gccrs/commit/6403311325b27f5a3a41abfb6d764e01aab85e2a
The commit has NOT been mentioned in any issue.
The commit has been mentioned in the following pull-request(s):
- https://github.com/Rust-GCC/gccrs/pull/4758
gcc/rust/resolve/rust-name-resolution-context.hxx | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/gcc/rust/resolve/rust-name-resolution-context.hxx
b/gcc/rust/resolve/rust-name-resolution-context.hxx
index f5af7b3fa..a92f15d7b 100644
--- a/gcc/rust/resolve/rust-name-resolution-context.hxx
+++ b/gcc/rust/resolve/rust-name-resolution-context.hxx
@@ -345,6 +345,10 @@ NameResolutionContext::resolve_segments (
}
else
{
+ // Non glob containers such as structures, we insert the
+ // segment but we let the type checker handle the rest since
+ // it has to resolve methode resolution & cie
+
// FIXME: Resolve segments always resolves in the Types NS
// correct? If so, we should remove the template parameter for
// this function - and use NS::Types directly here instead of
--
2.55.0
