diff options
author | Philip Herron <herron.philip@googlemail.com> | 2025-05-26 19:30:45 +0100 |
---|---|---|
committer | Philip Herron <philip.herron@embecosm.com> | 2025-05-26 19:18:47 +0000 |
commit | b401e72ba547d2fa595e13f119e3e5e337afc0d9 (patch) | |
tree | 8a5fb3500e2b0f6a6d222fbc194f2644b71e8aae /libjava/java/io/StringBufferInputStream.java | |
parent | 894e6951cfdd4868a396bde68ac01f0ad28326f0 (diff) | |
download | gcc-b401e72ba547d2fa595e13f119e3e5e337afc0d9.zip gcc-b401e72ba547d2fa595e13f119e3e5e337afc0d9.tar.gz gcc-b401e72ba547d2fa595e13f119e3e5e337afc0d9.tar.bz2 |
gccrs: Fix non canonical type bug with tuples
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>
Diffstat (limited to 'libjava/java/io/StringBufferInputStream.java')
0 files changed, 0 insertions, 0 deletions