Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-3204] Stored value type does not match pointer operand type! #45792

Open
swift-ci opened this issue Nov 14, 2016 · 8 comments
Open

[SR-3204] Stored value type does not match pointer operand type! #45792

swift-ci opened this issue Nov 14, 2016 · 8 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself crash Bug: A crash, i.e., an abnormal termination of software optimized only Flag: An issue whose reproduction requires optimized compilation

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-3204
Radar rdar://problem/29257389
Original Reporter plivesey (JIRA User)
Type Bug

Attachment: Download

Environment

Xcode 8.1, Swift 3

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, CompilerCrash, OptimizedOnly
Assignee None
Priority Medium

md5: 8d4ae1d8b2288094bcfe9de02fc2ebb1

Issue Description:

Compiling a project crashes the compiler with the following output:

Stored value type does not match pointer operand type!
  store %C11MyFramework11FindRequest* %6, %C11MyFramework11FindRequest.1** %4, align 8, !dbg !78
 %C11MyFramework11FindRequest.1*LLVM ERROR: Broken function found, compilation aborted!

I cannot seem to get the code smaller than this. Removing anything causes compilation to be successful. This also only fails on RELEASE builds.

The best way to reproduce is by downloading the attached project. But, the code is:
// In the main app

import Foundation
import MyFramework

func extractCollectionModel<ModelType: Model, MetadataType: Model>(_ response: CollectionResponse<ModelType, MetadataType>?) {
    
}

extension RecordTemplate: Model {
}

public protocol CachableRequest {
    /**
     Customized cacheKey to return alternative cache key if specified
     */
    func ndlCacheKey() -> String

    /**
     This is implmented by the Request class.
     */
    func cacheKey() -> String
}

extension FindRequest: CachableRequest {
}

// MARK: Implementation

extension CachableRequest {
    /**
     customized cacheKey to return alternative cache key if specified
     */
    public func ndlCacheKey() -> String {
        return cacheKey()
    }
}

// In a framework called MyFramework

import Foundation

public protocol Model {    
}

open class FindRequest<T: RecordTemplate, MD: RecordTemplate>: Request {
}

open class Request {
  open func cacheKey() -> String {
    return ""
  }
}

open class CollectionResponse<V: RecordTemplate, MD: RecordTemplate> {
}

open class RecordTemplate {
}
@belkadan
Copy link
Contributor

cc @bob-wilson

@bob-wilson
Copy link

aschwaighofer@apple.com (JIRA User) Arnold is also looking at something like this.

@swift-ci
Copy link
Collaborator Author

Comment by Myke Olson (JIRA)

@swift-ci create

@aschwaighofer
Copy link
Member

Does not reproduce with the Nov 11 [snapshot | https://swift.org/download/#snapshots].

There have been archetype builder fixes going in since the last release that could explain that this is fixed.

@aschwaighofer
Copy link
Member

I have reproduced this and can now say for certain that this is cause by a bug similar to the one fixed by Doug in #5815

The issue is that the compiler does not (did not) deal well with redundant type constraints. Which eventually manifests itself in mismatching llvm types causing this assertion.

The workaround is to remove the redundant constraints if possible.

In this case we have:

public protocol Model {
}

open class FindRequest<T: RecordTemplate, MD: RecordTemplate>: Request {
}

open class Request {
  open func cacheKey() -> String {
    return ""
  }
}

open class CollectionResponse<V: RecordTemplate, MD: RecordTemplate> {
}

open class RecordTemplate {
}

// Another file:

func extractCollectionModel<ModelType : Model , MetadataType: Model>(_ response: CollectionResponse<ModelType, MetadataType>?) {
    
}

extension RecordTemplate : Model {
}


public protocol CachableRequest {
    /**
     Customized cacheKey to return alternative cache key if specified
     */
    func ndlCacheKey() -> String

    /**
     This is implmented by the Request class.
     */
    func cacheKey() -> String
}

extension FindRequest: CachableRequest {
}

// MARK: Implementation

extension CachableRequest {
    /**
     customized cacheKey to return alternative cache key if specified
     */
    public func ndlCacheKey() -> String {
        return cacheKey()
    }
}

The problem is that the three generic parameter constraints in the system "ModelType : Model , MetadataType: Model" and "RecordTemplate : Model" create a redundant set of constraints on RecordTemplate.

func extractCollectionModel<ModelType : Model , MetadataType: Model>(_ response: CollectionResponse<ModelType, MetadataType>?) {
    
}

extension RecordTemplate : Model {
}

Eliminating either one of those constraints will make this example pass.

// ModelType and MetadataType are already constraint to be of protocol type Model because CollectionResponse's generic parameters are constraint to be RecordTemplate.
func extractCollectionModel<ModelType , MetadataTypel>(_ response: CollectionResponse<ModelType, MetadataType>?) {
    
}

extension RecordTemplate : Model {
}

@swift-ci
Copy link
Collaborator Author

swift-ci commented Oct 2, 2018

Comment by Robbert Brandsma (JIRA)

This bug seems to still exist in Swift 4.2 / Xcode 10

@belkadan
Copy link
Contributor

belkadan commented Oct 2, 2018

obbut (JIRA User), it's likely the bug you're seeing has a different cause. Can you file it separately?

@swift-ci
Copy link
Collaborator Author

swift-ci commented Aug 5, 2021

Comment by Ramil Minibaev (JIRA)

Seems to be resolved in Swift 5.5.

Got this issue in my project in Swift 5.4, but not in Swift 5.5

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@AnthonyLatsis AnthonyLatsis added the crash Bug: A crash, i.e., an abnormal termination of software label Dec 12, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself crash Bug: A crash, i.e., an abnormal termination of software optimized only Flag: An issue whose reproduction requires optimized compilation
Projects
None yet
Development

No branches or pull requests

5 participants