TypeVar and virtual support in Symbol Resolver #99

Merged
sb10q merged 12 commits from symbol_resolver_typevar into master 2021-12-01 22:44:53 +08:00
2 changed files with 0 additions and 11 deletions
Showing only changes of commit fe4fbdc5db - Show all commits

View File

@ -111,9 +111,7 @@ impl Resolver {
// do not handle type var param and concrete check here // do not handle type var param and concrete check here
Ok(Ok((unifier.add_ty(TypeEnum::TTuple { ty: vec![] }), false))) 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() { } 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(); let def = defs[def_id.0].read();
Outdated
Review

remove println

remove println
// println!("got def");
if let TopLevelDef::Class { if let TopLevelDef::Class {
object_id, object_id,
Outdated
Review

same

same
type_vars, type_vars,

View File

@ -71,7 +71,6 @@ fn main() {
assert_eq!(targets.len(), 1, "only support single assignment for now, at {}", targets[0].location); assert_eq!(targets.len(), 1, "only support single assignment for now, at {}", targets[0].location);
Outdated
Review

Again, is it difficult to iterate?

Again, is it difficult to iterate?
if let ExprKind::Call { func, args, .. } = &value.node { if let ExprKind::Call { func, args, .. } = &value.node {
if matches!(&func.node, ExprKind::Name { id, .. } if id == &"TypeVar".into()) { if matches!(&func.node, ExprKind::Name { id, .. } if id == &"TypeVar".into()) {
print!("registering typevar {:?}", targets[0].node);
let constraints = args let constraints = args
Outdated
Review

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() .iter()
.skip(1) .skip(1)
@ -87,14 +86,6 @@ fn main() {
}) })
.collect::<Vec<_>>(); .collect::<Vec<_>>();
let res_ty = composer.unifier.get_fresh_var_with_range(&constraints).0; 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( internal_resolver.add_id_type(
if let ExprKind::Name { id, .. } = &targets[0].node { *id } else { if let ExprKind::Name { id, .. } = &targets[0].node { *id } else {
Outdated
Review

same

same
panic!("must assign simple name variable as type variable") panic!("must assign simple name variable as type variable")
Outdated
Review

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.

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?

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?
Outdated
Review

Other PR merged.

Other PR merged.

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..