Nie można debugować Swift moduł/ramy osadzonej w Objective-C app

Question

Tytuły alternatywne (w celu ułatwienia przeszukiwania)

• Nie można debugować Swift 2.3 ram połączony z aplikacji Objective-C w Xcode 8
• error in auto-import: failed to get module 'XYZ' from AST context Xcode 8
• Xcode 8 nie można debugować Swift ramowa
• warning: Swift error in module <XYZ>
• obejście; Xcode Debugger nie może debugować aplikacji napisanych tylko w Objective-C, ale ten link do frameworków napisanych tylko w Swift. (28312362)

Mam app napisane w Objective-C, która łączy przeciwko niektórych modułów (ram) napisany w Swift 2.x.

Pytanie

wszystkiego (debugowanie itd.) Działa poprawnie w xcode7, jednak po przeniesieniu do xcode8 oraz aktualizację modułów używać swift2.3 byłem niezdolny do debugowania modułów.

LLDB zgłaszane te błędy:

warning: Swift error in module XYZ. 
Debug info from this module will be unavailable in the debugger. 

error: in auto-import: 
failed to get module 'ABC' from AST context 

nie stanie, jeśli odwołują się do modułów aplikacji zbudowanej w Swift 2.3.

Answer 1

tl: dr

Dodaj ustawienie zdefiniowanej przez użytkownika pod "Build Settings" na swojej docelowej aplikacji.

SWIFT_VERSION = 2.3

Więcej informacji

jestem pewien, czy jest to błąd Xcode 8 lub jeśli jest polityka firmy Apple (aby spróbować programistów siły do ​​Swift 3.0?). Ale ... domyślnie Xcode 8 instaluje wersje Swift 3.0 standardowych bibliotek runtime Swift.

Jeśli chodzi o debugowanie za pomocą LLDM, moduły Swift 2.3 nie ładują się (do środowiska wykonawczego Swift 3.0).

Zmuszenie aplikacji do użycia Swift 2.3 (lub starszej wersji Swift, jak to nazywa Apple) rozwiązuje problem.

Aplikacje Swift mają to ustawienie wystawione przez Xcode, ale musisz ręcznie dodać je do aplikacji Objective-C.

dodatkowej porady

Port Twój Swift Kod Swift 3.0 jak najszybciej 2.3, Apple nie będzie wspierać 2.x na bardzo długo.

Answer 2

W moim przypadku musiałem usunąć Objective-C Bridging header z pliku ustawień kompilacji. Mój plik nagłówkowy Bridging nie zrobił nic ... więc było w porządku.

Answer 3

Dla mnie było to tak proste, jak to było bolesne i czasochłonne:

import SDWebImagebył problem, ponieważ jedna z ram miał SDWebImage już zapakowane w nim (i nie mogłem zobaczyć it), a ta struktura stała się celem C, a aplikacja była Swift. Dodałem także SDWebImage do projektu, ponieważ używam go w klasach, które piszę, oraz tego, co stworzyło bałagan, z którym nie mógł sobie poradzić debugger xCode. Więc, w zasadzie, upewnij się, że nie masz żadnych duplikatów w jakikolwiek sposób, chciałbym sprawdzić na typowe rzeczy, takie jak SDWebImage na przykład.

Answer 4

Podczas próby debugowania w symulatorze 9.3 natknąłem się na komunikat error in auto-import: failed to get module 'XYZ' from AST context. Przejście na symulator 10.2 rozwiązało problem.

Answer 5

omówiłem ten problem z inżynierem firmy Apple o nazwie Sean na WWDC 2017

Mój zespół spędził tydzień próbuje dowiedzieć się tego, i skończyło się to bug na kompilator Apple, która nigdy nie mogła zorientowali się sami. Ponadto ma bardzo proste obejście.

Występuje błąd w sposobie, w jaki flagi kompilujące są agregowane ze struktur i projektu, a projekt "czysty Objective-C" "aktywuje" go.

Rozwiązanie: dodaj jeden, pusty plik Swift ("Whatever.swift" lub cokolwiek innego) w projekcie Objective-C, czyniąc go nie-czystym-celem-c (nowy-> plik-> plik Swift, nie twórz nagłówka pomostowego. Plik będzie zawierał tylko import Fundacji).

I to wszystko. Problem rozwiązany.

Answer 6

użycie fr v zamiast PO do debugowania

Więcej debugowania https://www.codeproject.com/Articles/1181358/Debugging-with-Xcode

Answer 7

próbie ponownego uruchomienia Xcode. W moim przypadku rozwiązał problem.

Answer 8

W moim przypadku wystąpił błąd kompilatora w kodzie "C", który został zgłoszony w LLDB, po naprawieniu błędu LLDB zaczął działać ponownie.

Answer 9

Zgodnie z sugestią Tima https://stackoverflow.com/a/41876400/1840269 podstawową przyczyną naszego problemu była kwestia duplikatów.

Mamy kategorię obj-c dla SDWebImage, która była używana zarówno z obiektów obj-c jak i Swift. Podczas importowania kategorii z Swift wszystko wybuchło z powodu redefinicji/duplikowania importu, ponieważ SDWebImage pod już ujawnił go samodzielnie jako moduł Swift.

Rozwiązanie? Ponownie zaimplementowaliśmy kategorię obj-c jako rozszerzenie Swift - i używaliśmy jej zarówno z Swift, jak i obj-c, dodając @objc przed rozszerzeniem i importując plik #import "product-Swift.h" z obiektu obj-c.

A może zacznij od sprawdzenia: .