[PATCH] D106598: [llvm-rc] Allow dashes as part of resource name strings
Adrian McCarthy via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Jul 23 09:28:53 PDT 2021
amccarth added a comment.
Cool. I'd never seen anyone use strings that don't look like a C or C++ identifier as a resource identifier, but it should work given that FindResource just uses the string as an opaque key.
If we maximally munch everywhere, we could consume an expression as a single identifier. For example:
#define WIDTH 400
#define HEIGHT 300
#define MARGIN 8
MyDlg DIALOGBOXEX 10, 10, WIDTH, HEIGHT
BEGIN
LTEXT "Text in dialog", 4, 4, WIDTH-MARGIN, HEIGHT-MARGIN
END
In this context, `WIDTH-MARGIN` better be recognized as three tokens representing an expression rather than as a single (undefined) identifier. I know there's code out there like that.
Also, we'd better not allow these types of identifiers to be defined, i.e., don't allow `#define FOO-BAR 42`.
If you add those examples as test cases and they do the right thing, I'd be happy with this change.
My guess is that RC.EXE is implemented as a recursive descent parser that doesn't really have a uniform concept of "tokens." When it's expecting a "numeric or string identifier," it applies one set of munching rules, but when it's expecting an expression, it applies a different set. I haven't looked closely enough to see whether llvm-rc has that kind of flexibility at tokenization.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D106598/new/
https://reviews.llvm.org/D106598
More information about the llvm-commits
mailing list