Please let me know if you can reproduce this, since I will be able to relax a bit knowing so : )

cc @DougGregor @slavapestov @huonw (I have a feeling that this is related to recursive constraints on associated types.)

@swift-ci create

The issue persists in Development Snapshot 2017-12-03.

Perhaps I should mention that when I try to compile the source files (of the attached project) from the command line, non-incrementally, it only works without -g, ie I can get it to compile (from the command line, using a single swiftc command)
without -g and with -wmo. But as soon as I use -g and not -wmo it crashes the compiler.

Seems strange that it can be successfully compiled from within Xcode in Debug (with -g and without -wmo, although incrementally and provided the source files are listed in the "magic" order in project.pbxproj as described in the bug-report) but not using a simple swiftc command like
swiftc -g -Onone {list all source files}

I have tried to see if the magic reordering of the source files would help here too but it crashes anyway.

Crashes during SIL deserialization in the merge-modules phase, so it may not be related to recursive constraints after all.

(Jens, a reminder that @inline(__always) isn't supported. But we'd like some form of inlinable functions to be soon, so we should do something about this.)

…and yes, managed to reproduce this with a near-master compiler.

My feeling that this might be related to recursive constraints on associated types is based on the following part of the crash message:

1.  While canonicalizing generic signature <τ_0_0 where τ_0_0 : ResampableTableData, τ_0_0.Value : Vector, τ_0_0.Coordinate.Index == VectorIndex2, τ_0_0.Value.Element == Float, τ_0_0.Value.Index == VectorIndex1> in requirement #&#8203;3
2.  While reading from 'ResampledNoise'
3.  While finishing conformance for type 'Vector2<Element>'
4.  While ... to 'Vector' in module 'ResampledNoise'
5.  While deserializing decl #&#8203;5 (XREF) in 'ResampledNoise'
6.  Cross-reference to module 'ResampledNoise'
    ... Vector
    ... init
    ... with type <τ_0_0 where τ_0_0 : Vector> (τ_0_0.Type) -> ((τ_0_0.Index) -> τ_0_0.Element) -> τ_0_0
7.  While reading from 'ResampledNoise'
8.  While finishing conformance for type 'Vector1<Element>'
9.  While ... to 'Vector' in module 'ResampledNoise'
10. While deserializing decl #&#8203;5 (XREF) in 'ResampledNoise'
11. Cross-reference to module 'ResampledNoise'
    ... Vector
    ... init
    ... with type <τ_0_0 where τ_0_0 : Vector> (τ_0_0.Type) -> ((τ_0_0.Index) -> τ_0_0.Element) -> τ_0_0
12. While resolving requirement ResampledNoise.(file).Vector.Index in conformance <Element> Vector2<Element>: Vector module ResampledNoise

The VectorIndex protocol has associated types that are constrained to conform to Vector and the Index-type of those Vectors must be Self. I have reported other bugs related to this before so I figured it might be related.

Also see:
https://bugs.swift.org/browse/SR-6224 (open)
and
https://bugs.swift.org/browse/SR-6130 (marked resolved by me as the problem went away (for unknown reasons) in a later snapshot, but perhaps this (6522) can be a clue as to what happened there?)

(Regarding @inline(__always), do you mean not supported as in not future-proof? I "had to" use it because it seems to be the only way to let the compiler optimize some code (not included here) that was otherwise too slow, related conversation here: https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20171030/006530.html and optimizer-issue described in more detailed here: https://bugs.swift.org/browse/SR-6254 (open))

I mean, I responded to you there with

It doesn't count as "using private APIs", but we assume no liability if your app is miscompiled. Also, we will not feel sorry for you when we change the syntax and your code doesn't compile any more.

I didn't explicitly mention crashing the compiler, but that too.

Still, thanks for helping us track down the issues with it. There's no other way to get it to a state where we do want to support something like it.

Yes, and just to be clear: The presence of the two @inline(__always) in the attached source code (Table.swift) is AFAICS not relevant for this issue, ie they can be removed and nothing changes, the compiler will still crash in Debug, unless the source files are "magically" ordered in project.pbxproj as mentioned in the report.

I could and should have removed the @inline(__always) to avoid confusion when using the code to demonstrate this issue.

Hm, true. Surprising, then, that we're getting crashes in SIL deserialization. What are we deserializing?

(clearly we're missing a PrettyStackTrace entry here—the struct that puts those "While…" lines in the output)

Another possible piece of the puzzle:

It seems like it has something to do with the stuff in TableResampling.swift (and its connections to Vector.swift, VectorIndex.swift, and StandardVectorTypes.swift, judging by the crash message and previous encounters with similar compiler issues while working on this project):

1. Open the attached project (in its original compiler-crashing-in-Debug state).

2. Comment out all code from main.swift.

3. Press Build, note that it still crashes the compiler.

4. Comment out all code from TableResampling.swift.

5. Press Build, note that it compiles, no crash.

And this line in the crash message:

1.  While canonicalizing generic signature <τ_0_0 where τ_0_0 : ResampableTableData, τ_0_0.Value : Vector, τ_0_0.Coordinate.Index == VectorIndex2, τ_0_0.Value.Element == Float, τ_0_0.Value.Index == VectorIndex1> in requirement #&#8203;3

must be talking about the following from TableResampling.swift:

// Resampling 2D single float data (currently using vImage):
extension ResampableTableData where
    Coordinate.Index == VectorIndex2,
    Value: Vector,
    Value.Element == Float,
    Value.Index == VectorIndex1
{
    ...

Fix is here: #13454