Apologies for the delay (Just started university so I haven't had a computer until now).

The milestones for the project:
https://gist.github.com/maxhaton/a44b0be7eaa9ee75df598794061fb9a0



There's not much more to add except for the "Data about D files" section:
I have laid the groundwork for this, but I don't know what to measure - any suggestions would be appreciated (Examples being the @safety of functions). This is done post-SEMA so any information available to the compiler can be included.

On Tuesday, 24 September 2019 at 21:14:51 UTC, Max Haughton wrote:

> any suggestions would be appreciated (Examples being the @safety of functions)

Some ideas off the top of my head:
* structs vs. classes
* throwing exceptions vs. returning error codes
* Error vs. assert
* `ref` vs. raw pointers
* comparing how much `@safe`, `@trusted`, and `@system` code there is.  Ideally, we should see `@safe` code increasing over time and `@trusted` and `@system` code decreasing over time.
* usage of templates
* usage of UFCS
* usage of CTFE (may be quite difficult to measure)
* usage of `pure`
* usage of `const`
* usage of `@nogc`
* usage of `in`
* usage of `@property`
* usage of DIP1000 features (e.g. `scope` and `return` attributes)
* usage of design-by-introspection (e.g. `__traits`, `static if`)
* usage of UDAs
* usage of `static foreach`
* usage of any D construct or idiom really
* % of code properly documented with DDoc

On Tuesday, 24 September 2019 at 21:14:51 UTC, Max Haughton wrote:
> Apologies for the delay (Just started university so I haven't had a computer until now).
>
> The milestones for the project:
> https://gist.github.com/maxhaton/a44b0be7eaa9ee75df598794061fb9a0
>
>
>
> There's not much more to add except for the "Data about D files" section:
> I have laid the groundwork for this, but I don't know what to measure - any suggestions would be appreciated (Examples being the @safety of functions). This is done post-SEMA so any information available to the compiler can be included.

Re integration with CI: I think this is the most important part as otherwise people won't be aware of your work.

You can get a build notification triggered via a GitHub webhook and then either send a GitHub status check update or send a comment. However, I strongly recommend to not implement your own GitHub CI, but add it as another project on the Buildkite project tester.

The only downside is that every time it will run on a different agent, so pure time measurements wouldn't work, but it should be great for all other stats.

Dlang-bot also receives all important web hooks and already sends a comment to every PR (+ has the permission to send status updates), so this might be another helpful place for your integration.