Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Failure("unknown variant: options") #58

Open
MisterDA opened this issue Jan 20, 2023 · 3 comments
Open

Failure("unknown variant: options") #58

MisterDA opened this issue Jan 20, 2023 · 3 comments

Comments

@MisterDA
Copy link
Contributor

2023-01-19 22:28.50: >>> Failure("unknown variant: options") (score = 30)
2023-01-19 22:28.50: >>> Failure("unknown variant: options") (score = 30)
2023-01-19 22:28.50: unknown variant: options

https://ci.ocamllabs.io/github/ocsigen/lwt/commit/3d6f0fac4fed71d3c9cbdc5b90d6a443949bb0d6/variant/(analysis)

This issue seems to come from

with_variant t (Some "options")

the only place afaict that introduces the variant "options". It is however not present in
let of_string = function
| "afl" -> Some `Afl
| "flambda" -> Some `Flambda
| "default-unsafe-string" -> Some `Default_unsafe_string
| "domains" -> Some `Domains
| "effects" -> Some `Effects
| "force-safe-string" -> Some `Force_safe_string
| "fp" -> Some `Frame_pointer
| "multicore" -> Some `Multicore
| "no-effect-syntax" -> Some `Multicore_no_effect_syntax
| "nnp" -> Some `No_naked_pointers
| "nnpchecker" -> Some `No_naked_pointers_checker
| "no-flat-float-array" -> Some `Disable_flat_float_array
| _ -> None

so there's an error at
let of_t t =
match t.extra with None -> Ok [] | Some extra ->
String.split_on_char '+' extra |>
List.map (fun b -> match of_string b with
| None -> Error (`Msg ("unknown variant: " ^ b))
| Some v -> Ok v) |>

I can't manage to prove that this is where the "options" variant was introduced in the version value, nor find another place where it might have, nor figure out why the extra field isn't None in Opam.V2.package.

cc @benmandrew who first found the issue.
cc @dra27 who might have a clue?

@dra27
Copy link
Contributor

dra27 commented Jan 20, 2023

Looking at the solver-service and the failures, this is coming from packages which have a dependency on base-domains and I expect it's while calculating the flambda variant.

@dra27
Copy link
Contributor

dra27 commented Jan 21, 2023

The issue here is that the solver-service is passing an opam package version back to Configure_options.is_multicore which is expecting the "extra" part of the version to be a recognised variant.

It's not clear to me exactly what the fix is. On the one hand, the existing functions are about determining whether a given release of OCaml had a multicore variant (e.g. 4.06, 4.10, 4.12, etc. all of which have +domains variants) as opposed to 5.0+ which is multicore. I'm leaning towards there being no issue per se with ocaml-version and - as shown in ocurrent/solver-service#38, the issue is more that the solver should be asking the correct question (i.e. is the version >= 5 or is this variant a multicore variant). The fact that OCaml 5.x+ is multicore could reasonably be included as new function in ocaml-version.

@tmcgilchrist
Copy link
Member

the existing functions are about determining whether a given release of OCaml had a multicore variant (e.g. 4.06, 4.10, 4.12, etc. all of which have +domains variants) as opposed to 5.0+ which is multicore.

I think for our CI purposes this is accurate (in ocaml-ci and base-images builder). Whether anyone wants to describe which compiler versions are multicore using this library, that could be useful. In that case would 4.12+domains,effects be considered multicore?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants