2015-12-09 18:22:48 -07:00
|
|
|
// errorcheck
|
|
|
|
|
|
|
|
|
|
// Copyright 2015 The Go Authors. All rights reserved.
|
|
|
|
|
// Use of this source code is governed by a BSD-style
|
|
|
|
|
// license that can be found in the LICENSE file.
|
|
|
|
|
|
|
|
|
|
// Verify that error messages print meaningful values
|
|
|
|
|
// for various extreme floating-point constants.
|
|
|
|
|
|
|
|
|
|
package p
|
|
|
|
|
|
|
|
|
|
// failure case in issue
|
|
|
|
|
const _ int64 = 1e-10000 // ERROR "1e\-10000 truncated"
|
|
|
|
|
|
|
|
|
|
const (
|
cmd/compile: fix misleading "truncated to int" messages
When defining an int const, the compiler tries to cast the RHS
expression to int. The cast may fail for three reasons:
1. expr is an integer constant that overflows int
2. expr is a floating point constant
3. expr is a complex constant, or not a number
In the second case, in order to print a sensible error message, we
must distinguish between a floating point constant that should be
included in the error message and a floating point constant that
cannot be reasonably formatted for inclusion in an error message.
For example, in:
const a int = 1.1
const b int = 1 + 1e-100
a is in the former group, while b is in the latter, since the floating
point value resulting from the evaluation of the rhs of the assignment
(1.00...01) is too long to be fully printed in an error message, and
cannot be shortened without making the error message misleading
(rounding or truncating it would result in a "1", which looks like an
integer constant, and it makes little sense in an error message about
an invalid floating point expression).
To fix this problem, we try to format the float value using fconv
(which is used by the error reporting mechanism to format float
arguments), and then parse the resulting string back to a
big.Float. If the result is an integer, we assume that expr is a float
value that cannot be reasonably be formatted as a string, and we emit
an error message that does not include its string representation.
Also, change the error message for overflows to a more conservative
"integer too large", which does not mention overflows that are only
caused by an internal implementation restriction.
Also, change (*Mpint) SetFloat so that it returns a bool (instead of
0/-1 for success/failure).
Fixes #11371
Change-Id: Ibbc73e2ed2eaf41f07827b0649d0eb637150ecaa
Reviewed-on: https://go-review.googlesource.com/35411
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
2017-01-18 03:48:14 -07:00
|
|
|
_ int64 = 1e10000000 // ERROR "integer too large"
|
|
|
|
|
_ int64 = 1e1000000 // ERROR "integer too large"
|
|
|
|
|
_ int64 = 1e100000 // ERROR "integer too large"
|
|
|
|
|
_ int64 = 1e10000 // ERROR "integer too large"
|
|
|
|
|
_ int64 = 1e1000 // ERROR "integer too large"
|
2015-12-09 18:22:48 -07:00
|
|
|
_ int64 = 1e100 // ERROR "10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 overflows"
|
|
|
|
|
_ int64 = 1e10
|
|
|
|
|
_ int64 = 1e1
|
|
|
|
|
_ int64 = 1e0
|
|
|
|
|
_ int64 = 1e-1 // ERROR "0\.1 truncated"
|
|
|
|
|
_ int64 = 1e-10 // ERROR "1e\-10 truncated"
|
|
|
|
|
_ int64 = 1e-100 // ERROR "1e\-100 truncated"
|
|
|
|
|
_ int64 = 1e-1000 // ERROR "1e\-1000 truncated"
|
|
|
|
|
_ int64 = 1e-10000 // ERROR "1e\-10000 truncated"
|
|
|
|
|
_ int64 = 1e-100000 // ERROR "1e\-100000 truncated"
|
|
|
|
|
_ int64 = 1e-1000000 // ERROR "1e\-1000000 truncated"
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
const (
|
cmd/compile: fix misleading "truncated to int" messages
When defining an int const, the compiler tries to cast the RHS
expression to int. The cast may fail for three reasons:
1. expr is an integer constant that overflows int
2. expr is a floating point constant
3. expr is a complex constant, or not a number
In the second case, in order to print a sensible error message, we
must distinguish between a floating point constant that should be
included in the error message and a floating point constant that
cannot be reasonably formatted for inclusion in an error message.
For example, in:
const a int = 1.1
const b int = 1 + 1e-100
a is in the former group, while b is in the latter, since the floating
point value resulting from the evaluation of the rhs of the assignment
(1.00...01) is too long to be fully printed in an error message, and
cannot be shortened without making the error message misleading
(rounding or truncating it would result in a "1", which looks like an
integer constant, and it makes little sense in an error message about
an invalid floating point expression).
To fix this problem, we try to format the float value using fconv
(which is used by the error reporting mechanism to format float
arguments), and then parse the resulting string back to a
big.Float. If the result is an integer, we assume that expr is a float
value that cannot be reasonably be formatted as a string, and we emit
an error message that does not include its string representation.
Also, change the error message for overflows to a more conservative
"integer too large", which does not mention overflows that are only
caused by an internal implementation restriction.
Also, change (*Mpint) SetFloat so that it returns a bool (instead of
0/-1 for success/failure).
Fixes #11371
Change-Id: Ibbc73e2ed2eaf41f07827b0649d0eb637150ecaa
Reviewed-on: https://go-review.googlesource.com/35411
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
2017-01-18 03:48:14 -07:00
|
|
|
_ int64 = -1e10000000 // ERROR "integer too large"
|
|
|
|
|
_ int64 = -1e1000000 // ERROR "integer too large"
|
|
|
|
|
_ int64 = -1e100000 // ERROR "integer too large"
|
|
|
|
|
_ int64 = -1e10000 // ERROR "integer too large"
|
|
|
|
|
_ int64 = -1e1000 // ERROR "integer too large"
|
2015-12-09 18:22:48 -07:00
|
|
|
_ int64 = -1e100 // ERROR "\-10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 overflows"
|
|
|
|
|
_ int64 = -1e10
|
|
|
|
|
_ int64 = -1e1
|
|
|
|
|
_ int64 = -1e0
|
|
|
|
|
_ int64 = -1e-1 // ERROR "\-0\.1 truncated"
|
|
|
|
|
_ int64 = -1e-10 // ERROR "\-1e\-10 truncated"
|
|
|
|
|
_ int64 = -1e-100 // ERROR "\-1e\-100 truncated"
|
|
|
|
|
_ int64 = -1e-1000 // ERROR "\-1e\-1000 truncated"
|
|
|
|
|
_ int64 = -1e-10000 // ERROR "\-1e\-10000 truncated"
|
|
|
|
|
_ int64 = -1e-100000 // ERROR "\-1e\-100000 truncated"
|
|
|
|
|
_ int64 = -1e-1000000 // ERROR "\-1e\-1000000 truncated"
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
const (
|
cmd/compile: fix misleading "truncated to int" messages
When defining an int const, the compiler tries to cast the RHS
expression to int. The cast may fail for three reasons:
1. expr is an integer constant that overflows int
2. expr is a floating point constant
3. expr is a complex constant, or not a number
In the second case, in order to print a sensible error message, we
must distinguish between a floating point constant that should be
included in the error message and a floating point constant that
cannot be reasonably formatted for inclusion in an error message.
For example, in:
const a int = 1.1
const b int = 1 + 1e-100
a is in the former group, while b is in the latter, since the floating
point value resulting from the evaluation of the rhs of the assignment
(1.00...01) is too long to be fully printed in an error message, and
cannot be shortened without making the error message misleading
(rounding or truncating it would result in a "1", which looks like an
integer constant, and it makes little sense in an error message about
an invalid floating point expression).
To fix this problem, we try to format the float value using fconv
(which is used by the error reporting mechanism to format float
arguments), and then parse the resulting string back to a
big.Float. If the result is an integer, we assume that expr is a float
value that cannot be reasonably be formatted as a string, and we emit
an error message that does not include its string representation.
Also, change the error message for overflows to a more conservative
"integer too large", which does not mention overflows that are only
caused by an internal implementation restriction.
Also, change (*Mpint) SetFloat so that it returns a bool (instead of
0/-1 for success/failure).
Fixes #11371
Change-Id: Ibbc73e2ed2eaf41f07827b0649d0eb637150ecaa
Reviewed-on: https://go-review.googlesource.com/35411
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
2017-01-18 03:48:14 -07:00
|
|
|
_ int64 = 1.23456789e10000000 // ERROR "integer too large"
|
|
|
|
|
_ int64 = 1.23456789e1000000 // ERROR "integer too large"
|
|
|
|
|
_ int64 = 1.23456789e100000 // ERROR "integer too large"
|
|
|
|
|
_ int64 = 1.23456789e10000 // ERROR "integer too large"
|
|
|
|
|
_ int64 = 1.23456789e1000 // ERROR "integer too large"
|
2015-12-09 18:22:48 -07:00
|
|
|
_ int64 = 1.23456789e100 // ERROR "12345678900000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 overflows"
|
|
|
|
|
_ int64 = 1.23456789e10
|
|
|
|
|
_ int64 = 1.23456789e1 // ERROR "12\.3457 truncated"
|
|
|
|
|
_ int64 = 1.23456789e0 // ERROR "1\.23457 truncated"
|
|
|
|
|
_ int64 = 1.23456789e-1 // ERROR "0\.123457 truncated"
|
|
|
|
|
_ int64 = 1.23456789e-10 // ERROR "1\.23457e\-10 truncated"
|
|
|
|
|
_ int64 = 1.23456789e-100 // ERROR "1\.23457e\-100 truncated"
|
|
|
|
|
_ int64 = 1.23456789e-1000 // ERROR "1\.23457e\-1000 truncated"
|
|
|
|
|
_ int64 = 1.23456789e-10000 // ERROR "1\.23457e\-10000 truncated"
|
|
|
|
|
_ int64 = 1.23456789e-100000 // ERROR "1\.23457e\-100000 truncated"
|
|
|
|
|
_ int64 = 1.23456789e-1000000 // ERROR "1\.23457e\-1000000 truncated"
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
const (
|
cmd/compile: fix misleading "truncated to int" messages
When defining an int const, the compiler tries to cast the RHS
expression to int. The cast may fail for three reasons:
1. expr is an integer constant that overflows int
2. expr is a floating point constant
3. expr is a complex constant, or not a number
In the second case, in order to print a sensible error message, we
must distinguish between a floating point constant that should be
included in the error message and a floating point constant that
cannot be reasonably formatted for inclusion in an error message.
For example, in:
const a int = 1.1
const b int = 1 + 1e-100
a is in the former group, while b is in the latter, since the floating
point value resulting from the evaluation of the rhs of the assignment
(1.00...01) is too long to be fully printed in an error message, and
cannot be shortened without making the error message misleading
(rounding or truncating it would result in a "1", which looks like an
integer constant, and it makes little sense in an error message about
an invalid floating point expression).
To fix this problem, we try to format the float value using fconv
(which is used by the error reporting mechanism to format float
arguments), and then parse the resulting string back to a
big.Float. If the result is an integer, we assume that expr is a float
value that cannot be reasonably be formatted as a string, and we emit
an error message that does not include its string representation.
Also, change the error message for overflows to a more conservative
"integer too large", which does not mention overflows that are only
caused by an internal implementation restriction.
Also, change (*Mpint) SetFloat so that it returns a bool (instead of
0/-1 for success/failure).
Fixes #11371
Change-Id: Ibbc73e2ed2eaf41f07827b0649d0eb637150ecaa
Reviewed-on: https://go-review.googlesource.com/35411
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
2017-01-18 03:48:14 -07:00
|
|
|
_ int64 = -1.23456789e10000000 // ERROR "integer too large"
|
|
|
|
|
_ int64 = -1.23456789e1000000 // ERROR "integer too large"
|
|
|
|
|
_ int64 = -1.23456789e100000 // ERROR "integer too large"
|
|
|
|
|
_ int64 = -1.23456789e10000 // ERROR "integer too large"
|
|
|
|
|
_ int64 = -1.23456789e1000 // ERROR "integer too large"
|
2015-12-09 18:22:48 -07:00
|
|
|
_ int64 = -1.23456789e100 // ERROR "\-12345678900000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 overflows"
|
|
|
|
|
_ int64 = -1.23456789e10
|
|
|
|
|
_ int64 = -1.23456789e1 // ERROR "\-12\.3457 truncated"
|
|
|
|
|
_ int64 = -1.23456789e0 // ERROR "\-1\.23457 truncated"
|
|
|
|
|
_ int64 = -1.23456789e-1 // ERROR "\-0\.123457 truncated"
|
|
|
|
|
_ int64 = -1.23456789e-10 // ERROR "\-1\.23457e\-10 truncated"
|
|
|
|
|
_ int64 = -1.23456789e-100 // ERROR "\-1\.23457e\-100 truncated"
|
|
|
|
|
_ int64 = -1.23456789e-1000 // ERROR "\-1\.23457e\-1000 truncated"
|
|
|
|
|
_ int64 = -1.23456789e-10000 // ERROR "\-1\.23457e\-10000 truncated"
|
|
|
|
|
_ int64 = -1.23456789e-100000 // ERROR "\-1\.23457e\-100000 truncated"
|
|
|
|
|
_ int64 = -1.23456789e-1000000 // ERROR "\-1\.23457e\-1000000 truncated"
|
|
|
|
|
)
|
