aboutsummaryrefslogtreecommitdiff
path: root/libjava/java/io/StringBufferInputStream.java
diff options
context:
space:
mode:
authorPhilip Herron <herron.philip@googlemail.com>2025-05-26 19:30:45 +0100
committerPhilip Herron <philip.herron@embecosm.com>2025-05-26 19:18:47 +0000
commitb401e72ba547d2fa595e13f119e3e5e337afc0d9 (patch)
tree8a5fb3500e2b0f6a6d222fbc194f2644b71e8aae /libjava/java/io/StringBufferInputStream.java
parent894e6951cfdd4868a396bde68ac01f0ad28326f0 (diff)
downloadgcc-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