Open Bug 1216730 Opened 10 years ago Updated 8 months ago

stop lying about JSJitInfo::ArgType being an enum

Categories

(Core :: JavaScript Engine: JIT, defect, P5)

43 Branch
defect

Tracking

()

People

(Reporter: froydnj, Unassigned)

References

(Blocks 1 open bug)

Details

We currently have this nice enum for JSJitInfo::ArgType. But the bindings codegen contains code that will merrily OR enum members together and forcibly cast the result back to a JSJitInfo::ArgType. This scheme works OK for Gecko, but fails for Servo: the automatically translated JS engine bindings for Rust define ArgType as a Rust enum, because that's what it looks like in C++. But because enums in Rust are much stronger than they are in C++, trying to OR enum values together makes Rust unhappy about trying to forcibly cast a random integer value into an ArgType. The current workaround (https://github.com/servo/servo/pull/8040) is to just give up when we would have to OR enum values together and just say we return "Any", but that's not ideal from the JIT's standpoint. One could imagine an enum that contains all (64?) combinations of bitflags, and a codegenerator that intelligently generates the correctly named value, but that seems...awful to maintain and/or generate in the first place (and adding a new argument type would be a lot of work!). The other, seemingly more palatable alternative is to define ArgType's values as normal bitflags (defines or static const members) and then twiddle them as normal integers. We lose strong typing that way, but maybe there are better ways that I'm not thinking of.
I suppose we could just use an integer with bitflags here... It's important to be able to quickly tell things like "only one of these is set" so a struct with "bool:1" members seems to be out. :(
Priority: -- → P5
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.