Hi Sam,
https://gitlab.haskell.org/ghc/ghc/-/wikis/building/running-tests/adding is
a well-written and well-hidden page that explains quite a lot about writing
a test. I'm not sure it's a good idea, though, to add a test to the GHC
test suite that enforces some guarantee that nobody signed up for in the
first place. To put it another way, the CLC proposal process should already
be providing the guarantees you're looking for, and figuring out how to
make that process meaningful and practical regarding GHC's internals is
already stressing the community's limits. I'd suggest to you that you make
a list of the functionality you actually consider "core" and get it into
the hands of the people working on that problem, and I'd suggest to *them*
that they put out a call for other such lists from users of the API.
On Tue, 23 May 2023 at 00:13, Sam Halliday
Thanks to everybody who chimed in on this thread.
I have now updated ghcflags / hsinspect to work with all versions of ghc from 8.8.3 through to 9.6.1. You can see the churn in various parts of the ghc api in the commit history https://gitlab.com/tseenshe/hsinspect/-/commits/develop ... if the authors of some refactors inside ghc were aware that some of these functions and data types were being used externally then perhaps they could have left functions in place that would have continued to work as before.
I'd like to extract this one part from the thread, and ask if there would be any objections to me submitting a standalone test file to the ghc codebase:
tooling authors can submit test code (in the sense that it is compiled as part of the ghc build) to ghc as documentation of their most sensitive uses of the ghc APIs. It wouldn't be distributed and therefore there is no risk to pollution of the ghc api.
It will take me some time to do this so I don't want to do it without understanding if it would be accepted. I think it will pay for itself after about 2 or 3 major releases of ghc, but it mitigates against anybody removing core functionality that I'm making use of which is the most important thing.
If that is ok, where should I start? I don't know how to add (or run) a test file to ghc that would simply test that the file compiles.
Thanks Simon,
Simon Peyton Jones wrote:
What we need is - An API for GHC that is *designed *and *actively curated*. ...
Some may believe that the API would need to be some huge reflection of the internal API, with maximal reuse in mind. That is a mammoth task, but an API could also end up being a lot of the code from tools pushed further into the ghc codebase (although perhaps a very inefficient way of doing it for everybody if it's going through committees).
I propose an alternative: that tooling authors can submit test code (in the sense that it is compiled as part of the ghc build) to ghc as documentation of their most sensitive uses of the ghc APIs. It wouldn't be distributed and therefore there is no risk to pollution of the ghc api.
Breaking changes would require fixing inside the ghc test codebase at the point of the breaking change by the author of the change (who presumably understands it the most!) and then when ghc is released, the tooling author knows exactly what to do to fix their code without having to involve the ghc developers any further, except to extend their thanks.
One of my biggest fears is that somebody just *removes* something from the api entirely and I can't do what I need at all anymore. I don't think that kind of problem can be addressed retrospectively.
I know this isn't helping Sam much in the short term -- apologies for
Sam Halliday wrote: that.
Bringing attention to it is helping, so thank you for that. My immediate problem can probably be solved by some kind soul dedicating 30 mins of their time to help push my code over the line. I'm more than happy to barter my own time for something they'd like in return, or send a small gift! :-)
-- Best regards, Sam
-- Best regards, Sam _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs