Is it valid to assume that the scope for a parameter-describing
DILocalVariable always is a DISubprogram? Or do you know of any case
where a parameter's scope can be a sub-scope of the DISubprogram?
I added a check to the IR verifier and an assertion to
DIBuilder::createParameterVariable() that verify this. This resulted in
one test case, DebugInfo/X86/double-declare.ll, failing when running
check-all:
Is it valid to assume that the scope for a parameter-describing
DILocalVariable always is a DISubprogram? Or do you know of any case
where a parameter's scope can be a sub-scope of the DISubprogram?
I believe that for the Clang and Swift frontends that should always be true. A hypothetical language frontend for a language that supports functions with multiple entry points might be a counterexample, but I don't know of any.
I added a check to the IR verifier and an assertion to
DIBuilder::createParameterVariable() that verify this. This resulted in
one test case, DebugInfo/X86/double-declare.ll, failing when running
check-all:
> Is it valid to assume that the scope for a parameter-describing
> DILocalVariable always is a DISubprogram? Or do you know of any case
> where a parameter's scope can be a sub-scope of the DISubprogram?
I believe that for the Clang and Swift frontends that should always be
true. A hypothetical language frontend for a language that supports
functions with multiple entry points might be a counterexample, but I
don't know of any.
FORTRAN and PL/I both support multiple entrypoints, to my knowledge,
although I am pretty sure in PL/I this does *not* introduce a new scope.
Don't know about FORTRAN. I think there's a Flang project with its own
mailing list? People there might know.
--paulr