Multiple operations with same opcode

[p3t3rix]

Currently multiple ops with the same opcode get generated in cases where an extension gets included in KHR extensions.
Example in autgent_context.rs:
5334u32 => Ok(ops::Op::ReportIntersectionNV
5334u32 => Ok(ops::Op::ReportIntersectionKHR

As just ignoring the issue seems out of question (#235 (comment)), we need a different solution to fix this. As currently this prevents the pipeline to be green.

[MarijnS95]

As just ignoring the issue seems out of question (#235 (comment)) [..] As currently this prevents the pipeline to be green.

To clarify my stance here, the CI being green should imply some form of legitimacy. If we start ignoring sensible errors - even if they may seem rather harmless on the surface - a green CI becomes more and more meaningless in my eyes.

Again these warnings aren't the end of the world and I haven't investigated whether they could really be harmful, they are at least confusing.

For example:

5334u32 => Ok(ops::Op::ReportIntersectionNV
5334u32 => Ok(ops::Op::ReportIntersectionKHR

Picks and returns the NV variant over KHR whereas the NV extensions shouldn't be used anymore since the standardization through KHR.

[MarijnS95]

This was already thought of earlier 😬:

rspirv/autogen/src/sr.rs

Lines 537 to 540 in 4f408eb

	// TODO: filter duplicated symbols mapping to the same discriminator to avoid
	// unreachable patterns.
	#[allow(unreachable_patterns)]
	pub fn lift_op(

(Comment specifically on fn lift_op(), which is the function giving off these warnings)

[msiglreith]

One more occurrence for reference

rspirv/autogen/src/main.rs

Lines 46 to 49 in 4f408eb

	if instruction.opname.starts_with("OpType")
	// Ignore AccelerationStructureNV which has the same opcode as AccelerationStructureKHR
	&& instruction.opname != "OpTypeAccelerationStructureNV"
	{

[MarijnS95]

👍

It's funny because identical warnings are already ignored by clippy::unreachable_patterns, and different ones now show up as clippy::match_overlapping_arm (which is surprisingly not mentioned in the title/commit message).

At the same time some #[allow(clippy::unreachable_patterns)] don't trigger any warnings currently...