Remove DCGs that have thrown an exception during term expansion

[hurufu]

Some DCG constructs aren't supported and can't be expanded, here we remove offending DCG rule and don't compile it at all – in a similar fashion to what we do when incorrect goal was found – whole predicate isn't getting compiled.

Fixes #2675

I know that request has low priority, but it is so much simpler than loder.pl refactoring, so I just couldn't help myself and fixed it right away.

[triska]

Thank you a lot for taking a look at this issue!

Regarding the approach: In which module is null/0 being defined? And further, supposing a definition for null/0 is already present for unrelated reasons in a module that loads library(dcgs), is that then inadvertently removed?

[UWN]

A blind catchall just leads to further problems. So restrict it to those terms that make sense here. Further, note that many implementations permit lists of clauses including [].

[hurufu]

Yes, I would also like to use an empty list, but currently Scryer just compiles a clause []/0, which isn't what I want to achieve here. Maybe that is a more deep problem to be solved instead.

[UWN]

One can always define the fact [] with the rule [] :- true.

[UWN]

... and, it is still a catchall.

[hurufu]

Oh... I forgot to push a commit

[hurufu]

Thank you a lot for taking a look at this issue!

Regarding the approach: In which module is null/0 being defined? And further, supposing a definition for null/0 is already present for unrelated reasons in a module that loads library(dcgs), is that then inadvertently removed?

null/0 is defined in dcgs module, so I don't see how realistically will someone define dcgs:null. in their code base, but this is a valid point. Which is connected to a discussion about how to correctly produce no clauses during term expansion...

[hurufu]

Additionally I do think that this has to be fixed in Prolog, because Rust code that generates this warning is applied universally to every compiled clause, so I will need to add an ugly special treatment for -->/2.

[hurufu]

I think this small PR is ready for review.

• I didn't use explicit exception, because it will be always rethrown, so I don't think that there is a risk of hiding it. (@UWN if you think that it is still a good idea to have explicit exception term, I can put it)
• Bad --> is expanded to a long name, so I don't expect any accidental name conflict.
• I decided to rethrow, because I want to rely on a default mechanism of exception printing during goal expansion.

[mthom]

looks good to me. further comments?

[hurufu]

1. I've just removed some leftover code from unit test.
2. I think style check should only verify files that have been touched by the commit, because now it files for files that I haven't modify.

[triska]

This just became infinitely more elegant!