Add the types.T.Alias type

[igrvlhlb]

Description

With the purpose of being able to retrieve aliased types in the AST, we've introduced the new Alias type to the types.T namespace.

Since we have the goal of being able to generate a type declaration file from a valid Pallene program, we are now forbidding exported symbols from shadowing each other. It is a measure for improving such files' consistency, so that their types don't mean different things depending on the reading order of the declarations.

Changes summary

Type shadowing prevention

• Added checks to prevent typealiases, records, functions, and module fields from shadowing each other’s names. The typechecker now raises descriptive errors when such shadowing occurs, and new tests have been added to verify these rules (spec/typechecker_spec.lua). [1] [2] [3]
• Refactored type symbol export logic in Typechecker to use a new export_type_symbol method and a unified check_exported_symbol_shadowing function for consistent error handling. [1] [2] [3]

Type alias expansion and comparison

• Updated the typechecker to consistently resolve and expand type aliases when checking types (e.g., in conditions, for-loops, function calls, and variable indexing), ensuring correct type comparisons and error messages. [1] [2] [3] [4] [5] [6] [7] [8]
• Added new tests to verify that type aliases are correctly expanded and compared for equality and consistency, including recursive expansion. (spec/types_spec.lua) [1] [2]

IR conversion and code generation

• Modified IR conversion to expand type aliases before processing, ensuring the IR operates on fully-resolved types. (src/pallene/to_ir.lua)
• Minor cleanup in code generation for for-loops, removing unnecessary blank lines. (src/pallene/coder.lua)

[hugomg]

Oi!, você pode por favor fazer o rebase dessa branch, pra cima do master?

[igrvlhlb]

Olá! Sim. Assim que fizer, te aviso por aqui.

[igrvlhlb]

@hugomg feito o rebase

[hugomg]

Muito bom, agradeço pelos links no texto da PR, que ajudaram bastante. A única parte que achei um pouco esquisita foi a metatabela ACTUAL_NOMINAL_MT. Talvez não precise dessa mágica toda. Algumas dessas alternativas seria viável?

1. Fazer o par ser uma tabela com campos actual e nominal em vez de campos 1 e 2.
2. Criar um par de funções comuns get_actual_type(par) e get_nominal_type(par).

[hugomg]

Reparei aqui que os testes não tinham rodado pois eu não tinha apertado o botão de "aprovar o workflow".
Você conseguiu rodar o CI no seu fork do antes de abrir a PR? Se achar que facilitará as coisas no futuro, eu ofereço que você pode trabalhar num branch desse repo em vez de em um fork.

[igrvlhlb]

Muito bom, agradeço pelos links no texto da PR, que ajudaram bastante. A única parte que achei um pouco esquisita foi a metatabela ACTUAL_NOMINAL_MT. Talvez não precise dessa mágica toda. Algumas dessas alternativas seria viável?

1. Fazer o par ser uma tabela com  campos `actual` e  `nominal` em vez de campos `1` e `2`.

2. Criar um par de funções comuns `get_actual_type(par)` e `get_nominal_type(par)`.

Com certeza! Essa implementação realmente se tornou residual. De início achei que seria útil ter a possibilidade da destruturação desse par, mas na prática (no outro PR no qual trabalhei, que faz uso dos Alias) acabou se mostrando muito mais intuitivo/prático realizar o acesso com .actual e .nominal ao invés do table.unpack() na maior parte das vezes.

Sendo assim, acredito que seja boa ideia seguir pela alternativa (1)

[igrvlhlb]

Reparei aqui que os testes não tinham rodado pois eu não tinha apertado o botão de "aprovar o workflow". Você conseguiu rodar o CI no seu fork do antes de abrir a PR? Se achar que facilitará as coisas no futuro, eu ofereço que você pode trabalhar num branch desse repo em vez de em um fork.

Não consegui rodar o CI, mas executei as verificações manualmente. O único detalhe é que foi necessário configurar o padrão da linguagem C para conseguir rodar os testes de forma bem-sucedida

EXTRACFLAGS="-std=c11" ./run-tests

pois o compilador estava se queixando da redefinição do CallInfo:

/usr/local/include/luacore.h:2386:25: error: redefinition of typedef 'CallInfo' is a C11 feature [-Werror,-Wtypedef-redefinition]
 2386 | typedef struct CallInfo CallInfo;
      |                         ^
/usr/local/include/luacore.h:3:25: note: previous definition is here
    3 | typedef struct CallInfo CallInfo;
      |                         ^

A propósito, o compilador C por padrão na minha máquina é o clang. Talvez o GCC não tenha a mesma reclamação.

---

Se achar que facilitará as coisas no futuro, eu ofereço que você pode trabalhar num branch desse repo em vez de em um fork.

Acho válido!

[hugomg]

Oi Igor, você pode fazer o merge?

Eu também poderia, mas acho que é uma boa oportunidade pra testar se suas permissões de escrita estão funcionando.