compiler crash: Functions in generic context must have an interface type

[tayloraswift]

reproduced on DEVELOPMENT-SNAPSHOT-2022-09-27-a:

struct S 
{
    static 
    func x(_ s:some StringProtocol) -> String 
    {
        .init(s)
    }
    static
    subscript(s:some StringProtocol) -> String 
    {
        Self.x(s)
    }
}

$ swiftc test8.swift 
error: compile command failed due to signal 6 (use -v to see invocation)
Functions in generic context must have an interface type
(accessor_decl range=[test8.swift:10:5 - line:12:5] 'anonname=0xbef4aa0' interface type=' (S.Type) -> (some StringProtocol) -> String' access=internal captures=(<generic> ) type get_for=subscript(_:)
  (parameter "self")
  (parameter_list range=[test8.swift:9:14 - line:9:36]
    (parameter "s" type='some StringProtocol' interface type='some StringProtocol'))
  (call_expr type='String' location=test8.swift:11:14 range=[test8.swift:11:9 - line:11:17] nothrow
    (dot_syntax_call_expr type='(some StringProtocol) -> String' location=test8.swift:11:14 range=[test8.swift:11:9 - line:11:14] nothrow
      (declref_expr type='(S.Type) -> (some StringProtocol) -> String' location=test8.swift:11:14 range=[test8.swift:11:14 - line:11:14] decl=test8.(file).S.x@test8.swift:4:10 [with (substitution_map generic_signature= (substitution some StringProtocol -> some StringProtocol))] function_ref=single)
      (argument_list implicit
        (argument
          (type_expr type='S.Type' location=test8.swift:11:9 range=[test8.swift:11:9 - line:11:9] typerepr='S'))))
    (argument_list
      (argument
        (declref_expr type='some StringProtocol' location=test8.swift:11:16 range=[test8.swift:11:16 - line:11:16] decl=test8.(file).S.<anonymous>.s@test8.swift:9:15 function_ref=unapplied)))))
Please submit a bug report (https://swift.org/contributing/#reporting-bugs) and include the project and the crash backtrace.
Stack dump:
0.      Program arguments: /home/ec2-user/.swiftenv/versions/DEVELOPMENT-SNAPSHOT-2022-09-27-a/usr/bin/swift-frontend -frontend -c -primary-file test8.swift -target x86_64-unknown-linux-gnu -disable-objc-interop -color-diagnostics -new-driver-path /home/ec2-user/.swiftenv/versions/DEVELOPMENT-SNAPSHOT-2022-09-27-a/usr/bin/swift-driver -empty-abi-descriptor -resource-dir /home/ec2-user/.swiftenv/versions/DEVELOPMENT-SNAPSHOT-2022-09-27-a/usr/lib/swift -module-name test8 -o /tmp/TemporaryDirectory.nrsWjH/test8-1.o
1.      Swift version 5.8-dev (LLVM ed4d811c2897d77, Swift 8491f52d478aca6)
2.      Compiling with the current language version
3.      While walking into decl 'S' (at test8.swift:1:1)
4.      While walking into 'S' (at test8.swift:1:1)
5.      While verifying AccessorDecl getter for subscript(_:) (at test8.swift:9:5)
6.      While verifying FuncDecl getter for subscript(_:) (at test8.swift:9:5)
7.      While verifying AbstractFunctionDecl getter for subscript(_:) (at test8.swift:9:5)

does not crash if the subscript is desugared to the where-based syntax.

[theblixguy]

Reduced:

struct S  {
  subscript(s: some StringProtocol) -> String {
    fatalError()
  }
}

[slavapestov]

Oops. I think this should work.

[LucianoPAlmeida]

It looks like this came with [SE-0341](https://github.com/apple/swift-evolution/blob/main/proposals/0341-opaque-parameters.md) and the crash is due to AbstractFunctionDecl::isGenericContext being based on getGenericParams() which is nullptr in this case for AccessorDecl because createOpaqueParameterGenericParams seems to not be able to create the implicit generic param list correctly because it should look through subscript(storage) signature instead of itself. This commit fixes the crash and I think it makes sense to me, but maybe there is more to it? @slavapestov

[slavapestov]

Your fix looks good! Three minor suggestions:

• You don't have to cast the result of getStorage() to ValueDecl since ValueDecl is a superclass of AbstractValueDecl.
• It would be better to add the test case to test/type/opaque_parameters.swift
• Can you test a subscript with a setter as well?

[AnthonyLatsis]

@LucianoPAlmeida For the future, please let me know before you start working on an issue that I have assigned myself to, in order to avoid potential "effort races".

[LucianoPAlmeida]

@LucianoPAlmeida For the future, please let me know before you start working on an issue that I have assigned myself to, in order to avoid potential "effort races".

For sure, sorry for that Anthony!

[slavapestov]

Reported via radar too: rdar://100783783