-
-
Notifications
You must be signed in to change notification settings - Fork 608
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ImportC: run cpp on Posix .c files #13955
Conversation
|
Thanks for your pull request, @WalterBright! Bugzilla referencesYour 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 locallyIf you don't have a local development environment setup, you can use Digger to test this PR: dub run digger -- build "master + dmd#13955" |
ccdb18b
to
06a362e
Compare
|
Eh, looks like lexer.d is not liking the output of |
|
|
||
| import dmd.astenums; | ||
| import dmd.globals; | ||
| import dmd.link; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because, no dmd driver/backend code should be pulled into the front-end. (cc @kinke).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
offer a suggestion
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Compiler interface might be one place for it. That is at least one module that is not meant to be common amongst implementing compilers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's already been replaced with a pointer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's imported from dmd.link?
8202e5c
to
1c51280
Compare
|
@ibuclaw this fails on linux with: The failing test case #13713 is written by you and I don't know what it is supposed to be doing. Please help. |
See #13707 for the related bug fix. It is expecting an error due to filemanager.lookup failing, but now you are calling preprocess and possibly getting another error (I hope not success). To reproduce/get the new error message: Yes, those file extensions are correct. |
|
@ibuclaw thanks for the quick answer |
a73e5ca
to
59fd43a
Compare
1926386
to
d769360
Compare
src/dmd/dmodule.d
Outdated
| if (FileName.equalsExt(srcfile.toString(), c_ext) && | ||
| FileName.exists(srcfile.toString())) | ||
| { | ||
| filename = global.preprocess(srcfile); // run C preprocessor |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Check for !is null.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It returns a struct, not a pointer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I presume he means if (global.preprocess !is null) filename = global.preprocess(srcfile);?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer to ask @ibuclaw to explain, as I tire of guessing :-)
Yes, the function pointer might be null.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I expect a "no-op preprocess" function would be provided that simply returned its argument. It's more attractive than adding the extra test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I expect a "no-op preprocess" function would be provided that simply returned its argument. It's more attractive than adding the extra test.
If you want that, global.preprocess should have a "contract" check for non-null function pointers. I agree with @ibuclaw anyway, because that way, there is a way to disable preprocess for those files. EDIT: I mean a "no-op" can do the job but it's counter-intuitive and a function call has higher latency for that purpose, instead of a simple test check.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't need a contract check for null pointers, as the hardware does that for you.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's counter-intuitive
It's a different style, called branchless programming. The nice thing about it is it removes clutter from the code.
and a function call has higher latency for that purpose, instead of a simple test check.
I'd agree if it was an inner loop, but it's once per file. Not significant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Initially this would be unimplemented in gdc and ldc though, resulting in a segfault. If this field was default initialized with a noop lambda then that'd be different.
|
|
||
| import dmd.astenums; | ||
| import dmd.globals; | ||
| import dmd.link; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Compiler interface might be one place for it. That is at least one module that is not meant to be common amongst implementing compilers.
|
We've had ImportC without preprocessor support for 6 months or thereabouts. It desperately needs to support the preprocessor. This is just a first step. Please approve this so I can move forward to getting it completed and useful. We won't know what a better design would be without making more progress with this. Nothing will move forward without this PR. |
src/dmd/dmodule.d
Outdated
| if (FileName.equalsExt(srcfile.toString(), c_ext) && | ||
| FileName.exists(srcfile.toString())) | ||
| { | ||
| filename = global.preprocess(srcfile); // run C preprocessor |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I presume he means if (global.preprocess !is null) filename = global.preprocess(srcfile);?
04e0a4c
to
8be14b0
Compare
|
ping @ibuclaw |
|
@WalterBright there is this comment from @ibuclaw that has not been addressed. |
|
cc @maxhaton. What are your thoughts on this? |
|
@RazvanN7 it had already been addressed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it had already been addressed.
No it hasn't, dmd/cpreprocess.d still imports dmd/link.d
Right. But cpreprocess.d is only called via a pointer. It does not need to be imported. It is only imported by mars.d, which is not used by gdc and ldc. |
requirements are already met
|
Added the "72h no objection -> merge" label. |
|
This should have a changelog entry. |
The approach is fairly crude but I don't mind merging this for now, as I can still work on mine. This PR cannot last because it can't pick the right preprocessor, but it's good enough for the immediate future. |
|
@kinke - any comments? |
|
Somewhat off-topic, regarding hardcoded |
Agreed on the hard coding of That the preprocessor handler is an I have reservations on this callback expecting a new file to be created though. I might chance it to instead do this all in memory without needing to fork(). |
The design in my PR is intended at least somewhat to automate finding the right preprocessor, or make it illegal to use the wrong one. It's beerconf so why not discuss it there I think |
|
This PR is coming up on being a month old. I don't have any angst about replacing it with something better, but right now we don't have anything better. We need something that works, and this works. |
|
@ibuclaw what's holding this up? |
I can't see it so needs to implicitly ImportC.h for one otherwise it's useless in practice because no system headers will work. |
|
I'm planning on implicitly #include-ing importc.h after this one is merged. |
|
72 hours are up! |
Answering myself: yes, both gcc and clang support
For gcc and clang, |
|
@kinke yes. There's also a switch for both MSVC and DMC's preprocessors to do a |
|
It looks like this PR introduced a CI regression. |
It's way past time for dmd to start running the C preprocessor. This kicks that baby bird out of the nest so it can learn to fly.
I like incrementalism, so this PR does as little as possible:
cppon the default pathcpp#include <importc.h>runProgram()inlink.dHence review should be easy.
Based on Max's prior work maxhaton@e132151 greatly simplified.