Implements #32046
Deprecates std.meta.fields and std.meta.declarationInfo, adds std.meta.fieldTypes helper
std.lang.Type #35234
Der_Teufel/zig:soa-builtin-type into master Implements #32046
Deprecates std.meta.fields and std.meta.declarationInfo, adds std.meta.fieldTypes helper
std.builtin.Type (削除ここまで)std.lang.Type 642a9eeacd
f1c71a48a6
std.lang.Type (削除ここまで)std.lang.Type (BREAKING!) Thank you for doing this! On the whole, this looks like great work.
I have a couple of review comments suggesting using a function Value.uninterpret in the Sema logic. That suggestion is non-blocking; I mainly just left that comment to make sure you knew about that function, because it can be handy at times!
The other comments I'd appreciate if you could quickly address, and in particular just clarify whether you meant to leave that commented-out block in lib/std/multi_array_list.zig.
Also, would it be possible to rebase this branch? The merge commits made the diff a little tricky to follow. But if the rebase is too confusing (since it looks like it crossed the std.builtin->std.lang migration) that's totally understandable, I can sort it out myself.
Let me know once you've done everything you plan to do and I'll take it from there. I'll clean up the commit history a little, probably do some small simplifications in Sema things, regenerate the zig1.wasm update, and then it should be merge-ready.
Thanks again!
@ -359,3 +270,1 @@
trytesting.expect(comptimesf[0].type==u8);
trytesting.expect(comptimeuf[0].type==u8);
}
pubconstdeclarationInfo=@compileError("Deprecated. Use @hasDecl instead");
/// To be removed after Zig 0.17.0 is tagged.pubconstdeclarationInfo=@compileError("Deprecated; use '@hasDecl' instead");/// To be removed after Zig 0.17.0 is tagged.pubconstfields=@compileError("Deprecated; use 'fieldNames' and 'fieldTypes' instead");
@ -186,3 +176,3 @@
constSelf=@This();
constfields=meta.fields(Elem);
// const fields: struct {
What's the deal with this commented-out logic? Did you mean to delete this?
@ -1079,0 +1080,4 @@
&new_names,
&new_types,
)|elem_field_name,elem_field_type,*new_name,*NewType|{
new_name.*=elem_field_name;
Looks like new_names doesn't need to exist at all, right? Just pass elem_info.field_names into the @Struct call below. So:
constelem_info=@typeInfo(Elem).@"struct";varnew_types:[elem_info.field_types.len]type=undefined;for(&new_types,elem_info.field_types)|*NewType,ElemFieldType|{NewType.*=*[len]ElemFieldType;}if(elem_info.is_tuple){return@Tuple(&new_types);}else{return@Struct(.auto,null,elem_info.field_names,&new_types,&@splat(.{}));}
@ -1097,0 +1104,4 @@
&new_names,
&new_types,
)|elem_field_name,elem_field_type,*new_name,*NewType|{
new_name.*=elem_field_name;
Likewise here.
@ -16141,0 +16182,4 @@
.ty=(trypt.optionalType(addrspace_ty.toIntern())).toIntern(),
.val=switch(info.flags.address_space){
.generic=>.none,
else=>(trypt.enumValueFieldIndex(addrspace_ty,@intFromEnum(info.flags.address_space))).toIntern(),
@typeInfo should never set this field to null! There is always an address space.
Also, consider using Value.uninterpret---something like this:
.val=(Value.uninterpret(info.flags.address_space,addrspace_ty,pt)catch|err|switch(err){error.TypeMismatch=>@panic("std.lang is corrupt"),error.OutOfMemory=>|e|returne,}).toIntern(),uninterpret is a general function for converting between a value known to the compiler implementation, and a comptime-known value in the program being compiled. Using it has a couple of benefits:
std.lang and panic instead of just triggering IBstd.lang (e.g. rearranging AddressSpace fields)@ -16330,0 +16379,4 @@
constenum_mode:Value=trypt.enumValueFieldIndex(enum_mode_ty,@intFromEnum(enum_mode_tag));
constenum_field_name_vals=trysema.arena.alloc(InternPool.Index,enum_obj.field_names.len);
Same deal with Value.uninterpret (by the way, it would be reasonable to make a small wrapper function in Sema which does the catch ... @panic for you, much like the existing Sema.interpretStdLangType for the opposite operation)
@ -16435,0 +16520,4 @@
defergpa.free(union_field_names);
constunion_field_types=trygpa.alloc(InternPool.Index,enum_obj.field_names.len);
defergpa.free(union_field_types);
constunion_field_attrs=trygpa.alloc(InternPool.Index,enum_obj.field_names.len);
This doesn't need to exist, because it's identical to union_obj.field_types.get(ip)! You can just use that slice directly when building field_types_val later. (Same in the .@"struct" case below.)
Thank you for doing this! On the whole, this looks like great work.
I have a couple of review comments suggesting using a function Value.uninterpret in the Sema logic. That suggestion is non-blocking; I mainly just left that comment to make sure you knew about that function, because it can be handy at times!
The other comments I'd appreciate if you could quickly address, and in particular just clarify whether you meant to leave that commented-out block in lib/std/multi_array_list.zig.
Also, would it be possible to rebase this branch? The merge commits made the diff a little tricky to follow. But if the rebase is too confusing (since it looks like it crossed the std.builtin->std.lang migration) that's totally understandable, I can sort it out myself.
Let me know once you've done everything you plan to do and I'll take it from there. I'll clean up the commit history a little, probably do some small simplifications in Sema things, regenerate the zig1.wasm update, and then it should be merge-ready.
Thanks again!
std.lang.Type (BREAKING!) (削除ここまで)std.lang.Type ba1fb36bd8
854cdf8dbf
854cdf8dbf
9973677295
9973677295
1263a46241
1263a46241
a80562b5cf
I've rebased and simplified things in Sema as suggested (Value.uninterpret is wonderful), the commented block in multi_array_list was just a leftover piece of transition code that I forgot to delete. It's ready for second review @mlugg
a80562b5cf
47678a4b29
47678a4b29
9e80795623
Final push done, thanks @Der_Teufel! Once this passes CI it'll be good to merge.
Release notes please!
@mlugg do you want to handle the release notes, since you've written the proposal thoroughly ?
Yep, sure thing! I'll write some up at some point (probably when we make the tag since that is likely soon-ish).
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?