Structural search support for filter repo:contains

[jensim]

Feature request description

repo:contains(file:java$ content:@:[[_]]Mapping patternType:structural) type:repo

Is your feature request related to a problem? If so, please describe.

I'm always frustrated when writing RegExp, cursing and wishing i was able to use the structural search instead..

Describe alternatives you've considered.

Regexp covers most simple cases, but structural search does everything better.

Additional context

Having comby match rules defined in the the filter would also improve the usefulness a lot.

This would help me find repos with patterns between files, like this case:
I have a suite of a few hundred applications built using maven, that have grown up over the last 10 years. And there's been poor use of maven properties in combination with an abundance of maven submodules everywhere. Where versions are declared in a root project properties block, and then consumed in a submodule. This causes modern upgrade mechanics like renovate to be unable to upgrade such versions using regular mvn versions:update-properties.

my-parent
├─ pom.xml
└─ applications
   ├─ pom.xml
   └─ my-application
      └─ pom.xml

I would like to be able to search for these using structural search something like this

# Find the root pom with a hole for a property declaration, hole will match
repo:contains(file:^pom.xml$ content:<properties>:[_]<:[propName~[^>]+]>:[_]</properties>
# Match a pom.xml that is not in the root
file:/pom.xml$
# Match a version declaration using property
<version>${:[verName~[^}]+]}</dependency>
# Make sure the property is not also declared here
not <:[propName2~[^>]+]>
# rule match that all are the same
rule:'where :[verName] == :[propName2] && :[propName2] == :[propName]'

[jensim]

Since I know little of the underlying challenges of implementing this.. I'm just sharing this feature request as a proposal, that I would be helped by having available in sourcegraph. It might (or not) be difficult to implement the cross-file matching, and negative matching that I imply in this feature request.

[rvantonder]

Noted! Most of the time, it's straightforward for us to add the functionality--the issue is making sure it's consistently performant enough so that users of larger installations don't go "this is too slow and sucks/seems broken". I think there is a middleground here, where we can identify potentially more expensive/unbounded searches and just give you a very visible indicator when you type the query that "this is possible but known to have potentially run slow--do not expect this to terminate soon".

Appreciate the additional context here, very useful!

[jensim]

I think there is a middleground here, where we can identify potentially more expensive/unbounded searches and just give you a very visible indicator when you type the query that "this is possible but known to have potentially run slow--do not expect this to terminate soon".

I love this approach! I sometimes need to add timeout to some of my läwider searches already, and that's totally fine!! 😁