Skip to content
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

[WIP] Generate C++ header files from public extern (C++) declarations #8591

Closed
wants to merge 7 commits into from

Conversation

@ibuclaw
Copy link
Member

commented Aug 21, 2018

Takes #5082 and converts it into a standalone program.

Still needs a bit of work, documentation, command-line option handling maybe to turn on/off certain parts.

Some bugs that I reported are still present, such as #5082 (comment)

Using the auto-generated header in the C++ unittest works at least.

@dlang-bot

This comment has been minimized.

Copy link
Contributor

commented Aug 21, 2018

Thanks for your pull request, @ibuclaw!

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#8591"

@ibuclaw ibuclaw added this to To do in DMD tooling via automation Aug 21, 2018

@ibuclaw ibuclaw force-pushed the ibuclaw:dtoh branch 3 times, most recently from fd44e79 to 2f24603 Aug 21, 2018

@jacob-carlborg

This comment has been minimized.

Copy link
Contributor

commented Aug 22, 2018

I would recommend using the Dub package. Also building the new tool as a Dub package.

@wilzbach
Copy link
Member

left a comment

Yeah it would save a lot of code in the main method if this would use the DMD dub package.

"safe.d", "sapply.d", "semantic2.d", "semantic3.d", "sideeffect.d", "statement.d",
"statementsem.d", "staticassert.d", "staticcond.d",
"target.d", "templateparamsem.d", "tokens.d", "traits.d", "typesem.d", "typinf.d",
"utf.d", "utils.d",

This comment has been minimized.

Copy link
@wilzbach

wilzbach Aug 22, 2018

Member

Can't we use globbing here like we do for the dub package or build.d, s.t. we have less files to update whenever a file gets moved?

This comment has been minimized.

Copy link
@ibuclaw

ibuclaw Aug 22, 2018

Author Member

Maybe, this part was carried over from the old PR.

For sure am open to design improvements - the most important part is the blacklisting of certain modules that we retain manual updates for.

src/dmd/dtoh.d Outdated Show resolved Hide resolved
// Generate special static inline function.
if (cd.isIdentifierClass())
{
buf.writestring(" static inline Identifier *idPool(const char *s) { return idPool(s, strlen(s)); }\n");

This comment has been minimized.

Copy link
@wilzbach

wilzbach Aug 22, 2018

Member

Why this special casing?

This comment has been minimized.

Copy link
@ibuclaw

ibuclaw Aug 22, 2018

Author Member

Because this doesn't exist in D for obvious reasons.

This comment has been minimized.

Copy link
@wilzbach

wilzbach Aug 22, 2018

Member

Oh I was more asking: shouldn't we do this in a more general-purpose way.

src/dmd/dtoh.d Outdated Show resolved Hide resolved
src/dmd/dtoh.d Outdated Show resolved Hide resolved
global.params.isLP64 = global.params.is64bit;

global.path = new Strings();
global.path.push(__FILE_FULL_PATH__.dirName.buildPath("../../../druntime/src/").toStringz());

This comment has been minimized.

Copy link
@wilzbach

wilzbach Aug 22, 2018

Member

This is fragile if druntime is checkout out in a different directory (I think the LDC people do this).

This comment has been minimized.

Copy link
@thewilsonator

thewilsonator Aug 29, 2018

Contributor

Yes our path is $LDCROOT/runtime/druntime.

@wilzbach

This comment has been minimized.

Copy link
Member

commented Aug 22, 2018

SemaphoreCI failure is due to the dub package trying to include dtoh:

../../src/dmd/dtoh.d(103,23): Deprecation: Using super as a type is deprecated. Use typeof(super) instead
../../src/dmd/dtoh.d(131,23): Error: function `dmd.dtoh.genCppFiles.ToCppBuffer!(ASTCodegen).ToCppBuffer.visit` conflicts with alias dmd.dtoh.genCppFiles.ToCppBuffer!(ASTCodegen).ToCppBuffer.visit at ../../src/dmd/dtoh.d(103,9)
../../src/dmd/dtoh.d(1140,19): Error: template instance `dmd.dtoh.genCppFiles.ToCppBuffer!(ASTCodegen)` error instantiating
@jacob-carlborg

This comment has been minimized.

Copy link
Contributor

commented Aug 22, 2018

@jacob-carlborg

This comment has been minimized.

Copy link
Contributor

commented Aug 22, 2018

@TurkeyMan this should be interesting for you.

@ibuclaw

This comment has been minimized.

Copy link
Member Author

commented Aug 22, 2018

@jacob-carlborg this differs in that it is not intended to be a general purpose tool. Same as the tool used to convert dmd to D. This handles only dmd specific style and quirks.

@kinke

This comment has been minimized.

Copy link
Contributor

commented Aug 23, 2018

Nice job Iain, thanks!

@ZombineDev

This comment has been minimized.

Copy link
Member

commented Aug 29, 2018

It would be better to make the hard-coded lists and paths command-line / or environment parameters.

src/dmd/intrange.d Outdated Show resolved Hide resolved
src/dmd/dtoh.d Outdated Show resolved Hide resolved
src/dmd/dtoh.d Outdated Show resolved Hide resolved
src/dmd/dtoh.d Outdated Show resolved Hide resolved
src/dmd/dtoh.d Outdated Show resolved Hide resolved
@TurkeyMan

This comment has been minimized.

Copy link
Contributor

commented Sep 29, 2018

What's going on with this? I could really use this like, yesterday.

@ibuclaw

This comment has been minimized.

Copy link
Member Author

commented Sep 29, 2018

@TurkeyMan - it's hardly meant for general purpose, there are many special cases that look for dmd-specific code.

If it gets used at all, it'll be part of the build process for generating headers that gdc and ldc can include. No need to check what is and isn't in sync.

@TurkeyMan

This comment has been minimized.

Copy link
Contributor

commented Sep 29, 2018

Right... I want to do an experiment where I define some struct's and functions in D, but they are extern(C++), and the .h file needs to be emit by the D compiler. Is that the goal here? It sounds like the same goal; keeping the C++ headers in sync.
This would be a massive enabler for my current project.

@thewilsonator

This comment has been minimized.

Copy link
Contributor

commented Sep 30, 2018

@TurkeyMan I'll do this up as a dub package once #8776 goes in.

@WalterBright

This comment has been minimized.

Copy link
Member

commented Oct 26, 2018

Is this still a WIP?

@thewilsonator

This comment has been minimized.

Copy link
Contributor

commented Oct 26, 2018

This needs:

  • the druntime path to be fixed for LDC
  • made to work for non-linux, and 32-bit

It would also be good to have the DMD-specific stuff factored out.

@ibuclaw

This comment has been minimized.

Copy link
Member Author

commented Oct 26, 2018

Is this still a WIP?

Yes, as I have done no testing whatsoever against gdc and auto-generated headers.

I've been too busy with work on other things to look back at this (you should know what other things are :-)

The cxxfrontend tests that are in dmd only cover the surface of the C++ bindings. That the generated header is compilable and the running program passes all tests is promising though.

As I've said before, this not meant to be general purpose, I would suggest maybe dpp is better suited for you than this utility tool.

@thewilsonator

This comment has been minimized.

Copy link
Contributor

commented Oct 26, 2018

As a general purpose dub-package-to-be: https://github.com/thewilsonator/dtoh

N.B. also completely untested.

@jacob-carlborg

This comment has been minimized.

Copy link
Contributor

commented Oct 26, 2018

I would suggest maybe dpp is better suited for you than this utility tool.

dpp is for the other way.

@TurkeyMan

This comment has been minimized.

Copy link
Contributor

commented Oct 26, 2018

As I've said before, this not meant to be general purpose, I would suggest maybe dpp is better suited for you than this utility tool.

dpp is the wrong way around; we want to emit .h files with the extern(C++) symbols like .di files work today... in this case, the D code should be the authoritative code. I don't want C++ injecting noise into this particular codebase.

Is there a path to making this work general purpose in the way I say?
extern(C++) doesn't support anything that C++ doesn't support; the mapping should be cleanly possible.

thewilsonator added a commit to thewilsonator/dmd that referenced this pull request Oct 28, 2018
Expose DMD's command line parsing
For DMDFE as a library so that tools can populate `global.params` correctly.

Required for https://github.com/thewilsonator/dtoh the dub package of dlang#8591

@thewilsonator thewilsonator force-pushed the ibuclaw:dtoh branch 2 times, most recently from 1d2f88b to 9b9e45a Nov 18, 2018

@thewilsonator thewilsonator force-pushed the ibuclaw:dtoh branch from 9b9e45a to 3e41ecf Nov 18, 2018

}
// Read the configurarion file
auto inifile = File(global.inifilename);
inifile.read();

This comment has been minimized.

Copy link
@wilzbach

wilzbach Feb 25, 2019

Member

I think most of this code in this main method could be saved by using DMD's dmd.frontend:

@thewilsonator

This comment has been minimized.

Copy link
Contributor

commented Jun 10, 2019

There is #9971 now, can this be closed?

@ibuclaw

This comment has been minimized.

Copy link
Member Author

commented Jun 10, 2019

If they're willing to take the baton in this relay race.

@wilzbach wilzbach closed this Jun 10, 2019

DMD tooling automation moved this from To do to Done Jun 10, 2019

@wilzbach

This comment has been minimized.

Copy link
Member

commented Jun 10, 2019

It's Edi's GSoC project, so he'll be working full-time on this over the next weeks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.