Adds a new model for code generator

[desaikd]

Issue #, if available:

Description of changes:

This PR is adds a new model for code generator to make it simpler for getting information on nested types and element type in sequence.

List of changes:

• DataModel is a the new abstract data type that will be used by code generator to render templates.
• CodeGenType is similar to the prior AbstractDataType but more informative includes fields details and element type details.
• FullyQualifiedTypeName and FullyQualifiedTypeReference are used for storing all levels of the fully qualified name of the type.
• This PR only introduces the model but doesn't yet use it in the implementation.

---

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

[zslayton]

Outdated comment?

[desaikd]

No. This model is going to use FullyQualifiedTypeReferences instead of pointing to DataModel itself. But in some case, for example sequence we need to look at the DataModel to check its element_type then we can use a HashMap which stores (FullQualifiedTypeReference, DataModel) pairs.

[popematt]

The model you have for an "entity" (type, struct, class, whatever) is a struct with common fields and an enum for the things that are different.

You may want to consider refactoring so that you have an enum as an "umbrella", and all of the data in the structs for the variants, even if there is some duplication. For example:

pub struct DataModelNode {
  name: String, // unqualified name
  this_type: Option<AnyDataType>,
  children: Vec<DataModelNode>,
}

pub enum AnyDataType {
  Struct(StructDataType),
  Scalar(ScalarDataType),
  Collection(CollectionDataType),
  // more types...
}

impl AnyDataType {
  fn source_isl() -> IslType { 
    // ...
  }
  fn doc_comment() -> Option<String> {
    // ...
  }
  fn qualified_name() -> FullyQualifiedTypeName {
    // ...
  }
}

pub struct StructDataType {
  qualified_name: FullyQualifiedTypeName,
  is_closed: bool,
  fields: HashMap<String, FullyQualifiedTypeReference>,
  source_isl: IslType,
}
// more types...

This will allow you to define functions that apply to all data model types using AnyDataType, or for specific data model types using e.g. StructDataType. I think that can go a long way toward having clear contracts and helping with readability in the long run.

If it makes it easier to reason about, you could create a trait that defines what AnyDataType and all the subtypes/variants have in common.

[popematt]

There are more important things right now, but in the future, we should consider changing this to Option<&'generator IslType>.

[desaikd]

The model you have for an "entity" (type, struct, class, whatever) is a struct with common fields and an enum for the things that are different.

You may want to consider refactoring so that you have an enum as an "umbrella", and all of the data in the structs for the variants, even if there is some duplication.

I have changed the model to store all information on a data type with its own implementation (e.g. Scalar, WrappedScalar, Sequence, Structure). A new variant WrappedScalar is added that can be used to represent a top level scalar type definition. A top level scalar type definition can have a name which is why its better to have it as a separate variant to have specific methods to it in WrappedScalar.

For example given below ISL,

type::{
  name: wrapped_scalar_type,
  type: int
}

Corresponding generated code in Rust would look like following:

struct WrappedScalarType {
    value: i64
 }