dmd
dmd copied to clipboard
dlang
ImportC - First go at implementing mixinC (In this iteration it has t…
…he syntax
mixin[C], bikeshed away) - Currently just for expressions.
We don't capture macros yet so this isn't particularly useful just yet (we do have a small macro engine for ddoc so maybe we don't need to reimplement the preprocessor), but it's important to know the semantic analysis is actually possible (it seems like it is?)
Thanks for your pull request, @maxhaton!
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 run digger -- build "master + dmd#14114"
interesting, mixin[C](import("s.c")) will work without additional change I suppose ?
I'd rather it be its own standalone node to keep it separate from mixins that come from user code. This isn't meant to be something that you interface with directly if done right.
I'd rather it be its own standalone node to keep it separate from mixins that come from user code. This isn't meant to be something that you interface with directly if done right.
Who is interfacing with what in this sentence?
I'd rather it be its own standalone node to keep it separate from mixins that come from user code. This isn't meant to be something that you interface with directly if done right.
Who is interfacing with what in this sentence?
Something to the effect of MACRO; in D user code that initially is constructed as an IdentifierExp being resolved as a CMacroSymbol that came from ImportC, which refers to a StringExp that is the unparsed macro value. This resolved symbol tells us that the expression is to be resolved internally as a CMixinExp.
That is the simplest case at least, the IdentifierExp in a CallExp would have to expand the CallExp into a CMixinExp with the parameters instantiated as enum or alias DeclarationExp in its enclosed Scope.
I don't think we should be supporting MACRO; in a context that expands to a CMixinStatement, that would mean we would have to permit IdentifierStatement and CallStatement in the D parser grammar.
looks like this so far only works with expressions, i guess cuz still wip. But it also passed through the D lexer and thus complained about a #include thing.
I don't know if this is acceptable without a DIP as it changes the grammar and adds new syntax? Feel free to add the DIP label, then. Aren't there other alternatives to that syntax? Like mixin(C)("...")? Can be tricky to support tho, due to callables, but these can be deprecated and enforced by explicitly choosing the language type. It feels to me a bit shifted from D style.
The issue within mixin(C) is that you can already write mixin(C)(sea)(c) in the grammar today, inside an expression
__mixinC()
but you know you have a winning idea when the only complaint is about the sin tax lol
The issue within mixin(C) is that you can already write mixin(C)(sea)(c) in the grammar today, inside an expression
Yes. What I said is that can be passed through a deprecation process and make language type specifier mandatory. We can minimize deprecation surface tension by only failing on cases where it is ambiguous. It's tricky but doable, I would say.
I understand that is a very big deprecation tho. I think we always have the possibility of using __mixinc or something like that with the underscore reserved keyword range.
