
Something Secret This Way Comes - llogiq
https://llogiq.github.io/2016/04/24/nsa.html
======
danschuller
This a total tangent but I always thought it might be interesting if an IDE
pulled data from source control (and presented it inline somehow).

How "hot" a function is - has it reiceved a lot of edits in the recent past?
Or is cold and old (and therefore you'd imagine reasonably bug-free for most
use cases).

I think the number of unqiue people editing a portion of code would also be
interesting to know. As you might expect multiple authors to have different
beliefs about the point of the code and therefore the code is probably going
to be more muddy and less clear.

~~~
revelation
Visual Studio does this:

[https://i-msdn.sec.s-msft.com/dynimg/IC805614.jpeg](https://i-msdn.sec.s-msft.com/dynimg/IC805614.jpeg)

(For C# at least)

~~~
jobigoud
Is it for Team Foundation only or can other VCS be integrated into this?

~~~
sandyarmstrong
It works with git out of the box.

------
da4c30ff
This is something that I'm actually writing for my own programming language,
coincidentally also written in Rust.

My idea was to label each expression with these flags, i.e. is the expression
constant?, tail recursive?, etc., and then make that information available for
the text editor and other tooling, so the user can instantly see certain
things about their program, and see the type of optimizations the compiler
will do for them.

~~~
dominotw
Thats a great idea. Do you have it available somewhere?

~~~
da4c30ff
Currently there's only a tokenizer/parser implementation publicly available.
I'm currently working on the type system.

Progress has been a bit slow, but I will be posting here on HN if I end up
making something worthwhile.

------
eigenrick
Sounds like it could be a basis for a security oriented scanner. Rust has less
to worry about regarding memory security, but performing taint analysis for
logical security flaws could be mighty interesting.

------
cm3
Reminds me of LLVM's EfficiencySanitizer that will probably land in 3.9:
[http://lists.llvm.org/pipermail/llvm-
dev/2016-April/098355.h...](http://lists.llvm.org/pipermail/llvm-
dev/2016-April/098355.html)

~~~
Manishearth
I'm personally very interested in "non-optimizing optimizers", essentially
lint passes which point out places where you may optimize something without
actually making that optimization. The advantage to this is that you get
access to a lot of optimizations which would otherwise require you to make a
lot of things undefined behavior to make work.

An example of this is the escape analysis lint in rust-clippy, which can
detect if an allocation via Box/Vec/String is unnecessary (though right now it
only supports one of those and I need to work on it more) and tell you how to
remove it.

~~~
llogiq
By the way, I recently tried to get rid of some `vec!`s in the benchmarksgame
entries (well, to see if I could), but got into trouble with IntoIterator
implementations, so an extension of EscapeAnalysis would be great!

~~~
Manishearth
I suspect that the escape analysis lint will never be as powerful as a human
looking in a reasonably small region of code to remove specific allocations,
so it wouldn't be able to help here. Probably. Its power is in that it can
find unnecessary allocations in a large codebase.

------
niccaluim
Maybe I'm missing something but this sounds less like a linter and more like
an optimization pass?

~~~
Manishearth
It's half a lint. It collects metadata about the code, making it easier to do
whole-program analysis. Most of the lints we have so far do at most whole-
function analysis. The other half, to be written, would use the metadata to
lint things. "Can never panic" is one such lint that could be written with
this for example.

As an optimization pass it would have to actually change the generated code.
It doesn't affect that (nor does Rust's plugin lint functionality; which it
uses; let you do that)

~~~
sievebrain
This sounds like a component of the type of tool normally called a static
analysis engine. "Lint" to me implies more of a lightweight tool that
complains about tabs vs spaces and things like that.

~~~
llogiq
I just call it a lint because it uses the rustic::lint API. And I posited that
such analysis belongs in the compiler.

However, lints no longer need to be lightweight; I've seen full-program
analysis passes called lints. And in rust, lints usually don't complain about
tabs/spaces (though we could write one), but rather certain idioms which are
exacerbating readability, flexibility, performance or any combination of the
above.

