aboutsummaryrefslogtreecommitdiff
path: root/gcc/config.gcc
diff options
context:
space:
mode:
authorIan Lance Taylor <ian@gcc.gnu.org>2020-01-09 15:58:42 +0000
committerIan Lance Taylor <ian@gcc.gnu.org>2020-01-09 15:58:42 +0000
commit0581e6ba3cfeb646553574aaa0efb1a822550a1f (patch)
treefa419773d258339a511cb550a8739b57ca49d154 /gcc/config.gcc
parentd6491d15676b0255eaaa4f5394fbb8ec7e3c6a5f (diff)
downloadgcc-0581e6ba3cfeb646553574aaa0efb1a822550a1f.zip
gcc-0581e6ba3cfeb646553574aaa0efb1a822550a1f.tar.gz
gcc-0581e6ba3cfeb646553574aaa0efb1a822550a1f.tar.bz2
compiler: don't add composite literal keys to package bindings
Adding composite literal keys to package bindings gets confusing when it is combined with dot imports. The test case showing the resulting compilation failure is https://golang.org/cl/213899. Fix this by adding a new expression type to hold composite literal keys. We shouldn't see it during lowering if it is a struct field name, because Composite_literal_expression::do_traverse skips struct field names. Or, it should, but that didn't quite work with pointer types so it had to be tweaked. This lets us remove the code that recorded whether an Unknown_expression is a composite literal key. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/214017 From-SVN: r280056
Diffstat (limited to 'gcc/config.gcc')
0 files changed, 0 insertions, 0 deletions