llvm-windres gives error in file that other MinGW toolchains do not

[DerellLicht]

I am building a project with clang project, downloaded from this website.
The project builds with no errors with TDM 10.3.0 and other MinGW packages, but gives this error with the clang package:

D:\clang\bin\windres winwiz.rc -v -O COFF -o rc.o
D:/clang/bin/i686-w64-mingw32-clang.exe --driver-mode=gcc -target i686-w64-mingw32 -E -xc -DRC_INVOKED winwiz.rc -o C:/Users/dan7m/AppData/Local/Temp/preproc-996694.rc
llvm-rc: Error parsing file: Invalid token found at position 10358
make: *** [rc.o] Error 1

The version info for this windres is:

D:\SourceCode\Git\winwiz Yes, Master?? > D:\clang\bin\windres --version
llvm-windres, compatible with GNU windres
LLVM (http://llvm.org/):
  LLVM version 20.1.6
  Optimized build.

The resource file can be viewed here; position 10358 appears to be in the middle of line 203
https://github.com/DerellLicht/winwiz/blob/master/winwiz.rc

[DerellLicht]

Further info... the error appears to actually be related to the END statement at line 204...
If I move the END statement down one line, the error changes to :

llvm-rc: Error parsing file: Invalid token found at position 10359

[mstorsjo]

I've looked at building this resource file with llvm-windres, and noticed 4 different issues that causes it to fail to build:

---

Division in arithmetic expressions

1 DIALOG 1, 2, 3, 4
BEGIN
    PUSHBUTTON "Foo", 42, 1, 2, 3, 4/2
END

With llvm-windres, this produces:

llvm-rc: Error parsing file: Invalid token found at position 62

This is accepted by both GNU windres and MS rc.exe; this is a clear defect that should be fixed.

Use of unquoted identifier for icon in dialog

1 DIALOG 1, 2, 3, 4
BEGIN
    ICON IDENTIFIER, 42, 10, 10, 0, 0
END

llvm-rc: Error parsing file: expected int or string, got IDENTIFIER

This is accepted by GNU windres, but MS rc.exe also errors out on it:

dialog-icon-identifier.rc(3) : error RC2104 : undefined keyword or key name: IDENTIFIER

We could consider supporting it, but this is a case of slightly out of spec source input; the correct form would be "IDENTIFIER". (This is the case for IDI_PLUS42IM in the referenced project.) As MS rc.exe doesn't accept it, it's less of a clear cut case. We do support a few things that GNU windres accepts that MS rc.exe doesn't, if they're widespread though.

Missing trailing numbers for icon in dialog

1 DIALOG 1, 2, 3, 4
BEGIN
    ICON "IDENTIFIER", 42, 10, 10
END

llvm-rc: Error parsing file: expected ',', got END

This is accepted by GNU windres, but MS rc.exe also errors out on it:

dialog-icon-abbreviated.rc(4) : error RC2108 : expected numerical dialog constant

This is the same as the previous one; we could consider supporting it, but it's probably also easy to just fix in the source.

Use of ALT in non-virtkey accelerators

1 ACCELERATORS
BEGIN
    "A", 42, ALT
END

llvm-rc: Error in ACCELERATORS statement (ID 1): 
Accelerator ID 42: Can only apply ALT, SHIFT or CONTROL to VIRTKEY accelerators

Both GNU windres and MS rc.exe do seem to accept this, but this seems like a case where llvm-windres is being helpful by rejecting flags that the documentation says doesn't have any effect here.

---

The issue with division arithmetic in expressions is a clear one that should be fixed in any case, the other ones probably can be argued either way.

[DerellLicht]

So which of these issues applies to my file??
I don't think I have any multiplication or division in that file...

my icon declaration isn't within a DIALOG block, it's a stand-alone declaration, and doesn't appear to require any arguments other than filename:

WINWIZICO ICON "pendant.ico"

[mstorsjo]

All of these issues apply to your file.

Here you have divisions: https://github.com/DerellLicht/winwiz/blob/master/winwiz.rc#L250-L253

Here you have an unquoted string: https://github.com/DerellLicht/winwiz/blob/master/winwiz.rc#L352 Plus on the same line you're missing the last two integer parameters to ICON.

At https://github.com/DerellLicht/winwiz/blob/master/winwiz.rc#L31-L37 you have ALT on an accelerator which isn't a VIRTKEY.

[DerellLicht]

Interesting...

Well, the divisions are computations that are significant there, I don't know how to get around them, unless I can change them to shift operations - but I don't know if that is even valid in a .rc file...

and those ALT operations are valid in those statements... at least, the references that I've used were formed that way... and they work fine in the program (which only means that MinGW windres knows what to do with them...)

regarding ICON:
disregard what I previously said here... doing more research...

[DerellLicht]

Wow, that ICON string didn't even exist in the file!! I had copied that dialog from another application, and neglected to update that icon data... sheesh...

And tdm32 windres didn't even complain about it. I just ended up with no icon displaying in the dialog box...

However, the last two parameters are optional, according to MSDN:

ICON text, id, x, y, [[width, height, style [[, extended-style]]]]

[DerellLicht]

Regarding the accelerators, Microsoft shows my form as being valid:

"B",   ID_ACCEL5, ALT                   ; ALT_SHIFT+B 
"I",   ID_ACCEL6, CONTROL, VIRTKEY      ; CTRL+I 
VK_F5, ID_ACCEL7, CONTROL, ALT, VIRTKEY ; CTRL+ALT+F5

https://learn.microsoft.com/en-us/windows/win32/menurc/using-keyboard-accelerators#creating-the-accelerator-table-resource

In fact, if I put VIRTKEY after ALT, the key does not work in the program at all...

[DerellLicht]

Hi @mstorsjo - when will I be able to get the i686/gnu distribution with the above fix included??

You mentioned three issues in my winwiz.rc file that could potentially cause problems with llvm-windres,
but the only one that I was actually getting an error on was the division issue that you fixed;
I would like to try it out when the distribution becomes available!!

[mstorsjo]

You mentioned three issues in my winwiz.rc file that could potentially cause problems with llvm-windres, but the only one that I was actually getting an error on was the division issue that you fixed

Yes, it errored out on the first issue; if one sidesteps that (which of course isn't a valid workaround in itself) one can see all the other issues after that, one at a time.

when will I be able to get the i686/gnu distribution with the above fix included??

I have a fix for the division issue pretty much ready to file for review. Once merged it would be available in llvm-mingw nightlies at https://github.com/mstorsjo/llvm-mingw/releases/nightly the next day. If it is deemed reasonable enough, and is done in time, it could also potentially be backported to the last 20.1.x point releases, but that may be tight. If it doesn't make it in time for that (and/or isn't approved for backport), it'll be in the 21.x release series which should have a first stable release around September.

[mstorsjo]

However, the last two parameters are optional, according to MSDN:

ICON text, id, x, y, [[width, height, style [[, extended-style]]]]

(To add references to this, this is at https://learn.microsoft.com/en-us/windows/win32/menurc/icon-control.)

Indeed this seems to be how it is documented, yet despite this, their own tool doesn't accept this form - if we try this snippet with MS rc.exe:

1 DIALOG 1, 2, 3, 4
BEGIN
    ICON "IDENTIFIER", 42, 10, 10
END

dialog-icon-abbreviated.rc(4) : error RC2108 : expected numerical dialog constant

As it is documented this way, we could of course consider allowing this form.

[mstorsjo]

Regarding the accelerators, Microsoft shows my form as being valid:

"B",   ID_ACCEL5, ALT                   ; ALT_SHIFT+B 
"I",   ID_ACCEL6, CONTROL, VIRTKEY      ; CTRL+I 
VK_F5, ID_ACCEL7, CONTROL, ALT, VIRTKEY ; CTRL+ALT+F5

https://learn.microsoft.com/en-us/windows/win32/menurc/using-keyboard-accelerators#creating-the-accelerator-table-resource

In fact, if I put VIRTKEY after ALT, the key does not work in the program at all...

I'm not really familiar with these accelerators; I presume things work a bit differently if they are treated as VIRTKEY (then you wouldn't use a literal character like "B" in the example above, but you'd use a virtual key integer like VK_F5).

Anyway, the docs at https://learn.microsoft.com/en-us/windows/win32/menurc/accelerators-resource say this:

ALT Causes the accelerator to be activated only if the ALT key is down. Applies only to virtual keys.

But if you say that this is useful also for non-virtkey accelerators, do we agree that the documentation is wrong? (Much of the documentation on that site is publicly editable via github repos like https://github.com/MicrosoftDocs/cpp-docs - so for those cases, it's very easy to make a pull request to them, to get it confirmed that it is a documentation bug. But I don't see that particular document there.)

In that case we should probably fix llvm-rc to not reject this case as well.