[Test] Bit Düzeyi (Bitwise) İşlemler — &, |, ^, ~, <<, >> #101

New Issue

saqut · 2026-06-14T22:26:27+03:00

saqut commented

2026-06-14 22:26:27 +03:00

Giriş (Nedir, Neden Önemli?)

Tokenizer'da &, |, ^, ~, <<, >> token'ları zaten tanımlı (src/tokenizer/tokenizer.hpp). Ama bu operatörlerin Pratt parser'da doğru öncelik ile ayrıştırıldığı ve tip denetiminde (Faz 3, sadece int üzerinde tanımlı) doğru ele alındığı henüz doğrulanmadı. Bu issue, "karmaşık bit işlemleri" için bir golden-test taslağıdır.

Test Kodu (`examples/tests/bit_islemleri.sqt`)

int main() {
    int a = 12;   // 0b1100
    int b = 10;   // 0b1010

    print(a & b);    // bitwise AND
    print(a | b);    // bitwise OR
    print(a ^ b);    // bitwise XOR
    print(~a);       // bitwise NOT (iki's complement)
    print(a << 2);   // sola kaydır
    print(a >> 2);   // sağa kaydır

    // Operatör önceliği: << ve >>, + ve - 'dan düşük öncelikli olmalı (C kuralı)
    print(1 << 2 + 1);   // (2+1)=3 -> 1 << 3 = 8, yoksa (1<<2)+1=5 olur
    print(a & b | b);    // & , | 'dan önce: (a&b) | b = 8 | 10 = 10
    return 0;
}

Beklenen Çıktı

Açık Sorular / Bağlı Fazlar

~a için -13 beklentisi, int'in iki's complement (ikiye tümleyen) imzalı 32-bit temsiline dayanır — bu, src/core/type.hpp'de int'in tam temsilinin (bit genişliği) şimdiden dokümante edilmesini gerektirir (Faz 0'a not).
1 << 2 + 1 örneği kasıtlı olarak kafa karıştırıcı — C'de <</>> aritmetik operatörlerden (+/-) daha düşük önceliklidir. saQut Pratt parser'ı bu sırayı C ile aynı mı tutacak, yoksa daha "şaşırtmasız" bir öncelik mi tanımlayacak? Karar ne olursa olsun docs'a yazılmalı, çünkü bu tip kararlar "sessiz" kalırsa en çok şikayet edilen bug kaynağı olur.
Bu operatörler sadece int için tanımlı olmalı; bool & bool veya float << 1 gibi kullanımlar E003 üretmeli (Faz 3'e not).

İmza/Yorum: "Karmaşık byte işlemleri" testi olarak istenen tam da bu — bit-manipülasyonu doğru çalışmayan bir derleyici, gerçek programlar (hash, sıkıştırma, bayrak/flag kümeleri) için kullanılamaz hale gelir.

### Giriş (Nedir, Neden Önemli?) Tokenizer'da `&`, `|`, `^`, `~`, `<<`, `>>` token'ları zaten tanımlı (`src/tokenizer/tokenizer.hpp`). Ama bu operatörlerin **Pratt parser'da doğru öncelik** ile ayrıştırıldığı ve **tip denetiminde** (Faz 3, sadece `int` üzerinde tanımlı) doğru ele alındığı henüz doğrulanmadı. Bu issue, "karmaşık bit işlemleri" için bir golden-test taslağıdır. --- ### Test Kodu (`examples/tests/bit_islemleri.sqt`) ```c int main() { int a = 12; // 0b1100 int b = 10; // 0b1010 print(a & b); // bitwise AND print(a | b); // bitwise OR print(a ^ b); // bitwise XOR print(~a); // bitwise NOT (iki's complement) print(a << 2); // sola kaydır print(a >> 2); // sağa kaydır // Operatör önceliği: << ve >>, + ve - 'dan düşük öncelikli olmalı (C kuralı) print(1 << 2 + 1); // (2+1)=3 -> 1 << 3 = 8, yoksa (1<<2)+1=5 olur print(a & b | b); // & , | 'dan önce: (a&b) | b = 8 | 10 = 10 return 0; } ``` ### Beklenen Çıktı ``` 8 14 6 -13 48 3 8 10 ``` --- ### Açık Sorular / Bağlı Fazlar - `~a` için `-13` beklentisi, `int`'in **iki's complement (ikiye tümleyen) imzalı 32-bit** temsiline dayanır — bu, `src/core/type.hpp`'de `int`'in tam temsilinin (bit genişliği) **şimdiden** dokümante edilmesini gerektirir (Faz 0'a not). - `1 << 2 + 1` örneği **kasıtlı olarak kafa karıştırıcı** — C'de `<<`/`>>` aritmetik operatörlerden (`+`/`-`) daha düşük önceliklidir. saQut Pratt parser'ı bu sırayı C ile aynı mı tutacak, yoksa daha "şaşırtmasız" bir öncelik mi tanımlayacak? **Karar ne olursa olsun docs'a yazılmalı**, çünkü bu tip kararlar "sessiz" kalırsa en çok şikayet edilen bug kaynağı olur. - Bu operatörler sadece `int` için tanımlı olmalı; `bool & bool` veya `float << 1` gibi kullanımlar `E003` üretmeli (Faz 3'e not). *İmza/Yorum:* "Karmaşık byte işlemleri" testi olarak istenen tam da bu — bit-manipülasyonu doğru çalışmayan bir derleyici, gerçek programlar (hash, sıkıştırma, bayrak/flag kümeleri) için kullanılamaz hale gelir.

saqut added the

test-senaryosu

label 2026-06-14 22:26:27 +03:00

Sign in to join this conversation.