This patch implements experimental vararg support for Darwin.
It's experimental because I don't know how exaclty you want to treat such params. Perhaps you also would like to use number references for it $0, $1, .., $n.
Patch adds dual representation of vararg parameter:
- It is kept as single vararg string.
- It also parsed onto tokens and stored in regular arguments collection.
Since don't know whether you need it at all, I've only activated GAS compatible rules.
Perhaps it would be dead Diff. But perhaps you will put your requests here, and I'll try to implement them ;-)
Here you can find:
- Patch himself.
- Test for darwin.
I also not sure about existing style. May be we refactor it a bit?
- Is it ok, we use structs everywhere? We could convert some of them into classes.
E.g.: MCAsmMacroParameter structure could be converted into:
class MCAsmMacroParameter {
StringRef Name;
MCAsmMacroArgument DefaultValue;
bool Required;
public:
void setName(StringRef Name) { this->Name = Name; }
StringRef getName() const { return Name; }
void setDefaultValue(const MCAsmMacroArgument &V) { DefaultValue = V; }
const MCAsmMacroArgument &getDefaultValue() const { return DefaultValue; }
void setRequired(bool Required) { this->Required = Required; }
bool getRequired() const { return Required; }
MCAsmMacroParameter() : Required(false) {}
};You'll get bigger constructions (P.getName() instead of P.Name). But.. well I don't know why, my intuition just hints me to prefer classes.
By now, I've kept structures.
- We could also use SmallVector instead of std::vector. Since collections are usually less than 8 items in size. I've kept std::vector in this diff.
- What do you think about "Substitution" term? In expandMacro we could use "ArrayRef<MCAsmMacroArgument> Substitutions" name then (instead of "ArrayRef<MCAsmMacroArgument> A").
So, if you agree, may be first we prepare refactor patch then?