[SR-6202] Miscompile because of weird interaction with type inference

[swift-ci]

Previous ID	SR-6202
Radar	None
Original Reporter	kzaher (JIRA User)
Type	Bug
Status	Resolved
Resolution	Done

Attachment: Download

Environment

Version 9.0.1 (9A1004)

Additional Detail from JIRA

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

md5: 6bc806f89c20823a0a9d4d5742e4b789

Issue Description:

I have a really weird case. I'm sorry I couldn't make the repro case smaller.

I've spent the entire afternoon on this and if I remove any further component, I can't repro it for some reason.

I've attached two files.

Running in bash `swift Crashes.swift` ->
```
Task #1(id: 35D3EC30-E320-44AF-8D50-7F8E39756CED, created: 2017-10-22 17:52:17 +0000, title: "Task 1")
Version #1<Task #1>(value: Task #1 in Crashes.crash() -> ()(id: 35D3EC30-E320-44AF-8D50-7F8E39756CED, created: 2017-10-22 17:52:17 +0000, title: "Task 1"))
0 swift 0x000000010e49adba PrintStackTraceSignalHandler(void*) + 42
1 swift 0x000000010e49a1f6 SignalHandler(int) + 662
2 libsystem_platform.dylib 0x00007fff59e6ef5a _sigtramp + 26
3 libswiftCore.dylib 0x000000011402ad9c _T0s26_RandomAccessCollectionBoxCAByxGx5_base_tcfcs6MirrorV14LegacyChildrenV_Tgq5 + 636
4 libswiftCore.dylib 0x0000000111f25716 _T0s26_RandomAccessCollectionBoxCAByxGx5_base_tcfcs6MirrorV14LegacyChildrenV_Tgq5 + 4260342774
5 libswiftCore.dylib 0x0000000113ed799c _T0s23_ContiguousArrayStorageCfD + 60
6 libswiftCore.dylib 0x000000011418c2e0 _swift_release_dealloc + 16
7 libswiftCore.dylib 0x0000000111f232b7 _swift_release_dealloc + 4258885607
8 libswiftCore.dylib 0x0000000111f230bc _swift_release_dealloc + 4258885100
9 swift 0x000000010ba2255f llvm::MCJIT::runFunction(llvm::Function*, llvm::ArrayRef<llvm::GenericValue>) + 655
10 swift 0x000000010ba28823 llvm::ExecutionEngine::runFunctionAsMain(llvm::Function*, std::_1::vector<std::1::basic_string<char, std::1::char_traits<char>, std::1::allocator<char> >, std::1::allocator<std::1::basic_string<char, std::1::char_traits<char>, std::_1::allocator<char> > > > const&, char const* const*) + 707
11 swift 0x000000010ae0f82d performCompile(swift::CompilerInstance&, swift::CompilerInvocation&, llvm::ArrayRef<char const*>, int&, swift::FrontendObserver*, swift::UnifiedStatsReporter*) + 22797
12 swift 0x000000010ae086b4 swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*) + 7716
13 swift 0x000000010adbd5d8 main + 12248
14 libdyld.dylib 0x00007fff59bee145 start + 1
15 libdyld.dylib 0x000000000000000a start + 2789285574
Stack dump:
0. Program arguments: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift -frontend -interpret Crashes.swift -enable-objc-interop -sdk /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -color-diagnostics -module-name Crashes
Segmentation fault: 11
```

Running in bash `swift Works.swift` ->
```
Task #1(id: 8660AF6F-C9A3-4A4B-9D60-340715CEA0E9, created: 2017-10-22 17:52:34 +0000, title: "Task 1")
Version #1<Task #1>(value: Task #1 in Works.crash() -> ()(id: 8660AF6F-C9A3-4A4B-9D60-340715CEA0E9, created: 2017-10-22 17:52:34 +0000, title: "Task 1"))
```

The difference between these two files is this:
```
diff --git a/Crashes.swift b/Works.swift
index e06af72..15f640a 100644

• • • a/Crashes.swift
      +++ b/Works.swift
      @@ -24,7 +24,7 @@ func crash() {
      static func `for`(tasks: [Task]) -> Todo {
      return tasks.reduce(Todo()) { (all, task) in
      var todo = all

• todo.tasks = todo.tasks.mutate(entity: Version(task), transform: Version.mutate { print($0) })
  + todo.tasks = todo.tasks.mutate(entity: Version(task), transform: Version<Task>.mutate { print($0) })
  return todo
  }
  }
  ```

If for some reason I just remove `<Task>` and let compiler decide the argument, it seems to me that it will somehow infer the wrong type.

[belkadan]

Seems to be fixed on master. I'm not sure whether it made it into the 4.0 branch.

[belkadan]

Yes, seems to be fixed in the 4.0 branch as well, which means it'll be in Xcode 9.1.

[swift-ci]

Comment by Krunoslav Zaher (JIRA)

Oh, cool. It took me quite a while to find out where was problem in this case 🙂