digitalmars.D - compile errors in attribute-inferred code
- aliak (45/45) Aug 01 2019 So this happened:
- Adam D. Ruppe (7/10) Aug 01 2019 Yes, I am of the opinion that it should show one layer next to
So this happened: A library I use had an safe test like this which was working great: auto result = [1, 2, 3] .map!(a => Try!(() => throwIfOdd(a))) .map!(tryResult => tryResult // <-- lambda .match!( (int _) => "even", (Exception _) => "odd" ) ); assert(result.equal(["odd", "even", "odd"])); Then all of a sudden, started failing on the CI. But the error message: Error: safe function ddash.utils.try_.__unittest_L10_C7 cannot call system function ddash.common.equal.equal!(null, MapResult!(__lambda3, MapResult!(__lambda2, int[])), string[]).equal And then it pointed me to equal in an implementation of equal that I had. Marking that safe then pointed me to std.algorithm.all, marking that safe pointed me to std.algorithm.find, marking that safe pointed me to "if (predFun(haystack.front))" ... and it went on. At the end, it turns out the CI was getting an updated version of a library called sumtype, which had added some safe inspections (so that's a good thing) but guess where the error was: The Try type contains a pointer to an Expect(T, Unexpected!Exception) type, and that in turn contains a SumType!(T, Unexpected!Exception). The Try type assigns the value of executing it's lambda to the Expect type (which is alias this'd to the SumType). The error was actually that the lambda was not safe, because it called .match on a try, which in turn calls resolve on a try, which assigned the result of the resolution to the expect type - that assignment was determined not safe because the sumtype didn't allow it. So I realize that drilling down all the way to what was actually unsafe can be painful, but what if it was limited to inferred code? Is that something feasible? So equal -> all -> find -> predFun (this called front on a map) -> lambda -> match -> try.resolve and it can stop there? Basically the error "cannot call system function equal" is pretty useless, so I'm wondering if there's anything that can be feasibly done about that? Cheers, - ali
Aug 01 2019
On Thursday, 1 August 2019 at 23:12:36 UTC, aliak wrote:So I realize that drilling down all the way to what was actually unsafe can be painful, but what if it was limited to inferred code? Is that something feasible?Yes, I am of the opinion that it should show one layer next to the bottom most inferred thing. I put it in bugzilla https://issues.dlang.org/show_bug.cgi?id=17374 Over two years later, no change :( will prolly have to do it ourselves.
Aug 01 2019