Implement DIP1035 - system variables

[dkorpel]

Make access of variables with STC.system a deprecation/error depending on -preview=systemVariables.
Does not implement inference of @system based on initializers yet, or checking against void initializing / array casting.

[dlang-bot]

Thanks for your pull request and interest in making D better, @dkorpel! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#14478"

[thewilsonator]

Please update the header

[dkorpel]

It's extern(D), do you think it should be exposed to the extern(C++) interface?

[thewilsonator]

Oh, I missed that. Thats a question for @ibuclaw or @kinke

[RazvanN7]

Nope, extern(D) does not need to be exposed to other backends.

[dkorpel]

It's currently red because of deprecations when compiling druntime/phobos caused by dlang/druntime#3007 which paints not only functions now, but also constants and variables @system.

[RazvanN7]

A list of suggestions and questions:

• declaring @System variable in a while/if condition and then using it should be tested.
• declaring @System parameters for functions should be tested
• is it allowed to take the address of a @System variable in @safe code? Anyway, a test with this should be added.
• is it allowed to pass a @System variable to a @safe function?
• should we add a trait similar to getFunctionAttributes which gets the attributes of a variable since we now have attributes for variables?
• if you can declare a system parameter, is it possible to declare a template function that receives a system parameter?

[RazvanN7]

A note on this: if we ever transition to @safe-by-default the functions that are present in this file will be wrongfully considered as being @safe. Maybe add the @System to those functions?

[RazvanN7]

This may apply to some of the other files as well.

[dkorpel]

Remember DIP1028 and what happened to it?

I don't think I have to account for that anymore.

[dkorpel]

• declaring @System variable in a while/if condition and then using it should be tested.

Not allowed by the grammar

• declaring @System parameters for functions should be tested

Not allowed by the grammar

• is it allowed to take the address of a @System variable in @safe code?

No, then you access it

Anyway, a test with this should be added.

Okay

• is it allowed to pass a @System variable to a @safe function?

Only if you're calling it from a @system or @trusted function

• should we add a trait similar to getFunctionAttributes which gets the attributes of a variable since we now have attributes for variables?

Probably, but not in this PR

• if you can declare a system parameter, is it possible to declare a template function that receives a system parameter?

You can't, and you can't

[dkorpel]

@RazvanN7 Anything else?

[RazvanN7]

Looks good to me, however, I would prefer if @WalterBright merges this.