Ensure everything compiles individually & sort includes #9
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A lot of the files in our codebase don't properly include all of their dependencies. A common example of this is a situation like this:
a.hpp
usesstd::vector
in a definition, so it would need to have a line saying#include <vector>
, but it doesn't.a.hpp
does not includevector
neither directly nor indirectly, but whenevera.hpp
is included from another file, that file just happens to includevector
beforehand.The result is that, while running
make
succeeds, the code is quite brittle. The fact thatvector
is always included beforea.hpp
(in current uses of the library) might be quite accidental, and users might in theory want to usea.hpp
in another file that doesn't needvector
itself. Besides, it's just not particularly good style to not include our dependencies explicitly.Luckily, this specific problem is easy to detect: if you were to try to compile
a.hpp
on its own, compilation would not succeed. I wrote a script (try_compiling.py
inlibsnark-tooling
) that tries to individually compile every single file (*.hpp
or*.cpp
) in libff and reports whether it succeeds.I then went through the report and fixed every single compilation error --- almost all of them were because of missing includes.
This does not resolve all possible include-related problems: in the situation above, perhaps
a.hpp
actually has a line saying#include <libff/b.hpp>
, andb.hpp
includesvector
--- thena.hpp
compiles just fine, but is still not explicitly listing all of its dependencies (perhapsb.hpp
's dependencies will change in the future, and it will no longer requirevector
--- then we'll get a brokena.hpp
despite no real changes inside it). But I think this is a much smaller problem, and it's also much harder to even detect automatically, so for now I'm submitting just these changes.While I was at it, I also sorted the #include directives in every file --- they are now grouped into three groups (standard library, external libraries, and libff) and sorted lexicographically within each group. This was done using
fix-includes.py
inlibsnark-tooling
.Another minor change I made is that
libff/common/default_types/ec_pp.hpp
will now refuse to compile (with a helpful error message) if none of theCURVE_*
symbols are defined, because that file is always included with the expectation that it will definedefault_ec_pp
.