Part of issue588.

Merged and pushed.

Yes, looks good!

I took care of your comments. Can we merge this?

I made some more comments.

I think one reviewer is indeed enough given that you already verified the
output, and in any case if anything goes seriously wrong here, the build bot is
likely to let us know about it.

If you're happy with the changes, Malte, maybe Silvan doesn't need to take a look 
after all?

Thanks, I hope my commit takes care of your comments.

I've had a look and made a few comments.

I can have a look at it, but don't know when yet (likely not today, and likely
earliest on Monday).

I made a pull request at 
https://bitbucket.org/jendrikseipp/downward/pull-requests/69

The help output is identical with the only difference being that now we sort the 
plugin type names alphabetically. Previously they were not sorted.

Any volunteers for reviewing it?

I'll try to find a solution for this. Changed the title to reflect the main change 
in this issue.

This makes sense. I forgot that these are still explicitly referenced by the
option parser code. So this one will go away automatically once we finish what
we started with the option parser. I don't think it's worth doing anything about
this in the meantime, but perhaps someone wants to take this as extra motivation
to contribute to the ongoing option parser effort. :-)

> By the way, the first occurrence of this bug was for Synergy, whose type plugin
> is defined in landmarks/lama_synergy.cc. I think it should be in
> options/synergy.cc instead. This isn't a solution for the overall problem, but I
> think it makes more sense to have the plugin definition next to the class
> definition, not next to its usage.

Synergy is special in some ways to the option parser because it returns two
things, and things leads to additional ugliness in the current code. I suggest
we also ignore this because we want to get rid of synergies in the long run.
(They are not actually needed; the same thing can be achieved without the
double-assignment option syntax with a wee bit of trickery that I didn't think
of when we first added this.)

I ran this in gdb and found the reason, but I don't know what to do about it.

If files that define PluginTypePlugins are disabled, then the help generation
for those classes will crash because it will try to access information about
those plugins.

If we get rid of the need to explicitly specify types for the help output in
issue588, this would fix the issue. Until then, I don't know how to avoid this.
Would it be problematic to leave it like this for now?


By the way, the first occurrence of this bug was for Synergy, whose type plugin
is defined in landmarks/lama_synergy.cc. I think it should be in
options/synergy.cc instead. This isn't a solution for the overall problem, but I
think it makes more sense to have the plugin definition next to the class
definition, not next to its usage.

When compiling with only
PLUGIN_BLIND_SEARCH_HEURISTIC_ and
PLUGIN_EAGER_SEARCH_ENABLED
enabled, ./fast-downward.py --help crashes.