Xcode 11 not recognizing Swift or UTF-8

Question

I just opened up a Swift Package in Xcode that I'm developing and the majority of the Swift files are disabled. I click on them and I get a system noise but that is all. In the Inspector pane, they aren't even recognised as Swift source. If I select Swift source from the Type drop down list, I notice that the text encoding is set to No Explicit Encoding. If I select UTF-8 it prompts me to confirm conversion, so I backed out. The reason I did, is that from the command line, if I use the `file -I` command it tells me that the files are indeed UTF-8. Also, for a project that had schemes, it now has none. I know the default is to create a Swift Package without a scheme, but I prefer what I'm familiar with.

I recloned the repo from bitbucket, but the results were exactly that same. So now I'm not sure where the problem is. Did Bitbucket corrupt my files? Are both Xcode 11.1 and Xcode 11.2 Beta 2 to blame? I doubt it, but the files are clearly Swift UTF-8.

Any ideas on how I can get Xcode to recognise my Swift source and magically restore my schemes? :-(

Xcode

1.9k

Posted by

alienspaces

Reply

Add a Comment

Answer 1

Solved: Although Xcode was prompting me to convert the disabled Swift files to UTF-8 when trying to get Xcode to recognize them, the problem and solution lay elsewhere...

Personally I feel this is a bug with Xcode, but because no one else seems to be affected by this (and this is still the current implementation), I guess I'm in the minority.

The default for a file's Location in the Identity and Type Inspector in the dropdown box is "Relative to Group". While this seems fine, what Xcode often does is specifiy the files relative location by first backtracking back to the root of the drive with ../../../../../ and then traversing down the file system hierarchy back to the file so your file's location is actually stored in the project file as ../../../../../Users/rayscott/Developer/Project/Project/Sources/main.swift. While it's relative, its still embedding the absolute path. My Beta of Catalina crashed - I had to restore from TM, and I decided to refactor the way I store my data and updated my user name too. Because I'd cloned the repo into a new location, it broke all these relatively absolute paths.

It seems that Xcode even uses this relatively absolute format to describe where it's own frameworks exist in the file system, because it wasn't just my Swift source files that were affected, but also Apple's own frameworks that I'd included in my project.

I've decided to go with Relative to Project for this Swift Package and see how it goes. You'd think that would be the default, as it's more portable.

One other point. Once I'd updated a Swift file's location to remove the relatively absolute path and it was accurately reflecting the file's location Relative to Group, without any file system traversal, once I added the file to the package's Target, I noticed that Xcode was still using this relatively absolute path format to list the file in the Compiled Sources build phase. It's only when you change it's location to Relative to Project, does Xcode add the entry with a portable URL.

Posted by

alienspaces

Add a Comment

Answer 2

Have you a valid backup to restart from ?

You say:

The reason I did, is that from the command line, …

You did what ?

Posted by

Claude31

Add a Comment

Answer 3

> know the default is to create a Swift Package without a scheme, but I prefer what I'm familiar with.

Might be time to broaden those horizons... At least give it try.

Posted by

KMT

Add a Comment

Answer 4

> If I select UTF-8 it prompts me to confirm conversion, so I backed out. The reason I did

The reason I backed out. The reason I didn't confirm the conversion.

Posted by

alienspaces

Add a Comment

Answer 5

> Have you a valid backup to restart from ?

I have git repos backed up, plus I might have simliar code state in a feature branch I can checkout and evaluate.

Posted by

alienspaces

Add a Comment

Answer 6

Solved: Although Xcode was prompting me to convert the disabled Swift files to UTF-8 when trying to get Xcode to recognize them, the problem and solution lay elsewhere...

Personally I feel this is a bug with Xcode, but because no one else seems to be affected by this (and this is still the current implementation), I guess I'm in the minority.

The default for a file's Location in the Identity and Type Inspector in the dropdown box is "Relative to Group". While this seems fine, what Xcode often does is specifiy the files relative location by first backtracking back to the root of the drive with ../../../../../ and then traversing down the file system hierarchy back to the file so your file's location is actually stored in the project file as ../../../../../Users/rayscott/Developer/Project/Project/Sources/main.swift. While it's relative, its still embedding the absolute path. My Beta of Catalina crashed - I had to restore from TM, and I decided to refactor the way I store my data and updated my user name too. Because I'd cloned the repo into a new location, it broke all these relatively absolute paths.

It seems that Xcode even uses this relatively absolute format to describe where it's own frameworks exist in the file system, because it wasn't just my Swift source files that were affected, but also Apple's own frameworks that I'd included in my project.

I've decided to go with Relative to Project for this Swift Package and see how it goes. You'd think that would be the default, as it's more portable.

One other point. Once I'd updated a Swift file's location to remove the relatively absolute path and it was accurately reflecting the file's location Relative to Group, without any file system traversal, once I added the file to the package's Target, I noticed that Xcode was still using this relatively absolute path format to list the file in the Compiled Sources build phase. It's only when you change it's location to Relative to Project, does Xcode add the entry with a portable URL.

Posted by

alienspaces

Add a Comment

Xcode 11 not recognizing Swift or UTF-8

Accepted Reply

Replies