[Issue 3858] mixin attribute is ignored

Apr 25, 2019

Basile-z

Nov 06, 2019

RazvanN

Mar 21, 2020

Basile-z

Apr 15, 2021

Adam D. Ruppe

https://issues.dlang.org/show_bug.cgi?id=3858 Basile-z <b2.temp@gmx.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|rejects-valid |accepts-invalid CC| |b2.temp@gmx.com --- Comment #2 from Basile-z <b2.temp@gmx.com> --- 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) --

https://issues.dlang.org/show_bug.cgi?id=3858 RazvanN <razvan.nitu1305@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |razvan.nitu1305@gmail.com --- Comment #3 from RazvanN <razvan.nitu1305@gmail.com> --- Maybe a solution would be to parse string mixins at parse time and simply glue the resulting AST to the main AST. --

April 15, 2021

[Issue 3858] mixin attribute is ignored

Posted by Adam D. Ruppe

Permalink

Adam D. Ruppe

Permalink

https://issues.dlang.org/show_bug.cgi?id=3858

Adam D. Ruppe <destructionator@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |destructionator@gmail.com
         Resolution|---                         |INVALID

--- Comment #4 from Adam D. Ruppe <destructionator@gmail.com> ---
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!

--

Forums