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)
Tracking
()
NEW
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.
Comment 1•10 years ago
|
||
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. :(
Updated•9 years ago
|
Priority: -- → P5
Updated•3 years ago
|
Severity: normal → S3
Updated•8 months ago
|
Blocks: sm-runtime
You need to log in
before you can comment on or make changes to this bug.
Description
•