Adds support for Java enum generation

[desaikd]

Issue #89

Description of changes:

This PR works on generating java enums.

List of changes:

• Adds changes for enum support
  • Adds build_enum_from_constraints method which generates Java enum based on valid_values constraint. (Only symbol and string type values are supported for this)
  • Adds verify_enum_variant_type which checks if the enum variant type is valid
  • Adds new AbstractDataType variant Enum
  • Adds EnumVariant and EnumVariantType to be used within AbstractDataType::Enum
  • Adds template enum.templ

Generates Java code:

(Note: Rust support for enums is not supported yet.)
The generated code only includes classes that has changes with this PR (i.e. StructWithEnumFields, Enum)
Generated code in Java can be found here.

Test changes:

adds tests for enum generation

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[popematt]

The way this is implemented, if I defined something like this, it would fail because it's not a supported way of defining an enum, even though a user would expect this to be a perfectly valid scalar.

type::{
  name: uint,
  type: int,
  valid_values: range::[0, max],
}

In order to classify something as an enum, it must have a valid_values constraint, and all of its valid values should be symbols so that we don't incorrectly classify something such as this example. (I would be inclined to limit it specifically to symbols unless we specifically get a request to allow other things.)

[desaikd]

Made changes to allow only symbol with valid_values for enum generation.

[popematt]

I'm not sure I explained myself well enough. The way you have implemented this, the categorization (i.e. this if condition) is overly broad. That means it could catch other type definitions that are not intended to be enums in the first place.

In order to even be categorized as an enum, it should have a valid_values constraint with only symbols. Checking for symbols in the valid_values constraint needs to happen here, or else the enum code will reject things like

type::{
  name: uint,
  type: int,
  valid_values: range::[0, max],
}

I believe it should be something like this (although this is quite long for an if condition, and should probably be extracted to a helper function).

Suggested change

	} else if constraints
	.iter()
	.any(|it| matches!(it.constraint(), IslConstraintValue::ValidValues(_)))
	} else if constraints
	.iter()
	.any(|it| {
	if let IslConstraintValue::ValidValues(valid_values) = it.constraint() {
	valid_values.values().iter().all(|val| {
	matches!(val, ValidValue::Element(Value::Symbol(_)))
	})
	} else {
	false
	}
	})

[desaikd]

I did have this check inside the build_enum_from_constraints. But I understand that adding it here keeps the generation separate from these checks. I will change this.

[popematt]

I'm not sure I explained myself well enough. The way you have implemented this, the categorization (i.e. this if condition) is overly broad. That means it could catch other type definitions that are not intended to be enums in the first place.

In order to even be categorized as an enum, it should have a valid_values constraint with only symbols. Checking for symbols in the valid_values constraint needs to happen here, or else the enum code will reject things like

type::{
  name: uint,
  type: int,
  valid_values: range::[0, max],
}

I believe it should be something like this (although this is quite long for an if condition, and should probably be extracted to a helper function).

Suggested change

	} else if constraints
	.iter()
	.any(|it| matches!(it.constraint(), IslConstraintValue::ValidValues(_)))
	} else if constraints
	.iter()
	.any(|it| {
	if let IslConstraintValue::ValidValues(valid_values) = it.constraint() {
	valid_values.values().iter().all(|val| {
	matches!(val, ValidValue::Element(Value::Symbol(_)))
	})
	} else {
	false
	}
	})