When working on rpit we needed to change to use a monomorphized clone of
the result of function calls. This ended up causing a verify gimple issue
with tuples because:
fn test<A, B>(a: A, b: B) -> (A, B)
When passing for example:
let a = test::<i32, i32> (123, 456) -> (A=i32, B=i32)
The resulting gimple types became:
const struct (A=i32, B=i32) vs struct (i32, i32)
We removed the VIEW_CONVERT_EXPR support to auto fix this stuff a good
while ago because it hides these kinds of issues because the type hasher
included the A=i32, B=i32 vs the i32, i32 name so updating this to use
get_name instead keeps the naming the same as well as the fields meaning
these types are 100% equivilant and therefore no conversion is required.
This only occurs because tuples are not named types we should really add
more rust specific info on our gimple TYPES.
gcc/rust/ChangeLog:
* backend/rust-compile-type.cc (TyTyResolveCompile::visit): use get_name
* typecheck/rust-tyty.cc (TupleType::get_name): likewise
Signed-off-by: Philip Herron <herron.philip@googlemail.com>
}
tree struct_type_record = Backend::struct_type (fields);
- translated = Backend::named_type (type.as_string (), struct_type_record,
+ translated = Backend::named_type (type.get_name (), struct_type_record,
type.get_ident ().locus);
}
std::string fields_buffer;
for (const TyVar &field : get_fields ())
{
- fields_buffer += field.get_tyty ()->as_string ();
+ fields_buffer += field.get_tyty ()->get_name ();
bool has_next = (i + 1) < get_fields ().size ();
fields_buffer += has_next ? ", " : "";
i++;