[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