Use existing AvailabilityKind enum for code completion availability (#160296)
This adresses point 4 from #156680. This is a necessary step before
`CompletionChunk.Kind` can be removed.
The `ChunkCompletion.Kind` implements `__str__` and `__repr__`
differently from our other enum classes. I have adapted the `__repr__`
of `CompletionString` to stringify the availability of the chunk
differently so that it still looks the same as before.
Also introduce a temporary `AvailabilityKindCompat` to ensure that
`__str__` returns the same format, while also leaving a deprecation
warning that this will be removed in a future release.
---------
Co-authored-by: Vlad Serebrennikov <serebrennikov.vladislav at gmail.com>
[clang][ssaf] Add the TUSummaryExtractorRegistry (#173290)
This patch adds the TUSummaryExtractorRegistry for plugging in custom
summary extractors.
This also adds a fake TUSummaryBuilder to observe the side effects of
inserting into the registry.
The original TUSummaryBuilder class will be used to create EntityIDs and
to map those to summary "facts" in the shape of "TUSummaryData" objects,
but that part is not yet upstreamed.
The important point is that TUSummaryBuilders have a use beyond just testing.
---------
Co-authored-by: Jan Korous <jkorous at apple.com>
[AArch64][GlobalISel] Generate WZR for constants < 32bits. (#176106)
I believe how this should work is that a GPR G_CONSTANT is legalized at
least in regbankselect, but this helps clean up some gisel
inefficiencies and prevent some regressions in #175810.
[NFC][IR2Vec][MIR2Vec] llvm-ir2vec refactor - move Tool class implementations into a separate utils file (#174133)
# Refactoring Tool class implementation into a separate utils file
- Addresses https://github.com/llvm/llvm-project/issues/141839
## Summary
This patch extracts the core functionality of llvm-ir2vec's Tool classes
into a separate emb-tool class files to enable code reuse and future
extensibility. This is the next step toward adding Python bindings
interfaces to IR2Vec/MIR2Vec.
## Motivation
Currently, all llvm-ir2vec functionality is contained together. This
makes it difficult to:
- Reuse the embedding generation logic in other contexts
- Create language bindings (Python, etc.)
- Build additional tools on top of IR2Vec/MIR2Vec
[38 lines not shown]