Use locally unqualified types to filter ordered type declarations in
`TypeCollector::GetTypeDeclarations()`. This is necessary, as
`clang::TypeName::getFullyQualifiedName()` and
`TypeDecl::getQualifiedNameAsString()` have different ideas which
qualifiers belong to the name. The former works on `QualType`s, while
the latter deals with the declaration directly. This change decays a
`TypeDecl` into its locally unqualified `QualType`.
PiperOrigin-RevId: 490500091
Change-Id: Ie2f4eece4e673f8b06ab6661d7b6611daf34fba9
This change changes the emitter to work on `clang::TypeDecl`s instead of
`clang::QualType`s, as the latter only describe complete definitions. This
allows us to better deal with situations where we would otherwise have a kind
of circular type dependencies: For example, a `typedef` that depends on a
`struct` which in turn has a member that references the typedef.
For this to work, we now also record the actual source order of declarations,
similar to what the libclang based header generator does.
Also add some more tests for the newly covered cases.
PiperOrigin-RevId: 488370914
Change-Id: I2d1baa863fb12d1801bf11a20f3f88df7fde3129
When generating headers from libraries that export functions as `extern "C"`
but still use namespaces (C-compatible C++ libraries), we want to generate
a Sandboxed API that includes fully-qualified namespace names as well.
In addition, we want the generated API to have the same source order as the
original library. Not only is this less surprising when reading the generated
code, it's also more accurate. Previously, we'd bundle all definitions in a
namespace and sort those alphabetically, but for code that relies on symbols
from another namespace to be available, generation will fail:
```c++
namespace zzz {
using entity_count_t = uint64_t;
} // namespace zzz
namespace sheep_counter {
using sheep_count_t = :💤:entity_count_t;
extern "C" void IncreaseSheepCounter(sheep_count_t increment);
} // namespace sheep_counter
```
PiperOrigin-RevId: 486586024
Change-Id: I419c9db8e9cb5b904364b353e2dc3d7f1030fab3
An `absl::StatusCode` of `kCancelled` now indicates warnings inside the emitter.
PiperOrigin-RevId: 485851898
Change-Id: I10a57cbc1b6c2d4b708c3c19aa0fa71451845a22
The libclang based header generator disallows functions that pass structs (or
more generally "record types") by value. While this can be implemented, the
such functions as emitted by the clang_generator never worked.
We should revisit this when we implement support for passing 128-bit integer
types directly, as those will work the same as small structs.
PiperOrigin-RevId: 485522603
Change-Id: Iae8284720da52496d7a48fe3ca3c3c8605e6d19d
This uses the Google formatting style to format the prototype comments, with an
internal line length of 75, which accomodates the indentation in the generated
API class.
PiperOrigin-RevId: 435303665
Change-Id: I4dcdf0ed773a79ebc55ead3843f07ca8556fd985
The enclosing type is enough to reconstruct the AST when writing the header and this
change avoids emitting the same struct twice.
PiperOrigin-RevId: 435300029
Change-Id: I34bd660db5ba5c68b64cce73ecf2f026727ac57b
This is a follow up to fa9e6e8a5c.
Drive-by:
- Replace deprecated calls to `getNameAsString()`
PiperOrigin-RevId: 435287759
Change-Id: I81d8c2f93b1ab23c781421b114779b7a241e4a7e
There are a lot of internal users depending on the old behavior of the
libclang-based generator.
PiperOrigin-RevId: 432281224
Change-Id: If82333fc3001f52de59e57a874f28bf8815d0877
Only externally visible changes should be a few changed includes as well as
some formatting changes.
PiperOrigin-RevId: 353226662
Change-Id: Iebf5be13774efcbd94c5d5a17b9b27e47275b229
This change allows us to emit forward declarations to classes that are
templated. For headers generated by the proto compiler this is sometimes
necessary.
Note:
- This will only emit types for a single level of template instantiations.
That is, template template arguments are not supported.
- Typedefs only occurring in template arguments will be fully desugared
and thus will not be available under their aliased name in the generated
API code. This is consistent with the Python based generator (which
does not emit these at all and relies on text extraction).
Signed-off-by: Christian Blichmann <cblichmann@google.com>
- Support multiple input files
- Better testability
- Support for the `--sapi_isystem` argument, same as the Python generator
PiperOrigin-RevId: 333686891
Change-Id: I3e618165c1bd58bb755e1193617fb0737c29ee77
- Extract dependent types directly from the Clang AST and re-serialize
back into compilable code
- Collect types and emit diagnostics
- Format generated code
Signed-off-by: Christian Blichmann <mail@blichmann.eu>
