
Testing LLVM - awalGarg
http://blog.regehr.org/archives/1450
======
KenoFischer
I always find committing to LLVM very nerve wrecking, because of the post-
commit CI testing. LLVM has so many architectures that more often than not
something I write will fail on one of them. And the only way for me to find
out is to commit it, wait for the buildbot to fail (which can take a few
hours, during which I really can't leave my computer lest I leave trunk broken
on some buildbot, which is a big faux pas), revert it and then figure out what
went wrong. I'm hoping that at some point this will be improved, such that I
can run the whole buildbot army on my commit before putting it on trunk.

~~~
wyldfire
I get the feeling that there's parts of the community that feel the same way.
I'm hoping that the planned move to github will naturally cascade into pre-
commit checks.

~~~
ezanmoto
Do you know of solutions that exist for pre-commit checks for GitHub at the
moment?

~~~
dikaiosune
Rust uses [https://github.com/rust-community/bors](https://github.com/rust-
community/bors) which maintains a linear queue of PRs which can only land
after being rebased onto the commits before the PR and subsequently passing
tests.

------
SloopJon
Interesting to see screenshots of LCOV. I'm hoping to get an intern to work on
test coverage this summer, and I wondered whether LCOV is still current. Looks
like the latest release is from December 2016.

~~~
Joky
The screenshots are from the "old" style coverage. We have much better views
now: [http://lab.llvm.org:8080/coverage/coverage-
reports/opt/cover...](http://lab.llvm.org:8080/coverage/coverage-
reports/opt/coverage/Users/buildslave/jenkins/sharedspace/clang-
stage2-coverage-R@2/llvm/lib/Transforms/Scalar/CorrelatedValuePropagation.cpp.html#L354)

See for instance how having your cursor on top of each side of a condition
tells you how many times each individual condition were evaluated!

------
bootload
_" Compilers are usually not networked, concurrent, or timing-dependent, and
overall interact with the outside world only in very constrained ways."_

Are there any parallel compliers?

~~~
Locke1689
It depends on what you mean by parallel.

Certainly the Roslyn C# compiler is highly parallel. All files are parsed in
parallel, then all classes are bound (semantically analyzed) in parallel, then
the IL serialization phase is sequential.

~~~
bootload
_" It depends on what you mean by parallel."_

Across different machines, not cores on ^a^ chip?

~~~
Locke1689
I wouldn't say that's what most people mean by parallel, but in that case I
think you're better off building a layer on top of the compiler for that.

For instance, provided deterministic compilation you could keep a networked
cache of compiled libraries that would be delivered as needed.

Trying to be network-parallel at any finer level is probably a waste of time
-- network and (de)serialization overhead would eat away all the advantages.

------
newsat13
One quirk of llvm is that they don't have a pre-commit CI.

------
mp3geek
I do find it strange that such a large project isn't using a better VCS. SVN
seems to be very antiquated.

~~~
DannyBee
For a project like LLVM, it just doesn't matter _too_ much. git-svn or plain
svn works pretty well for most people. Certainly it matters, and it'll move
eventually, but i'd rather see time spent on better testing tools than a
"better" vcs.

When i moved GCC from CVS to SVN, it made life a bit easier but it's not
revolutionary change.

Which is funny, considering how often people argue about VCS systems.

~~~
Locke1689
I don't agree.

Before we moved to Git, Roslyn was on TFS, which was basically
Perforce/CVS/SVN.

You're absolutely right that the distinction among the former VCS's is
minimal. However, Git offers value that was transformative compared to the
former. Namely,

    
    
      1. Git allows you to easily switch between multiple work items while keeping track of the work done in each item.
    
      2. Git allows you to easily integrate with people who have significantly diverged clones of your tree without too much trouble.
    
      3. Git allows you to easily work offline.
    

(1) is definitely the largest benefit, but was mitigated with tools like g5
when I was at Google. However, the Google gravity well has its own drawbacks.

(2) is very important if you want to host rapid release schedules with
divergence of features. It's especially useful if you want to have long
stabilization periods and low-risk bug fixes delivered in parallel to multiple
customers.

(3) is pretty self-explanatory, but for most people it's underestimated how
much downtime your VCS has. I'd bet, for most people, it's significantly less
than 5 9's. Not only is that wasted time, it's frustrating because it's
usually consecutive and removes entire working days at random.

~~~
saurik
I take it you haven't actually used the tool that was mentioned in the comment
you replied to, namely git-svn? My use of svn to interface with projects using
Subversion has essentially entirely been replaced by git-svn, and I can say it
is essentially impossible for someone who has used it to not realize that at
least offline now works like git. Taking a step back: at some point what you
run on the server is just a storage format; unless you used some of the more
advanced Subversion features (at which point you might actually like using
it), it generally maps pretty directly to git semantics, at which point
essentially all other functionality differences are mere porcelain.

~~~
lomnakkus
Presumably not everyone is using git-svn... otherwise what would be the point
of sticking with svn?

