Facebook open sources flint, a C++ linter written in D

On Mon, 24 Feb 2014 13:06:29 -0800, Andrei Alexandrescu wrote: > This is a first on so many levels. > > https://news.ycombinator.com/item?id=7293396 > > http://www.reddit.com/r/programming/comments/1yts5n/ facebook_open_sources_flint_a_c_linter_written_in/ > > > Andrei The real first is that I managed to comment on your reddit within two minutes of submission.

On Monday, 24 February 2014 at 21:07:00 UTC, Andrei Alexandrescu wrote: > This is a first on so many levels. > > https://news.ycombinator.com/item?id=7293396 > > http://www.reddit.com/r/programming/comments/1yts5n/facebook_open_sources_flint_a_c_linter_written_in/ > > > Andrei Congratulations! This is great news. D is sure to get tons of exposure from this, and it proves how D is useful for real world work.

February 24, 2014

Re: Facebook open sources flint, a C++ linter written in D

Posted by bearophile
in reply to Andrei Alexandrescu

Permalink

bearophile

Posted in reply to Andrei Alexandrescu

Permalink

Andrei Alexandrescu:

> http://www.reddit.com/r/programming/comments/1yts5n/facebook_open_sources_flint_a_c_linter_written_in/

>3. Reserved identifiers (checkDefinedNames). A C and C++ naming rule that often gets forgotten is that all identifiers starting with an underscore followed by an uppercase letter, plus all identifiers containing two consecutive underscores, are reserved by the implementation. (Of course there are exceptions to the rule in our code, such as _GNU_SOURCE or _XOPEN_SOURCE, which is why flint keeps aside a whitelist while checking for reserved identifier patterns.)<

D language has similar rules, but I don't rember if the D compiler warns against usage of similar identifiers.


>8. Initializing a variable from itself (checkInitializeFromItself). We found that people wrote constructors like:

class X {
   ...
   int a_;
   X(const X& rhs) : a_(a_) {}
   X(int a) : a_(a_) {}
};

The intent was to use a_(rhs.a_) in the first constructor and a_(a) in the second. That hardly ever helps, and the compiler keeps mum about it. We like to say, "There's a flint rule for that," in order to resolve the problem.<

I'd like a similar warning in the D compiler for a similar (very) common bug:

class Foo {
   int x;
   this(int x_) { this.x = x; }
}
void main() {}


>16. Check against throwing new-allocated bald pointers (checkThrowsHeapException). This eliminates the throw new T anti-pattern.<

I don't fully understand this.

The "throw new Exception(...)" pattern in D was recently discussed, and sometimes re-using an Exception is more efficient.



>20. Pass cheap types by value (checkFollyStringPieceByValue). Certain user-defined types, such as iterators or pair of iterators, are small and cheap to copy so it's virtually always better to pass them by value instead of the conservative reference to const. Folly's StringPiece is an example - it occupies two words and has raw copy semantics.<

In D there is about the same problem.

Additionally the D compiler doesn't warn if you do kind of the opposite:

alias MyArr = int[5000];
void foo(MyArr x) {}
void main() {}

Bye,
bearophile

On Monday, 24 February 2014 at 21:07:00 UTC, Andrei Alexandrescu wrote: > This is a first on so many levels. > > https://news.ycombinator.com/item?id=7293396 > > http://www.reddit.com/r/programming/comments/1yts5n/facebook_open_sources_flint_a_c_linter_written_in/ > > > Andrei Awesomeness. Look forward to learning from its style. Thanks Joseph

"bearophile" wrote in message news:bskrlqgtwkqdyoqwkxqn@forum.dlang.org... > D language has similar rules, but I don't rember if the D compiler warns against usage of similar identifiers. It doesn't! > > [snip etc] The D compiler is not a lint tool!

Daniel Murphy: >> D language has similar rules, but I don't rember if the D compiler warns against usage of similar identifiers. > > It doesn't! Perhaps it should? >> [snip etc] > > The D compiler is not a lint tool! Currently the D compiler catches several bugs that are caught only by C lints. Clang shows that you can add lot of lint-like tests to the compiler. I'd like some more tests in the D compiler. Bye, bearophile

Andrei Alexandrescu: > http://www.reddit.com/r/programming/comments/1yts5n/facebook_open_sources_flint_a_c_linter_written_in/ An interesting comment from Reddit: klusark>I've been trying to build this for the past hour. It requires folly. folly requires some "double-conversion" library, but you can't use the default version, you have to build it with scripts from folly's source. After I finally get folly to get past configure stage I get some random python error in one of the build scripts. I just gave up at this point. I'm sure I could get it working, but the time isn't worth it.< Bye, bearophile

On Tuesday, 25 February 2014 at 11:20:37 UTC, bearophile wrote: > Currently the D compiler catches several bugs that are caught only by C lints. Clang shows that you can add lot of lint-like tests to the compiler. I'd like some more tests in the D compiler. Full stop. It should be other way around - remove all such arguable warnings from compiler to dedicated lint tool and never add any single one to compiler.

Forums