michaelplatings added a comment.
A constraint is that the user should be able to choose the library with a
single list of arguments, as displayed with `-print-multi-lib`. Therefore I'm
sceptical about making the selection mechanism too expressive, because
`-print-multi-lib` can't explain that to the user. Already the presence of
negation is stretching that.
Nevertheless let's pick an example of something that can't be directly
expressed in the prototype: `NOT (a AND b)`. (I don't know why you'd want to do
that, if you have a motivating example of something genuinely useful then that
would be better)
The expression can be rearranged to `(a AND NOT b) OR (b AND NOT a) OR ((NOT a)
AND NOT b)` which can be represented in an ugly way:
variants:
- path: p
args: [-a]
attrs: [a, not-b]
- path: p
args: [-b]
attrs: [not-a, b]
- path: p
args: []
attrs: [not-a, not-b]
arguments:
- regex: -a
matchAttrs: [a]
noMatchAttrs: [not-a]
- regex: -b
matchAttrs: [b]
noMatchAttrs: [not-b]
I think this fits with the spirit of "Make the easy things easy, and the hard
things possible."
> perhaps it's enough to just make sure there's extension room in the syntax so
> that this can be added later
One of the many nice things about JSON & YAML is it gives you loads of room for
extension, so yes. For example, currently `attrs` must be an array, but the
option could be added later that it could be an object like `attrs: {not: [a,
b]}`. But I hope it doesn't prove necessary ;)
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D140959/new/
https://reviews.llvm.org/D140959
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
