Change .location, NewLocation, and Location to lazily compute location information

[ashfordium]

• Adds Loc class as replacement for LocationCreator and the location node step. Loc is a replacement that is meant to compute and store less up-front compared to LocationCreator and location. IIUC, scala lazy values also take up space, so I eyeballed the operations that might take more steps to compute and made those lazy and those that are just lookups on the underlying node and made these methods.
• Adds a duplicate of one of the c2cpg test files to use Loc rather than replacing the other tests for now
• Add deprecation warnings to the previous location code

[itsacoderepo]

Sorry for the short comment. Please don't merge this, we need to discuss it first.

[fabsx00]

Why do we need to deprecate the .location step and replace it with .loc? The query language is long-standing public API and .location can be spoken while .loc is more of an abbreviation.

[fabsx00]

I don't think we should deprecate .location in favour of .loc. Is it not possible to simply adapt the old implementation but keep the name? Also, can you motivate why this change is necessary in the first place?

[ashfordium]

I don't think we should deprecate .location in favour of .loc. Is it not possible to simply adapt the old implementation but keep the name? Also, can you motivate why this change is necessary in the first place?

@fabsx00, sorry, I did not see your earlier mesage.

This is an attempt at a more efficient implementation of LOCATION and the .location node step. These implementations compute and store all of the fields of the Location/NewLocation, but users may not use all of the computed information.

I had an internal issue assigned to me, IIUC deprecating instead of replacing the location implementation is because there is maybe some dislike for defining location in the CPG schema. I will send you a link here and maybe we can all discuss.

[ashfordium]

After some discussion: there are understandably some problems with the name loc and Loc: it could means 'lines of code' or something else and isn't directly related to location unless you know already. Maybe we will change the name to .newLocation or .locationLazy or something besides .loc.

[ashfordium]

It was decided that we will replace Location and NewLocation with the new lazily computed location info (previously Loc and .loc in this PR thread). This also means deleting these from the CPG spec: ShiftLeftSecurity/codepropertygraph#1819.

[ashfordium]

Pushed some changes to make this nicer to use as a consumer of joern that extends the codepropertygraph / location types. It is nicer in that both the joern location types and any extended location types can both be wildcard imported, but the extended location types will be used by the implicits because of the way extending the location information uses subclassing.

Say that you have a package, io.shiftleft.extendedcpg that extends the codepropertygraph and location nodes. For these extended nodes, you subclass LazyLocation with something called like ExtendedLazyLocation and provide the implicit apply. Then, in the consuming packages, you now do this:

package io.shiftleft.extendedcpg;

def doSomething(node: AbstractNode): Unit = {
  ...
  val location = node.location
  ...
}

and everything works as expected even if node is an extended node type.

Similarly, if you import both the location types in joern and the location types in the extending and consuming library, then the implicit location creator in the extending and consuming library will be chosen since it will be more specific with this design. So this works as expected:

package io.shiftleft.someotherpackage;
import io.shiftleft.extendedcpg.*
import import io.shiftleft.semanticcpg.language.*

def doSomething(node: AbstractNode): Unit = {
  ...
  val location = node.location
  ...
}

The location will be ExtendedLazyLocation and the location creator in the extended library will be used, not the one in the joern repo.

[ml86]

So the scenario here is that people only have to adjust den import but not the other references to NewLocation in there code?

[ml86]

This should be a recursive call to location, at least my IDE agrees with me.
Same applies to the other XXXMethods.scala files except for NodeMethods.scala.
I think we do not even need all those overrides anymore. It is enough to have location defined in NodeMethods.

[ml86]

Do we still need this? I have not seem a usage in Joern or CS repo outside of declarations.