As was already stated in a previous comment, the parameter isn't
necessarily referring to one of the DeclContext's parameter. We
should check the index is within the range to avoid out-of-boundary
access.
Details
Diff Detail
- Repository
- rC Clang
Event Timeline
clang/test/SemaCXX/PR41139.cpp | ||
---|---|---|
3 ↗ | (On Diff #193045) | Add a comment what this test does? |
clang/test/SemaCXX/cxx1y-generic-lambdas.cpp | ||
946 ↗ | (On Diff #193045) | Does this have to be in that namespace? |
clang/lib/Sema/SemaTemplateInstantiate.cpp | ||
---|---|---|
2895 ↗ | (On Diff #194152) | Have you analyzed how we get here? |
clang/lib/Sema/SemaTemplateInstantiate.cpp | ||
---|---|---|
2895 ↗ | (On Diff #194152) | It's not the caller's fault. The cause is that a function pointer or a function typedef isn't a declcontext, so even if the getDeclContext() of its parameter returns a function, it has nothing to do with its own ParmVarDecl. That's why we check if the corresponding ParmVarDecl is the same one. |
I won't be able to properly review this, sorry.
While i'm sure this fix silences the assert, i don't know what that means for the original caller.
Does it fail? Does it retry in some other scope? Should it be more picky about the original scope in the first place?
Can you suggest someone with familiarity for this part of code? The reviewers I randomly added by git blame doesn't seem to be reviewing.
While i'm sure this fix silences the assert, i don't know what that means for the original caller.
Does it fail? Does it retry in some other scope? Should it be more picky about the original scope in the first place?
This small function is just to get the canonical ParmValDecl for a given one. If the check doesn't pass, it simply mean there is no canonical one (it's obvious for a function pointer), so we just use the passed one. There is nothing wrong here.
This fix makes sense to me, however, Richard Smith @rsmith is the best person to review this patch.