[AST] ParamDecl::isNonEphemeral() not to evaluate InterfaceTypeRequest

[rintaro]

-dump-parse for the following code used to hit an assertion failure:

  struct MyStruct {}
  _ = { (val: MyStruct) in }

Because isNonEphemeral() on val parameter unintentionally causes InterfaceTypeRequest::evaluate(). Since isNonEphemeral() inference based on the interface type is not possible after type checking, return false unless hasInterfaceType(). Use the presence of @_nonEphemeral attribute in ASTDumper instead.

Also:

• Dump parameter list on EnumElementDecl as well
• Adjust the position of range=... in dumping parameter list

https://bugs.swift.org/browse/SR-12728 / rdar://problem/62895098

[rintaro]

@swift-ci Please smoke test

[hamishknight]

Rather than adding a check for hasInterfaceType(), could we change the ASTDumper to check for the presence of the @_nonEphemeral attribute instead of calling isNonEphemeral()?

[CodaFi]

Seconded. The semantic versions of these entrypoints are still needed, they just need to be documented as semantic entrypoints.

[rintaro]

Is isNonEphemeral() only intended to be called after type checking the ParamDecl?
I don't completely understand the semantics of it, but it is called from ConstraintGenerator::inferClosureType() via ParamDecl::toFunctionParam(). Since the ParamDecl of the closure hasn't been type checked yet, getInterfaceType() results ErrorType unless it has TypeRepr. I don't think it's semantically correct. Should we do something for that?

[CodaFi]

Aha, that's just closure parameters being their special weird selves. @hamishknight Is it possible to early-exit for un-annotated closure parameters?

[hamishknight]

Ah yeah, it seems we should keep the new arrangement of the logic where we check whether the parent is an EnumElementDecl before querying the interface type, but remove the check for hasInterfaceType.

[rintaro]

Okay, I will

• Remove the hasInterfaceType() check in isNonEphemeral().
• In ASTDumper, use @_nonEphemeral attribute instead of isNonEphemeral()

How do you think of the assertion I added in setNonEphemeralIfPossible()?

[hamishknight]

Sounds good, thank you!

How do you think of the assertion I added in setNonEphemeralIfPossible()?

I'm okay with keeping for it for now, at some point I'd like to refactor away setNonEphemeralIfPossible and have an IsNonEphemeralRequest that can check if the param is a part of an implicit memberwise initializer.

[rintaro]

@swift-ci Please smoke test

[rintaro]

@swift-ci Please smoke test