Fix Issue 23173 - "Error: signed integer overflow" for compiler gener…

[dkorpel]

…ated string of long.min

I don't know of a clean way to write -9223372036854775808 typed as a long, so it's a bit ugly.

[dlang-bot]

Thanks for your pull request and interest in making D better, @dkorpel! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	23173	normal	"Error: signed integer overflow" for compiler generated string of `long.min`

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#14218"

[dkorpel]

mir-algorithm wants to be able to parse the result of long.min.stringof.

        enum m = T.min + 0;
        str = m.stringof;
        assert(parse(str, val));
        val.should == T.min;

https://github.com/libmir/mir-algorithm/blob/69868ac096204c3735af2b1574cf9bbfd43e268c/source/mir/parse.d#L398-L401

[dkorpel]

Perhaps the lexer should just allow 9223372036854775808L

[maxhaton]

Can we not just make the lexer more lenient?

[dkorpel]

Can we not just make the lexer more lenient?

Yes, but that would also allow:

long x = 9223372036854775808L; // will overflow

[maxhaton]

Can we not just make the lexer more lenient?

Yes, but that would also allow:

long x = 9223372036854775808L; // will overflow

Move the check into the semantic analysis. Doing it in the lexer in the first place is silly for this reason

[dkorpel]

Move the check into the semantic analysis.

What will typeof(9223372036854775808L) be then?

[maxhaton]

Move the check into the semantic analysis.

What will typeof(9223372036854775808L) be then?

An error. The semantics don't have to change it's just that doing the check in the lexer is completely wrong

[thewilsonator]

not that this needs to take it into account but (when) is cent becoming a thing? Will we have the same problems there?

[dkorpel]

What will typeof(9223372036854775808L) be then?

An error. The semantics don't have to change it's just that doing the check in the lexer is completely wrong

Then -9223372036854775808L will be an error as well. What's stumping me is that the lexer/parser still need to generate some IntegerExp for 9223372036854775808L with a type and a value.

[dkorpel]

not that this needs to take it into account but (when) is cent becoming a thing?

Walter thinks it should stay a library type, because its usage is not common and it would complicate the compiler / make dmd use more memory.

Will we have the same problems there?

If it's implemented in the same way as long/ulong, then yes.

[ibuclaw]

Suggested change

	if (v == long.min)
	{
	// https://issues.dlang.org/show_bug.cgi?id=23173
	// This is a special case because - is not part of the
	// integer literal and 9223372036854775808L overflows a long
	buf.writestring("cast(long)-9223372036854775808");
	}
	else
	{
	buf.printf("%lldL", v);
	}
	buf.printf("cast(long)%lldL", v);

Is there any reason why we can't just throw in the cast implicitly?

[ibuclaw]

Only just noticing the other discussion.

[ljmf00]

Move the check into the semantic analysis.

What will typeof(9223372036854775808L) be then?

An error. The semantics don't have to change it's just that doing the check in the lexer is completely wrong

AFAIK, most of these overflow checks are being made in the lexer. The lexer token has a special case for integers. Which I don't think it should be the way to do it, unless there's any performance benefits that overcome the complexity of adding such special case.

[thewilsonator]

Dependant PR merged

[dkorpel]

auto-test failure looks unrelated

****** FAIL release64 std.experimental.logger.core
core.exception.AssertError@std/experimental/logger/core.d(2228): lineCall(2098) ll2Off(1) gll(1) ll(1) ll2(96) cond(0) condValue(0) memOrG(1) shouldLog(1) foo == 199 1 1 1 1 1

[dkorpel]

@RazvanN7 this is ready for review