c3lang
Error with symbol resolution
Repro
module test(<Type>);
import std::thread;
struct Test {
Mutex mu;
}
module xxx;
import test;
def MyTest = Test(<int>);
fn void! MyTest.test(&self) {
}
fn void! main(String[] args) {
MyTest t;
}
@lerno The changes in sema_analyse_parameterized_identifier broke my build, the compiler hangs on a TYPE_TYPEDEF type for which canonical points to itself.
I was not able to extract a minimal test case so far.
@cbuttner could you try to identify dependencies on conditional types in std and make those dependencies conditional as well??
check the line marked with @if(true) below.
module test(<Type>);
import std::thread;
struct Test {
Mutex mu;
}
module xxx;
import test;
def MyTest = Test(<int>);
fn void! MyTest.test(&self) @if(true) {
}
fn void! main(String[] args) {
MyTest t;
}
So here's what happens:
1 sema_analyse_parameterized_identifier sema_decls.c 4319 0x61cb34dd6375
2 sema_resolve_generic_type sema_types.c 368 0x61cb34e48745
3 sema_resolve_type sema_types.c 415 0x61cb34e48745
4 sema_resolve_type_info sema_types.c 31 0x61cb34e48413
5 sema_analyse_struct_member sema_decls.c 244 0x61cb34de1e33
6 sema_analyse_struct_members sema_decls.c 499 0x61cb34de0ec0
7 sema_analyse_struct_union sema_decls.c 700 0x61cb34dd8fc6
In sema_analyse_parameterized_identifier with the vec_add(unit->global_decls, symbol); codepath the typedef is never analysed, and then immediately afterwards in sema_analyse_struct_member at line 246 type_storage_type is called, which loops forever because canonical wasn't set.
The type in question is Hash_Map
module foo::hash_map(<TKey, TValue>);
import foo::hash_map_impl;
def Hash_Map = Hash_Map_Impl(<TKey, TValue, false>);
def Marking_Hash_Map = Hash_Map_Impl(<TKey, TValue, true>);
module foo::hash_map_impl(<TKey, TValue, MARKING>);
struct Hash_Map_Impl {
// ...
}
Which is used as a struct member in some other module. It works fine for four generic module instatiations before failing on the fifth.
@lerno No, I can't come up with a minimal example where this codepath is hit. But the logical error should be apparent, the type is just not being analysed in time.
In my code line 4319 is in sema_analyse_attribute_decl, which is what I find surprising.
Forgot I added some debugging code, here are the correct line numbers:
1 sema_analyse_parameterized_identifier sema_decls.c 4306 0x59e6cc1f4354
2 sema_resolve_generic_type sema_types.c 368 0x59e6cc266665
3 sema_resolve_type sema_types.c 415 0x59e6cc266665
4 sema_resolve_type_info sema_types.c 31 0x59e6cc266333
5 sema_analyse_struct_member sema_decls.c 244 0x59e6cc1ffd53
6 sema_analyse_struct_members sema_decls.c 499 0x59e6cc1fede0
7 sema_analyse_struct_union sema_decls.c 700 0x59e6cc1f6f46