show failing clauses in template constraint match attempts

[adamdruppe]

No description provided.

[dlang-bot]

Thanks for your pull request and interest in making D better, @adamdruppe! 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 annotated coverage diff directly on GitHub with CodeCov's browser extension
• 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

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

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

dub fetch digger
dub run digger -- build "master + dmd#9419"

[thewilsonator]

Thanks, I suspect the test suite will need a fair bit of updating (urgh).

[wilzbach]

Thanks, I suspect the test suite will need a fair bit of updating (urgh).

This should take care of updating most of the files:

./run.d AUTO_UPDATE=1

(it doesn't handle complicated cases)

[jacob-carlborg]

Looks like this could be const.

[jacob-carlborg]

const?

[jacob-carlborg]

Curly braces on their own lines.

[adamdruppe]

So what this does so far is, for a test program:

import std.algorithm;
struct R {}
void main() {
	sort([1,2,3].filter!("a == 1"));
	R r;
	sort(r);
}

We'll get error messages like this:

/home/me/test/ooooo.d(21): Error: template std.algorithm.sorting.sort cannot deduce function from argument types !()(FilterResult!(unaryFun, int[])), candidates are:
../generated/linux/release/64/../../../../../phobos/std/algorithm/sorting.d(1855):        std.algorithm.sorting.sort(alias
ess = "a < b", SwapStrategy ss = SwapStrategy.unstable, Range)(Range r) if ((ss == SwapStrategy.unstable && (hasSwappableElements!Range || hasAssignableElements!Range) || ss != SwapStrategy.unstable && hasAssignableElements!Range) && isRandomAccessRange!Range && hasSlicing!Range && hasLength!Range)
/home/me/test/ooooo.d(21):        constraint clause isRandomAccessRange!(FilterResult!(unaryFun, int[])) was false
/home/me/test/ooooo.d(23): Error: template std.algorithm.sorting.sort cannot deduce function from argument types !()(R), candidates are:
../generated/linux/release/64/../../../../../phobos/std/algorithm/sorting.d(1855):        std.algorithm.sorting.sort(alias
ess = "a < b", SwapStrategy ss = SwapStrategy.unstable, Range)(Range r) if ((ss == SwapStrategy.unstable && (hasSwappableElements!Range || hasAssignableElements!Range) || ss != SwapStrategy.unstable && hasAssignableElements!Range) && isRandomAccessRange!Range && hasSlicing!Range && hasLength!Range)
/home/me/test/ooooo.d(23):        constraint clause hasSwappableElements!(R) was false
/home/me/test/ooooo.d(23):        constraint clause hasAssignableElements!(R) was false
/home/me/test/ooooo.d(23):        constraint clause cast(SwapStrategy)0 != cast(SwapStrategy)0 was false

Notice the "constraint clause .... was false" lines.

The problem remaining is if there are multiple candidates, it will only print errors from the last one it happened to examine. Otherwise though, I'm pretty happy with it. (And I don't even see that remaining problem as being a blocker, personally).

Better yet IMO would be actually formatting the candidates' constraints and highlighting which ones are true/false/short-circuited inline, but meh. Again, like I said on the forum, my goal here is not to get this merged per se, just to prove this kind of thing is possible and encourage further exploration of improvements of existing code (perhaps in addition to the DIP discussion, but I find the dip less than compelling given the possibilities this proves exist)

[UplinkCoder]

One problem is new ing in this very tight loop.
Other than that this would be a viable approach.

[adamdruppe]

On Wed, Mar 06, 2019 at 01:43:50PM -0800, Stefan Koch wrote: One problem is `new` ing in this very tight loop.

I considered just making it a little struct, but to get really useful information out of it for the error message, it needs to maintain some kind of tree structure. I'd be ok with a change though if you can think of a better idea. Though as a general point, I actually believe usability is worth a speed hit. I like fast builds - in fact, with my code, the build time is part of my test suite and a reduction I treat like a regression bug - but a fraction of a second per build speed hit is a worthwhile trade off when we can reliably cut several minutes of bug hunting off. Of course, another idea is to do it quickest possible in the happy case, then when an error occurs, run the function again, this time gathering more information. Since builds error out kinda quickly anyway they do tend to have a little time to spare, and even full seconds out of the compiler is worth it, since its information will very likely save a full minute (or more) of programmer time in figuring out the actual problem.

…

Other than that this would be a viable approach. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #9419 (comment)

[thewilsonator]

it needs to maintain some kind of tree structure.

Under my DIP the top-level would be an array,

One problem is new ing in this very tight loop.

which would solve this problem, also the problem I had was that I was having trouble printing out the source, which you seem to have managed, but you only need to do that if the match has failed.

[adamdruppe]

On Wed, Mar 06, 2019 at 05:39:59PM -0800, Nicholas Wilson wrote: Under my DIP the top-level would be an array,

Yeah. I could probably get down to an array too, since what I'm really interested in for error messages are just the leaf nodes. But I still want to get better printing of the whole expression, so for now I want to keep the tree anyway. (reminder again this is meant to be a proof of concept more than a final proposal)

[Geod24]

Superseded by #9715