DebugInfo file+line info generation for susbtitutions is using the wrong source file

[adinn]

The debug info generator is currently generating the wrong file info for some method and field substitutions.

This can be shown by running any native app that uses method substitutions. Placing a break on at substituted method entry will use the right line number but display the code in the file for the original method.

The failure happens on Graal 21.1 and on the latest head.

The problem is actually a combination of several errors. One of them is down to a change to the way class SubstitutionMethod and SubstitutionField report the declaring class for a substituted method/field. The fix should include a modification to the debuginfotest test code (class hello.Hello) to ensure that it tests break points for substituted methods, ensuring that any future changes which might cause similar problems are caught early.

[munishchouhan]

@adinn thanks for reporting the issue
please provide a reproducer for this issue

[christianwimmer]

@adinn The Oracle GraalVM support team (@mcraj017 in this case) is monitoring GitHub issues and triaging them before raising them internally.
Now issues like this one is something that is a bit confusing for them, because they do not know that this is an issue for a component that you are actually working on so a bug that you are (hopefully) going to fix eventually.

We have a few options on how to make that transparent for the support team:

1. You can immediately assign the issue to yourself, or someone else you know who might eventually look at it. Then it is clear that you are responsible for the issue.
2. We can come up with a special label for such issues.

The first is probably the easiest. What do you think?

[adinn]

@christianwimmer

Hi Christian. Apologies for causing confusion here. I agree that it would be best if I assigned issues like this to myself or to someone else who is tasked to fix the problem.

Unfortunately, I'm not clear how I am supposed to achieve that. Likewise, I am not clear how to link the PR for a fix to the original issue -- as you can see I raised PR #3421 right after creating the issue but it is still not linked.

Is there some gadget in the github API that I am unaware of which allows me to assign issues and link PRs or do I need some specific project permissions?

Of course, I can always add an explanatory note to the issue for the benefit of the support team and will endeavour to do so in lieu of any alternative remedy.

[christianwimmer]

Unfortunately, I'm not clear how I am supposed to achieve that. Likewise, I am not clear how to link the PR for a fix to the original issue -- as you can see I raised PR #3421 right after creating the issue but it is still not linked.

Interesting. I guess I need to find out how more people can be allowed to assign issues (and if there is a good reason why this is restricted in the first place). @shelajev do you know?

[zakkak]

Likewise, I am not clear how to link the PR for a fix to the original issue -- as you can see I raised PR #3421 right after creating the issue but it is still not linked.

@adinn the easiest way to achieve this is to add fixes #3420 or closes #3420 in the description of the PR, see here for more details.

Interesting. I guess I need to find out how more people can be allowed to assign issues (and if there is a good reason why this is restricted in the first place).

@christianwimmer +1 we have started a similar discussion in #2767 as well, so @RoxaBee might able to answer about the "Triage" privilege.

BTW @mcraj017 you may close this issue as it has been fixed in #3421.

[munishchouhan]

I have attached the PR with this issue
Closing it now