Add usize and isize as a primitive type

[Y-Nak]

We don't have usize and isize to represent target-dependent pointer-size, which are useful, especially for

1. Memory Indexing: usize is primarily used for indexing into collections and working with memory sizes.
2. System Compatibility: Both isize and usize provide a means to write code that is portable across systems.

This issue can be split up into several phases.

• Modify the parser to accommodate these types
• Make name resolution handle them properly as a builtin type
• Make type check handle them. These types will affect other built-in types, e.g., array type definition.

[lana-shanghai]

Hey, could I work on this? @Y-Nak

[Y-Nak]

Yes, of course!

[lana-shanghai]

Yes, of course!

Sweet! So this task includes mentoring from you? :) if you have any guidance on how to start with the parser, please share, otherwise I am diving into the codebase for now!

[Y-Nak]

So this task includes mentoring from you?

yep!

if you have any guidance on how to start with the parser

Sorry, I made the wrong description for the issue; you don't need to modify the parser. So, the first step for this issue would be to make the name resolution handle the two types properly.

The concrete steps would be

1. Add usize and isize tohir::hir_def::ident::kw.
2. Modify hir::hir_def::prim_ty to accommodate those two types(IntTy and UintTy are the places where you would need to modify).
3. Modify hir::hir_def::PrimTy::all_types so that it includes the newly added usize and isize in step 2.

[Y-Nak]

For the type checker module, the steps would be

1. Modify hir_analysis::ty::ty_def::PrimTy.
2. Modify impl From<HirPrimty> for TyBase in ty_def module.

In addition to that, you probably need to modify some auxiliary methods like ty_def::PrimTy::is_integral.

Basically, that'd be all necessary things(I might miss something, though).
Please feel free to ask any questions.

[Y-Nak]

Oh, currently, the head of v2 is #1007, which will be merged soon.
Please use that branch as a base.

[Y-Nak]

resolved in #1012