TypeVar and virtual support in Symbol Resolver #99
@ -111,9 +111,7 @@ impl Resolver {
|
||||
// do not handle type var param and concrete check here
|
||||
Ok(Ok((unifier.add_ty(TypeEnum::TTuple { ty: vec![] }), false)))
|
||||
} else if let Some(def_id) = self.pyid_to_def.read().get(&ty_id).cloned() {
|
||||
// println!("getting def");
|
||||
let def = defs[def_id.0].read();
|
||||
|
||||
// println!("got def");
|
||||
if let TopLevelDef::Class {
|
||||
object_id,
|
||||
sb10q
commented
same same
|
||||
type_vars,
|
||||
|
@ -71,7 +71,6 @@ fn main() {
|
||||
assert_eq!(targets.len(), 1, "only support single assignment for now, at {}", targets[0].location);
|
||||
sb10q
commented
Again, is it difficult to iterate? Again, is it difficult to iterate?
|
||||
if let ExprKind::Call { func, args, .. } = &value.node {
|
||||
if matches!(&func.node, ExprKind::Name { id, .. } if id == &"TypeVar".into()) {
|
||||
print!("registering typevar {:?}", targets[0].node);
|
||||
let constraints = args
|
||||
sb10q
commented
Remove print. If we want this sort of debug output we should use the logger crate. Remove print. If we want this sort of debug output we should use the logger crate.
|
||||
.iter()
|
||||
.skip(1)
|
||||
@ -87,14 +86,6 @@ fn main() {
|
||||
})
|
||||
.collect::<Vec<_>>();
|
||||
let res_ty = composer.unifier.get_fresh_var_with_range(&constraints).0;
|
||||
println!(
|
||||
" ...registered: {}",
|
||||
composer.unifier.stringify(
|
||||
res_ty,
|
||||
&mut |x| format!("obj{}", x),
|
||||
&mut |x| format!("tavr{}", x)
|
||||
)
|
||||
);
|
||||
internal_resolver.add_id_type(
|
||||
if let ExprKind::Name { id, .. } = &targets[0].node { *id } else {
|
||||
sb10q
commented
same same
|
||||
panic!("must assign simple name variable as type variable")
|
||||
sb10q
commented
Do not call panic from errors in user code. Proper error message and Python exceptions are required here. Do not call panic from errors in user code. Proper error message and Python exceptions are required here.
ychenfo
commented
Thanks for pointing this out, yes this and the previous issue about iterating over assignment should be resolved. Sorry that I forgot to handle these earlier.. Since this is basically the same place in the code as the default default parameter support (in Thanks for pointing this out, yes this and the previous issue about iterating over assignment should be resolved. Sorry that I forgot to handle these earlier..
Since this is basically the same place in the code as the default default parameter support (in `nac3standalone/src/main.rs`), maybe I will wait for that one to be mereged first and then modify this PR?
sb10q
commented
Other PR merged. Other PR merged.
ychenfo
commented
Hi, the new commits resolves the conflict, and support iteration over multiple typevar assignments in the same line. I will also see if my previous PRs introduce the bug newly found.. Hi, the new commits resolves the conflict, and support iteration over multiple typevar assignments in the same line. I will also see if my previous PRs introduce the bug newly found..
|
||||
|
remove println