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
Anthony Latsis
daaac531cb Gardening: Migrate test suite to GH issues: SILGen (1/2) 2022-09-04 07:02:59 +03:00
Holly Borla
8713d78704 [PrintOptions] Print explicit 'any' in SIL. 2022-08-18 01:15:12 -04:00
Slava Pestov
d222ac5f6e Sema: New syntax for @opened archetypes in textual SIL
The old syntax was

    @opened("UUID") constraintType

Where constraintType was the right hand side of a conformance requirement.

This would always create an archetype where the interface type was `Self`,
so it couldn't cope with member types of opened existential types.

Member types of opened existential types is now a thing with SE-0309, so
this lack of support prevented writing SIL test cases using this feature.

The new syntax is

    @opened("UUID", constraintType) interfaceType

The interfaceType is a type parameter rooted in an implicit `Self`
generic parameter, which is understood to be the underlying type of the
existential.

Fixes rdar://problem/93771238.
2022-08-07 19:03:46 -04:00
Hamish Knight
a1cf598b65 [CSApply] Hack around existential closing for callables
The current existential closing logic relies on
maintaining a stack of expressions, and closing the
existential when the size of the stack goes below
a certain threshold. This works fine for cases
where we open the existential as a part of an
user-written member reference, as we push it onto
the stack when walking over the AST. However it
doesn't handle cases where we generate an implicit
member reference when visiting a part of the AST
higher up in the tree.

We therefore run into problems with both implicit
`callAsFunction` and `@dynamicCallable`, both of
which generate implicit member refs when we visit
the apply. To hack around this issue, push the
apply's fn expr onto the stack before building the
member reference, such that we don't try to
prematurely close the existential as a part of
applying the curried member ref.

The good news at least is that this hack allows us
to remove the `extraUncurryLevel` param which was
previously working around this issue for the
`shouldBuildCurryThunk` function.

To properly fix this, we'll need to refactor
existential opening to not rely on the shape of the
AST prior to re-writing.

Resolves SR-12590.
2020-04-17 14:12:45 -07:00