Large number of duplicated symbol USRs in the `_Differentiation` module

Development Swift-DocC
1

there are a large number of duplicated USRs in the _Differentiation@Swift graph, which is one of the modules that ships with the toolchain. the USRs conflict with symbols in the main Swift module. they all seem to be synthesized symbols, from what i’ve observed.

NIOConcurrencyHelpers@Swift also contains duplicate symbols.

has anyone else observed this? filtering out duplicate symbols is relatively straightforward, but what about edges? how do i detect if an edge is a duplicate?

2

I don't see the USRs of the symbols on that page; which USRs are duplicated?

3

in _Differentiation@Swift: gist

in NIOConcurrencyHelpers: gist

4

@taylorswift the first link in your above comment seems to link to NIOConcurrencyHelpers at the moment, instead of _Differentiation. For the reference of anyone else reading this, the link for _Differentiation is here:

1 Like
5

oops, thanks for catching that!

6

Oh, I think I see what you mean now. The USRs in those gists are actually unique, but some of them have synthesized copies. For example, if two structs inherit from a common protocol that defines a method in an extension, it is expected for that each struct gets a synthesized method with a unique USR. From the compiler's perspective, they are not duplicate.

If you want to omit synthesized members from the generated symbol graph, you can look at the -skip-synthesized-members option which is available on the swift-symbolgraph-extract command.

7

no this isn’t what i mean. the id s:s4SIMDPsSF6ScalarRpzrlE2meoiyyxz_xtFZ::SYNTHESIZED::s:s5SIMD2V already exists in Swift.symbols.json, it shows up a second time in _Differentiation. this has no relation to the base symbol s:s4SIMDPsSF6ScalarRpzrlE2meoiyyxz_xtFZ, which also lives in Swift.symbols.json, and does not conflict with its synthesized copy for s:s5SIMD2V.

8

Without seeing the full symbol graphs you generated i can't be sure, but my hunch (based on looking at the SIMD2 docs page) is that the "duplication" is likely for different protocol conformance conditions. e.g. the one property appears either when Scalar is a FixedWithInteger or a FloatingPoint. Could that be culprit?

9

no, that can’t be it, because the protocol conformance conditions are encoded in the USR:

for example:

SIMD2.one from FixedWidthInteger:

s:s4SIMDPss17FixedWidthInteger6ScalarRpzrlE3onexvpZ::SYNTHESIZED::s:s5SIMD2V

SIMD2.one from FloatingPoint:

s:s4SIMDPsSF6ScalarRpzrlE3onexvpZ::SYNTHESIZED::s:s5SIMD2V

here are the symbolgraphs i generated:

10

this is very late, but i have discovered that this issue is due to @_exported module imports.