Using the structure search plugin

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

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).

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).

>

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

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!"

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!"

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!"

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!"

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!"