On Wednesday, 26 September 2018 at 16:29:24 UTC, Neia Neutuladh
wrote:
* If you encounter a mixin in the module you're analyzing, give
up.
Unfortunately, our code uses mixins heavily, so I don't think
this would be useful for us.
In any case, I fundamentally don't consider the approach of "well
if you want *this* side of D, you can't use *that* side of D" an
acceptable way to find solutions.
To weigh in on the warnings debate, while I generally think that
warnings being fine-grained toggleable makes sense, I also think
it's correct for this specific feature to be a warning, because
it's only useful if you're using D in a certain mode (one-shot
recursive compilation of a closed set of source files into a
binary), which just happens to also be the mode that most of our
code uses.
In any case, the linter/compiler separation simply does not make
sense for D, simply because the language is under heavy
development and having the linter depend on the same frontend as
the compiler means you're perennially forced to develop to the
intersection subset of compiler-supported features and
linter-supported features. Even with a pure-syntax linter like
D-Scanner, we've ran into this issue quite recently with the in()
contract syntax change causing breakage all over Github. The only
sane way to write a semantic linter in D is to ship the DMDFE as
a global library with a stable interface that linters can link
against, so you can upgrade DMD and get a linter frontend upgrade
"for free", or else as a tool shipped with the compiler distro so
that it's again linked against the same code. In any case, this
approach is still inherently inefficient because you're
essentially compiling the *exact same* code twice in a row, since
in modern D at least 50% of the time is spent in the frontend. It
makes more sense, in my opinion, both from a design and
performance perspective to process the information in the natural
place it is produced in the first place - the frontend. Making
DMD available as a library with a stable API is a good second
place. Hell, even allowing DMD plugins to load from the
commandline (with a semistable API) would work. Making DMD
available as a non version tagged separate package so that you
have to rebuild all your tools during a compiler upgrade,
manually checkout a specific revision of the DMD repo, hodge
together a manual build process because dub, D's native package
system can't be used due to some weird insistence on keeping
strict semver on the dub side and arbitrarily violating semver on
the DMD side, so that you then have to manually run the D compile
workflow in order to finally dump some information that you
immediately read back in and output as warnings - I cannot see
this as a sane approach.
