Metody realizacji języków programowania/MRJP Wykład 3

Statyczna analiza semantyczna

Statyczna analiza semantyczna ma na celu częściowe sprawdzenie poprawności kodu źródłowego programu w czasie kompilacji. Na tym etapie zakładamy, że program źródłowy został już sparsowany i zostało zbudowane drzewo składniowe oraz tablice symboli. Założenia te nie zawsze są konieczne. Niektóre kompilatory mogą przeprowadzać analizę semantyczną w czasie parsowania kodu, w czasie budowy tablicy symboli lub w czasie generowania kodu. Jednak takie podejście pozwala łatwiej zrozumieć tę fazę działania kompilatora.

Głównym zadaniem w czasie analizy semantycznej jest sprawdzenie, czy program może być jednoznacznie skompilowany. Pewne konstrukcje, mimo że dopuszczalne przez gramatykę języka, mogą być niepoprawne. Poniżej zaprezentowane jest kilka przykładów niepoprawnych konstrukcji. Pzykłady są podane w języku C++, ale w innych językach występują te same typy błędów.

• Użycie zmiennej, która nie była zadeklarowana:

int f(void) {
   int zmienna = 5;
   return zmianna;          // literówka!
}

• Niezgodność typów przy przypisaniu:

void f(void) {
   String s = "tekst";
   int a = s;               // błąd typu!
}

• Wywołanie nieistniejącej metody obiektu lub nieistniejącej funkcji:

class C {
   void print();
};
void f(void) {
   C obiekt;
   obiekt.prnt();           // literówka!
}

• Odwołanie do zmiennych klasy z metod statycznych:

class C {
   int a;
   static int getA() {
      return a;            // błąd! - funkcja getA jest statyczna
   }
};

• Użycie instrukcji w niedozwolonych miejscach, np. this poza klasą (ten problem nie występuje na przykład w Javie), break poza pętlą:

int main(int argc, char** argv) {
   if (argc > 2)
      break;                // błąd! - break poza pętlą
   else
      return this->a;       // błąd! - main nie jest metodą klasową
}

• Przypisanie do nie L-wartości (np. do wyniku zwracanego przez funkcję lub do wyniku dodawania - więcej o L-wartościach będzie napisane w FIXME):

int f(void) {
   int a = 2;
   int b = 4;
   (a + b) = 8;           // błąd! (a + b) jest tymczasową wartością 
                          // i nie odpowiada żadnej lokacji w pamięci
}

Zakres analizy semantycznej zależy od języka programowania. Niektóre języki dopuszczają użycie niezadeklarowanych zmiennych, niektóre sprawdzają poprawność przypisania, czy wywołania metody, w czasie wykonywania programu, a nie w czasie kompilacji. Pozostawienie sprawdzania poprawności na czas wykonywania programu można nazwać dynamiczną analizą semantyczną (lub częściej dynamicznym typowaniem, gdyż sprawdzanie typów jest znaczą częścią analizy semantycznej).

Ogólnie, im więcej jest sprawdzane w tej fazie statyczniej analizy semantycznej tym łatwiej pisać skomplikowane a jednocześnie poprawne programy. Dużą część błędów (np. literówki), które mogłyby powstać w czasie wykonywania programu, wykrywa się na etapie kompilacji. Dzięki temu można znacznie skrócić fazę testów oprogramowania i pisać kod z mniejszą liczbą błędów.

Z drugiej strony zaawansowana statyczna analiza semantyczna wymaga pewnego nakładu ze strony programisty i ogranicza możliwości języków programowania. Sama deklaracja każdej zmiennej zabiera czas programiście piszącemu kod źródłowy. Dlatego możliwość używania niezadeklarowanych zmiennych jest pożądana w językach skryptowych oraz używanych do szybkiego prototypowania. Języki z brakiem statycznego sprawdzania poprawności typów (w szczególności języki obiektowe, jak smalltalk czy python) są bardziej elastyczne. Pozwalają na skupienie się na samym zadaniu do rozwiązania, a nie na zmieszczeniu rozwiązania w ramach języka programowania. To z kolei ułatwia i przyspiesza projektowanie, zarówno w małych projektach jak i w dużych systemów informatycznych. Projektant języka programowania musi odpowiednio wyważyć zalety i wady statycznej analizy semantycznej, mając na uwadze przeznaczenie języka.

W tym rozdziale zostaną opisane najistotniejsze elementy statycznej analizy semantycznej:

• kontrola typów, czyli sprawdzanie poprawności typów w każdej instrukcji (zawiera także sprawdzanie, czy identyfikatory zostały zadeklarowane);
• kontrola poprawności instrukcji, czyli sprawdzenie, czy instrukcje mają sens w kontekście, w którym zostały użyte,
• kontrola nazw, czyli sprawdzenie, czy nazwy jednoznacznie identyfikują funkcje, etykiety i inne konstrukcje języka programowania.

Ten podział nie oznacza, że analiza semantyczna jest rozbita na trzy kroki. W rzeczywistości instrukcje sprawdzane są po kolei, mając na uwadze wszystkie trzy kryteria. Niektóre sprawdzenia, jak na przykład kontrola, czy jakaś etykieta nie została zadeklarowana dwukrotnie, odnoszą się do programu jako do całości.

Kontrola typów

Kontrola typów ma na celu sprawdzenie poprawności typów w takich konstrukcjach językowych jak:

• przypisania - typ wartości przypisywanej musi być zgodny z typem elementu do którego przypisujemy,
• operacje arytmetyczne - wartości, do których używany jest operator arytmetyczny, muszą zgadać się z rodzajem operatora.
• wywołania funkcji - typy parametrów funkcji przy jej wywyłaniu muszą zgadzać się z typami zadeklarowanymi,
• odwołania do pól rekordu - rekord, do którego się odwołujemy, musi mieć pole podanej nazwie,
• wywołania metod obiektu - obiekt musi być klasy, która zawiera metodę, która jest wywoływana.

Zgodność typów nie oznacza, że typy są identyczne, ale, że operacja może być zastosowana dla tych typów. W dalszej części tego rozdziału przedstawione będą rodzaje typów, ich zgodność oraz kontrola ich poprawności.

W czasie kontroli typów sprawdzane jest, czy identyfikatory były zadeklarowane. Do tego celu służy zbudowana wcześniej tablica symboli.

System typów

Typy obejmują:

• typy arytmetyczne (int, char, etc.)
• wskaźniki i referencje
• rekordy
• obiekty
• tablice
• funkcje

Różne języki programowania mają różne systemy typów. Nie wszystkie będą zawierały wszystkie tych typów, a niektóre będą miały system typów bardziej rozbudowany.

Typy arytmetyczne

Typy arytmetyczne są przeznaczone do bezpośrednich operacji przez procesor lub maszynę wirtualną. Obejmują one liczby całkowite (1, 2, 4, 8 bajtów), zmiennopozycyjne (4, 8, 10 bajtów) i znaki (1 lub 2 bajty). Nie wszystkie języki programowania dopuszczają typy o wszystkich rozmiarach, a niektóre mogą dopuszczać inne rozmiary. Procesor lub maszyna wirtulana posiada zwykle instrukcje do odczytywania tych wartości z pamięci, wykonywania na nich operacji (dodawanie, mnożenie, etc.) i zapisywanie w pamięci. Czasem jednak, na przykład dla architektur bez możliwości obliczeń zmiennopozycyjnych, dodawanie dwóch liczb zmiennopozycyjnych może być zamienione na wywołanie odpowiedniej funkcji lub przerwania.

Wskaźniki i referencje

Referencje to małe obiekty, które przechowują informację o dostępie do innej wartości (np. do wartości zmiennej lub do obiektu) - wskazują na nią. Dzięki referencji można mieć dostęp do wskazywanej wartości. Zwykle wystarczającą informacją jest adres w pamięci.

Wskaźniki są tym samym co referencje, ale tym razem zakłada się, że przechowują wyłącznie adres pamięci pod którym zapisana jest inna wartość.

Używając referencji lub wskaźnika niejako tworzymy inną nazwę na istniejącą już wartość. Niech, na przykład, pod adresem 0x11111111 będzie zapisana zmienna x, która jest równa 2. Jeśli zmienna w jest wskaźnikiem na x to jej wartość będzie równa 0x11111111. Mając dostęp do zmiennej w możemy odczytać wartość zmiennej x. Jeśli teraz dokonamy przypisania:

x = 3;

to korzystając z tej samej zmiennej w możemy odczytać nową wartość równą 3.

Wskaźniki (i referencje) mogą mieć różny typ: wskaźnik na liczbę całkowitą na liczbę zmiennopozycyjną, na obiekt, element tablicy.

Referencje i wskaźniki w rzeczywistości są tym samym. Jedyna różnica jest taka, że mówiąc wskaźnik mamy na myśli tylko adres w pamięci, a mówiąc referencja, być może również jakiś inny rodzaj dostępu.

Niektóre języki programowania, na przykład C++ rozróżniają między wskaźnikami a referencjami i przypisują im nieco różną składnię i semantykę. Na przykład w C++ referencje są niezmienialne, tzn. nie można zmienić adresu na który wzkazuje zainicjalizowana referencja. W innych, jak Java jest tylko jeden rodzaj i nazywa się je referencjami (słowo wskaźnik nie jest używane wśród programistów Javy).

Rekordy

Rekordy (zwane także strukturami lub krotkami) to złożone typy, które zawierają pola o innych typach. Na przykład konstrukcja z języka C:

struct A {
   int I;
   double D;
};

definiuje typ rekordowy A, który zawiera dwa pola: liczbę całkowitą I oraz liczbę zmiennopozycyjną D.

Rekord grupuje wartości różnych typów i pozwala na przechowywanie tych wartości w pojedynczej zmiennej. Odwołanie do poszczególnych pól rekordu jest wykonywane przez podanie nazwy pola (czasem numeru pola), np. a.I w języku C oznacza wzięcie pola I ze zmiennej a, która jest typu rekordowego. Operator . (kropka) oznacza dostęp do pola.

Rekordy mogą zawierać pola o dowolnych typach. Szczegóły są uzależnione od języka programowania.

Obiekty

Obiekty są jak rekordy, ale mogą przechowywać funkcje (zwane metodami). Z wnątrza takiej funkcji jest dostęp do pól obiektu, z którego funkcja została wywołana. Główną techą obiektów jest to, że ich typy - klasy - mogą dziedziczyć po innych klasach. Zainteresowanego czytelnika odsyłamy do książek poświęconych podstawom programowania obiektowego.

Tablice

Tablice to ciągły obszar pamięci zawierający kolejne instancje typu tablicy. Na przykład tablica 100 liczb całkowitych to obszar pamięci zawierający kolejno 100 liczb całkowitych. Mogą być tablice obiektów, referencji, tablic.

Funkcje

W przypadku funkcji też możemy mówić o typach. Typy funkcji są takie same, jeśli funkcja przyjmuje tę samą liczbę argumentów, argumenty są tego samego typu oraz typ wartości zwracanej test taki sam. Typ funkcji można zapisać w postaci sygnatury typu funkcji:

Typ_Arg1, typ_Arg2, ..., Typ_ArgN -> Typ_Wart

Liczba N oznacza liczbę argumentów, Typ_Argi to typ i-tego argumentu, a Typ_Wart to typ wartości. Jeśli na przykład w języku C mamy funkcję:

double funkcja(char a, int* p);

to jej typem jest:

char, int* -> double

Jak widać, aby sprawdzić, czy dwie funkcje są tego samego typu, wystarczy porównać ich sygnatury.

W przypadku języków proceduralnych lub obiektowch (ogólnie, w językach imperatywnych) rzadko używa się zmiennych, których typem jest funkcja (taka zmienna wtedy zwykle przechowuje adres pod którym jest kod funkcji). Jednak w językach funkcyjnych zmienne bardzo często przechowują funkcje. Funkcje są w tych językach pełnoprawnymi wartościami i można na nich przeprowadzać operacje, które mogą zmienić ich typ (na przykład mając funkcję biorącą liczbę całkowitą i znak i dającą liczbę zmiennopozycyjną można zaaplikować jeden z argumentów, np. liczbę całkowitą; wynikiem aplikacji będzie funkcja, która oczekuje znaku i daje liczbę zmiennopozycyjną). Dlatego w językach funkcyjnych bardzo ważna jest analiza typów funkcji.Więcej o językach funkcyjnych jest napisane w rozdziale FIXME.

Konwersja typów

Wartości niektórych typów mogą w pewnych sytuacjach być konwertowane do wartości innego typu. Na przykład jeśli oczekujemy liczby całkowitej 4-bajtowej, a mamy 2 bajtową to możemy rozszerzyć ją o brakujące dwa bajty nie gubiąc przy tym żadnej informacji.

Taka niejawna konwersja typów zależy od kompilatora. Często obejmuje ona:

• konwersję liczb całkowitych do zmiennoprzecinkowych
• konwersja liczb całkowitych do liczb całkowitych o większej precyzji
• konwersja liczb zmiennoprzecinkowych do zmiennoprzecinkowych o większej precyzji
• konwersja typu obiektu do nadklasy (gdyż podklasa może być użyta wszędzie tak, gdzie oczekujemy nadklasy

Dobrze zaprojektowany język powinien zabraniać niejawnej konwersji przy której może wystąpić utrata informacji. Z kolei niejawna konwersja, przy której nie ma utraty informacji znacząco ułatwia pracę programiście.

Przy sprawdzaniu typów, przed zgłoszeniem błędu niezgodności typów kompilator powienien zawsze sprawdzić, czy podany typ może być poddany konwersji niejawnej. Może również zajść sytuacja, w której konwersja jest możliwa na dwa różne sposoby. Wtedy semantyka dobrze zaprojektowanego języka powinna określać priorytety konwersji typów lub określać, że taka niejednoznaczność jest błędem.

Oprócz niejawnej konwersji typów języki programowania często pozwalają programiście na jawną zmianę typu elementu. W przypadku konwersji zmiennej rzeczywistej na całkowitą oznacza to utratę precyzji (ale zaakceptowaną przez programistę, gdyż jawnie zaznaczył ją w programie). W przypadku konwersji typów obiektów (zwane rzutowaniem) może to prowadzić do błędów, gdy konwertujemy typ obiektu na klasę całkowiecie nie związaną z poprzednią klasą. Takie błędy nie są możliwe do wykrycia na etapie kompilacji. Projektant języka może dać możliwość sprawdzenia takiego rzutowania w czasie wykonania programu. Takie podejście zostało zastosowane w języku Java. Pomaga to w wykryciu błędów, ale jednocześnie spowalnia nieco wykonanie programu. Z kolei w C++ poprawność rzutowania nie jest domyślnie sprawdzana. Dzięki temu kod jest szybszy, ale istnieje ryzyko pojawienia się trudnych do lokalizacji błędów (w C++ da się jednak zaznaczyć, czy chcemy dynamicznie sprawdzać poprawność rzutowania obiektów).

Sprawdzanie poprawności typów

Sprawdzanie poprawności typów polega na przejściu drzewa składniowego, sprawdzeniu w każdym węźle, czy jego operacja może być zastosowana do typów dzieci tego węzła i w końcu na określeniu typu samego węzła. Przy przechodzeniu drzewa korzysta się z tablicy symboli do określenia typów zmiennych, funkcji, pól rekordów, etc.

Aby lepiej zrozumieć analizę semantyczną spójrzmy na prosty przykład. Chcemy sprawdzić fragment drzewa odpowiadający instrukcji

x = y + 5;

W tablicy zaczynamy od liści drzewa składniowego. Dla zmiennych x i y typy sprawdzamy w tablicy symboli. Jeśli x lub y nie zostało zadeklarowane to zgłaszamy błąd niezadeklarowanej zmiennej. Przypuśćmy, że typem x jest double, czyli liczba zmiennoprzecinkowa podwójnej precyzji, a typem y jest int, czyli liczba całkowita. Typem węzła odpowiadającego stałej 5 jest również int. Sprawdzamy węzeł '+': typami dzieci tego węzła są int oraz int, więc operacja dodawania może być przeprowadzona. Wynikiem jest typ int. Sprawdzamy węzeł '=' (przypisanie): typem lewej strony jest double, a prawej int. Zakładamy, że nasz kompilator pozwala na przypisanie zmiennej całkowitej do zmiennoprzecinkowej więc całą instrukcję uznajemy za poprawną. Jako typ całości bierzemy double, czyli typ zmiennej na którą przypisujemy (jest to semantyka wzięta z języka C, który dopuszcza przypisania w postaci x = y = 1; alternatywnie moglibyśmy takich przypisań zabronić i jako typ wyniku wziąć void - specjalny typ, który nie niesie żadnej wartości).

Na powyższym przykładzie widzimy, że analiza semantyczna jest dość skomplikowana, ale można ją rozbić na małe fragmenty - każdy odpowiada pojedynczemu węzłowi w drzewi składniowym.

W podpunktach niżej omówione zostaną reguły odpowiadające pewnym węzłom w drzewie składniowym.

Przypisania

Przy przypisaniach typ wartości, którą przypisujemy musi być zgodny z typem elementu do kórego przypisujemy. Zgodność w tym przypadku może być ścisła - ten sam typ, lub może być dozwolona niejawna konwersja typów. Konwersja może pozwolić na przypisanie na przykład wartości całkowitej na liczbę zmiennopozycyjną, wartości całkowitej na ciąg znaków (dostaniemy liczbę zapisaną w kodzie ASCII) lub obiektu na zmienną o typie będącym nadklasą typu obiektu (w językach obiektowych wszędzie, gdzie można użyć pewnej klasy, można użyć też jej podklasy, więc takie przypisanie ma sens).

Operacje arytmetyczne

W operacjach arytmentycznych wartości, do których używany jest operator arytmetyczny, muszą pasować do rodzaju operatora. Na przykład pomnożenie dwóch liczb całkowitych jest dozwolone, a pomnożenie dwóch stałych napisowych nie.

Niektóre języki dopuszczają definiowanie własnej semantyki operatorów arytmetycznych. W takim przypadku programista zwykle pisze kod funkcji, która będzie wywołana zamiast przeprowadzania operacji arytmetycznej. W takim przypadku sprawdzanie semantyki przebiega tak jak opisane niżej sprawdzanie semantyki wywołania funkcji.

Wywołania funkcji

Przy wywołaniach funkcji typy parametrów muszą zgadzać się z typami określonymi w deklaracji funkcji. Jako wynik wywołania funkcji bierze się typ zwracany przez funkcję.

Ze sprawdzaniem semantyki wywołania funkcji związane jest także sprawdzanie semantyki powrotu z funkcji (choć jest to sprawdzane w innym miejscu kodu źródłowego - przy analizie semantycznej kodu funkcji). Przy analizie semantycznej powrotu z funkcji (zwykle jest to instrukcja return) należy sprawdzić, czy typ wartości zwracanej przez funkcję (zwykle jest to wyrażenie policzone wewnątrz funkcji, np w instrukcji return <Expr>, gdzie <Expr> oznacza wyrażenie) jest zgodny z zadeklarowanym typem wyniku funkcji.

Odwołania do pól rekordu

Przy odwołaniach do pól rekordu należy przede wszystkim sprawdzić, czy element, do którego pola się odwołujemy jest naprawdę rekordem (jeśli jest on np. liczbą całkowitą to takie odwołanie jest błędne) oraz, czy taki rekord rzeczywiście zawiera pole o tej nazwie. Nazwy pól rekordów są dostępne w tablicy symboli. Typem zapisanym w węźle drzewa składniowego będzie typ pola rekordu.

Wywołania metod obiektu

Analiza jest taka sama, jak w przypadku odwołania do pól rekordu i wywołaniu funkcji.

Równość typów FIXME

Przy sprawdzaniu poprawności typów trzeba sprawdzić, czy typ węzła jest taki jak oczekujemy (np. taki sam jak typ parametru funkcji, która jest wołana na wyrażeniu). Trzeba więc porównać typy. W przypadku typów arytmetycznych wystarczy sprawdzić, czy nazwa typu jest taka sama (i oczywiście uwzględnić automatyczną konwersję typów). W przypadku typów rekordowych są dwie możliwości:

• równoważność strukturalna
• równoważność przez nazwę

Równoważność strukturalna sprowadza się do porównania, czy rekordy mają takie same pola. Równoważność przez nazwę występuje gdy możemy robić aliasy dla typów. Takie aliasy, przy równoważności przez nazwę, będą oznaczały różne typy. Aby zbadać równoważność strukturalną trzeba rekurencyjnie sprawdzić wszystkie pola (kolejność deklaracji pól też jest ważna). Rekurencyjnie, bo rekord może mieć pola także typu rekordowego.

Przeciążanie funkcji FIXME

Funkcje o tej samej nazwie lecz różnych typach parametrów to funkcje przeciążone. Przykład: operator + działający na intach lub double lub float lub char, .... Przeciążać czasem można też typ wartości zwracanej z funkcji.

W przypadku przeciążania typów parametrów wystarczy przy wywołaniu sprawdzić jakie konwersje typów są dozwolone i która z funkcji może być wywyłana przy minimalnej liczbie konwersji.

Jeśli przeciążamy wartość zwracaną to zamiast typów wyrażeń wyliczamy zbiory możliwych typów (możemy mieć np funkcję Date date() i int date()). Następnie kontynuujemy analizę semantyczną. Jeśli natrafimy na użycie wartości, dla którego niektóre typy są niepoprawne (np date() + 4 nie będzie działać z typem string) to zaznaczamy te niepoprawne typy. Na końcu przechodzimy drzewo składniowe jeszcze raz, eliminując niepoprawne użycia. Jeśli na końcu wyjdzie, że w pewnym miejscu możemy użyć dwóch z możliwych funkcji to zgłaszamy błąd bądź wybieramy jedną z nich na podstawie jakichś reguł.

szablony (c++) i generyki (java)

???

Języki funkcyjne i wnioskowanie typów

• Zmienne typów;
• unifikacja, etc.

Kontrola poprawności instrukcji

Przez "poprawność instrukcji" rozumiemy wszeklą inną poprawność instrukcji poza sprawdzaniem typów. Sprawdzanie obejmuje między innymi

• kontrolę L-wartości,
• kontrolę przepływu sterowania,
• kontrolę dostępu do obiektów i klas,
• pozostałe sprawdzenia.

L-wartości

L-wartość to wartość, która może stać z prawej strony instrukcji przypisania, czyli wartość do której można przypisywać zmienną. Przykładami L-wartości są:

x;      // zmienna
y.a;    // pole rekordu
t[4];   // element tablicy

Z kolei wyrażenia, które nie są L-wartościami to:

5;      // stała
f(x);   // wynik funkcji
x+y;    // wynik operacji arytmetycznych

Sprawdzanie L-wartości najłatwiej zrobić etykietując drzewo składniowe wartością logiczną określającą, czy wyrażenie jest L-wartością.

L-wartości kontroluje się przy instrukcji przypisania, gdzie sprawdza się, czy lewa strona jest L-wartością. Także przy wywołaniu funkcji przez zmienną, gdy funkcja może zmodyfikować przekazywaną zmienną, przekazywana wartość musi być L-wartością.

Kontrola przepływu sterowania

W ramach kontroli przepływu sterowania sprawdza się instrukcje, które zmieniają liniowy bieg programu. Sprawdza się:

• czy break jest wewnątrz bloku switch, for, while, itp.
• czy etykieta przy instrukcji goto jest zadeklarowana

Kontrola obiektów i klas

Pod pojęciem kontroli obiektów i klas mieści się ogół akcji związanych ze sprawdzeniem poprawności semantycznej obiektowych części programu. Weryfikuje się:

• użycie this (w innych językach self) tylko wewnątrz klasy, w metodzie niestatycznej. Ta instrukcja zapewnia dostęp do zmiennych i metod obiektu dla którego wywoływana była metoda.
• czy klasa tworzonego obiektu nie jest abstrakcyjna,
• czy nie ma cykli w hierarchii klas,
• czy nadklasa nie jest finalna,
• czy w nadklasie są metody, które się przedefiniowuje (niektóre języki wymagają jawnego wyspecyfikowania, czy funkcja jest nowa, czy przeładowuje funkcję z nadklasy), czy są wirtualne, czy zwracany typ i parametry są take same.
• próby czytania zmiennych prywatnych spoza klasy
• próby czytania zmiennych chronionych spoza podklas lub pakietu

inne pomysły

Podane wcześniej miejsca sprawdzania poprawności semantycznej nie obejmują wszystkich agadnień. Pominięto sprawdzenie:

• czy przy tworzeniu nowego obiektu typu tablicowego został podany rozmiar.

kontrola nazw

Kontrola nazw polega na sprawdzeniu, czy nazwy identyfikatorów i etykiet w programie źródłowym są poprawne. Za niepoprawne często uważa się:

• deklaracje dwóch zmiennych o tej samej nazwie w tym samym zakresie widoczności,
• deklaracje dwóch funkcji o tej samej nazwie i tych samych parametrach w tym samym zakresie widoczności,
• użycie niezadeklarowanej zmiennej,
• użycie tej samej nazwy w dwóch kontekstach, np. jako nazwa typu rekordu i nazwa zmiennej (choć wiele kompilatorów ma oddzielne przestrzenie nazw i takie użycie jest uważane za poprawne,
• użycie słowa kluczowego jako identyfikatora,
• deklaracja dwóch etykiet (np. dla goto lub case) o tej samej nazwie, lub brak deklaracji użytej etykiety.

Niektóre języki pozwalają na deklaracje dwóch funkcji o t`ej samej nazwie, ale różnych parametrach lub różnej wartości zwracanej. Taki mechanizm jest zwany przeciążaniem funkcji. W miescu programu, w którym jest wywoływana funkcja kompilator określa na podstawie typów argumentów, którą z funkcji wywołać. Ta decyzja jst też częścią analizy semantycznej.

Część z tych rzeczy, np. podwójne deklaracje, jest sprawdzana jeszcze w fazie tworzenia tablicy symboli.

test wiki

Uzupelnij tytul

a1	b1	c1
a2	b2	c2