Fix deprecation warnings

[neonichu]

This fixes almost all deprecation warnings in TSC, except for the ones in IndexStoreAPIImpl. That code is using DLHandle etc which was marked as "moved to swift-driver" when being deprecated, so not sure what the right solution here is.

[neonichu]

@swift-ci please test

[tomerd]

cc @compnerd which deprecated the APIs

[compnerd]

Thank you! Sorry about the additional work here, I didn't think of checking within the repository itself :-(

[neonichu]

@compnerd Any ideas about IndexStoreAPIImpl? That code is using DLHandle etc which was marked as "moved to swift-driver" when being deprecated, so not sure what the right solution here is. Maybe we overly eagerly deprecated it? It does seem like IndexStore is being used by SwiftPM, so we can't remove it.

[compnerd]

@neonichu hmm .. DLHandle is not used anywhere else. Is there a way to prevent new users from showing up? But perhaps we just need to eat that cost for now and just hope that no new uses are introduced and un-deprecate it for the time being :-(.

[neonichu]

@compnerd I'm assuming swift-driver has migrated off it by now? Maybe we can move it into IndexStore.swift and make it private?

[compnerd]

Yes, swift-driver now uses a different implementation of that (assuming that there has been a snapshot). I think that the only problem with making it internal and private is ... well, its internal and private and it was public before. So technically that is a problem if you use an old version and mix and match shared libraries, etc. Basically I am worried that the ABI/API break here would be something that may be material to someone depending on the library and this change would break semver unless we did a major version bump.

[neonichu]

I guess another solution would be to make an internal one that's not deprecated and let the deprecated public one call into the internal one. The issue with that is that clients inside TSCUtility could still continue to appear.

I'm not sure how worried we are about ABI/API breakage since we haven't declared a stable API so far. @tomerd wdyt?

[tomerd]

making it internal SGTM. we can keep a public deprecated version that wraps the internal non-deprecated types until we are ready to remove them

[tomerd]

@neonichu is this ready to merge?

[neonichu]

Yah, I think we can merge this and address the remaining deprecation warnings in a follow-up.