Skip to content

runtime,reflect: reflect.bitVector and runtime.bitvector not sync #66822

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.

Sign up for GitHub

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

Jump to bottom
Closed
qiulaidongfeng opened this issue Apr 14, 2024 · 3 comments
Closed

runtime,reflect: reflect.bitVector and runtime.bitvector not sync #66822

qiulaidongfeng opened this issue Apr 14, 2024 · 3 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. FrozenDueToAge

Comments

@qiulaidongfeng
Copy link
Member

Go version

tip

Output of go env in your module/workspace:

no need.

What did you do?

See https://github.com/golang/go/blob/master/src/runtime/stack.go#L580-L583 and https://github.com/golang/go/blob/master/src/reflect/type.go#L2914-L2918 .

What did you see happen?

reflect.bitVector and runtime.bitvector not sync.

What did you expect to see?

Implement matching annotations.
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Apr 14, 2024
@novitoll
Copy link
Contributor

novitoll commented Apr 14, 2024 •
edited
Loading

runtime/stack.go has n int32. Should it be changed to n uint32 as in reflect/type.go and keeping the name struct name bitvector w/o camelCase for consistency?

If so, there are conditions where -1 is returned where we don't have a valid pcdata, and pc* functions and type pcvalueCacheEnt struct.

Please advise if it's OK to change to uint32 and use uint32(0) instead of int32(-1) for the condition above, I can send a patch.

UPDT: Change reflect.bitVector number of bits (uint32) to int32

@gopherbot
Copy link
Contributor

Change https://go.dev/cl/578796 mentions this issue: reflect: change bitVector number of bits to int32

@cherrymui
Copy link
Member

They need to match semantically, and they do. The code may not look identical at surface level. If you think the code and/or the comment can be adjusted, feel free to send a CL.

There is no need to file an issue like this. In general, this is internal implementation detail, not a user-observable issue. Thanks.

@cherrymui cherrymui closed this as not planned Won't fix, can't repro, duplicate, stale Apr 15, 2024
@golang golang locked and limited conversation to collaborators Apr 15, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. FrozenDueToAge
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@novitoll @gopherbot @cherrymui @qiulaidongfeng