class C { mixin("private:"); void f() {} invariant() { f(); } } fails to compile. The private attribute is probably not being inserted early enough during the parsing process.
This is another example of the same phenomenon. This should fail to compile, but succeeds. class F { mixin("static:"); void foo() { throw this; } }
This is complicated to fix properly. During CompileDeclaration semantic, DMD parses a token (so the protection let's say), the colon and then a block that's empty (since it's already there). A kind of flag must be put to detect this particular case and then after the CompileDeclaration semantic, if the flag is set, all the following declarations must be pulled in the new attribute. The most simple at first glance would be to disallow MixinDeclaration to finish with an AttributeSpecifier (the form that uses a colon)
Maybe a solution would be to parse string mixins at parse time and simply glue the resulting AST to the main AST.
I'm gonna go ahead and close this because it isn't really a bug. mixins always work on complete AST nodes. They don't paste in code that modifies future things, it is all self-contained. So you should think of the mixin stuff to be wrapped in {}. Sort of, obviously that's not always literally true but it illustrates the scope limitation. So mixin("private:") is like mixin("{private:}"). that is, it does exactly what it is supposed to do: apply private to the end of the current declaration block... but the current declaration block inside the mixin ends where the mixin ends. Meaning it is just a do-nothing thing, which is perfectly legal!