| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
|---|---|---|---|---|---|---|---|---|---|
| 0000485 | mercury | Bug | public | 2019-09-29 03:54 | 2019-09-29 14:05 | ||||
| Reporter | juliensf | ||||||||
| Assigned To | zs | ||||||||
| Priority | normal | Severity | minor | Reproducibility | have not tried | ||||
| Status | resolved | Resolution | fixed | ||||||
| Product Version | |||||||||
| Target Version | Fixed in Version | ||||||||
| Summary | 0000485: Various bits of extras not building with rotd-2019-09-28 | ||||||||
| Description | Various graphics library bindings (e.g. the OpenGL one) in extras no longer build due to the fact that they contain things like: :- module foo. :- interface. :- type quad_boolean_state ---> color_writemask. :- implementation. :- pragma foreign_enum("C", quad_boolean_state/0, [ color_writemask - "561" ]). Building the interface files now results in: foo.m:008: Error: the Mercury definition of `quad_boolean_state'/0 is not an. foo.m:008: enumeration type, so there must not be any foo.m:008: `:- pragma foreign_enum' declarations for it. foo.m:004: That Mercury definition is here. | ||||||||
| Tags | No tags attached. | ||||||||
| Attached Files |
| ||||||||
 Relationships |
|
 Relationships |
| Notes |
|
|
zs (developer) 2019-09-29 04:04 |
I think the bugs in each extra should be fixed by whoever understands that program the best. |
|
juliensf (administrator) 2019-09-29 04:18 |
Why does the compiler think that quad_boolean_state/0 is not an enumeration? Because it's a dummy type? If so, that's wrong, because the presence of a foreign_enum pragma should suppress the dummyness of the type. |
|
zs (developer) 2019-09-29 04:31 |
The Mercury definition is a dummy type, and the type as a whole is a dummy type on every platform on which that foreign_enum is not applicable. The crux here is that - enum types have N functors of arity 0 - dummy types have 1 functor of arity 0 so yes, dummy types can be viewed as a special case of enum types in terms of whether a foreign enum is applicable to them. The question for me is: when someone writes code like that (Mercury dummy type paired with a foreign enum with one constant) is it likely to be an error? The type requires representation on some backends, but not others, which is strange. I haven't used foreign enums much, so I don't know the answer. |
|
juliensf (administrator) 2019-09-29 05:05 Last edited: 2019-09-29 05:05 |
This issue arises in the OpenGL, GLFW and Allegro bindings. Since they are all bindings to C libraries the issue of the type requiring a representation on some backends but not others is a non-issue; those bindings cannot be meaningfully compiled with the other backends anyway. The information conveyed by such types is the foreign value of the functor. In the example I gave above, even though quad_boolean_state only has a single value in Mercury, the functions that use it in C can take many other values -- in Mercury, we represent those other values are represented using other enum types. Another reason this may arise is due to a library binding being incomplete. Both the code in extras and not treating foreign_enums as dummy types is intentional. |
|
zs (developer) 2019-09-29 14:05 |
Fix committed 2019 sep 29. |
| Notes |
| Issue History |
|||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2019-09-29 03:54 | juliensf | New Issue | |
| 2019-09-29 04:04 | zs | Note Added: 0001048 | |
| 2019-09-29 04:18 | juliensf | Note Added: 0001049 | |
| 2019-09-29 04:31 | zs | Note Added: 0001050 | |
| 2019-09-29 05:05 | juliensf | Note Added: 0001051 | |
| 2019-09-29 05:05 | juliensf | Note Edited: 0001051 | View Revisions |
| 2019-09-29 12:03 | zs | Assigned To | => zs |
| 2019-09-29 12:03 | zs | Status | new => assigned |
| 2019-09-29 14:05 | zs | Status | assigned => resolved |
| 2019-09-29 14:05 | zs | Resolution | open => fixed |
| 2019-09-29 14:05 | zs | Note Added: 0001052 | |
| Issue History |