Hello!

Here is an update of the progress made during the last week of Milestone 1 as part of #SAOC2020:
- I mostly worked on the token location offset tests[1]. This included studying the lexer, parser and tokens in more detail to make sure all the tokens are getting the right offset.
- Updated the list of locations[2] to show the nodes missing the start location more clearly. It currently contains most nodes in attrib.d and DebugCondition and VersionCondition from cond.d.

For next week:
- Add the start location to the nodes that lack this information, starting with the ones from cond.d

These tasks were mentioned in the previous update[3] and will be done during the second Milestone:
- Bring all DMD as a library additions hidden behind a version under DMDLIB
- Add the token size

The initial milestones can be found here[4]. I will post the updated list as a reply to that thread and use that link in future updates.

[1]: https://github.com/dlang/dmd/pull/11823
[2]: https://drive.google.com/file/d/1lb-eP9Pai713tggud6iuzA1cIetbK4zc/view?usp=sharing
[3]: https://forum.dlang.org/post/vshahvctwdhrmrjssool@forum.dlang.org
[4]: https://forum.dlang.org/post/ztbjfjebxtysmugfzkmz@forum.dlang.org

While going through the token types I also noticed that TOK.arrow seems to be unused. Is there a reason for keeping it? Same for int128 and uns128 but I thought those might be implemented in the future. Is TOK.arrow in a similar situation?

On Sunday, 18 October 2020 at 23:37:04 UTC, Mihaela Chirea wrote:
> Hello!
>
> Here is an update of the progress made during the last week of Milestone 1 as part of #SAOC2020:
> - I mostly worked on the token location offset tests[1]. This included studying the lexer, parser and tokens in more detail to make sure all the tokens are getting the right offset.
> - Updated the list of locations[2] to show the nodes missing the start location more clearly. It currently contains most nodes in attrib.d and DebugCondition and VersionCondition from cond.d.
>
> For next week:
> - Add the start location to the nodes that lack this information, starting with the ones from cond.d
>
> These tasks were mentioned in the previous update[3] and will be done during the second Milestone:
> - Bring all DMD as a library additions hidden behind a version under DMDLIB
> - Add the token size
>
> The initial milestones can be found here[4]. I will post the updated list as a reply to that thread and use that link in future updates.
>
> [1]: https://github.com/dlang/dmd/pull/11823
> [2]: https://drive.google.com/file/d/1lb-eP9Pai713tggud6iuzA1cIetbK4zc/view?usp=sharing
> [3]: https://forum.dlang.org/post/vshahvctwdhrmrjssool@forum.dlang.org
> [4]: https://forum.dlang.org/post/ztbjfjebxtysmugfzkmz@forum.dlang.org

Quick feature suggestion, I've been using DMD to transform code to run a safe script inside a game (the details don't matter, It's very specific usecase but I may open source it).

It's currently a bit of a pain to do a full semantic analysis while also maintaining a compilable buffer i.e. you have to trim toPrettyChars() (or whatever it is) to not have the typeinfo things (i.e. the mixins from object.d, while also having vanilla object.d) for types for when you want to compile your modified code. Being able to control this without a flag from a topdown view into the compiler (i.e. as a library) could be a big stepping stone to fruitful projects.

Am 19.10.2020 um 17:59 schrieb Mihaela Chirea:
> While going through the token types I also noticed that TOK.arrow seems to be unused. Is there a reason for keeping it? Same for int128 and uns128 but I thought those might be implemented in the future. Is TOK.arrow in a similar situation?
> 

I think the only reason is to give a helpful error message in case someone ports code from C/C++ or writes in that fashion. This is what DMD outputs:

Error: use . for member lookup, not ->

On Monday, 19 October 2020 at 17:37:46 UTC, Sönke Ludwig wrote:
> Am 19.10.2020 um 17:59 schrieb Mihaela Chirea:
>> While going through the token types I also noticed that TOK.arrow seems to be unused. Is there a reason for keeping it? Same for int128 and uns128 but I thought those might be implemented in the future. Is TOK.arrow in a similar situation?
>> 
>
> I think the only reason is to give a helpful error message in case someone ports code from C/C++ or writes in that fashion. This is what DMD outputs:
>
> Error: use . for member lookup, not ->

Actually, at the site where that error is printed the condition utilizes 2 distinct tokens [1]: minus and greater than. Therefore I think we can get rid of Tok.arrow

[1] https://github.com/dlang/dmd/blob/master/src/dmd/parse.d#L7737

Am 21.10.2020 um 04:01 schrieb RazvanN:
> On Monday, 19 October 2020 at 17:37:46 UTC, Sönke Ludwig wrote:
>> Am 19.10.2020 um 17:59 schrieb Mihaela Chirea:
>>> While going through the token types I also noticed that TOK.arrow seems to be unused. Is there a reason for keeping it? Same for int128 and uns128 but I thought those might be implemented in the future. Is TOK.arrow in a similar situation?
>>>
>>
>> I think the only reason is to give a helpful error message in case someone ports code from C/C++ or writes in that fashion. This is what DMD outputs:
>>
>> Error: use . for member lookup, not ->
> 
> Actually, at the site where that error is printed the condition utilizes 2 distinct tokens [1]: minus and greater than. Therefore I think we can get rid of Tok.arrow
> 
> [1] https://github.com/dlang/dmd/blob/master/src/dmd/parse.d#L7737

You are right, should also remember to remove TOKarrow then, too.