Skip to content

GitLab

Switch branch/tag
  1. 15 Nov, 2019 1 commit
    • go101's avatar
      reflect: factor out special channel assignability rule from haveIdenticalUnderlyingType · 4e8d2706
      go101 authored 
      Go specification says: A value x is assignable to a variable of type T if x
is a bidirectional channel value, T is a channel type, x's type V and T have
identical element types, and at least one of V or T is not a defined type.
However, the current reflection implementation is incorrect which makes
"x is assignable to T" even if type V and T are both defined type.

The current reflection implementation also mistakes the base types of two
non-defined pointer types share the same underlying type when the two
base types satisfy the above mentioned special channel assignability rule.

Fixes #29469

Change-Id: Ia4b9c4ac47dc8e76a11faef422b2e5c5726b78b3
GitHub-Last-Rev: 487c20a564091a1d2ba5feb95ab5196331c699c2
GitHub-Pull-Request: golang/go#29739
Reviewed-on: https://go-review.googlesource.com/c/go/+/157822


Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      4e8d2706
  3. 22 Oct, 2019 1 commit
  5. 21 Oct, 2019 1 commit
  7. 10 Oct, 2019 1 commit
    • Brad Fitzpatrick's avatar
      all: remove nacl (part 3, more amd64p32) · 03ef105d
      Brad Fitzpatrick authored 
      Part 1: CL 199499 (GOOS nacl)
Part 2: CL 200077 (amd64p32 files, toolchain)
Part 3: stuff that arguably should've been part of Part 2, but I forgot
        one of my grep patterns when splitting the original CL up into
        two parts.

This one might also have interesting stuff to resurrect for any future
x32 ABI support.

Updates #30439

Change-Id: I2b4143374a253a003666f3c69e776b7e456bdb9c
Reviewed-on: https://go-review.googlesource.com/c/go/+/200318


Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      03ef105d
  9. 09 Oct, 2019 1 commit
  11. 28 Sep, 2019 1 commit
  13. 18 Sep, 2019 1 commit
    • Jean de Klerk's avatar
      reflect: give type hints in error messages · 09824ccf
      Jean de Klerk authored 
      Currently, if you call various reflect methods you might get a panic with a
message like, "reflect: Field of non-struct type". Sometimes it's easy to
grok what's going on, but other times you need to laboriously go perform
reflect.ValueOf(myType).Kind().

This CL just adds that detail to the error message, saving debuggers the
extra step and making the error message more clear.

Change-Id: I7e0c211a3001e6b217b828cbcf50518080b5cb1e
Reviewed-on: https://go-review.googlesource.com/c/go/+/183097

Reviewed-by: default avatarDaniel Martí <mvdan@mvdan.cc>
Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      09824ccf
  15. 03 Sep, 2019 1 commit
    • Keith Randall's avatar
      cmd/compile,runtime: generate hash functions only for types which are map keys · 36f30ba2
      Keith Randall authored 
      Right now we generate hash functions for all types, just in case they
are used as map keys. That's a lot of wasted effort and binary size
for types which will never be used as a map key. Instead, generate
hash functions only for types that we know are map keys.

Just doing that is a bit too simple, since maps with an interface type
as a key might have to hash any concrete key type that implements that
interface. So for that case, implement hashing of such types at
runtime (instead of with generated code). It will be slower, but only
for maps with interface types as keys, and maybe only a bit slower as
the aeshash time probably dominates the dispatch time.

Reorg where we keep the equals and hash functions. Move the hash function
from the key type to the map type, saving a field in every non-map type.
That leaves only one function in the alg structure, so get rid of that and
just keep the equal function in the type descriptor itself.

cmd/go now has 10 generated hash functions, instead of 504. Makes
cmd/go 1.0% smaller. Update #6853.

Speed on non-interface keys is unchanged. Speed on interface keys
is ~20% slower:

name                  old time/op  new time/op  delta
MapInterfaceString-8  23.0ns ±21%  27.6ns ±14%  +20.01%  (p=0.002 n=10+10)
MapInterfacePtr-8     19.4ns ±16%  23.7ns ± 7%  +22.48%   (p=0.000 n=10+8)

Change-Id: I7c2e42292a46b5d4e288aaec4029bdbb01089263
Reviewed-on: https://go-review.googlesource.com/c/go/+/191198


Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarMartin Möhrmann <moehrmann@google.com>
      36f30ba2
  17. 02 Sep, 2019 1 commit
  19. 27 Aug, 2019 1 commit
  21. 03 Apr, 2019 1 commit
  23. 26 Mar, 2019 2 commits
  25. 25 Mar, 2019 1 commit
  27. 08 Mar, 2019 1 commit
    • Daniel Martí's avatar
      all: simplify multiple for loops · 49662bc6
      Daniel Martí authored 
      If a for loop has a simple condition and begins with a simple
"if x { break; }"; we can simply add "!x" to the loop's condition.

While at it, simplify a few assignments to use the common pattern
"x := staticDefault; if cond { x = otherValue(); }".

Finally, simplify a couple of var declarations.

Change-Id: I413982c6abd32905adc85a9a666cb3819139c19f
Reviewed-on: https://go-review.googlesource.com/c/go/+/165342


Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      49662bc6
  29. 07 Mar, 2019 1 commit
    • Keith Randall's avatar
      reflect: fix more issues with StructOf GC programs · 9dc3b8b7
      Keith Randall authored 
      First the insidious bug:

  var n uintptr
  for n := elemPtrs; n > 120; n -= 120 {
    prog = append(prog, 120)
    prog = append(prog, mask[:15]...)
    mask = mask[15:]
  }
  prog = append(prog, byte(n))
  prog = append(prog, mask[:(n+7)/8]...)

The := breaks this code, because the n after the loop is always 0!

We also do need to handle field padding correctly. In particular
the old padding code doesn't correctly handle fields that are not
a multiple of a pointer in size.

Fixes #30606.

Change-Id: Ifcab9494dc25c20116753c5d7e0145d6c2053ed8
Reviewed-on: https://go-review.googlesource.com/c/go/+/165860


Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      9dc3b8b7
  31. 06 Mar, 2019 1 commit
  33. 29 Dec, 2018 1 commit
  35. 16 Nov, 2018 1 commit
  37. 06 Nov, 2018 1 commit
  39. 02 Nov, 2018 1 commit
    • Brad Fitzpatrick's avatar
      all: use "reports whether" consistently in the few places that didn't · 3813edf2
      Brad Fitzpatrick authored 
      Go documentation style for boolean funcs is to say:

    // Foo reports whether ...
    func Foo() bool

(rather than "returns true if")

This CL also replaces 4 uses of "iff" with the same "reports whether"
wording, which doesn't lose any meaning, and will prevent people from
sending typo fixes when they don't realize it's "if and only if". In
the past I think we've had the typo CLs updated to just say "reports
whether". So do them all at once.

(Inspired by the addition of another "returns true if" in CL 146938
in fd_plan9.go)

Created with:

$ perl -i -npe 's/returns true if/reports whether/' $(git grep -l "returns true iff" | grep -v vendor)
$ perl -i -npe 's/returns true if/reports whether/' $(git grep -l "returns true if" | grep -v vendor)

Change-Id: Ided502237f5ab0d25cb625dbab12529c361a8b9f
Reviewed-on: https://go-review.googlesource.com/c/147037

Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      3813edf2
  41. 29 Sep, 2018 1 commit
    • Keith Randall's avatar
      reflect: ensure correct scanning of return values · ef503739
      Keith Randall authored 
      During a call to a reflect-generated function or method (via
makeFuncStub or methodValueCall), when should we scan the return
values?

When we're starting a reflect call, the space on the stack for the
return values is not initialized yet, as it contains whatever junk was
on the stack of the caller at the time. The return space must not be
scanned during a GC.

When we're finishing a reflect call, the return values are
initialized, and must be scanned during a GC to make sure that any
pointers in the return values are found and their referents retained.

When the GC stack walk comes across a reflect call in progress on the
stack, it needs to know whether to scan the results or not. It doesn't
know the progress of the reflect call, so it can't decide by
itself. The reflect package needs to tell it.

This CL adds another slot in the frame of makeFuncStub and
methodValueCall so we can put a boolean in there which tells the
runtime whether to scan the results or not.

This CL also adds the args length to reflectMethodValue so the
runtime can restrict its scanning to only the args section (not the
results) if the reflect package says the results aren't ready yet.

Do a delicate dance in the reflect package to set the "results are
valid" bit. We need to make sure we set the bit only after we've
copied the results back to the stack. But we must set the bit before
we drop reflect's copy of the results. Otherwise, we might have a
state where (temporarily) no one has a live copy of the results.
That's the state we were observing in issue #27695 before this CL.

The bitmap used by the runtime currently contains only the args.
(Actually, it contains all the bits, but the size is set so we use
only the args portion.) This is safe for early in a reflect call, but
unsafe late in a reflect call. The test issue27695.go demonstrates
this unsafety. We change the bitmap to always include both args
and results, and decide at runtime which portion to use.

issue27695.go only has a test for method calls. Function calls were ok
because there wasn't a safepoint between when reflect dropped its copy
of the return values and when the caller is resumed. This may change
when we introduce safepoints everywhere.

This truncate-to-only-the-args was part of CL 9888 (in 2015). That
part of the CL fixed the problem demonstrated in issue27695b.go but
introduced the problem demonstrated in issue27695.go.

TODO, in another CL: simplify FuncLayout and its test. stack return
value is now identical to frametype.ptrdata + frametype.gcdata.

Fixes #27695

Change-Id: I2d49b34e34a82c6328b34f02610587a291b25c5f
Reviewed-on: https://go-review.googlesource.com/137440


Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarAustin Clements <austin@google.com>
      ef503739
  43. 26 Sep, 2018 1 commit
  45. 28 Jun, 2018 1 commit
    • Ian Lance Taylor's avatar
      reflect: remove struct tags from unexported types · 997d7a18
      Ian Lance Taylor authored 
      Before CL 4281055 in 2011, the reflect package was quite different.
rtype, then called commonType, was embedded in exported structs with
names like StructType. In order to avoid accidental conversions
between pointers to these public structs, which sometimes had
identical fields, the embedded commonType fields were tagged.

In CL 4281055 the formerly public structs were unexported, and all
access was done through the Type interface. At that point the field
tags in the reflect structs were no longer useful.

In Go 1.8 the language was changed to ignore struct field tags when
converting between types. This made the field tags in the reflect
structs doubly useless.

This CL simply removes them.

Fixes #20914

Change-Id: I9af4d6d0709276a91a6b6ee5323cad9dcd0cd0a0
Reviewed-on: https://go-review.googlesource.com/121475


Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      997d7a18
  47. 27 Jun, 2018 1 commit
  49. 29 May, 2018 1 commit
  51. 10 May, 2018 1 commit
  53. 06 May, 2018 1 commit
    • Martin Möhrmann's avatar
      runtime: remove hmap field from maptypes · 4ebc67d3
      Martin Möhrmann authored 
      The hmap field in the maptype is only used by the runtime to check the sizes of
the hmap structure created by the compiler and runtime agree.

Comments are already present about the hmap structure definitions in the
compiler and runtime needing to be in sync.

Add a test that checks the runtimes hmap size is as expected to detect
when the compilers and runtimes hmap sizes diverge instead of checking
this at runtime when a map is created.

Change-Id: I974945ebfdb66883a896386a17bbcae62a18cf2a
Reviewed-on: https://go-review.googlesource.com/91796


Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: default avatarJosh Bleecher Snyder <josharian@gmail.com>
      4ebc67d3
  55. 15 Mar, 2018 1 commit
  57. 17 Feb, 2018 1 commit
  59. 09 Jan, 2018 1 commit
  61. 02 Jan, 2018 1 commit
  63. 01 Dec, 2017 1 commit
  65. 27 Sep, 2017 1 commit
  67. 05 Sep, 2017 1 commit
  69. 23 Aug, 2017 1 commit
  71. 16 Aug, 2017 1 commit
  73. 15 Jul, 2017 1 commit
  75. 13 Jun, 2017 1 commit
    • Pravendra Singh's avatar
      reflect: prevent structs with invalid field name · 538b3a5f
      Pravendra Singh authored 
      According to the language spec, a struct field name should
be an identifier.

  identifier = letter { letter | unicode_digit } .
  letter = unicode_letter | "_" .

Implements a function 'isValidFieldName(fieldName string) bool'.
To check if the field name is a valid identifier or not.
It will panic if the field name is invalid.

It uses the non-exported function implementation 'isLetter'
from the package 'scanner', used to parse an identifier.

Fixes #20600.

Change-Id: I1db7db1ad88cab5dbea6565be15cc7461cc56c44
Reviewed-on: https://go-review.googlesource.com/45590

Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      538b3a5f
  77. 08 Jun, 2017 1 commit
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7