@typeInfo should return declarations in declaration order

[andrewrk]

Currently @typeInfo returns declarations in hash map order, which leaks nondeterminism into builds. It also prevents declarations from being used as data. E.g. here:

zig/lib/std/target/riscv.zig

Lines 71 to 120 in 5e37fc0

	pub const cpu = struct {
	pub const baseline_rv32 = Cpu{
	.name = "baseline_rv32",
	.llvm_name = "generic-rv32",
	.features = featureSet(&[_]Feature{
	.a,
	.c,
	.d,
	.f,
	.m,
	}),
	};
	pub const baseline_rv64 = Cpu{
	.name = "baseline_rv64",
	.llvm_name = "generic-rv64",
	.features = featureSet(&[_]Feature{
	.@"64bit",
	.a,
	.c,
	.d,
	.f,
	.m,
	}),
	};
	pub const generic_rv32 = Cpu{
	.name = "generic_rv32",
	.llvm_name = "generic-rv32",
	.features = featureSet(&[_]Feature{}),
	};
	pub const generic_rv64 = Cpu{
	.name = "generic_rv64",
	.llvm_name = "generic-rv64",
	.features = featureSet(&[_]Feature{
	.@"64bit",
	}),
	};
	};
	/// All riscv CPUs, sorted alphabetically by name.
	/// TODO: Replace this with usage of `std.meta.declList`. It does work, but stage1
	/// compiler has inefficient memory and CPU usage, affecting build times.
	pub const all_cpus = &[_]*const Cpu{
	&cpu.baseline_rv32,
	&cpu.baseline_rv64,
	&cpu.generic_rv32,
	&cpu.generic_rv64,
	};

Currently std.meta.declList does a comptime sort. But that should be unnecessary, and in some cases declaration order could be meaningful.

A related proposal is to remove declarations from @typeInfo altogether. I thought I had an open proposal for that, but I can't find it at the moment.

Another related pull request right now is making @typeInfo declarations lazy: #4435

[FireFox317]

Is this a stage 2 thing?

For stage1 we could add a list to next to the decl table, which stores pointers to key,value pairs, however this would increase memory usage and since we are not yet at the 3.5GB max memory usages, that is probably not a good idea.

Another option is to change the decl table to a list, but that would probably slow down the compiler to much, since lookup will change from log(O) to log(N).

[andrewrk]

Is this a stage 2 thing?

Sure, I think it would be reasonable to implement this only in stage 2.