[video member=pervognsen stream_platform=twitch project=bitwise title="More Order-Independent Declarations" vod_platform=youtube id=4AOnbPDyQXw annotator=Miblo]
[0:08][Recap and set the stage for the day, with a plug of the GitHub commits newly tagged by day and the annotated episode guide][:speech]
[3:45][Review off-stream work on buf__printf(), the Typespec struct and AST_DUP()][:memory :research]
[8:08][Review the current status of order-independent declaration support, with the determination to redo it handling ordering first][:parsing :research]
[13:41][Introduce order_decl() and order_typespec()][:parsing]
[23:52][Introduce order_expr() and order_name()][:parsing]
[31:54][Introduce order_test()][:parsing]
[33:56][:Run it and hit a syntax error][:parsing]
[34:22][Pull out code_decls\[i\] into a variable in order_test()][:parsing]
[35:07][Step in to order_test() and realise that it calls parse_decl() incorrectly][:parsing :run]
[35:29][Make order_test() call init_stream()][:parsing]
[35:44][:Run it to see how it works][:parsing]
[35:55][Make every function that doesn't need an argument take void as an argument][:language]
[37:44][Introduce order_decls()][:parsing]
[40:27][Step into order_decls() to see what's going on][:parsing :run]
[40:41][Make order_decls() call order_name()][:parsing]
[41:04][Step through order_decls()][:parsing :run]
[41:34][Prevent main_test() from calling resolve_test()][:parsing]
[42:15][Step back through order_test()][:parsing :run]
[42:18][Add a variable-based declaration test case in order_test()][:parsing]
[42:29][Step in to order_decl() and inspect the decl][:parsing :run]
[43:18][Add an out-of-order test case in order_test()][:parsing]
[43:25][Step recursively through order_decl() to see what it does][:parsing :run]
[44:42][Add a cyclical declaration test case in order_test()][:parsing]
[44:52][Step through order_decl() to see how it handles it][:parsing :run]
[45:18][Add struct test cases in order_test()][:parsing]
[46:29][Step in to order_decl() to see how it parses our structs][:parsing :run]
[47:02][Introduce sym_builtin() to handle things like "int" in structs][:parsing]
[49:16][:Run it to see how it handles our structs][:parsing :run]
[50:20][Add an out-of-order declared struct member test case][:parsing]
[50:47][:Run it to see how that works][:parsing :run]
[51:09][Review the core of our algorithm, with the determination to handle pointers][:parsing :research]
[56:33][Plan not to detect cycles in the ordering pass][:parsing :speech]
[58:58][Q&A][:speech]
[59:04][@nothings2][@pervognsen What case prevents you from just NOT ordering into pointer decls? If you said I missed it][:parsing]
[59:27][@orcnz29][@pervognsen For order-independent declarations, could you first do a scan through the top level (order-independent) declarations (funcs etc.) registering the names in the symbol table as unresolved, then do a full pass and do the your recursive type resolution as you go? The extra initial scan would only be at the global / top scope so it would / should be quick][:parsing]
[1:00:31][@xanatos387][Is all of this only needed for the C backend, or does it apply for our own codegen as well?][:language :parsing]
[1:02:28][Consider the cases preventing us from not ordering into pointer declarations][:parsing :speech]
[1:04:44][@nothings2][I think you have to do it that way, otherwise there's no way to get 'struct S { T t; }; struct T { S *s;};' to work][:parsing]
[1:05:51][Validate [@nothings2 Sean]'s cases][:parsing :programming :run]
[1:06:46][Consider implementing enum :parsing][:parsing :speech]
[1:08:52][@nothings2][@pervognsen So you're not going to allow 'enum { A,B=X,C }; enum { X,Y=C,Z };'? I think it's possible to resolve it, but it's fine if you don't want to][:parsing]
[1:11:19][Implement enum support, introducing a SymKind enum for all of our sym_*() functions, including a new sym_enum_const(), to use][:parsing]
[1:19:12][Step in to order_decl() to see how enums get handled][:parsing :run]
[1:21:00][Enable order_name() to handle SYM_DECL specially][:parsing]
[1:22:08][:Run it to see that it works][:parsing]
[1:22:10][Add some dependency tests in order_test()][:parsing]
[1:22:30][:Run it to see what happens][:parsing]
[1:24:14][Make order_name() call itself rather than order_decl()][:parsing]
[1:24:43][:Run it and unexpectedly hit a cyclic dependency][:parsing]
[1:25:23][Revert order_name() to call order_decl() for SYM_DECL, and itself only for SYM_ENUM_CONST][:parsing]
[1:26:01][:Run it to see that it actually works[:parsing]]
[1:26:19][Add an out-of-order declared enum test case in order_test()][:parsing]
[1:26:29][:Run it to see that it works as expected][:parsing]
[1:26:38][Mention that the enum stuff will change][:parsing :speech]
[1:27:09][Q&A][:speech]
[1:27:22][@nothings2][@pervognsen Can you put sym_decl() and the preceding function on the screen while you're talking? I was AFK while you did it]
[1:27:58][@twicetimes][@pervognsen Will Ion have variable name shadowing?][:language]
[1:29:17][@nothings2][I'd prefer to call that 'newcap' or something]
[1:29:25][Rename the shadowed cap and n to new_cap and new_n in buf__printf()][:memory]
[1:30:26][@nothings2][@pervognsen If you keep that code you have to assign n back to new_n, or replicate the final lines]
[1:30:29][Revert buf__printf() to use the existing n, only renaming cap to new_cap][:memory]
[1:31:08][A few thoughts on variable shadowing, and taking a step back and approaching problems from other directions][:speech]
[1:36:34][@nothings2][@pervognsen Do you think your programming has changed since you were at RAD?]
[1:38:07][@ezysigh][So, what kinds of things, i.e. what bad habits?]
[1:39:55][That's enough philosophical digressions for one day][:speech]
[/video]
