Issues with "future" parser in 9.2 beta

IDA General
1

I’ve encountered some quirks of the “future” parser while testing it:

  1. By default, the first parameter of a __thiscall function will be assigned the name this by IDA. However, if you try to modify the function prototype without removing the name this (which is reserved), the future parser will throw an error: 1:61 error invalid parameter name: 'this' is a keyword .
    This has quickly gotten frustrating, because the legacy parser could handle this just fine.

  2. When changing the type of a parameter through the decompiler UI (by pressing Y), it’s necessary to specify a name for the parameter as well, otherwise I get another parse error: 1:9 error expected unqualified-id. The legacy parser could handle me just entering int * as the type, and completely ignored whatever parameter name I provided.

  3. Not exactly a parser issue, but something that I think should be corrected at some point: by default, it is still impossible to assign templated names to functions (or seemingly any other data). If I have a struct called A<B>, and there’s a __thiscall function that works on objects of type A<B>, and I know that function corresponds to a method called C, I would like to be able to name the function A<B>::C, instead of something weird like A_B::C.

Separate from all of this, I’m constantly getting tripped up by the recent changes to the behavior of “Add Type”. In the past, I could press INS on the local type window, enter multiple type declarations in the dialog, click OK, and they’d all get created. If I do the same thing today, I get a bunch of parser errors (whether I use the future parser or the legacy parser). This seriously confused me, but I eventually realized that’s because I need to use the “Parse declarations” command instead… even though the documentation suggests the old way should still work:

Please note that Ins can be used to add many types at once. For that the user just needs to enter multiple declarations, one after another in the dialog box.

This hasn’t worked for me since IDA 9.1. Just try putting struct MultiDec1 {};struct MultiDec2 {}; (with any indentation or line-breaking you want) in the Ins-triggered dialog. On IDA 9.2 with the future parser, only MultiDec1 is added.

I like the direction the product is going (even partial support for C++ template types is enormously helpful for me), and hope some of these rough edges can be addressed before the final release of 9.2.

2

Another bug: re-typing a local variable to a shifted pointer that references a namespaced type will result in a parser error.

struct TestNS::TestStruct
{
    unsigned int x1;
    unsigned int x2;
    unsigned int x3;
};

image
image535×145 6.62 KB

image

It seems like colons are being replaced with underscores, and that’s messing up the compiler?

3

Thank you very much for the report! For the future, please use https://support.hex-rays.com/ > Early access feedback, as that allows us to track and route the beta issues better (we don’t monitor the forum as closely).

5

Noted; should I go ahead and submit the things I’ve listed in this thread, or have they already been recorded somewhere?

6

No need to resubmit, we handled these already. Thank you.

1 Like