Using the structure search plugin


If I want to search on all if statements how would I do it?

Currently if I enter:

if ($expr$)
{

}

It doesn't match. How do I use this sucker?




9 comments
Comment actions Permalink

You are searching for if statements with empty bodies.

Try this:

where $statement$ has an occurrences count of 0-100000.

Good luck. You need it with the structural search. :)

/Mikael

0
Comment actions Permalink

I've tried to perform the same search as well, but could
not get consistent behaviour. It helps to put a $statements$
variable in the search pattern or else, as pointed above,
the search looks for an empty if statement. Also, I've
noticed that the $expr$ variable must have a pattern or else it does not match anything, so maybe this is the problem.
The $statements$ var should or can have no pattern and it should not be a target of the search.

Also, as Maxim Mossienko pointed out (without really explaining), the pattern is parsed by the same Java parser as in the editor,
So the pattern should be a valid java like construct.
I think the search parser allows access to
the various productions in the grammar, allowing the plugin to identify the kind of construct the search is
looking for and to ignore chunks of productions where the
variables are specified.
What I'm not sure of is why sometimes specifying no text pattern behaves the same as
specifying .* - both grab anything between the syntactic
delimiters (the parentheses in your pattern).

0
Comment actions Permalink


I got something working. Weird thing though. If you have nested if's
sometimes it will pick up the inner if and sometimes the outer if but never
both.

-- Glen

"Bonny Rais" <bonnyr@optushome.com.au> wrote in message
news:28728675.1088030937521.JavaMail.itn@is.intellij.net...

I've tried to perform the same search as well, but could
not get consistent behaviour. It helps to put a $statements$
variable in the search pattern or else, as pointed above,
the search looks for an empty if statement. Also, I've
noticed that the $expr$ variable must have a pattern or else it does not

match anything, so maybe this is the problem.

The $statements$ var should or can have no pattern and it should not be a

target of the search.
>

Also, as Maxim Mossienko pointed out (without really explaining), the

pattern is parsed by the same Java parser as in the editor,

So the pattern should be a valid java like construct.
I think the search parser allows access to
the various productions in the grammar, allowing the plugin to identify

the kind of construct the search is

looking for and to ignore chunks of productions where the
variables are specified.
What I'm not sure of is why sometimes specifying no text pattern behaves

the same as

specifying .* - both grab anything between the syntactic
delimiters (the parentheses in your pattern).

>


0
Comment actions Permalink

Glen Stampoultzis wrote:

I got something working. Weird thing though. If you have nested if's
sometimes it will pick up the inner if and sometimes the outer if but never
both.


Try turning on recursive matching?

Ciao,
Gordon

--
Gordon Tyler (Software Developer)
Quest Software <http://java.quest.com/>
260 King Street East, Toronto, Ontario M5A 4L5, Canada
Voice: (416) 933-5046 | Fax: (416) 933-5001

0
Comment actions Permalink

Hi,

Since there is no else branch in your pattern the plugins pick ups the
ifs without else (which appears nested sometimes:)
So general form for the if would be:
if ($expr$) {
$ThenStatements$;
} else {
$ElseStatements$;
}

$ThenStatements$ - 0 ... max_value
$ElseStatements$ - 0 ... max_value

Constraint for $expr$ is not needed.

Glen Stampoultzis wrote:

I got something working. Weird thing though. If you have nested if's
sometimes it will pick up the inner if and sometimes the outer if but never
both.

-- Glen

"Bonny Rais" <bonnyr@optushome.com.au> wrote in message
news:28728675.1088030937521.JavaMail.itn@is.intellij.net...

>>I've tried to perform the same search as well, but could
>>not get consistent behaviour. It helps to put a $statements$
>>variable in the search pattern or else, as pointed above,
>>the search looks for an empty if statement. Also, I've
>>noticed that the $expr$ variable must have a pattern or else it does not


match anything, so maybe this is the problem.

>>The $statements$ var should or can have no pattern and it should not be a


target of the search.

>>Also, as Maxim Mossienko pointed out (without really explaining), the


pattern is parsed by the same Java parser as in the editor,

>>So the pattern should be a valid java like construct.
>>I think the search parser allows access to
>>the various productions in the grammar, allowing the plugin to identify


the kind of construct the search is

>>looking for and to ignore chunks of productions where the
>>variables are specified.
>>What I'm not sure of is why sometimes specifying no text pattern behaves


the same as

>>specifying .* - both grab anything between the syntactic
>>delimiters (the parentheses in your pattern).
>>




--
Best regards,
Maxim Mossienko
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

0
Comment actions Permalink

Hi,

Recursive matching turned on should allow finding all nested ifs (given
the pattern is updated to have else part).

Gordon Tyler wrote:

Glen Stampoultzis wrote:

>> I got something working. Weird thing though. If you have nested if's
>> sometimes it will pick up the inner if and sometimes the outer if but
>> never
>> both.


Try turning on recursive matching?

Ciao,
Gordon



--
Best regards,
Maxim Mossienko
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

0
Comment actions Permalink

Hi,

If someone interested, the structural search works in the following way:
- The pattern is (should be) valid java code (on block level), it is
parsed by the java parser producing the PSI tree.
- Then the tree is matched on source java trees in order to find such
fragments which are suitable for the constraints specified.
- Search variables are evaluated as tree fragments.
- Variable with unspecified (empty) constraints will get the value as
appropriate by the context (as if .* text pattern is specified).

Bonny Rais wrote:

I've tried to perform the same search as well, but could
not get consistent behaviour. It helps to put a $statements$
variable in the search pattern or else, as pointed above,
the search looks for an empty if statement. Also, I've
noticed that the $expr$ variable must have a pattern or else it does not match anything, so maybe this is the problem.
The $statements$ var should or can have no pattern and it should not be a target of the search.

Also, as Maxim Mossienko pointed out (without really explaining), the pattern is parsed by the same Java parser as in the editor,
So the pattern should be a valid java like construct.
I think the search parser allows access to
the various productions in the grammar, allowing the plugin to identify the kind of construct the search is
looking for and to ignore chunks of productions where the
variables are specified.
What I'm not sure of is why sometimes specifying no text pattern behaves the same as
specifying .* - both grab anything between the syntactic
delimiters (the parentheses in your pattern).



--
Best regards,
Maxim Mossienko
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

0
Comment actions Permalink


Many thanks. However I'm still getting some problems. I've added an else
condition and put the suggested constraints on it but it still ignores
anything with an else part.

Regards,

Glen

"Maxim Mossienko" <Maxim.Mossienko@jetbrains.com> wrote in message
news:cbesnq$41a$1@is.intellij.net...

Hi,

>

Since there is no else branch in your pattern the plugins pick ups the
ifs without else (which appears nested sometimes:)
So general form for the if would be:
if ($expr$) {
$ThenStatements$;
} else {
$ElseStatements$;
}

>

$ThenStatements$ - 0 ... max_value
$ElseStatements$ - 0 ... max_value

>

Constraint for $expr$ is not needed.

>

Glen Stampoultzis wrote:

>

I got something working. Weird thing though. If you have nested if's
sometimes it will pick up the inner if and sometimes the outer if but

never

both.

>

-- Glen

>

"Bonny Rais" <bonnyr@optushome.com.au> wrote in message
news:28728675.1088030937521.JavaMail.itn@is.intellij.net...

>
>>I've tried to perform the same search as well, but could
>>not get consistent behaviour. It helps to put a $statements$
>>variable in the search pattern or else, as pointed above,
>>the search looks for an empty if statement. Also, I've
>>noticed that the $expr$ variable must have a pattern or else it does not
>

match anything, so maybe this is the problem.

>
>>The $statements$ var should or can have no pattern and it should not be

a

>

target of the search.

>
>>Also, as Maxim Mossienko pointed out (without really explaining), the
>

pattern is parsed by the same Java parser as in the editor,

>
>>So the pattern should be a valid java like construct.
>>I think the search parser allows access to
>>the various productions in the grammar, allowing the plugin to identify
>

the kind of construct the search is

>
>>looking for and to ignore chunks of productions where the
>>variables are specified.
>>What I'm not sure of is why sometimes specifying no text pattern behaves
>

the same as

>
>>specifying .* - both grab anything between the syntactic
>>delimiters (the parentheses in your pattern).
>>
>
>
>

>
>

--
Best regards,
Maxim Mossienko
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"



0
Comment actions Permalink

Hi,
Please, post the exact pattern with constraints you are using and the
code you would like to match.


Glen Stampoultzis wrote:

Many thanks. However I'm still getting some problems. I've added an else
condition and put the suggested constraints on it but it still ignores
anything with an else part.

Regards,

Glen

"Maxim Mossienko" <Maxim.Mossienko@jetbrains.com> wrote in message
news:cbesnq$41a$1@is.intellij.net...

>>Hi,
>>
>>Since there is no else branch in your pattern the plugins pick ups the
>>ifs without else (which appears nested sometimes:)
>>So general form for the if would be:
>>if ($expr$) {
>> $ThenStatements$;
>>} else {
>> $ElseStatements$;
>>}
>>
>>$ThenStatements$ - 0 ... max_value
>>$ElseStatements$ - 0 ... max_value
>>
>>Constraint for $expr$ is not needed.
>>
>>Glen Stampoultzis wrote:
>>
>>
>>>I got something working. Weird thing though. If you have nested if's
>>>sometimes it will pick up the inner if and sometimes the outer if but


never

>>>both.
>>>
>>>-- Glen
>>>
>>>"Bonny Rais" <bonnyr@optushome.com.au> wrote in message
>>>news:28728675.1088030937521.JavaMail.itn@is.intellij.net...
>>>
>>>
>>>>I've tried to perform the same search as well, but could
>>>>not get consistent behaviour. It helps to put a $statements$
>>>>variable in the search pattern or else, as pointed above,
>>>>the search looks for an empty if statement. Also, I've
>>>>noticed that the $expr$ variable must have a pattern or else it does not
>>>
>>>match anything, so maybe this is the problem.
>>>
>>>
>>>>The $statements$ var should or can have no pattern and it should not be


a

>>>target of the search.
>>>
>>>
>>>>Also, as Maxim Mossienko pointed out (without really explaining), the
>>>
>>>pattern is parsed by the same Java parser as in the editor,
>>>
>>>
>>>>So the pattern should be a valid java like construct.
>>>>I think the search parser allows access to
>>>>the various productions in the grammar, allowing the plugin to identify
>>>
>>>the kind of construct the search is
>>>
>>>
>>>>looking for and to ignore chunks of productions where the
>>>>variables are specified.
>>>>What I'm not sure of is why sometimes specifying no text pattern behaves
>>>
>>>the same as
>>>
>>>
>>>>specifying .* - both grab anything between the syntactic
>>>>delimiters (the parentheses in your pattern).
>>>>
>>>
>>>
>>>
>>
>>--
>>Best regards,
>> Maxim Mossienko
>>IntelliJ Labs / JetBrains Inc.
>>http://www.intellij.com
>>"Develop with pleasure!"




--
Best regards,
Maxim Mossienko
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

0

Please sign in to leave a comment.