Is it possible to use other file extensions while having the compiler treat it as a ".swift" file?
If I type
ld: warning: ignoring file Test.foo, file was built for unsupported file format ( 0x70 0x72 0x69 0x6E 0x74 0x28 0x22 0x48 0x65 0x6C 0x6C 0x6F 0x20 0x77 0x6F 0x72 ) which is not the architecture being linked (x86_64): Test.foo
Undefined symbols for architecture x86_64:
"_main", referenced from:
implicit entry/start for main executable
ld: symbol(s) not found for architecture x86_64
Which I guess happens because it's trying to guess what kind of file it is by reading its first bytes (which are just a print statement).
How do I force the compiler to treat the file as a ".swift" file?
Best regards, V.
For a single input file, you can write:
swiftc -o Test - < Test.foo
For additional source files, I think the
.swift extension may be too intrinsic to how the compiler and module system work. (At least that's the impression I get from skimming various frontend and compiler invocation files in the source.)
It'd be reasonable to have a compiler flag that says "treat all following inputs as source files" or something. Clang and GCC use
-x <file-kind> for this; I'm not sure if we want to follow that spelling, or do something specific to "Swift source file", or something else.
Does this change require a proposal?
No, just a thought-out design. It's an additive change to Swift's command-line interface, which isn't really considered part of the language itself. It might still be nice to discuss it beforehand to get others' opinions on how to spell the option, though.
(Also, if you want Xcode or SwiftPM to adopt it, things may get more complicated. Xcode means "file a Radar"; SwiftPM can be discussed here.)
Okay, let's think it out.
How does the whole "kind of the file" even work to begin with? I see that it tries to analyze the first bytes of the source if it doesn't recognize the extension.
Which file kinds are accepted in addition to a ".swift" source file? Is there a list?
Magic numbers in files are used to identify mainly binary files. Wikipedia explains this and has a list. The unix command line tool 'file' uses magic numbers for this reason as well.
The only text file format I'm familiar with that uses a magic number for identification is shell script files that use a shebang '#!' for identification.
The file extension has become the standard way to tell compilers and other tools how to identify many kinds of files. Most likely the solution here is a way to tell the compiler to accept .foo files as .swift files, not magic numbers.
There's an extension-matching list in include/swift/Basic/FileTypes.def, so you could look at places in the Driver library that try to find
TY_Swift files. I think the Frontend library already assumes weird filenames should be parsed as regular sources if it doesn't recognize them.