-
Notifications
You must be signed in to change notification settings - Fork 17.5k
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
x/tools/gopls: show hex/binary literal with which a const was declared on mouse over #47453
Comments
Isn't it a duplicate of #45802? Can you please check if the fix in golang.org/x/tools/gopls@v0.7.1-pre.1 meets what you want? |
@hyangah negative. The issues are similar in nature though. I'm not asking for literal evaluation but rather that gopls show me how the author initialized a const integer since there are around 5 ways of initializing the same number and usually non-decimal form carries useful information about certain bits (i.e. bitfields, masks) |
…iables and constants This change improves the hover information for variables and constants by showing both an original declaration and a value. The value is shown as an inline comment. Two kinds of declarations are currently supported: 1. Basic literals of type int: * var x int64 = 0xff // 255 * const x untyped int = 0b11 // 3 * const x uint = 1_000_000 // 1000000 2. Binary expressions with bitwise operators: * var x uint = 0b10 | 0b1 // 3 * const x untyped int = 10 << 20 // 10485760 This change also removes TestHoverIntLiteral in favor of marker tests Fixes golang/go#47453
Change https://golang.org/cl/381961 mentions this issue: |
Hey there! I'd like to bump this issue. This is something I regularly run into. I use Go for firmware/embedded systems and hexadecimals plague my code. It'd be really nice to get this mouse-over information |
I wonder, to me it would suffice if the decimal representation was shown next to a hexadecimal representation. This is similar to how const time.Millisecond time.Duration = 1000000 // 1ms |
IMO, it would be even better to always show the original declaration for constants. For example, consider these declarations: // From src/math/bits.go
const (
mask = 0x7FF
shift = 64 - 11 - 1
bias = 1023
fracMask = 1<<shift - 1
)
const (
timeout = time.Minute + 30 * time.Second
) Here is a comparison between the current hover and the proposed one:
I also checked the GoLand behavior. It shows both the original declaration and the value: I could successfully implement this feature without any serious issues. However, I noticed that the hover logic had been significantly rewritten. And I am not sure that the function // TODO(rfindley): this function does too much. We should lift the special
// handling to callsites. @findleyr I would like to hear your opinion on this matter. |
@ShoshinNikita first of all, I'm very sorry about https://go.dev/cl/381961, which appears to have gotten stuck in limbo. If you would be interested in seeing this through, we would greatly appreciate the contribution. You can send the CL to me and I'll be sure to get it in expediently. Yes, I had to refactor hover to disentangle the places where we depended on implicit relationships between packages or parsed files (so that we can break these relationships to improve gopls' scaling). I hope that it is easier to contribute to now, so please let me know if you find otherwise. If you want to put the logic into the const block of objectString, that's OK. I'll eventually get around to that TODO. That TODO means this: objectString looks almost entirely like types.ObjectString, except when it doesn't: when the object is a const or when the type has inferred arguments (and the latter only occurs at one call site). It would be simpler to avoid the abstraction and just handle the special case(s) at the call site. Specifically, I think we'd just need to handle the const case in the one location where we format a general object string (here). But as I said, it would be fine if you just modify the const case of objectString. |
… value of constants in hover This change improves the hover information for constants by showing both the original declaration and the value. The value is displayed as an inline comment. If the original declaration and the value are the same, there will be no inline comment. Examples: ```go const duration time.Duration = 15*time.Minute + 10*time.Second // 15m10s const octal untyped int = 0o777 // 511 const expr untyped int = 2 << (0b111&0b101 - 2) // 16 const boolean untyped bool = (55 - 3) == (26 * 2) // true const dec untyped int = 500 ``` Other changes: * Calls to `objectString` that format methods or variables have been replaced with `types.ObjectString`. * The logic of inferred signature formatting has been extracted from `objectString` to a new function `inferredSignatureString`. * Remove unused function `extractFieldList`. Fixes golang/go#47453
@findleyr no problem. The original PR was too outdated. So, I decided to create a new one - https://go.dev/cl/480695 |
Just curious: how would it render a constant made out of other constants and literals? |
@soypat as it was declared: const fracMask untyped int = 1<<shift - 1 // 4503599627370495 |
Change https://go.dev/cl/480695 mentions this issue: |
What did you do?
Mouse over a hex/binary notation integer
What did you expect to see?
The literal used to declare the
const
. Usually when one declares a const in hex, binary or octal representation it carries with it a significance, to aid the reader of the code. If we wrote programs for machinesgofmt
would convert these literals to decimals or whatever the computer like.With the philosophy out of the way, I expected to see:
const hex untyped int = 0xe34e (58190)
const bin untyped int = 0b10101 (21)
.What did you see instead?
The usual
gopls
help string ofconst hex untyped int = 58190
const bin untyped int = 21
.The text was updated successfully, but these errors were encountered: