Constant Default Parameter Support #98

Merged
sb10q merged 7 commits from default_parameter into master 2021-11-23 07:32:09 +08:00
10 changed files with 188 additions and 55 deletions
Showing only changes of commit 6397e42e74 - Show all commits

View File

@ -2,7 +2,7 @@ use inkwell::{types::BasicType, values::BasicValueEnum, AddressSpace};
use nac3core::{ use nac3core::{
codegen::CodeGenContext, codegen::CodeGenContext,
location::Location, location::Location,
symbol_resolver::SymbolResolver, symbol_resolver::{SymbolResolver, SymbolValue},
toplevel::{DefinitionId, TopLevelDef}, toplevel::{DefinitionId, TopLevelDef},
typecheck::{ typecheck::{
type_inferencer::PrimitiveStore, type_inferencer::PrimitiveStore,
@ -14,7 +14,7 @@ use pyo3::{
types::{PyList, PyModule, PyTuple}, types::{PyList, PyModule, PyTuple},
PyAny, PyObject, PyResult, Python, PyAny, PyObject, PyResult, Python,
}; };
use nac3parser::ast::StrRef; use nac3parser::ast::{self, StrRef};
use std::{ use std::{
cell::RefCell, cell::RefCell,
collections::{HashMap, HashSet}, collections::{HashMap, HashSet},
@ -399,9 +399,86 @@ impl Resolver {
} }
} }
} }
fn get_default_param_obj_value(&self, obj: &PyAny, helper: &PythonHelper) -> PyResult<Result<SymbolValue, String>> {
let ty_id: u64 = helper
.id_fn
.call1((helper.type_fn.call1((obj,))?,))?
.extract()?;
Ok(
if ty_id == self.primitive_ids.int || ty_id == self.primitive_ids.int32 {
let val: i32 = obj.extract()?;
Ok(SymbolValue::I32(val))
} else if ty_id == self.primitive_ids.int64 {
let val: i64 = obj.extract()?;
Ok(SymbolValue::I64(val))
} else if ty_id == self.primitive_ids.bool {
let val: bool = obj.extract()?;
Ok(SymbolValue::Bool(val))
} else if ty_id == self.primitive_ids.float {
let val: f64 = obj.extract()?;
Ok(SymbolValue::Double(val))
} else if ty_id == self.primitive_ids.tuple {
let elements: &PyTuple = obj.cast_as()?;
let elements: Result<Result<Vec<_>, String>, _> = elements
.iter()
.map(|elem| {
self.get_default_param_obj_value(
elem,
helper
)
})
.collect();
let elements = match elements? {
Ok(el) => el,
Err(err) => return Ok(Err(err))
};
Ok(SymbolValue::Tuple(elements))
} else {
Err("only primitives values and tuple can be default parameter value".into())
}
)
}
} }
impl SymbolResolver for Resolver { impl SymbolResolver for Resolver {
fn get_default_param_value(
&self,
expr: &ast::Expr
) -> Option<SymbolValue> {
match &expr.node {
ast::ExprKind::Name { id, .. } => {
Python::with_gil(
|py| -> PyResult<Option<SymbolValue>> {
let obj: &PyAny = self.module.extract(py)?;
let members: &PyList = PyModule::import(py, "inspect")?
.getattr("getmembers")?
.call1((obj,))?
.cast_as()?;
let mut sym_value = None;
for member in members.iter() {
let key: &str = member.get_item(0)?.extract()?;
let val = member.get_item(1)?;
if key == id.to_string() {
let builtins = PyModule::import(py, "builtins")?;
let helper = PythonHelper {
id_fn: builtins.getattr("id").unwrap(),
len_fn: builtins.getattr("len").unwrap(),
type_fn: builtins.getattr("type").unwrap(),
};
sym_value = Some(self.get_default_param_obj_value(val, &helper).unwrap().unwrap());
break;
}
}
Ok(sym_value)
}
)
.unwrap()
}
_ => unimplemented!("other type of expr not supported at {}", expr.location)
}
}
fn get_symbol_type( fn get_symbol_type(
&self, &self,
unifier: &mut Unifier, unifier: &mut Unifier,

View File

@ -37,6 +37,10 @@ impl Resolver {
} }
impl SymbolResolver for Resolver { impl SymbolResolver for Resolver {
fn get_default_param_value(&self, _: &nac3parser::ast::Expr) -> Option<crate::symbol_resolver::SymbolValue> {
unimplemented!()
}
fn get_symbol_type( fn get_symbol_type(
&self, &self,
_: &mut Unifier, _: &mut Unifier,

View File

@ -44,6 +44,7 @@ pub trait SymbolResolver {
ctx: &mut CodeGenContext<'ctx, 'a>, ctx: &mut CodeGenContext<'ctx, 'a>,
) -> Option<BasicValueEnum<'ctx>>; ) -> Option<BasicValueEnum<'ctx>>;
fn get_symbol_location(&self, str: StrRef) -> Option<Location>; fn get_symbol_location(&self, str: StrRef) -> Option<Location>;
fn get_default_param_value(&self, expr: &nac3parser::ast::Expr) -> Option<SymbolValue>;
// handle function call etc. // handle function call etc.
} }

View File

@ -1136,7 +1136,7 @@ impl TopLevelComposer {
default_value: match default { default_value: match default {
None => None, None => None,
Some(default) => Some(default) =>
Some(Self::parse_parameter_default_value(default)?) Some(Self::parse_parameter_default_value(default, resolver)?)
} }
}) })
}) })
@ -1353,7 +1353,7 @@ impl TopLevelComposer {
if name == "self".into() { if name == "self".into() {
Outdated
Review

Technically CPython lets you name self whatever you want, it's only a convention.
So this test should be "the function is a method and we are looking at its first parameter".

Technically CPython lets you name ``self`` whatever you want, it's only a convention. So this test should be "the function is a method and we are looking at its first parameter".

Would it be acceptable that in nac3, we just enforce and document that the self should always be self and should not be named arbitrarily? As I think this would not cause very big problems and our existing nac3 codebase is already doing this (e.g., here, here, and here)

Would it be acceptable that in nac3, we just enforce and document that the `self` should always be `self` and should not be named arbitrarily? As I think this would not cause very big problems and our existing nac3 codebase is already doing this (e.g., [here](https://git.m-labs.hk/M-Labs/nac3/src/branch/master/nac3core/src/codegen/expr.rs#L293), [here](https://git.m-labs.hk/M-Labs/nac3/src/branch/master/nac3core/src/codegen/expr.rs#L348), and [here](https://github.com/m-labs/artiq/blob/nac3/artiq/language/core.py#L56))
Outdated
Review

It is acceptable but not super clean - is it difficult to use the condition I proposed instead?

https://github.com/m-labs/artiq/blob/nac3/artiq/language/core.py#L56 is unavoidable without a lot of code (AFAICT) because CPython does not tell you if something is a method until it is bound, but inside NAC3 we have more information.

It is acceptable but not super clean - is it difficult to use the condition I proposed instead? https://github.com/m-labs/artiq/blob/nac3/artiq/language/core.py#L56 is unavoidable without a lot of code (AFAICT) because CPython does not tell you if something is a method until it is bound, but inside NAC3 we have more information.
return Err(format!("`self` parameter cannot take default value at {}", x.location)); return Err(format!("`self` parameter cannot take default value at {}", x.location));
} }
Some(Self::parse_parameter_default_value(default)?) Some(Self::parse_parameter_default_value(default, class_resolver)?)
} }
} }
}; };

View File

@ -347,51 +347,64 @@ impl TopLevelComposer {
Ok(result) Ok(result)
} }
pub fn parse_parameter_default_value(default: &ast::Expr) -> Result<SymbolValue, String> { pub fn parse_parameter_default_value(default: &ast::Expr, resolver: &(dyn SymbolResolver + Send + Sync)) -> Result<SymbolValue, String> {
fn handle_constant(val: &Constant, loc: &Location) -> Result<SymbolValue, String> { parse_parameter_default_value(default, resolver)
match val { }
Constant::Int(v) => { }
if let Ok(v) = v.try_into() {
Ok(SymbolValue::I32(v)) pub fn parse_parameter_default_value(default: &ast::Expr, resolver: &(dyn SymbolResolver + Send + Sync)) -> Result<SymbolValue, String> {
} else { fn handle_constant(val: &Constant, loc: &Location) -> Result<SymbolValue, String> {
Err(format!( match val {
ychenfo marked this conversation as resolved Outdated

Should we just accept int32? int64 is handled in the call part, e.g. int64(1234).

Should we just accept int32? int64 is handled in the call part, e.g. `int64(1234)`.

this is handled in the new commit below

this is handled in the new commit below
"int64 default parameter should be specified explicitly by `int64()` at {}", Constant::Int(v) => {
ychenfo marked this conversation as resolved Outdated
Outdated
Review

Isn't that an internal compiler error if this code is executed, not a problem with the user code?
Using unreachable!() sounds more appropriate here.

Isn't that an internal compiler error if this code is executed, not a problem with the user code? Using ``unreachable!()`` sounds more appropriate here.
Outdated
Review

Isn't that an internal compiler error if this code is executed, not a problem with the user code?
Using unreachable!() sounds more appropriate here.

Isn't that an internal compiler error if this code is executed, not a problem with the user code? Using ``unreachable!()`` sounds more appropriate here.

No I don't think so? It is possible for users to specify some default value outside the range of int64. I think a more appropriate error message would be value out of range and only say int64 if the value is really an int64?

No I don't think so? It is possible for users to specify some default value outside the range of int64. I think a more appropriate error message would be value out of range and only say `int64` if the value is really an int64?
Outdated
Review

OK, yes.

OK, yes.

Thanks, this error message is updated in the new commit

Thanks, this error message is updated in the new commit
loc if let Ok(v) = v.try_into() {
)) Ok(SymbolValue::I32(v))
} } else {
} Err(format!(
Constant::Float(v) => Ok(SymbolValue::Double(*v)), "int64 default parameter should be specified explicitly by `int64()` at {}",
Constant::Bool(v) => Ok(SymbolValue::Bool(*v)), loc
Constant::Tuple(tuple) => Ok(SymbolValue::Tuple( ))
tuple.iter().map(|x| handle_constant(x, loc)).collect::<Result<Vec<_>, _>>()? }
)), }
_ => unimplemented!("this constant is not supported at {}", loc), Constant::Float(v) => Ok(SymbolValue::Double(*v)),
} Constant::Bool(v) => Ok(SymbolValue::Bool(*v)),
} Constant::Tuple(tuple) => Ok(SymbolValue::Tuple(
match &default.node { tuple.iter().map(|x| handle_constant(x, loc)).collect::<Result<Vec<_>, _>>()?
ast::ExprKind::Constant { value, .. } => handle_constant(value, &default.location), )),
ast::ExprKind::Call { func, args, .. } if { _ => unimplemented!("this constant is not supported at {}", loc),
match &func.node { }
ast::ExprKind::Name { id, .. } => *id == "int64".into(), }
Outdated
Review

Aren't we matching on id(numpy.int64) elsewhere?
https://git.m-labs.hk/M-Labs/nac3/src/branch/master/nac3artiq/src/lib.rs#L270-L306
I'm fine with string matches since they're simpler and potentially faster, but we should do things consistently.

Aren't we matching on ``id(numpy.int64)`` elsewhere? https://git.m-labs.hk/M-Labs/nac3/src/branch/master/nac3artiq/src/lib.rs#L270-L306 I'm fine with string matches since they're simpler and potentially faster, but we should do things consistently.

I think here we are handling default parameters in nac3core so we do not really know the id(numpy.int64)?

In type inference module we also do things using strings matches here and here. So I think it is ok to use strings? Or did I miss anything?

I think here we are handling default parameters in nac3core so we do not really know the `id(numpy.int64)`? In type inference module we also do things using strings matches [here](https://git.m-labs.hk/M-Labs/nac3/src/branch/master/nac3core/src/typecheck/type_inferencer/mod.rs#L659) and [here](https://git.m-labs.hk/M-Labs/nac3/src/branch/master/nac3core/src/typecheck/type_inferencer/mod.rs#L624). So I think it is ok to use strings? Or did I miss anything?

Aren't we matching on id(numpy.int64) elsewhere?
https://git.m-labs.hk/M-Labs/nac3/src/branch/master/nac3artiq/src/lib.rs#L270-L306
I'm fine with string matches since they're simpler and potentially faster, but we should do things consistently.

That is matching on the value type, not about functions.

> Aren't we matching on `id(numpy.int64)` elsewhere? https://git.m-labs.hk/M-Labs/nac3/src/branch/master/nac3artiq/src/lib.rs#L270-L306 I'm fine with string matches since they're simpler and potentially faster, but we should do things consistently. That is matching on the value type, not about functions.
Outdated
Review

What's the difference? There isn't one in CPython.
Also this can cause issues e.g. if the user types from numpy import int64 as i64. CPython and nac3artiq will expect i64, whereas nac3core will expect int64.
If that's the simplest thing to do, I'm fine having restrictions such as "numpy types must be imported as their reserved NAC3 keywords int64/int32/..." but they should be documented and enforced by the compiler.

What's the difference? There isn't one in CPython. Also this can cause issues e.g. if the user types ``from numpy import int64 as i64``. CPython and nac3artiq will expect ``i64``, whereas nac3core will expect ``int64``. If that's the simplest thing to do, I'm fine having restrictions such as "numpy types must be imported as their reserved NAC3 keywords int64/int32/..." but they should be documented and enforced by the compiler.
Outdated
Review

Anyway this isn't the most pressing issue at the moment and we can do this inconsistent string/id match for now. Let's continue this discussion in #105

Anyway this isn't the most pressing issue at the moment and we can do this inconsistent string/id match for now. Let's continue this discussion in https://git.m-labs.hk/M-Labs/nac3/issues/105
_ => false, match &default.node {
} ast::ExprKind::Constant { value, .. } => handle_constant(value, &default.location),
} => { ast::ExprKind::Call { func, args, .. } if {
if args.len() == 1 { match &func.node {
match &args[0].node { ast::ExprKind::Name { id, .. } => *id == "int64".into(),
ast::ExprKind::Constant { value: Constant::Int(v), .. } => _ => false,
Ok(SymbolValue::I64(v.try_into().unwrap())), }
_ => Err(format!("only allow constant integer here at {}", default.location)) } => {
} if args.len() == 1 {
} else { match &args[0].node {
Err(format!("only allow constant integer here at {}", default.location)) ast::ExprKind::Constant { value: Constant::Int(v), .. } =>
} Ok(SymbolValue::I64(v.try_into().unwrap())),
} _ => Err(format!("only allow constant integer here at {}", default.location))
ast::ExprKind::Tuple { elts, .. } => Ok(SymbolValue::Tuple(elts }
Outdated
Review

Lists should also be supported (also if they are a module global, see comment below).

Lists should also be supported (also if they are a module global, see comment below).

Lists are not immutable, I think we discussed this previously?

M-Labs/nac3-spec#6

Function parameter defaults for kernel, portable, and rpc functions are very important for us. The limitation of only allowing immutable or primitive default types is fine.

Lists are not immutable, I think we discussed this previously? https://git.m-labs.hk/M-Labs/nac3-spec/issues/6 > Function parameter defaults for kernel, portable, and rpc functions are very important for us. The limitation of only allowing immutable or primitive default types is fine.
Outdated
Review

Indeed, and that's a well-known pitfall in CPython as well.
ARTIQ drivers do use lists with default parameter. AFAICT this can be changed to tuple, so far...

Indeed, and that's a well-known pitfall in CPython as well. ARTIQ drivers do use lists with default parameter. AFAICT this can be changed to tuple, so far...
Outdated
Review

Well we can start with tuples only for now and see if that causes any serious problems.

Well we can start with tuples only for now and see if that causes any serious problems.
.iter() } else {
.map(|x| Self::parse_parameter_default_value(x)) Err(format!("only allow constant integer here at {}", default.location))
.collect::<Result<Vec<_>, _>>()? }
)), }
Outdated
Review

We also want to support globals defined in the module, e.g.:

FOO = 1234

class XXX:
   def yyy(self, z: int32 = FOO):
      ...

See the ARTIQ drivers, this is used in many places.

We also want to support globals defined in the module, e.g.: ```python FOO = 1234 class XXX: def yyy(self, z: int32 = FOO): ... ``` See the ARTIQ drivers, this is used in many places.
Outdated
Review

In fact, why not just compile the expression like any other?
Things like def foo(x=[i*2 for i in range(3)]) are also valid Python.

In fact, why not just compile the expression like any other? Things like ``def foo(x=[i*2 for i in range(3)])`` are also valid Python.

The expression should be immutable and primitive types/tuples. I think we can eval() the expression and set the default value if its type can be accepted.

The expression should be immutable and primitive types/tuples. I think we can `eval()` the expression and set the default value if its type can be accepted.
Outdated
Review

eval is slow and not available in nac3standalone.

``eval`` is slow and not available in nac3standalone.

Regarding performance issue, I think we can optimize it later if it is really that slow. For nac3standalone, I think we can support simple cases first and leave this later, I don't think this is of high priority?

Regarding performance issue, I think we can optimize it later if it is really that slow. For nac3standalone, I think we can support simple cases first and leave this later, I don't think this is of high priority?
Outdated
Review

Well the only thing we really need is module globals. If that can be done then something like the current code seems fine.

Well the only thing we really need is module globals. If that can be done then something like the current code seems fine.

Ok I will add module globals support on top of the current constant support

Ok I will add module globals support on top of the current constant support

Sorry, still one thing not very clear about this...

To handle complex expressions(calling eval for now? Also, expressions like Module.T which refers to things defined in another module imported) as default value, should we add a function in symbol resolver, which accepts a ast::Expr and return a SymbolValue?

Sorry, still one thing not very clear about this... To handle complex expressions(calling `eval` for now? Also, expressions like `Module.T` which refers to things defined in another module imported) as default value, should we add a function in symbol resolver, which accepts a `ast::Expr` and return a `SymbolValue`?
Outdated
Review

Let's not call eval and let's keep the more restricted approach. Keep the current mechanism and simply add support for being able to use globals e.g.:

FOO = 1234

class XXX:
   def yyy(self, z: int32 = FOO):
      ...
Let's not call ``eval`` and let's keep the more restricted approach. Keep the current mechanism and simply add support for being able to use globals e.g.: ```python FOO = 1234 class XXX: def yyy(self, z: int32 = FOO): ... ```

I have added the basic module primitive/tuple global default parameter in the new commit.

No eval is used, only simple variable name is supported, but still involve some changes in symbol resolver(adding a function in symbol resolver which accepts a ast::Expr and return a SymbolValue). If I do not miss anything, I do not think there is another way to workaround this without changing symbol resolver... since in nac3artiq the core compiler does not know anything about the module globals if symbol resolver does not provide any information to it. Please have a review, thanks!

I have added the basic module primitive/tuple global default parameter in the new commit. No `eval` is used, only simple variable name is supported, but still involve some changes in symbol resolver(adding a function in symbol resolver which accepts a `ast::Expr` and return a `SymbolValue`). If I do not miss anything, I do not think there is another way to workaround this without changing symbol resolver... since in nac3artiq the core compiler does not know anything about the module globals if symbol resolver does not provide any information to it. Please have a review, thanks!
Outdated
Review

LGTM

LGTM
_ => unimplemented!("only constant default is supported now at {}", default.location), ast::ExprKind::Tuple { elts, .. } => Ok(SymbolValue::Tuple(elts
} .iter()
.map(|x| parse_parameter_default_value(x, resolver))
.collect::<Result<Vec<_>, _>>()?
)),
ast::ExprKind::Name { id, .. } => {
resolver.get_default_param_value(default).ok_or_else(
|| format!(
"this module global `{}` cannot be used as a default parameter at {} (should be primitive type or tuple)",
id,
default.location
)
)
}
_ => unimplemented!("only constant default is supported now at {}", default.location),
} }
} }

View File

@ -23,7 +23,7 @@ use inkwell::values::BasicValueEnum;
pub struct DefinitionId(pub usize); pub struct DefinitionId(pub usize);
pub mod composer; pub mod composer;
mod helper; pub mod helper;
mod type_annotation; mod type_annotation;
use composer::*; use composer::*;
use type_annotation::*; use type_annotation::*;

View File

@ -35,6 +35,10 @@ impl ResolverInternal {
struct Resolver(Arc<ResolverInternal>); struct Resolver(Arc<ResolverInternal>);
impl SymbolResolver for Resolver { impl SymbolResolver for Resolver {
fn get_default_param_value(&self, _: &nac3parser::ast::Expr) -> Option<crate::symbol_resolver::SymbolValue> {
unimplemented!()
}
fn get_symbol_type( fn get_symbol_type(
&self, &self,
_: &mut Unifier, _: &mut Unifier,

View File

@ -19,6 +19,10 @@ struct Resolver {
} }
impl SymbolResolver for Resolver { impl SymbolResolver for Resolver {
fn get_default_param_value(&self, _: &nac3parser::ast::Expr) -> Option<crate::symbol_resolver::SymbolValue> {
unimplemented!()
}
fn get_symbol_type( fn get_symbol_type(
&self, &self,
_: &mut Unifier, _: &mut Unifier,

View File

@ -2,21 +2,22 @@ use inkwell::values::BasicValueEnum;
use nac3core::{ use nac3core::{
codegen::CodeGenContext, codegen::CodeGenContext,
location::Location, location::Location,
symbol_resolver::SymbolResolver, symbol_resolver::{SymbolResolver, SymbolValue},
toplevel::{DefinitionId, TopLevelDef}, toplevel::{DefinitionId, TopLevelDef, helper::parse_parameter_default_value},
typecheck::{ typecheck::{
type_inferencer::PrimitiveStore, type_inferencer::PrimitiveStore,
typedef::{Type, Unifier}, typedef::{Type, Unifier},
}, },
}; };
use parking_lot::{Mutex, RwLock}; use parking_lot::{Mutex, RwLock};
use nac3parser::ast::StrRef; use nac3parser::ast::{self, StrRef};
use std::{collections::HashMap, sync::Arc}; use std::{collections::HashMap, sync::Arc};
pub struct ResolverInternal { pub struct ResolverInternal {
pub id_to_type: Mutex<HashMap<StrRef, Type>>, pub id_to_type: Mutex<HashMap<StrRef, Type>>,
pub id_to_def: Mutex<HashMap<StrRef, DefinitionId>>, pub id_to_def: Mutex<HashMap<StrRef, DefinitionId>>,
pub class_names: Mutex<HashMap<StrRef, Type>>, pub class_names: Mutex<HashMap<StrRef, Type>>,
pub module_globals: Mutex<HashMap<StrRef, ast::Expr>>,
} }
impl ResolverInternal { impl ResolverInternal {
@ -27,11 +28,27 @@ impl ResolverInternal {
pub fn add_id_type(&self, id: StrRef, ty: Type) { pub fn add_id_type(&self, id: StrRef, ty: Type) {
self.id_to_type.lock().insert(id, ty); self.id_to_type.lock().insert(id, ty);
} }
pub fn add_module_global(&self, id: StrRef, expr: &ast::Expr) {
self.module_globals.lock().insert(id, expr.clone());
}
} }
pub struct Resolver(pub Arc<ResolverInternal>); pub struct Resolver(pub Arc<ResolverInternal>);
impl SymbolResolver for Resolver { impl SymbolResolver for Resolver {
fn get_default_param_value(&self, expr: &ast::Expr) -> Option<SymbolValue> {
match &expr.node {
ast::ExprKind::Name { id, .. } => {
let expr = self.0.module_globals.lock().get(id).cloned();
expr.map(|x| {
parse_parameter_default_value(&x, self).unwrap()
})
}
_ => unimplemented!("other type of expr not supported at {}", expr.location)
}
}
fn get_symbol_type( fn get_symbol_type(
&self, &self,
_: &mut Unifier, _: &mut Unifier,

View File

@ -4,7 +4,7 @@ use inkwell::{
OptimizationLevel, OptimizationLevel,
}; };
use nac3core::typecheck::type_inferencer::PrimitiveStore; use nac3core::typecheck::type_inferencer::PrimitiveStore;
use nac3parser::parser; use nac3parser::{ast::{ExprKind, StmtKind}, parser};
use std::env; use std::env;
use std::fs; use std::fs;
use std::{collections::HashMap, path::Path, sync::Arc, time::SystemTime}; use std::{collections::HashMap, path::Path, sync::Arc, time::SystemTime};
@ -48,6 +48,7 @@ fn main() {
id_to_type: builtins_ty.into(), id_to_type: builtins_ty.into(),
id_to_def: builtins_def.into(), id_to_def: builtins_def.into(),
class_names: Default::default(), class_names: Default::default(),
module_globals: Default::default(),
} }
.into(); .into();
let resolver = let resolver =
@ -66,6 +67,18 @@ fn main() {
); );
for stmt in parser_result.into_iter() { for stmt in parser_result.into_iter() {
// handle module globals
if let StmtKind::Assign { targets, value, .. } = &stmt.node {
if targets.len() == 1 {
if let ExprKind::Name { id, .. } = &targets[0].node {
internal_resolver.add_module_global(*id, value);
}
} else {
unimplemented!("only single assign supported now")
Outdated
Review

Come on. It's not more code to iterate on targets, is it?

Come on. It's not more code to iterate on ``targets``, is it?

Oh sure, now the symbol resolver change is ok, I will add this support now.

Oh sure, now the symbol resolver change is ok, I will add this support now.

This is supported in the latest commit, as well as a better type check for default parameter, please have a review, thanks!

This is supported in the latest commit, as well as a better type check for default parameter, please have a review, thanks!
}
continue;
}
let (name, def_id, ty) = composer let (name, def_id, ty) = composer
.register_top_level(stmt, Some(resolver.clone()), "__main__".into()) .register_top_level(stmt, Some(resolver.clone()), "__main__".into())
.unwrap(); .unwrap();