代码拉取完成，页面将自动刷新
Currently we maintain all attributes in the same list (function, field, attr，GenericAttrKind).
We are running out of the bits so should we consider seperate them by purpose?
To be more specific，why do we need GenericAttrKind?
enum AttrKind : unsigned {
#define TYPE_ATTR
#define ATTR(STR) ATTR_##STR,
#include "all_attributes.def"
#undef ATTR
#undef TYPE_ATTR
};
enum FieldAttrKind {
#define FIELD_ATTR
#define ATTR(STR) FLDATTR_##STR,
#include "all_attributes.def"
#undef ATTR
#undef FIELD_ATTR
};
enum FuncAttrKind : unsigned {
#define FUNC_ATTR
#define ATTR(STR) FUNCATTR_##STR,
#include "all_attributes.def"
#undef ATTR
#undef FUNC_ATTR
};
// only for internal use, not emitted
enum GenericAttrKind {
#define FUNC_ATTR
#define TYPE_ATTR
#define FIELD_ATTR
#define ATTR(STR) GENATTR_##STR,
#include "all_attributes.def"
#undef ATTR
#undef FUNC_ATTR
#undef TYPE_ATTR
#undef FIELD_ATTR
};
I did not know anything about GenericAttrKind and why or who introduced it. But on a grep, I think it is OK to remove it. It is only used by class GenericAttrs, and this class defines some member functions, but nobody uses GenericAttrs at all.
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。
HuWen
成员
GenericAttrKind is used by frontend, please check dex2mpl. during parsing, we record all attributes to be generic ones first then check whether it is for type, function or fields and convert to specific kinds
In class GenericAttrs:
private:
uint64 attrFlag = 0;
Just make this field larger than 64 bits, since this is the only field that needs more than 64 attributes.
Since this issue can be solved by dex2mpl, it is no longer a general issue.
登录 后才可以发表评论