@swift-ci create

Would this be a good StarterBug @xedin ?

Yeah, I think it would be a good parser starter bug.

Comment by Artem Burmistrov (JIRA)

I'd like to work on this, but I have a few questions:

1. As far as my understanding goes this check should be moved from parser (where it currently is producing error based on parsed token) to semantic analysis. So my question is: where should I start digging?
2. I kinda thought that the best place to report error could be something related to member lookup. But I struggle to understand lib/sema because it's complicated (especially since I'm a novice). Is that even a correct assumption or the error should be reported somewhere else?

Terky (JIRA User) Yes, you are correct regarding number one from your list, warning has to be removed from the parser. Type-checker implements "special" `. dynamicType` member as `DynamicTypeOf` constraint in the solver. You'd have to move the warning to constraint solver by adding a new `ConstraintFix` and `FailureDiagnostic` implementations and recording the fix in `ConstraintSystem::simplifyDynamicTypeOfConstraint`. You can take a look at how `AllowCoercionToForceCast` is implemented for example. Let me know if you have any other questions or need help with this.

Comment by Artem Burmistrov (JIRA)

@xedin, thank you for the help. I looked at `DynamicTypeOf` and as far as my understanding goes it is produced from the `type(of: )`, not from the `.dynamicType` member. I also tried to remove error diagnostics from the parser and place the breakpoint in the `ConstraintSystem::simplifyConstraint`. But from what I got there was no `DynamicTypeOf` constraint kind. Is `dynamicType` member even supported as a special member? Also if I remove the `dynamicType` property declaration from the example it would produce the `MissingMemberFailure`. Am I missing something or there should be another place to produce `ConstraintFix`?

Terky (JIRA User) Once you have removed the diagnostic from the parser, you need to move it to the DiagnosticsSema.def and produce it in `MissingMemberFailure::diagnose` instead of a default missing member diagnostic. Sorry I forgot that `DynamicTypeOf` is only used for `type(of: ...)` since I thought, for some reason, that this was a warning and not an error...

It's been 5 years, and `dynamicType` was not exactly a popular feature when it was first introduced. I think we can probably just remove this diagnostic altogether. The chance of confusion stemming from the fallback diagnostic of

value of type 'X' has no member 'dynamicType'

is low. I say we just remove the special case from the parser.

That sounds good to me!

Comment by Ehud Adler (JIRA)

Merged. PR: #39443