-
Notifications
You must be signed in to change notification settings - Fork 65
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
Implement AST parent edges #1479
base: main
Are you sure you want to change the base?
Conversation
6faff13
to
6eee05b
Compare
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Due to a bug in the symbol resolver, we did not resolve fields that are in base classes of classes incorrectly
This PR adds the way `Type.isDerivedFrom` works. More concretly, we are once again taking the "wrap state" of the type into account. This means that pointer types and non-pointer types will not match even though their root types derive from each other. This was the way this function behaved in the past and it seems this was changed at some point, which led to some weird over-approximations in call resolving, basically ignoring wether a type was a pointer or not.
* Extracted call/cast replacement into separate pass Multiple languages, such as Go and C++ support "functional style casts", in the form of int(5). During the frontend parsing, they are indistinguishable from function calls. Therefore, we need to do a cleanup after all types are known but before other passes are invoked that replace those calls with casts. The proposed solution is to include a new language trait HasFuntionalCasts and to move the logic from the GoExtraPass into a separate, language-neutral one. Fixes #1487 * Added annotation to pass that requires a language trait
* Fix style of docs * Clean DFG spec a bit * re-generate graph schema with minor style updates
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
* Add BoolOp and + or * nicer error handling * Add some messages to better debug the TODO()s in the future --------- Co-authored-by: Alexander Kuechler <[email protected]>
* Fixing javaparser resultion error * Always use our scope manager --------- Co-authored-by: Alexander Kuechler <[email protected]>
Provides an API similar to #1479 but different approach for setting the AST parent Co-Authored-By: Maximilian Kaul <[email protected]>
Slightly inspired by discussion with @konradweiss. This adds a helper function to set the ast parent in cases where the node cannot be created within the `withChildren` block.
Provides an API similar to #1479 but different approach for setting the AST parent Co-Authored-By: Maximilian Kaul <[email protected]>
I propose to close this in favour of the eventual node build v2 (#1874) |
I'm ok with closing this, if the new nodebuilder supports the idea |
Still open to discussion but the last state implements something like this: example with scope: var func = functionDeclaration(name = parseName("my::name"), rawNode = funcy).withScope {
parameters += handle(funcy.argsy)
} and without scope var func = functionDeclaration(name = parseName("my::name"), rawNode = funcy) {
parameters += handle(funcy.argsy)
} |
WIP!
withChildren
style #1621this
in nested blocks is not anASTStackProvider