swift
swift copied to clipboard
swiftlang
Reordering autolink-extract runtime orderings
Order is important. The ordering generated by autolink-extract is nonsensical in main and 5.9. I haven't had a chance to actually build the full symbol dependency graph to generate the proper ordering so I expect that I'm missing something, but this gets us closer to the actual library link order, so it might hopefully unblock some folks who are running into the "missing" symbols.
rdar://107643395 rdar://107445812
Why does it feel like you're playing 52 card pick up?
Best quote of 2023. We can go home now.
I would buy this ordering.
Now let's just hope we don't have too many cycles.
https://github.com/apple/swift-integration-tests/pull/78
@swift-ci build toolchain
Can this be closed given that we don't have tests that confirm that changing ordering fixes the issue we were chasing and we've merged alternative fixes since then?
We may still want to fix the ordering since, even though the group makes it so that ordering “doesn’t matter”, it’s basically a while-loop around the linker algorithm until things converge. Putting things in the right order will help them converge faster while consuming less memory. It’s basically an optimization now.
We may still want to fix the ordering since, even though the group makes it so that ordering “doesn’t matter”, it’s basically a while-loop around the linker algorithm until things converge. Putting things in the right order will help them converge faster while consuming less memory. It’s basically an optimization now.
FWIW, if the group had "fully" helped with ordering, I wouldn't have run into the XCTest issue that made me throw up my hands and add ordering to the deduplication pass in the first place, so a good choice of ordering is definitely a good thing. (Fixing the XCTest issue would also be good! 😆)
It was my impression that #65795 solved the static linking issue; does that include the Radars mentioned by this PR?
