M-Labs/nac3
M-Labs
/
nac3
8
0
Fork 10
Code Issues 98 Pull Requests 20 Releases Wiki Activity

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
Conversation 7 Commits 12 Files Changed 8 -11
2 changed files with 0 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files
Showing only changes of commit fe4fbdc5db - Show all commits

2
nac3artiq/src/symbol_resolver.rs
View File

@ -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();
sb10q commented 2021-11-22 13:07:26 +08:00
Outdated
Review
Copy Link

remove println

remove println
// println!("got def");
if let TopLevelDef::Class {
object_id,
sb10q commented 2021-11-22 13:07:31 +08:00
Outdated
Review
Copy Link

same

same
type_vars,

9
nac3standalone/src/main.rs
View File

@ -71,7 +71,6 @@ fn main() {
assert_eq!(targets.len(), 1, "only support single assignment for now, at {}", targets[0].location);
sb10q commented 2021-11-22 17:12:09 +08:00
Outdated
Review
Copy Link

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 2021-11-22 13:09:06 +08:00
Outdated
Review
Copy Link

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 2021-11-22 13:09:26 +08:00
Outdated
Review
Copy Link

same

same
panic!("must assign simple name variable as type variable")
sb10q commented 2021-11-22 17:13:13 +08:00
Outdated
Review
Copy Link

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 2021-11-23 01:09:26 +08:00
Outdated
Review
Copy Link

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?
sb10q commented 2021-11-23 07:33:16 +08:00
Outdated
Review
Copy Link

Other PR merged.

Other PR merged.
ychenfo commented 2021-11-24 18:50:27 +08:00
Outdated
Review
Copy Link

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