-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Type system / manager overhaul #1199
Conversation
5c6b31c
to
2aad863
Compare
First iteration of this is done. Before I cleanup the type manager itself any more... any first feedback on this? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's a very good idea to let the frontends generate and parse the types as they have more (specific and relevant) information available and we do not have to assemble a string only to parse it again. I also think that adding this to a frontend shouldn't be problematic in most cases.
It would be good to have one method in the LanguageFrontend
which has to be implemented by their instances to generate the type. Currently, they have a different name everywhere. I'd also appreciate to have a common usage pattern provided by the node builder (e.g. pointer(primitiveType("int"))
instead of primitiveType("int").reference(POINTER)
or so). I think this is not consistent yet.
cpg-language-cxx/src/main/kotlin/de/fraunhofer/aisec/cpg/frontends/cxx/CPPLanguage.kt
Outdated
Show resolved
Hide resolved
2a088e7
to
12b828d
Compare
Kudos, SonarCloud Quality Gate passed! |
68cbaa2
to
ac4579e
Compare
5e814e1
to
6b307b5
Compare
ee38bd0
to
3b6e111
Compare
ba0de3f
to
340a5f8
Compare
5338ea5
to
07ffc9d
Compare
0c5239f
to
023a53d
Compare
Kudos, SonarCloud Quality Gate passed! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTU
This PR contains a complete re-write of the Go language frontend based on JNA instead of a pure Go implementation. While this has a slight performance drawback (I am working on providing some numbers), it has infinitly better debugging capabilities. The handlers and most of the frontend itself is written in Kotlin using our classes and we than use a JNA bridge to a C API wrapper around the Go `go/ast` package. Depends on #1199 Fixes #1256 Fixes #1257 Fixes #1258 Fixes #1259
This PR contains a complete re-write of the Go language frontend based on JNA instead of a pure Go implementation. While this has a slight performance drawback (I am working on providing some numbers), it has infinitly better debugging capabilities. The handlers and most of the frontend itself is written in Kotlin using our classes and we than use a JNA bridge to a C API wrapper around the Go `go/ast` package. Depends on #1199 Fixes #1256 Fixes #1257 Fixes #1258 Fixes #1259
This PR contains a complete re-write of the Go language frontend based on JNA instead of a pure Go implementation. While this has a slight performance drawback (I am working on providing some numbers), it has infinitly better debugging capabilities. The handlers and most of the frontend itself is written in Kotlin using our classes and we than use a JNA bridge to a C API wrapper around the Go `go/ast` package. Depends on #1199 Fixes #1256 Fixes #1257 Fixes #1258 Fixes #1259
This PR contains a complete re-write of the Go language frontend based on JNA instead of a pure Go implementation. While this has a slight performance drawback (I am working on providing some numbers), it has infinitly better debugging capabilities. The handlers and most of the frontend itself is written in Kotlin using our classes and we than use a JNA bridge to a C API wrapper around the Go `go/ast` package. Depends on #1199 Fixes #1256 Fixes #1257 Fixes #1258 Fixes #1259
Prep Work
TypeManager
to KotlinProblemType
, similar toProblemDeclaration
andProblemExpression
newPrimitiveType
andnewObjectType
as part of the node buildersFrontends
C/C++ Frontend
newPrimitiveType
instead of calling the type parserparseType
with type parsing in frontend andnewObjectType
Java Frontend
newPrimitiveType
instead of calling the type parserparseType
with type parsing in frontend andnewObjectType
LLVM Frontend
newPrimitiveType
instead of calling the type parserparseType
with type parsing in frontend andnewObjectType
TypeScript Frontend
newPrimitiveType
instead of calling the type parserparseType
with type parsing in frontend andnewObjectType
Go Frontend
newPrimitiveType
instead of calling the type parserparseType
with type parsing in frontend andnewObjectType
Python Frontend
newPrimitiveType
instead of calling the type parserparseType
with type parsing in frontend andnewObjectType
Cleanup
TypeParser
unsigned long long int
) to correctly parse all primitive typestypeOf
function in theLanguageFrontend
)