[SR-5766] Remove the warning Redundant conformance constraint ... #48336
Comments
|
Comment by Josh Wiechman (JIRA) I have not been able to verify that this issue may also result in a compiling resulting in an Abort trap: 6, but here is the output on an example project called SpringboardUIComponents. 0 swift 0x000000010a8ba42a PrintStackTraceSignalHandler(void*) + 42 1 swift 0x000000010a8b9866 SignalHandler(int) + 662 2 libsystem_platform.dylib 0x00007fffb5b42b3a _sigtramp + 26 3 libsystem_platform.dylib 0x00000001156e1551 _sigtramp + 1606019633 4 libsystem_c.dylib 0x00007fffb59c7420 abort + 129 5 swift 0x0000000107fcf821 swift::ModuleFile::readConformance(llvm::BitstreamCursor&, swift::GenericEnvironment*) + 5985 6 swift 0x0000000107fcf408 swift::ModuleFile::readConformance(llvm::BitstreamCursor&, swift::GenericEnvironment*) + 4936 7 swift 0x0000000107fcf408 swift::ModuleFile::readConformance(llvm::BitstreamCursor&, swift::GenericEnvironment*) + 4936 8 swift 0x0000000107fd244c swift::ModuleFile::loadAllConformances(swift::Decl const*, unsigned long long, llvm::SmallVectorImplswift::ProtocolConformance\*&) + 300 9 swift 0x000000010840f35c swift::ConformanceLookupTable::updateLookupTable(swift::NominalTypeDecl*, swift::ConformanceLookupTable::ConformanceStage, swift::LazyResolver*) + 1068 10 swift 0x000000010840f027 swift::ConformanceLookupTable::updateLookupTable(swift::NominalTypeDecl*, swift::ConformanceLookupTable::ConformanceStage, swift::LazyResolver*) + 247 11 swift 0x0000000108413201 swift::ConformanceLookupTable::lookupConformance(swift::ModuleDecl*, swift::NominalTypeDecl*, swift::ProtocolDecl*, swift::LazyResolver*, llvm::SmallVectorImplswift::ProtocolConformance\*&) + 49 12 swift 0x0000000107fce68e swift::ModuleFile::readConformance(llvm::BitstreamCursor&, swift::GenericEnvironment*) + 1486 13 swift 0x0000000107fcf408 swift::ModuleFile::readConformance(llvm::BitstreamCursor&, swift::GenericEnvironment*) + 4936 14 swift 0x0000000107fd244c swift::ModuleFile::loadAllConformances(swift::Decl const*, unsigned long long, llvm::SmallVectorImplswift::ProtocolConformance\*&) + 300 15 swift 0x000000010840f35c swift::ConformanceLookupTable::updateLookupTable(swift::NominalTypeDecl*, swift::ConformanceLookupTable::ConformanceStage, swift::LazyResolver*) + 1068 16 swift 0x000000010840f027 swift::ConformanceLookupTable::updateLookupTable(swift::NominalTypeDecl*, swift::ConformanceLookupTable::ConformanceStage, swift::LazyResolver*) + 247 17 swift 0x0000000108413201 swift::ConformanceLookupTable::lookupConformance(swift::ModuleDecl*, swift::NominalTypeDecl*, swift::ProtocolDecl*, swift::LazyResolver*, llvm::SmallVectorImplswift::ProtocolConformance\*&) + 49 18 swift 0x0000000107fce68e swift::ModuleFile::readConformance(llvm::BitstreamCursor&, swift::GenericEnvironment*) + 1486 19 swift 0x0000000107fcf408 swift::ModuleFile::readConformance(llvm::BitstreamCursor&, swift::GenericEnvironment*) + 4936 20 swift 0x0000000107fcf408 swift::ModuleFile::readConformance(llvm::BitstreamCursor&, swift::GenericEnvironment*) + 4936 21 swift 0x0000000107fd244c swift::ModuleFile::loadAllConformances(swift::Decl const*, unsigned long long, llvm::SmallVectorImplswift::ProtocolConformance\*&) + 300 22 swift 0x000000010840f35c swift::ConformanceLookupTable::updateLookupTable(swift::NominalTypeDecl*, swift::ConformanceLookupTable::ConformanceStage, swift::LazyResolver*) + 1068 23 swift 0x000000010840f027 swift::ConformanceLookupTable::updateLookupTable(swift::NominalTypeDecl*, swift::ConformanceLookupTable::ConformanceStage, swift::LazyResolver*) + 247 24 swift 0x000000010840f09c swift::ConformanceLookupTable::updateLookupTable(swift::NominalTypeDecl*, swift::ConformanceLookupTable::ConformanceStage, swift::LazyResolver*) + 364 25 swift 0x0000000108413bd7 swift::ConformanceLookupTable::getAllProtocols(swift::NominalTypeDecl*, swift::LazyResolver*, llvm::SmallVectorImplswift::ProtocolDecl\*&) + 39 26 swift 0x0000000107b9ec2d (anonymous namespace)::NominalTypeWalker::walkToDeclPre(swift::Decl*) + 205 27 swift 0x00000001083f9f98 (anonymous namespace)::Traversal::doIt(swift::Decl*) + 280 28 swift 0x0000000107c82cdf swift::SILPassManager::SILPassManager(swift::SILModule*, llvm::StringRef) + 1807 29 swift 0x0000000107c8931f swift::runSILDiagnosticPasses(swift::SILModule&) + 175 30 swift 0x000000010722eb14 performCompile(swift::CompilerInstance&, swift::CompilerInvocation&, llvm::ArrayRef<char const*>, int&, swift::FrontendObserver*, swift::UnifiedStatsReporter*) + 13844 31 swift 0x0000000107229c94 swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*) + 7716 32 swift 0x00000001071debb8 main + 12248 33 libdyld.dylib 0x00007fffb5933235 start + 1 Stack dump:
|
|
There's no source-compatible way for protocol B to "no longer require protocol A", because anyone could have written code assuming that B implies A. If you don't want this assumption, you should make A and B separate protocols, but provide default implementations of B's operations in terms of A using a constrained extension of B. |
|
Comment by Josh Wiechman (JIRA) You make the assumption people can control how protocols are implemented vs. used from a third party. 'There's no source-compatible way for protocol B to "no longer require protocol A"' Exactly, my point. If I am using third party protocols, and I know my class needs A & B, I should be able to leverage both without a warning, even if B already inherits A. If the provider of the protocol makes changes, the impact to local code would not be affected. Is this approach ideal, no, but is it realistic, yes. The current implementation couples the protocols (which isn't the direct issue). The issue is providing a warning because a class implements two protocols when one of the protocols implements the other. A warning should not occur because a protocol constraint is applied directly and indirectly to the same class. |
|
Comment by Josh Wiechman (JIRA) Only considering code that is directly owned by the programmer is not a realist constraint in the real world. A warning occurring with protocols are double applied stressing a redundant of conformance leads to noise for legitimate warnings. |
|
Comment by Fae Charlton (JIRA) I'm getting a ton of these errors in my project right now, so here's how it's turning up in one practical scenario. I'm working with coordinate geometry:
where "Ring" is a protocol requiring various arithmetic operations. At the same time, I have a bunch of functions that act on Coords2d in various ways, for example:
Now, PathBoundaries explicitly requires R to be a Ring. But PathBoundaries doesn't care whether Coords2d also requires its parameter to be a Ring – some day it may not, maybe it will change to some other more general protocol. But if it does, PathBoundaries will still require its parameter to conform to Ring. But right now I'm getting a bunch of warnings for specifying this intentional, not-really-redundant constraint. Besides which, even if the constraint can be inferred one way or another, I want my functions that require Rings to explicitly say so in their declarations – as far as I'm concerned that's part of their documentation and linking it to an indirect inference rule in a semi-related class will lead to confusing compiler errors at best and breakages at worst. |
|
Josh Wiechman, do you happen to have a project that you can share that demonstrates the compiler crash? Independent of the usefulness of the warning, we'd like to reproduce that crash so we can fix it. The warning itself is discussed in https://bugs.swift.org/browse/SR-5753. |
|
Comment by Josh Wiechman (JIRA) Hi Doug, I discovered the main error from my first comment was an issue when using Xcode 9 where the command line utilities was set to 8.3.3. Once I updated the Xcode CLT to 9, the issue magically resolved. As for the discussion in SR-5753, I can move my comments to the other ticket, but I have one question. Is there a value statement why the warning exists? I understand what the warning is saying, but not the intended value. I do see the git pull on GH. I like the idea of opting in to seeing these warnings. I think understand the value proposition in the context of a warning would help facilitate the discussion. |
|
Let's dupe to SR-5753 and have discussion there. |
Additional Detail from JIRA
md5: a677d712b6d8443b00064027da39c7e9
duplicates:
relates to:
Issue Description:
This may only be an issue with protocols with extensions.
Say we have two protocols and we call them protocol A and protocol B.
Protocol B inherits protocol A.
Now we have a class we will call C which implements protocol A and protocol B.
Class C has concrete requirements from both A and B.
During compilation, a warning of "Redundant conformance constraint 'Self': 'A'"
The warning doesn't necessarily make sense.
Protocol B may depend on protocol A, and class C limit the class definition to protocol B and implicitly get the benefits of protocol A.
If protocol B no longer requires protocol A (and removes A) all implementing classes will be affected. This is problematic if classes have a direct dependency on protocol A.
If a class explicitly need protocol A and B, (even if B implements A) the class should indicate that it implements A and B and not defer to using B propagating A in order to avoid warnings.
If class C does not directly require protocol A (but implements A), then only supplying protocol B in the class definition and transitively implementing protocol A makes sense.
The text was updated successfully, but these errors were encountered: