Auto-generate traits from source

[wilzbach]

This is a proof of concept following from dlang/dlang.org#1683 and the idea is to generate the spec based on the ddoc comments.

[wilzbach]

AFAICT is parameters not documented nor implemented. Is this a relict?

[andralex]

This looks very nice. I think we should merge it regardless on future directions. @WalterBright ?

[andralex]

@wilzbach mind the odd errors in testers

[wilzbach]

@wilzbach mind the odd errors in testers

Thanks.
This was due to unimplemented and unused parameters traits. I split these changes into a separate commit. If it's controversial, I am happy to drop this commit.

[andralex]

Made one more pass, a thought: this exposes a bunch of nicely-named symbols. Can we make them private and still generate the documentation?

[wilzbach]

I don't think so (without bug hacks/work), but DMD != Phobos, so having public symbols shouldn't a big problem. Currently the only users are GCC + LDC and they can't use this without C++ interfaces. Also we are stuck with these traits nearly forever, so I doubt that worrying about the deprecation of a public symbol is a worry here. Deprecating a trait from the language is a different pair of shoes though.

[dlang-bot]

Thanks for your pull request, @wilzbach!

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 fetch digger
dub run digger -- build "master + dmd#6877"

[WebFreak001]

this would be really nice for example in DCD where there is a list of traits for autocompletion currently hardcoded in. It would make sense having this in a few places where D code generation is done at CTFE for example as you could go over __traits(allMembers. Except for auto completion programs it could also be used to check using is(typeof(...)) instead of __traits(compiles if a trait is available, which might be a bit nicer

[wilzbach]

Rebased to include the new isDisabled trait.

[wilzbach]

(rebaseD again).

Another ping on this.
Seems like for the last nine months no one opposed this and @andralex was in favor...

[andralex]

Yes, apologies for the slowness. I think a good next step is to hook this in and eliminate the now redundant docs on dlang.org. Thanks!

[jacob-carlborg]

I suggest using __traits(identifier, isArithmetic) to get the string. Instead of having to repeat all the enum names twice.

[ibuclaw]

Isn't that what .stringof is for? I see no problem really with the repetition, as the intent is clear.

[jacob-carlborg]

.stringof will result in a forward reference error.

[WalterBright]

I've been finding it convenient to merely put a link in the code to the spec.

[wilzbach]

It would have been nice to automatically generate the list of traits, but I have bigger fish to fry for now.