delta/go-git.git/src/go/constant, branch dev.inline

go/constant: follow-up for https://go-review.googlesource.com/32870

2016-11-07T20:59:49+00:00

For #17812.

Change-Id: I58411aaa0e8b2250a16ddb20c951e39da3d601e8
Reviewed-on: https://go-review.googlesource.com/32872
Reviewed-by: Alan Donovan

go/constant: improved fatal error messages

2016-11-07T19:09:21+00:00

Fixes #17812.

Change-Id: I08202165dd3f72ae04420e7b6129b8b689e74f5c
Reviewed-on: https://go-review.googlesource.com/32870
Reviewed-by: Alan Donovan

go/constant: document that BinaryOp doesn't handle comparisons or shifts

2016-11-05T23:59:04+00:00

Fixes #17797.

Change-Id: I544df81c4bcf3cbd36a793be40050f14f9a9974f
Reviewed-on: https://go-review.googlesource.com/32761
Reviewed-by: Dominik Honnef

go/constant: document that Value.String and ExactString return quoted strings

2016-09-07T04:28:35+00:00

This has always been the case but it was not obvious from the documentation.
The reason for the quoting is that String() may return an abbreviated string,
starting with double-quote (") but ending in ... (w/o a quote). The missing
quote indicates the abbreviation (in contrast to a string ending in ...").

constant.StringVal can be used to obtain the unquoted string of a String Value.

Change-Id: Id0ba45b6ff62b3e024386ba8d907d6b3a4fcb6d7
Reviewed-on: https://go-review.googlesource.com/28576
Reviewed-by: Alan Donovan

math/big: special-case a 0 mantissa during Rat parsing

2016-06-24T20:51:06+00:00

Previously, a 0 mantissa was special-cased during big.Float
parsing, but not during big.Rat parsing. This meant that a value
like 0e9999999999 would parse successfully in big.Float.SetString,
but would hang in big.Rat.SetString. This discrepancy became an
issue in https://golang.org/src/go/constant/value.go?#L250,
where the big.Float would report an exponent of 0, so
big.Rat.SetString would be used and would subsequently hang.

A Go Playground example of this is https://play.golang.org/p/3fy28eUJuF

The solution is to special-case a zero mantissa during big.Rat
parsing as well, so that neither big.Rat nor big.Float will hang when
parsing a value with 0 mantissa but a large exponent.

This was discovered using go-fuzz on CockroachDB:
https://github.com/cockroachdb/go-fuzz/blob/master/examples/parser/main.go

Fixes #16176

Change-Id: I775558a8682adbeba1cc9d20ba10f8ed26259c56
Reviewed-on: https://go-review.googlesource.com/24430
Reviewed-by: Robert Griesemer 
Run-TryBot: Robert Griesemer 
TryBot-Result: Gobot Gobot

go/constant: fix typos in MakeFromLiteral docs

2016-03-01T06:04:27+00:00

Change-Id: I99c737415a082df883a9c12cdb43bdd5a1b9a8ad
Reviewed-on: https://go-review.googlesource.com/20082
Reviewed-by: Brad Fitzpatrick

go/constant: fix doc strings

2016-02-18T17:44:29+00:00

Fixes #14357.

Change-Id: I91acff0b0cc7be2bcbad68925a19a437dbd4c83d
Reviewed-on: https://go-review.googlesource.com/19620
Reviewed-by: Alan Donovan

go/constant: fix String() implementation

2016-02-08T23:10:00+00:00

Fixes #14262.

Change-Id: Id590995dd4460e81f6b91bcfb3f02515a97650fe
Reviewed-on: https://go-review.googlesource.com/19361
Run-TryBot: Robert Griesemer 
Reviewed-by: Alan Donovan 
TryBot-Result: Gobot Gobot

go/constant: use Float.Rat method instead of doing it manually

2015-12-16T00:24:11+00:00

Also fixed conversion bug and added corresponding test case.

Change-Id: I26f143fbc8d40a6d073ecb095e61b461495f3d68
Reviewed-on: https://go-review.googlesource.com/17872
Run-TryBot: Robert Griesemer 
TryBot-Result: Gobot Gobot 
Reviewed-by: Alan Donovan

go/constant: switch to floating-point representation when fractions become too large

2015-12-14T23:42:01+00:00

Use two internal representations for Float values (similar to what is done
for Int values). Transparently switch to a big.Float representation when
big.Rat values become unwieldy. This is almost never needed for real-world
programs but it is trivial to create test cases that cannot be handled with
rational arithmetic alone.

As a consequence, the go/constant API semantics changes slightly: Until now,
a value could always be represented in its "smallest" form (e.g., float values
that happened to be integers would be represented as integers). Now, constant
Kind depends on how the value was created, rather than its actual value. (The
reason why we cannot automatically "normalize" values to their smallest form
anymore is because floating-point numbers are not exact in general; and thus
normalization is often not possible in the first place, or would throw away
precision when it is not desired.) This has repercussions as to how constant
Values are used go/types and required corresponding adjustments.

Details of the changes:

go/constant package:
- use big.Rat and big.Float values to represent floating-point values
  (internal change)
- changed semantic of Value.Kind accordingly
- String now returns a short, human-readable form of a value
  (this leads to better error messages in go/types)
- added ToInt, ToFloat, and ToComplex conversion functions
- added ExactString to obtain an exact string form of a value

go/types:
- adjusted and simplified implementation of representableConst
- adjusted various places where Value.Kind was expected to be "smallest"
  by calling the respective ToInt/Float/Complex conversion functions
- enabled 5 disabled tests in stdlib_test.go that now work

api checker:
- print all constant values in a short human-readable form (floats are
  printed in floating-point form), but also print an exact form if it
  is different from the short form
- adjusted test golden file and go.1.1.text reference file

Fixes #11327.

Change-Id: I492b704aae5b0238e5b7cee13e18ffce61193587
Reviewed-on: https://go-review.googlesource.com/17360
Reviewed-by: Alan Donovan 
Run-TryBot: Robert Griesemer 
TryBot-Result: Gobot Gobot