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

[Mihaela Chirea]

Hello!

Here is the status of this project at the end of Milestone 2 of 
#SAOC202.

Since the last update, I worked on adding location to the 
StorageClassDeclaration[1] and UserAttributeDeclaration[2] nodes 
(the only ones remaining if I didn't miss anything during the 
last check). Doing this I noticed a few of issues with both these 
nodes and a couple others and I need some advice on how to 
proceed in this regard:

- The location should start at the first byte of the AST node to 
preserve the context. Some nodes already had locations before I 
started working on this project, but I noticed that not all of 
them follow this rule. VarDeclaration and FuncDeclaration, for 
example, start at the name of the variable/function, skipping the 
type and the storage classes. As these locations are used for 
errors, I was thinking of adding another variable to these 
classes instead of replacing the value of this one.

- In the case of UserAttributeDeclaration, consecutive 
expressions are all put into the same node. While the expressions 
already have their location set, none contain the `@` symbol. In 
a situation like `@uda1 @uda2 @uda3` moving this location just a 
bit to the left wouldn't be a problem. However, `@(uda1, uda2, 
uda3)` is represented in the exact same way by the parser: one 
UserAttributeDeclaration node with 3 expressions. So who gets the 
`@` in this case? My idea would be to set the start location of 
UserAttributeDeclaration to the first `@` symbol in the group, 
and, later, set the end location to wherever the last symbol is. 
The problem with this approach is that all attributes, both 
storage classes and user defined, can be applied on the same 
variable/function, so the UserAttributeDeclaration range can 
contain more than just user defined attributes.

- 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.

To deal with these situations, I need to know a bit more about 
the desired usecases. What information should we be able to get 
from these nodes?

For now, I will put these issues on hold. For the next milestone, 
I will focus on:
- Adding the possibility of analyzing source code that is only in 
memory
- Stopping the generation of TypeInfo nodes when not needed
- Adding end location where possible

I will get back to the start locations as soon as I find a 
suitable solution.

The tasks planned for milestone 2 can be found here: [3]

[1] 
https://github.com/AsterMiha/dmd/tree/StorageClassDeclarationLoc
[2] https://github.com/AsterMiha/dmd/tree/uadLoc
[3] 
https://forum.dlang.org/post/kfcxcjauafpcrmfuajam@forum.dlang.org