October 26, 2015 Re: Improving assert-printing in DMD | ||||
---|---|---|---|---|
| ||||
Posted in reply to Per Nordlöw | On Thursday, 1 October 2015 at 11:51:29 UTC, Per Nordlöw wrote:
> On Tuesday, 29 September 2015 at 21:02:42 UTC, Nordlöw wrote:
>> As a follow-up to
>>
>> https://github.com/D-Programming-Language/phobos/pull/3207#issuecomment-144073495
>
> I added a long comment about a new more flexible solution to this problem:
>
> https://github.com/D-Programming-Language/phobos/pull/3207#issuecomment-144701371
Would `onAssertFailed` have an implementation in druntime? If one is included with D after this DIP is implemented, how would one override the default behaviour? Do I understand it correctly that `assert(a == b)` and `assert(a != b)` would call different overloads? The reason I ask about that last one is because there's no overloading of `!=` in D.
Atila
|
October 26, 2015 Re: Improving assert-printing in DMD | ||||
---|---|---|---|---|
| ||||
Posted in reply to Atila Neves | On Monday, 26 October 2015 at 15:17:37 UTC, Atila Neves wrote: > Would `onAssertFailed` have an implementation in druntime? Yes, that's my plan. > If one is included with D after this DIP is implemented, how would one override the default behaviour? > Do I understand it correctly that `assert(a == b)` and `assert(a != b)` would call different overloads? That depends on how we want this to work. > The reason I ask about that last one is because there's no overloading of `!=` in D. > > Atila Ahh, good catch. Eventhough compiler rewrites X != Y into !(X == Y) and we cannot explicit overload opBinary!"!=" there is nothing stopping us allowing onBinaryAssert!"!=" in the rewriter. I'll update http://wiki.dlang.org/DIP83 with a proposed solution for `!=`-lowering. |
October 26, 2015 Re: Improving assert-printing in DMD | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nordlöw | On Monday, 26 October 2015 at 17:36:37 UTC, Nordlöw wrote:
> On Monday, 26 October 2015 at 15:17:37 UTC, Atila Neves wrote:
>> Would `onAssertFailed` have an implementation in druntime?
>
> Yes, that's my plan.
>
>> If one is included with D after this DIP is implemented, how would one override the default behaviour?
I haven't thought about that in detail. One way would be to have a default implementation in druntime, say in `core.assert` that triggers pretty pretting when imported. For this work in a convenient way, it could be convenient to move logic from std.conv to, say, `core.conv`. `core.assert` could then import `core.conv` in order to reuse toString-conversion logic for, say, builtin types and types that have the member `string toString`.
Maybe we need to propose a set of alternatives and do a vote about how to solve this.
|
October 26, 2015 Re: Improving assert-printing in DMD | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nordlöw | On Monday, 26 October 2015 at 17:36:37 UTC, Nordlöw wrote:
> I'll update
>
> http://wiki.dlang.org/DIP83
>
> with a proposed solution for `!=`-lowering.
Update along with other changes...done.
|
October 26, 2015 Re: Improving assert-printing in DMD | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nordlöw | On Monday, 26 October 2015 at 17:36:37 UTC, Nordlöw wrote:
> Eventhough compiler rewrites
>
> X != Y
>
> into
>
> !(X == Y)
>
> and we cannot explicit overload opBinary!"!=" there is nothing stopping us allowing
>
> onBinaryAssert!"!="
>
> in the rewriter.
Correction:
there is nothing stopping us from allowing
onAssertFailed!"!="
to be defined as long as the compiler lowering logic can do the correct rewrite.
|
October 26, 2015 Re: Improving assert-printing in DMD | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nordlöw | On Monday, 26 October 2015 at 19:17:13 UTC, Nordlöw wrote: > there is nothing stopping us from allowing > > onAssertFailed!"!=" > > to be defined as long as the compiler lowering logic can do the correct rewrite. For further details, see also: http://wiki.dlang.org/DIP83#Non-Equality_Operator_Lowering |
October 26, 2015 Re: Improving assert-printing in DMD | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nordlöw | On Monday, 26 October 2015 at 17:50:13 UTC, Nordlöw wrote:
> On Monday, 26 October 2015 at 17:36:37 UTC, Nordlöw wrote:
>> On Monday, 26 October 2015 at 15:17:37 UTC, Atila Neves wrote:
>>> [...]
>>
>> Yes, that's my plan.
>>
>>> [...]
>
> I haven't thought about that in detail. One way would be to have a default implementation in druntime, say in `core.assert` that triggers pretty pretting when imported. For this work in a convenient way, it could be convenient to move logic from std.conv to, say, `core.conv`. `core.assert` could then import `core.conv` in order to reuse toString-conversion logic for, say, builtin types and types that have the member `string toString`.
>
> Maybe we need to propose a set of alternatives and do a vote about how to solve this.
I think druntime should at least be mentioned in the DIP.
Atila
|
October 31, 2015 Re: Improving assert-printing in DMD | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nordlöw | On Tuesday, 29 September 2015 at 21:02:42 UTC, Nordlöw wrote:
> As a follow-up to
>
> https://github.com/D-Programming-Language/phobos/pull/3207#issuecomment-144073495
>
> I starting digging in DMD for logic controlling behaviour of assert(), especially whether it's possible to add automatic printing of `lhs` and `rhs` upon assertion failure if `AssertExp` is a binary expression say `lhs == rhs`.
>
> After grepping for `AssertExp` the only possible place I could think of was
>
> ToElemVisitor::visit(AssertExp *ae)
>
> inside
>
> elem *toElem(Expression *e, IRState *irs)
>
> in file e2ir.c.
>
> Questions:
>
> 1. Is this the right place where this lhs-rhs-printing logic should be added? If so could somebody tell me how to make this happen?
>
> 2. Is it possible to from within DMD generate expressions that do
>
> `import std.stdio : write`
>
> and then calls write on the `lhs` and `rsh`...or this a completely wrong approach to solving this problem?
More thoughts on this: what about ranges and testing for equality? It would be helpful if either this DIP made the compiler recognise and deal with `std.algorithm.equal` differently or recognise that on one or both sides of `==` there's a range.
I'm thinking of all the different `shouldXXX` functions I wrote for unit-threaded. Equality is by far the most common thing to assert on in a test, but there are other useful ones that need to be considered. Two that come to mind right now are asserting that a range contains an element and that two ranges are the same ignoring ordering.
For the former, `assert(range.canFind(elt))` would be hard to deal with in this DIP. I don't see a better way, however, since `in` only works for AAs.
For the latter... I don't know either.
Atila
|
Copyright © 1999-2021 by the D Language Foundation