Merge oneOf with many compatible enums of a single value

[jayvdb]

OAI/OpenAPI-Specification#348 (comment) is apparently the best way to describe enum values, like

    "enum-value-descriptions": {
      "type": "object",
      "description": "https://github.com/OAI/OpenAPI-Specification/issues/348#issuecomment-1484163189",
      "oneOf": [
        {
          "enum": ["A"],
          "description": "An A"
        },
        {
          "enum": ["B"],
          "description": "A B"
        }
      ]
    }

Typify generates a bunch of variants for the above, when they could be collapsed into a single Rust enum.

[ahl]

Thanks for filing this. Today we get something like this:

pub enum Thing {
    Variant0(ThingVariant0),
    Variant1(ThingVariant1),
}

pub enum ThingVariant0 {
    A,
}

pub enum ThingVariant1 {
    B,
}

Awful! The good news is that a bunch of recent refactoring has been oriented around addressing precisely this kind of weirdness. In particular, my plan is to do a "simplification" or "canonicalization" pass in the oneOf handling before trying to map it against various encodings of enums.

As another example:

typify/typify/tests/schemas/merged-schemas.rs

Lines 904 to 919 in 1f97f16

	pub enum WeirdEnum {
	Variant0 {
	pattern: String,
	},
	Variant1 {
	patterns: String,
	},
	Variant2 {
	#[serde(rename = "pattern-either")]
	pattern_either: String,
	},
	Variant3 {
	#[serde(rename = "pattern-regex")]
	pattern_regex: String,
	},
	}

There's no reason this shouldn't be an externally tagged variant:

pub enum WeirdEnum {
   #[serde(rename = "pattern")]
    Pattern(String),
   #[serde(rename = "patterns")]
    Patterns(String),
   #[serde(rename = "pattern-either")]
    PatternEither(String),
    #[serde(rename = "pattern-regex")]
    PatternRegex(String),
}

[ahl]

On closer inspection, there are two slightly different issues. The first is that the type of your schema is object. Arguably, typify should be rejecting this because there is no value that satisfies the schema (i.e. is an object and is either "A" or "B").

A more obvious error from typify is that it requires the subschemas to have "type": "string". This should be unnecessary, and I've got a PR to fix it (see #500).

[jayvdb]

Sorry the 'object' bit was my mistake.

OAI/OpenAPI-Specification#348 (comment) says to use type: string

[ahl]

Sorry the 'object' bit was my mistake.

I was just observing that this is another gap in typify's logic--it should either register some sort of error saying that this type is unsatisfiable or produce some sort of Never type (e.g. enum Never{}).