Invalid SQL statements with Xcode 10.2

[tanzolone]

Build Information

• SQLite iOS Version 0.11.4 (however it's likely to impact all the targets)
• Xcode 10.2 beta 4
• manual integration in our project

General guidelines

In Xcode 10.2 beta 4 the macro#functionshows a different behaviour. As SQLite.swift relies on #function in different subroutines for the composition of SQLite queries, several bugs linked to invalid SQLite statements seem to be introduced.

I have just run the SQLite.swift tests with Xcode 10.2 beta 4 and there are several failures linked to this issue.

An example as follows:

In the following helper function (Helpers.swift line 107):

func wrap<T>(_ expression: Expressible, function: String = #function) -> Expression<T> {
    return function.wrap(expression)
}

when called from

static func count(_ star: Star) -> Expression<UnderlyingType>

the value of function when running in Xcode 10.2 beta 4 is count(_:) instead of count. This leads to invalid SQLite statements of the type SELECT count(_:)(*) myTable.

[christopheblin]

I have the exact same problem with Xcode Version 10.2 (10E125) (not the beta normally) !

Do you have a workaround or a fix ?

[tanzolone]

The best option in my opinion is to get rid altogether of the #function default parameter and explicitly passing the name of the SQL function (maybe an enum with string raw value). The #function macro seems to be intended for debug purposes (this explains this sort of change in a minor update of Xcode) and I would avoid relying on it for such a critical part of the SQL statement composition.

[christopheblin]

Note that this also silently breaks SqlLiteMigrationManager

https://github.com/garriguv/SQLiteMigrationManager.swift/blob/a716a877eca2e25fd8f0201605feaebfc0db27fc/Sources/SQLiteMigrationManager.swift#L68

=> Will always fall into the catch and report that no migration exists ...

garriguv/SQLiteMigrationManager.swift#29

[christopheblin]

Here is a patch to apply if you have a pod install

mystuff.patch.zip

[chess92]

the simplest fix would be to just ignore any string after the first ( of #function

[arjavlad]

Here is a patch to apply if you have a pod install

mystuff.patch.zip

I tried your patch but now it started giving 148 errors similar to /Pods/SQLite.swift/Sources/SQLite/Typed/Operators.swift:471:12: Use of unresolved identifier 'infix'
/Pods/SQLite.swift/Sources/SQLite/Typed/CoreFunctions.swift:73:16: Use of unresolved identifier 'wrap'.

@christopheblin Could you please explain how you used the patch?

The Patch did not work properly

[w8wjb]

In folder where you cloned repo:
patch -p3 < mystuff.patch

All tests pass after patch applied

[arjavlad]

Thanks,
But for now, I forked the original repo and manually made changes.

[itruf]

@stephencelis hello! Can you check this issue and linked pr? Any project with SQLite.swift will not work on new Xcode 10.2 without this fix.

[timshadel]

The symptom which lead me down this rabbit hole was first seeing was that it could not prepare a statement so: The operation couldn’t be completed. (SQLite.Result error 0.). Turning on the trace logging helped see which statements were successful. Finally spitting out query.asSQL() in the catch of the error showed that count and != had now been rendered as count(_:) and !=(_:_:).

I agree with @chess92. My simple workaround for now this change in Helpers.swift. It fixes all the problems I had, but obviously I'll toss it out and use a formal fix as soon as it's ready.

private func trimName(_ function: String) -> String {
    return function.components(separatedBy: "(").first ?? function
}

func infix<T>(_ lhs: Expressible, _ rhs: Expressible, wrap: Bool = true, function: String = #function) -> Expression<T> {
    return trimName(function).infix(lhs, rhs, wrap: wrap)
}

func wrap<T>(_ expression: Expressible, function: String = #function) -> Expression<T> {
    return trimName(function).wrap(expression)
}

func wrap<T>(_ expressions: [Expressible], function: String = #function) -> Expression<T> {
    return trimName(function).wrap(", ".join(expressions))
}

[tanzolone]

@timshadel return function.components(separatedBy: "(").first ?? function yucky :)

[karishmapujara]

Hello
Any solution for this problem?

[ypopovych]

@karishmapujara We have PR with the fix. Waiting for @stephencelis to review and merge

[timshadel]

@timshadel return function.components(separatedBy: "(").first ?? function yucky :)

Right??!! Exactly why I was waiting for a real fix. 😃 It looks like #891 handles this nicely with several enums and removes the #function magic.