Mihaela Chirea - SAOC 2020 Milestone 2 Update 4 - Improving DMD as a Library

[Mihaela Chirea]

Thanks for the advice and examples! I'll get back to these issues 
as soon as I finish the first tasks for milestone 3.

On Friday, 20 November 2020 at 14:24:14 UTC, Jacob Carlborg wrote:
> On Thursday, 19 November 2020 at 22:07:23 UTC, Mihaela Chirea 
> wrote:
>> - In the case of UserAttributeDeclaration, consecutive 
>> expressions are all put into the same node.
>
> Does that apply to these forms as well:
>
> @uda1
> {
>     int a = 3;
> }
>
> @uda2:
>
> int b = 4;

No. If there is a ':' symbol or a '{' in the way, each will get 
their own node.
In your example there is 1 node for @uda1 and another one for 
@uda2.

@uda1
@uda2
{
     int a = 3;
}

Here @uda1 and @uda2 share the same node.

@uda1
{
     @uda2
     {
         int a = 3;
     }
}

But not here. This case generates one node for @uda1 and one for 
@uda2.

@uda1: @uda2:
int a = 3;

Same here, two nodes.

> For your above examples:
>
> `@uda1 @uda2 @uda3 void foo();`
>
> Would be represented as one `UserAttributeDeclaration`, 
> containing three `UserAttributeDeclarationItem`. Each 
> `UserAttributeDeclarationItem` containing one `IdentifierExp`.
>
> `@(uda1, uda2, uda3) nothrow @(uda4, uda5, uda6) void foo();`
>
> Would be represented as one `UserAttributeDeclaration`, 
> containing two `UserAttributeDeclarationItem`. Each 
> `UserAttributeDeclarationItem` containing three `IdentifierExp`.

That's a great solution! However since it will introduce some 
overhead I think I'll only make this available under version 
DMDLIB.

>> - A StorageClassDeclaration node is not always created when 
>> meeting a storage class. Most nodes have a StorageClass field 
>> where this information is stored in the form of a ulong 
>> variable, and therefore there is no node to attach its 
>> location to. For example, `const a = 1;` generates a 
>> VarDeclaration node with the location at `a` and the storage 
>> class with the const bit set. Putting consecutive storage 
>> classes into the same node happens here as well.
>
> Hmm, I see. In my opinion, either the parser needs to be 
> modified to output a `StorageClassDeclaration` for that 
> variable declaration, or the location needs to move for the 
> variable declaration to start from `c`.

The main problem here is that there are quite a lot of node types 
using stc this way so both of these options would require 
significant changes. I'll check the locations of the rest of the 
nodes as well to see if any of them include the storage classes.