Skip to content
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: internal compiler error: missed typecheck [1.21 backport] #61909

Closed
gopherbot opened this issue Aug 9, 2023 · 4 comments
Closed
Labels
CherryPickApproved Used during the release process for point releases compiler/runtime Issues related to the Go compiler and/or runtime.
Milestone

Comments

@gopherbot
Copy link
Contributor

@cuonglm requested issue #61908 to be considered for backport to the next 1.21 minor release.

@gopherbot Please backport this to go1.21

@gopherbot gopherbot added the CherryPickCandidate Used during the release process for point releases label Aug 9, 2023
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Aug 9, 2023
@gopherbot gopherbot added this to the Go1.21.1 milestone Aug 9, 2023
@gopherbot
Copy link
Contributor Author

Change https://go.dev/cl/518115 mentions this issue: [release-branch.go1.21] cmd/compile: make backingArrayPtrLen to return typecheck-ed nodes

@mknyszek
Copy link
Contributor

@mdempsky @cuonglm Happy to cherry-pick approve this if you can provide just a little more context, such as:

  • How severe is it?
  • What's the risk with backporting the change?
  • Is it possible to work around?

At first glance I assume the answers are probably:

  • It's bad.
  • Low.
  • No.

But a confirmation from one or both of you would be appreciated. :) Thanks.

@cuonglm
Copy link
Member

cuonglm commented Aug 11, 2023

@mknyszek

  • Yes, it's bad.
  • It's quite low. Emitting tychecked nodes is the right thing, and does not harm. Actually, emitting un-tychecked nodes is harmful, and only discovered when https://go-review.googlesource.com/c/go/+/497276 land.
  • No, because user may avoid use len(string(bytes(...)), but that pattern is also generated by the compiler implicitly, e.g: string comparison where arguments are string(bytes(...)).

@dmitshur dmitshur added CherryPickApproved Used during the release process for point releases and removed CherryPickCandidate Used during the release process for point releases labels Aug 16, 2023
@gopherbot
Copy link
Contributor Author

Closed by merging 25c6dce to release-branch.go1.21.

gopherbot pushed a commit that referenced this issue Aug 17, 2023
…n typecheck-ed nodes

Fixes #61909

Change-Id: Ief8e3a6c42c0644c9f71ebef5f28a294cd7c153f
Reviewed-on: https://go-review.googlesource.com/c/go/+/517936
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/518115
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CherryPickApproved Used during the release process for point releases compiler/runtime Issues related to the Go compiler and/or runtime.
Projects
None yet
Development

No branches or pull requests

4 participants