[SR-1171] Changed property from T? to T caused link failure due to incremental compilation not detecting change

[NachoSoto]

Previous ID	SR-1171
Radar	None
Original Reporter	@NachoSoto
Type	Bug

Attachment: Download

Environment

Xcode 7.3 (7D175) Swift 2.2. Code in question is in an application target, no frameworks involved.

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug, IncrementalBuild
Assignee	None
Priority	Medium

md5: 84d325546cc9ab39c2c31497f42427cc

Issue Description:

Twitter conversation: https://twitter.com/NachoSoto/status/717792128491913216

[NachoSoto]

I just ran into this again, this time by adding a new parameter to a method (`init`). The linker error is the same as shown above, except the expected result is different: in the original issue the new property was still valid, because it was being assigned a non-optional anyway. This time, the linker error is coming from a method invocation that is now missing the new parameter, but instead of getting a compile error (for missing the new parameter), I get a linker error because the old method no longer exists!

There's another difference in this case: these linker errors are coming from a separate target. I'm not sure if the same thing would reproduce if the method invocations had been in the same target.

[belkadan]

Being cross-target is definitely interesting. You're saying you changed a method in a library, rebuilt the library and the app, and one of the app's files wasn't recompiled when it should have been?

[NachoSoto]

That's correct, but the first example did not involve separate targets so that detail might not be relevant.

[belkadan]

For incremental compilation, they're very different scenarios. I guess both need to be investigated.

[NachoSoto]

I just ran into the same bug, but coming from a different code change:

• Module1:
  public func f(i: Int, defaultValue v: Bool) {}

• Module2:
  f(2)

After compiling, if you change `defaultValue` to something else, you'll get a linker error because the `f(2)` call is no longer valid but the incremental compilation did not detect this.

[NachoSoto]

This is still an issue in Xcode 7.3.1. I'll check again once I start using Xcode 8.

[belkadan]

Haven't had the chance to look at it yet, sorry.

[belkadan]

I can't possibly see how the name change one would show up.

[NachoSoto]

@belkadan I wonder if this is the same as SR-1030, and fixed by #3352

[NachoSoto]

Any update on this?

[belkadan]

If anything fixed it, it would be #3935 which makes sure that errors don't cause the compiler to forget it has to rebuild something. But that wouldn't cover the cross-module case.