Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixes for assorted SILGen bugs #6543

Merged
merged 8 commits into from Jan 4, 2017

Conversation

slavapestov
Copy link
Member

@slavapestov slavapestov commented Jan 4, 2017

rdar://problem/22465834

…g statements

Otherwise we might miss emitting a local type that's inside
unreachable code. Normally such a type cannot be found via
name lookup either, but IRGen will walk the list of local types
and try to emit a class with no SIL vtable, which will crash.

Fixes <https://bugs.swift.org/browse/SR-1924>.
Swift admits implicit conversions between tuple types to
introduce and eliminate argument labels, and re-order
argument labels. These are expressed as TupleShuffleExpr
in the AST.

SILGen has two different code paths for lowering TupleShuffleExpr,
which is also used for varargs and default arguments in call
argument emission.

These two code paths support different subsets of TupleShuffleExpr;
neither one supports the full generality of the other, but there
is some overlap.

Work around the damage by routing the two different "kinds" of
TupleShuffleExprs to the correct place in argument emission.

The next incremental step here would be to refactor ArgEmitter to
make it usable when lowering SubscriptExpr; then the RValueEmitter's
support for varargs in TupleShuffleExpr can go away. Once that's
done we can split off an ArgumentExpr from TupleShuffleExpr, and
in the fullness of time, fold ArgumentExpr into ApplyExpr.

At that point this dark corner of the AST will start to be sane...

Fixes <https://bugs.swift.org/browse/SR-2887>.
Previously, SIL type lowering would assume a MetatypeType was
completely lowered if it had a representation, but this is not
quite right; after substitution, we can have a MetatypeType
whose instance type is a DynamicSelfType. Strip these away more
eagerly, since they show up in SILType::subst(), where we first
substitute AST-level generic parameters, and then lower the
result to get the final SIL type.

Fixes <https://bugs.swift.org/browse/SR-2733>.
This might only come up in invalid code, but for example
casting a function type to String would trigger it.
@slavapestov
Copy link
Member Author

@swift-ci Please smoke test

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant