ned14 / pcpp

A C99 preprocessor written in pure Python
Other
220 stars 41 forks source link

mcpp tests still failing #24

Closed Sei-Lisa closed 5 years ago

Sei-Lisa commented 5 years ago

I've tried the general mcpp test suite as modified by Boost::Wave. These are the tests t_5_*.cpp. I thought you might be interested in the results.

The tests from that mcpp suite that are failing are:

I also checked t_1_*.cpp but there were too many failures due to incorrect macro expansion. The most notable failure in my opinion is t_1_017.cpp, which seems to be at the heart of many others.

Here's a link to the Boost::Wave full suite: https://github.com/boostorg/wave/tree/develop/test/testwave/testfiles

Expected output is marked with //R. Expected errors are marked with //E. I have only tested the output, not the errors.

ned14 commented 5 years ago

Digraphs are supposed to be working. They were never tested, though.

We deliberately define nothing predefined as for passthru, it would expand stuff we don't want expanded. The docs do mention this, and say if you want those defined, define them manually.

I am surprised that as much of Wave's test suite passes as you say. I know of at least one fundamental flaw in tokenisation and another in macro expansion. But a bit like with the line directive, I didn't and don't personally need better. Once pcpp could fully handle <windows.h>, the Microsoft COM headers and my own preprocessor metaprogramming I stopped fixing bugs. I remember Hartmut (author of Wave) trying very hard to persuade me to keep going until pcpp was perfect, but I've never subscribed to the perfection school unless I'm being paid for it. And pcpp is very much developed far outside of work in the tiny amount of free time left after family and work.

Now, all that said, I'm happy to accept donations of fixing this stuff, if accompanied by a rigorous test suite and if the implementation is maintainable. I'm also happy to accept improvements to the test suite which demo these failing bugs, because then we can link to those failures in the documentation which improves the user experience. And it would help somebody else gauge the work needed if one of these bugs is a showstopper for them.

But I'll be blunt in saying I'm not willing to fix any bugs apart from trivial ones unless they fix my own personal use cases. I will accept open bug issues if they are specific to each bug and detailed with repros, and I'll just leave them open, but with links to them from the Readme.

I appreciate this is probably not the answer you were hoping for, however I have to prioritise my very precious and limited free time, sorry. Again, donations are welcome.

Sei-Lisa commented 5 years ago

Thanks, this is actually along the lines of what I expected. #23 was my blunder, for not looking into the code before posting the feature request and erroneously thinking it was trivial.

I posted this report because this part of the README:

pcpp passes a modified edition of the mcpp unit test suite. Modifications done were to clarify ternary operators with extra brackets, plus those testing the unusual special quirks in expression evaluation (see detailed description below)

led me to think that you could be interested in fixing the above failures, since they belong to the mcpp suite and are not related to expression evaluation. Apologies if I was wrong. Perhaps the claim should be clarified to not mislead others.

I will accept open bug issues if they are specific to each bug and detailed with repros, and I'll just leave them open, but with links to them from the Readme.

I'm taking your word and post a new issue for a problem I found, which is a showstopper for me. __LINE__ is broken, and in the language for which my optimizer is written, which completely lacks a debugger and is very memory restricted, it's essential.

ned14 commented 5 years ago

The engineer in me is interested in fixing any known failure, of course. But I have to be realistic. Documenting known problems with repros I think is reasonable given resources available to me.