Add LLVM-16 to the Nix builds and CI matrix. Also add the option to explicitly
select an LLVM version so the CircleCI build can still work as before.
We should support at least LLVM-17 currently, but there appears to be a
significant performance regression in compiling the generated code for large
variants that I'm going to debug separately. The long term goal is to support
and test all versions 15 and up.
Test plan:
- CI
OI's build is challenging and has often been a problem for the Open Source
community. It requires an extremely specific set of dependencies that are very
hard to achieve on most systems. There are frequent breakages, like when
updating to CentOS Stream 9, or when trying to update the CI's clang from
clang-12 to clang-15 - OI requires the clang libraries to be version 15 but
can't be compiled with it on the CI!
This changes provides a mostly working build environment with `nix`. This
environment is pinned to a specific nixpkgs revision using `flake.lock`, and
only updates when we explicitly tell it to.
Summary of changes:
- Update CMakeLists.txt required version to 3.24. This allows specifying
`FIND_PACKAGE_ARGS` in `FetchContent`, meaning we can use system packages.
This is available on most up to date distros (3.30.2 is current).
- Extends `flake.nix` to be able to build OI. Adds instructions for building
and developing OI using `nix`.
- Partially runs the tests in GitHub Actions. A huge amount must be excluded
because of incompatibilites between the clangStdenv compiler and drgn. We
have similar, though fewer, issues when building with the clang-12/libstdcxx
mix on the Ubuntu 22.04 CircleCI, though this is at least reproducible.
- Updates CircleCI to build CMake from source as we don't have a newer image
available. Also add some newly found dependencies (not sure how it was
working without them before).
Test plan:
This change requires less testing than previous build related changes because
it deprecates most of the build types.
- The internal BUCK build is unaffected. No special testing.
- The semi-internal CMake build is gone. Use Nix.
- The Nix build for clang-15 and some tests are continuously tested in GitHub
actions.
- Tested the set of Nix commands in the README. All work except the one that
points to GitHub as this must be merged first.
- The existing CircleCI runs on Ubuntu 20.04 are maintained.
- Unable to test the new `test-report.yml` as it must be merged due to the
permissions it needs. Will follow up with testing after this is merged. See:
https://github.com/dorny/test-reporter?tab=readme-ov-file#recommended-setup-for-public-repositories
The list of exclusions for GitHub Actions/nix testing is currently very long, I
think 29% of the tests. This should be stable and reproducible though, and
likely needs deep changes to OI to fix. That's why fixes are excluded from this
PR. It's all to do with the forked drgn not being able to parse clang's newer
DWARF output, and can't be fixed by rolling back as we required a relatively
new libcxx.
Currently we pull a modified folly repository to be able to use it header only.
The only difference in this repository is adding the `folly-config.h` file.
Pull this patch into this repo instead and use upstream folly.
Bump folly to latest main as well.
Test plan:
- CI build. I have local build issues at the moment.
Summary:
oilgen: migrate to source parsing
Using debug information generated from partial source (that is, not the final
binary) has been insufficient to generally generate OIL code.
A particular example is pointers to templates:
```cpp
#include <oi/oi.h>
template <typename T>
struct Foo {
T t;
};
template <typename T>
struct Bar {
Foo<T>& f;
};
void foo(const Bar<int>& b) {
oi::introspect(b);
}
```
The pointer/reference to `Foo<int>` appears in DWARF with
`DW_AT_declaration(true)` because it could be specialised before its usage.
However, with OIL, we are creating an implicit usage site in the
`oi::introspect` call that the compiler is unable to see.
This change reworks OILGen to work from a Clang command line rather than debug
information. We setup and run a compiler on the source, giving us access to an
AST and Semantic Analyser. We then:
- Find the `oi::introspect` template.
- Iterate through each of its callsites for their type.
- Run `ClangTypeParser::parse` on each type.
- Run codegen.
- Compile into an object file.
Having access to the semantic analyser allows us to forcefully complete a type,
as it would be if it was used in the initial code.
Test Plan:
hope
`buck2 run fbcode//mode/opt fbcode//object-introspection/oil/examples/compile-time:compile-time`
Reviewed By: tyroguru
Differential Revision: D51854477
Pulled By: JakeHillion
Adds the range-v3 library which supports features that otherwise wouldn't be
available until C++23 or C++26. I caught a couple of uses that suit it but this
will allow us to use more in future.
Test Plan:
- CI
Summary:
Spin around our open/closed source checks. Previously we defined `OSS_ENABLE` in open source builds. This change defines `OI_META_INTERNAL` instead. This is nicer, as external users don't have to do anything special to get a working build.
Use this new macro to define a boolean constant in a new header `Portability.h`. This is inspired by Folly, and makes the internal build easier - definitions in Buck2 have to propagate up from a dependency instead of down from one. Annoyingly we can't use `if constexpr` for a lot of the previous `#ifdef` blocks as we conditionally include the headers. Longer term we could fix this by exposing a header interface but no source, allowing these to build but not be compiled in. For now I did something weird: I defined a function style macro in `Portability.h` based on the compile time macro. This forces you to have included `Portability.h` before using it to ensure the definition is everywhere. Open to feedback as I haven't seen anyone else do this.
Reviewed By: tyroguru
Differential Revision: D50000454
Summary:
Previously OID/OIL required exactly one configuration file. This change makes it so you can supply 0 or more configuration files. 0 is useful if you have pre-generated the cache or use some sort of remote generation system. 1 is useful for the common case, where you have a configuration file that describes your entire source and use just that. More are useful if you have supplemental bits of config you wish to apply/override - see the changes to the integration test framework where we do exactly this.
Test Plan:
This isn't super well tested. It works for the test cases which add features via the config or enable `codegen.ignore`.
- CI
Reviewed By: ajor
Differential Revision: D49758032
Pulled By: JakeHillion
Github is currently extremely slow to load for me for some reason.
Due to that, I first thought that `cmake` is hung up, but tracing
that I realized it's waiting for minutes to download the sources
for tomlplusplus via FetchContent.
This patch enables progress reporting for FetchContent to make it
more obvious what's going on here.
Summary:
Update to clang-15 compiler and libraries as clang-12 is ancient.
The changes to oilgen are necessary because the new internal toolchain is being more picky about linking PIC to PIC. In certain modes we build with PIC, but try to link a non-PIC oilgen artifact. Add the ability to build the oilgen artifacts with PIC which sorts this.
Reviewed By: ttreyer
Differential Revision: D46220858
With the previous method of enabling them on a target-by-target basis,
it was very easy to accidentally miss a target. This had happened in a
number of instances, e.g. "codegen" and "symbol_service".
Previously we had an `R"(` string in `OITraceCode.cpp` which allowed us
to include the file as a string. Instead, keep `OITraceCode.cpp` a fully
formed C++ file and utilise the build system to turn it into a string.
This will be used for more header files that are needed both as valid
headers and as strings for JIT compilation in the Typed TreeBuilder
work.
To help with the transition to type-graph based CodeGen, we need to
reduce dependencies on legacy CodeGen from other parts of OI.
Pieces of CodeGen referenced by other files, but which only return
drgn data have been moved into a new "drgn_utils" target, allowing
us to remove CodeGen dependencies for these functions.
The new "symbol_service" build target can be used in the future by
other files only needing access to symbol information and not full
CodeGen.
Add CODE_COVERAGE option to enable coverage instrumentation in builds.
Add new CI job to upload coverage reports to CodeCov.io.
Reports can be found by navigating the codecov.io UI, or by going to
the URL printed at the end of the "Code Coverage" CI job. More CodeCov
integration could be set up later once we have coverage reporting on the
main branch.
