Commit Graph

5 Commits

Author SHA1 Message Date
Erik Eckstein
7cceaff5f3 SIL: don't print operand types in textual SIL
Type annotations for instruction operands are omitted, e.g.

```
  %3 = struct $S(%1, %2)
```

Operand types are redundant anyway and were only used for sanity checking in the SIL parser.

But: operand types _are_ printed if the definition of the operand value was not printed yet.
This happens:

* if the block with the definition appears after the block where the operand's instruction is located

* if a block or instruction is printed in isolation, e.g. in a debugger

The old behavior can be restored with `-Xllvm -sil-print-types`.
This option is added to many existing test files which check for operand types in their check-lines.
2024-11-21 18:49:52 +01:00
Slava Pestov
df5d531dc6 ASTPrinter: Fix printing of pack requirements
Also remove the flag for printing 'each' and make it always on.
2023-04-19 13:04:51 -04:00
Holly Borla
e48a9b5aeb [NFC] Remove the VariadicGenerics flag from tests that don't use generic types
with parameter packs.
2023-04-15 17:48:08 -07:00
Sophia Poirier
70cffb06f3 [Variadic Generics] type parameter pack syntax change: T... -> each T 2023-03-02 14:42:28 -08:00
John McCall
2169743c65 Test that SIL inlining works for the new variadic generics instructions
I had a fix a bunch of bugs in this, which isn't very surprising.

I changed remapSubstitutionMap to preserve the non-canonical signature
of the substitutions because otherwise it messes up printing
open_pack_element pretty badly --- we end up printing a sugared shape
class but a desugared generic signature.  I'd rather not eagerly
canonicalize everything there because the sugar is quite nice.
Still, I don't feel great about this approach, and this is the
second time I've found myself doing something a little gross in order
to preserve sugar for printing this instruction.

Canonicalizing the replacement types is important for test stability,
and I think it's good downstream.

The most interesting part of this is that I implemented a rule which
handles tuple types becoming scalar as part of the substitution of
tuple_pack_element_addr.  We talked about having this rule in the
formal type system, and I thought we were going to do it, but it
looks like we haven't actually implemented that yet.  I added it to
SIL substitution because (1) I anticipate we'll be doing this
eventually in the formal type system, and that will have consequences
for SIL, and (2) we don't actually have a way to parse these singleton
tuple types, and I didn't want expanding singleton packs into tuples
to become this weird untestable corner case.  I did have to poke a
hole in this rule to preserve types that were singleton tuples before
substitution, since apparently AutoDiff makes a lot of those.

I think adding a type_refine_addr that statically asserts a type
match is the right way to go in the long term for rewriting
singleton tuple_pack_element_addr, but I'm a little sick of adding
SIL instructions, so we just rewrite to unchecked_addr_cast for now.
2023-02-10 14:58:37 -05:00