replace @Type with individual type-creating builtins

[alichraghi]

Closes #10710

I updated zig1.wasm in first commit to ensure the CI is passing. once ready, one of the core team members can handle updating it.

I also didn't add @Array because as @Hejsil pointed out, it can be implemented in a single line of user-land code.

if (sentinel) |sen| [size:sen]T else [size]T

Same goes for @Float. std.meta.Float() is no longer a wrapper of @Type.

[SoundOfScooting]

Although it was not listed in the issue, would it be reasonable to add @Fn as well?

[nitrogenez]

Seems like a good change. I like it. Though, is it necessary to remove @Type altogether? Can't these builtins co-exist? Or is there some deep technical reason they can't?

[linusg]

Though, is it necessary to remove @Type altogether?

"Only one obvious way to do things."

[nitrogenez]

"Only one obvious way to do things."

Oh, yeah. That makes sense. Thanks. Then, I don't see why this change can't be accepted. Seems pretty useful and straightforward.

[tauoverpi]

Does @Struct(..), @Union(..), and @Enum(..) really need to use the Type.{Struct, Union, Enum} types or is this for it being easier to use with the result of @typeInfo(..)?

Each of the fields of those are of different types thus @Struct(.@"extern", fields, .@"struct") would better match what the use is today (I've omitted the .decl field as it's always empty anyway) or just @Struct(.@"extern", fields) and @Tuple(fields) as even if they share syntax and representation in the compiler they aren't the same from the user's view of the language. The same applies to @Union(.@"auto", E, fields)/@Union(.@"extern", null, fields) and @Enum(fields, .sparse)/@Enum(fields, .exhaustive).

It's not possible to pass the wrong type for any of those and if the bools were instead changed to enum it would communicate what the parameters are sufficiently enough not to need the Type.{..} struct.

[mlugg]

Someone asked me about the status of this PR, so just commenting to say that I'm aware of it, and appreciate the effort that went into it -- I'd definitely like to avoid letting this work rot. I'll hopefully get to it soon, but we have some huge changes currently in the pipeline, so the team's all a little busy right now, and it's not a great time to merge big breaking PRs. I'm hoping I'll be able to have a look at this once the reader/writer changes, and codegen pipeline changes, are all in, and everything's settling down a little.

No need to worry about rebasing or anything, I will probably be happy to resolve conflicts when I get around to reviewing this.

One note: I am firmly of the opinion that there should be an @EnumLiteral(), rather than relying on @TypeOf(.enum_literal). That said, I can make that change on top of this PR myself fairly easily when I review it.

By the way, @alichraghi: were the usages of @Type all updated by hand, or did you semi-automate the process? Knowing this will probably help the review process when the time comes.

[alichraghi]

Yeah i figured that this is gonna take long and im fine with handling conflicts myself. was mostly waiting for writergate branch to be merged.

were the usages of @Type all updated by hand, or did you semi-automate the process? Knowing this will probably help the review process when the time comes.

They are updated by hand but it wasn't painful because most new builtins accept the same std.builtin.Type parameters.