`LLVM::Attribute` with more than 64 kinds

[HertzDevil]

There are currently 98 LLVM attributes, and this number is expected to increase. LLVM::Attribute in Crystal maintains only a subset of these, but LLVM could e.g. attach them to intrinsics at will, in which case the corresponding enum member must be present (see Captures in #15771). Yet, since LLVM::Attribute is a 64-bit flags enum, by definition it cannot represent every possible attribute, and increasing the underlying type to a 128-bit integer merely delays the onset of the issue.

IMO we should first define the attribute kinds in a new non-flags enum:

enum LLVM::AttributeKind
  Alignment
  AllocSize
  AlwaysInline
  # ...
end

Then the old LLVM::Attribute will be served by a new bitset type:

struct LLVM::AttributeSet
  @set = uninitialized UInt8[16] # enough to hold all `AttributeKind`s

  # this is the same as the one in `Attribute`
  private def self.load_llvm_kinds_from_names
    # `get_last_enum_attribute_kind` is one past the greatest valid index
    unless sizeof(@set) * 8 >= LibLLVM.get_last_enum_attribute_kind
      raise "BUG: AttributeSet is not large enough!"
    end
    # ...
  end
end

Alternatively, the set-like behavior of LLVM attribute kinds might not be needed at all, and there would be bindings for individual attributes instead (e.g. EnumAttribute, StringAttribute). In either case LLVM::Attribute will be deprecated.

[straight-shoota]

I count even 111 attributes in that file (number of matches against def .+:\s\w+Attr<"). Even more reason to avoid a fixed 128-bit limit.

LLVM itself separates attributes into different types, so I suppose it would be natural to do this in the Crystal API as well.
The proposal to separate LLVM::Attribute into individual enums for each attribute type would be my preference.
EnumAttr still has 79 values, so we'll need to upgrade to a 128 bit integer. But there's at least a lot of space to grow.

[HertzDevil]

LibLLVM.get_enum_attribute_kind_for_name returns 0 for all the StrBoolAttrs and ComplexStrAttrs at the bottom, and LibLLVM.get_last_enum_attribute_kind excludes these attributes. I don't know why. (More specifically, it seems the IDs are assigned by EnumAttr -> TypeAttr -> IntAttr -> ConstantRangeAttr -> ConstantRangeListAttr, then by internal name.)