Verification pass

[emhane]

Defines VerificationPass and VerificationCtx

[Y-Nak]

The overall design intent of this PR is unclear. Specifically, it's not clear how the actual passes will be managed, what granularity of parallelization is being considered, or how flexible you intend the verification pass system to be (e.g., will users be able to inject their own passes?).

Could you provide more details on your design approach so I can better understand your intentions?

[emhane]

The overall design intent of this PR is unclear. Specifically, it's not clear how the actual passes will be managed, what granularity of parallelization is being considered, or how flexible you intend the verification pass system to be (e.g., will users be able to inject their own passes?).

no parallelisation is being considered for starters, aiming to get the base in, and have a very simple verifier working first of all, then add complexity from there as next milestones.

can remove the RwLock around error stack in verification context for now, since parallelisation is out of scope.

Could you provide more details on your design approach so I can better understand your intentions?

the verifier passes will be implemented on a function basis, not module basis, to start with. just like was done for graphviz, which is yet to be implemented on a module basis (should open issue for this).

[Y-Nak]

The main part that makes VerificationCtx complex more than necessary would be PrimaryMap<PassRef, FuncRef>.
I still think this is a misusage of PrimaryMap. If the pass needs to obtain the Function definition, it's enough that the pass takes FuncRef and asks it by calling VerificationCtx::func_data.
Why do you need to define PassRef? I don't see any advantage to using it from the current implementation/design.

[emhane]

The main part that makes VerificationCtx complex more than necessary would be PrimaryMap<PassRef, FuncRef>. I still think this is a misusage of PrimaryMap. If the pass needs to obtain the Function definition, it's enough that the pass takes FuncRef and asks it by calling VerificationCtx::func_data. Why do you need to define PassRef? I don't see any advantage to using it from the current implementation/design.

agreed, I have shrunk the scope to better fit the function-basis passes that I will implement to start with (except FunctionIsNullReference when verifying a call instruction, because it will require the module)

sonatina/crates/verifier/src/error/kind.rs

Lines 11 to 34 in 5e919c7

	#[derive(Debug, Clone, Copy)]
	pub enum ErrorKind {
	// Function errors
	PhiInEntryBlock(Insn),
	// Block errors
	EmptyBlock(Block),
	TerminatorBeforeEnd(Insn),
	NotEndedByTerminator(Insn),
	InstructionMapMismatched(Insn),
	BranchBrokenLink(Insn),
	// Instruction errors
	ValueIsNullReference(Value),
	BlockIsNullReference(Block),
	FunctionIsNullReference(FuncRef),
	BranchToEntryBlock(Block),
	// SSA form errors
	ValueLeak(Value),
	// Type errors
	InsnArgWrongType(Type),
	InsnResultWrongType(Type),
	CalleeArgWrongType(Type),
	CalleeResultWrongType(Type),
	CompoundTypeIsNullReference(Type),
	}

[emhane]

blocked by #69

[Y-Nak]

@emhane Would you rebase to the master? Sorry for the inconvenience.

[emhane]

@emhane Would you rebase to the master? Sorry for the inconvenience.

done @Y-Nak

[Y-Nak]

LGTM