-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd/compile: (more) bad pcln entries when compiling type parametric functions #49523
Comments
Thanks for doing this, Alessandro! I will take this, I can see one small change that will fix a bunch of these wrong positions (which are often because of new nodes added for implicit operations like conversions). Then I'll try to hunt down the remaining wrong positions. |
@aarzilli I think the "-l" option was not gettiing parsed correctly in the gcflags option, so there was still inlining happening. I changed the line to:
and got fewer errors, because now there was no inlining. Then I was able to fix the rest of the errors with the upcoming change (some still show up because of auto-generated functions, which I think is fine). |
Change https://golang.org/cl/363835 mentions this issue: |
AFAICT passing multiple -gcflags options like that does a different thing, they don't get concatenated, the second one replaces the first one. You can see it with
with
Enabling optimizations removes some of the instructions that had incorrect line numbers, hence fewer errors. |
@aarzilli Yes, thanks, that makes sense now. I thought inlining was still happening, but it was a position problem related to multiple return values. I fixed that issue as well. So, there are no issues, except for auto-generated code (which I think are fine), when running bad.go now. |
Thanks! |
I found one more issue like #49436 so I decided to write a program to find all of them. The program is https://github.com/aarzilli/badlngenerics/.
When run with
test/typeparam/*.go
it produces https://gist.github.com/aarzilli/7c4ba1e87e986f0ec1a89cdec455392a as output. The output format iswhich means that after compiling append.go with
-gcflags='-N -l'
instruction 0x454e8d, which belongs to an instantiation of main._Append, is assigned to line 29 of append.go, which happens to be outside of the body of main._Append in the source file.Some of the output could be false positives but I've spot-checked some of it and it looks like it's detecting real problems.
There's a few of them.
Tested with:
cc @dr2chase
The text was updated successfully, but these errors were encountered: