Feat: Tuple element access (indexing) not implemented

[yuvimittal]

Summary

Tuples are lowered to LLVM literal structs, but there is no visitor for index access (e.g. t[0]). Accessing a struct field in LLVM IR requires extractvalue for constants or getelementptr + load for allocas. Without this, tuples are write-once, read-never constructs.

Additional Information

Code of Conduct

• I agree to follow the Code of Conduct

[JoshuaGlaZ]

@yuvimittal I would like to take this issue, could you assign it to me?

[JoshuaGlaZ]

@yuvimittal I would like to take this issue, could you assign it to me?

[Jaskirat-s7]

@yuvimittal , the LiteralTuple already lowers to an ir.LiteralStructType constant in LLVM IR ->the data is there, but completely inaccessible. The issue explicitly names the two LLVM mechanisms to unlock it: extractvalue for constants and getelementptr + load for allocas. Without a visitor for SubscriptExpr on tuple operands, tuples are write-once, read-never.

The key constraint LLVM imposes is that struct field indices must be constants — unlike arrays, you cannot use a runtime variable to index into a struct. This shaped the entire design:

1.a Constant tuple + constant index → pure compile-time extraction (.constant[idx] directly from the ir.Constant Python object). zero IR overhead and the result is just another constant. This is the primary use case and what extractvalue reduces to when all operands are known at compile time.

2.non-constant index → explicit TypeError with a clear message. Not a limitation we're hiding — it's a fundamental LLVM struct constraint. A struct is not an array.

3.Out-of-bounds index → explicit IndexError at IR generation time rather than silent undefined behavior.

We reuse SubscriptExpr (the same ASTx node used for dict and list indexing) rather than introducing a new AST node, since the issue is purely a visitor gap ->the representation and the node both already exist.

[Jaskirat-s7]

Added visit(SubscriptExpr) to LLVMLiteIRVisitor-> the missing visitor that makes t[0] work on a LiteralTuple.

tests/test_literal_tuple.py
Added 4 new tests:

test_tuple_index_first_element->(10, 20)[0]→ constant 10
test_tuple_index_second_element ->(10, 20)[1]→ constant 20
test_tuple_index_out_of_bounds->(10, 20)[5]→ IndexError
test_tuple_index_variable_rejected->t[identifier] → TypeError
All 7 tests pass (3 existing + 4 new). Lint clean (ruff + douki).

[Jaskirat-s7]

@yuvimittal ,happy to open a PR!

[Jaskirat-s7]

@yuvimittal , can you please assign this issue to me as i have done quite a progressive work for this issue!