These are the labmda self references. This is similar to
how `BlockParameterArgumentNode` is excluded for Ruby.
It is important that we restrict `call` in this logic.
Otherwise, we get a cartesian product and the consistency
check runs for a very long time...
TODO:
The member predicate `LibraryLambdaMethod::getACall` is
currently too permissive.
Ideally, we would have `libraryCallHasLambdaArg`
as in Ruby. But even a more precise
`libraryCall` predicate might be fine.
This provides variable capture in standard situations:
- nested functions
- lambdas
There are some deficiencies:
- we do not yet handle objects capturing variables.
- we do not handle variables captured via the `nonlocal` keyword.
This should be solved at the AST level, though, and then it
should "just work".
There are still inconsistencies in the case where
a `SynthesizedCaptureNode` has a comprehensions
as its enclosing callable. In this case,
`TFunction(cn.getEnclosingCallable())` is not
defined and so getEnclosingCallable does not exist
for the `CaptureNode`.
This reverts commit 62910f0cab525ca4d4901c4c27f6e6b22c3375fc.
This reverts commit 75a8197879ec47094d9b18f3dab7bcc1c1cdba28.
We don't find `kombu.serialization.pickle_load` since we respect
`__all__`. I think that was an attempt to not flood the captured
modeling with useless re-exports, but I think we've ended up doing that
anyway... we should consider to remove that restriction!
see 21d7df29c7/kombu/serialization.py (L29)
This reverts commit 1213e786519a11142746fd3a725c874181f3a42b.
By fixing a few bugs in the SubclassFinder + manually running Find.ql on the geonode DB from DCA, I found that the installed version of owslib had both: https://github.com/geopython/OWSLib/blob/0.27.2/owslib/etree.py
I fixed it in both predicates... I think we might still be able to remove
`newDirectAlias` -- but with it being better, it will allow us to better test if `newImportAlias` actually cover everything we need!
Due to the 'only model most specific spec' logic highlighted in previous
commit, I'm changing away from MethodView/View, and use Django view instead.
In practice this shouldn't matter at all, but for writing tests it would
have been a nice fix to only have the "same name but more specific"
logic apply when it's the same _definition_ location. We used to have
this information available, but right now we don't... so instead of
spending a lot of time rewriting the core library, I simply used a
different class :D :O :(
