[move-compiler-v2] add parser code for lambda types #14792

brmataptos · 2024-09-28T04:44:57Z

Description

Extend syntax

lambda expression: move |args| body with copy, store
function types: |T1, T2| T3 with copy+store
curry construction:
- from lambda: |a, b| f(x, 3, a, b)
- to simplify review, EarlyBind expression now takes a function-valued expression and a set of argument expressions, which correspond to a prefix of the function parameters.
arbitrary function calls:
- (|x, y| x + y)(2, 3)
suppress printing common abilities (all functions have drop)

Modify exp_builder and lambda_lifter to generate function values.

Modify model to track "used" functions in addition to "called" functions to be able to catch all dependencies when function values are created but not called.

Attaches an AbilitySet to Type::Fun and Exp::Lambda based on source. Adds a new ExpCall operation in parser/expansion ASTs to be able to carry more generalized function calls through to move-model, which already can support this through Invoke, which previously was underutilized. Added basic type checking for function abilities.

Current Gaps

I was targeting the test cases return_func.move and doable_func.move, but this PR is still missing

inference of ability store for function values built by curry with only storable parameters
allowing storable function types as type parameters and function returns

I will try to patch those in while this is being reviewed, or add them to a later PR.

How Has This Been Tested?

Added more lambda tests under move-compiler-v2/tests/lambda/ which are run "with" and "without" lambda features enabled. Currently, many things pass through to hit "not yet implemented" errors in bytecode gen, etc.

Ran and carefully checked all tests under third_party and aptos.

Key Areas to Review

Key features are illustrated in test move-compiler-v2/tests/lambda/storable/doable_func.move and the two corresponding output files, along with the test return_func.move in the same directory. Most other test outputs should be largely unchanged, although error messages related to lambda use in default configuration have changed.

Tricky features are:

parser is modified for lambda syntax extensions.
In some cases, abilities may not be inferred well yet, so examples may need to be over-annotated with abilities.
in ty.rs: unification checks Fun abilities as well as other things.
in lambda_lifter.rs, we (1) reject lambdas without move free-var handling, (2) try to reduce lambda to curry, by checking for a simple function call with simple args, the last of which are identical to the lambda parameters.

Type of Change

Which Components or Systems Does This Change Impact?

Checklist

I have read and followed the CONTRIBUTING doc
I have performed a self-review of my own code
I have commented my code, particularly in hard-to-understand areas
I identified and added all stakeholders and component owners affected by this change as reviewers
I tested both happy and unhappy path of the functionality
I have made corresponding changes to the documentation

trunk-io · 2024-09-28T04:45:00Z

⏱️ 2h 25m total CI duration on this PR

Slowest 15 Jobs	Cumulative Duration	Recent Runs
rust-move-unit-coverage	17m	🟩
rust-cargo-deny	15m	🟩 🟩 🟩 🟩 🟩 (+4 more)
general-lints	12m	🟩 🟩 🟩 🟩 🟩 (+4 more)
rust-move-unit-coverage	12m	🟩
rust-move-unit-coverage	11m	🟩
rust-move-tests	10m	🟩
rust-move-tests	9m	🟩
check-dynamic-deps	8m	🟩 🟩 🟩 🟩 🟩 (+4 more)
rust-move-tests	8m	🟥
rust-move-unit-coverage	5m	🟥
rust-move-unit-coverage	4m	🟥
rust-move-unit-coverage	4m	🟥
rust-move-unit-coverage	4m	🟥
rust-move-unit-coverage	3m	🟥
semgrep/ci	3m	🟩 🟩 🟩 🟩 🟩 (+4 more)

_{settings ⋅ feedback ⋅ docs ⋅ learn more about trunk.io}

brmataptos · 2024-09-28T04:45:13Z

This stack of pull requests is managed by Graphite. Learn more about stacking.

codecov · 2024-09-28T04:56:41Z

Codecov Report

Attention: Patch coverage is 79.67290% with 87 lines in your changes missing coverage. Please review.

Please upload report for BASE (09-27-extend_parser_for_lambda_types@243ea0f). Learn more about missing BASE report.

Files with missing lines	Patch %	Lines
third_party/move/move-compiler/src/parser/ast.rs	24.2%	25 Missing ⚠️
...hird_party/move/move-compiler/src/expansion/ast.rs	25.0%	24 Missing ⚠️
third_party/move/move-model/src/exp_rewriter.rs	55.8%	15 Missing ⚠️
third_party/move/move-model/src/ty.rs	56.5%	10 Missing ⚠️
third_party/move/move-model/src/ast.rs	50.0%	7 Missing ⚠️
...arty/move/move-compiler/src/expansion/translate.rs	96.2%	4 Missing ⚠️
...piler-v2/src/env_pipeline/unused_params_checker.rs	92.3%	1 Missing ⚠️
...d_party/move/move-model/src/builder/exp_builder.rs	98.4%	1 Missing ⚠️

Additional details and impacted files

@@                           Coverage Diff                           @@
##             09-27-extend_parser_for_lambda_types   #14792   +/-   ##
=======================================================================
  Coverage                                        ?    59.9%           
=======================================================================
  Files                                           ?      852           
  Lines                                           ?   207826           
  Branches                                        ?        0           
=======================================================================
  Hits                                            ?   124528           
  Misses                                          ?    83298           
  Partials                                        ?        0

Flag	Coverage Δ
	`59.9% <79.6%> (?)`

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

third_party/move/evm/move-to-yul/tests/AccountStateMachine.exp

third_party/move/move-compiler-v2/tests/bytecode-generator/freeze_mut_ref.exp

rahxephon89 · 2024-11-01T16:17:59Z

third_party/move/move-compiler-v2/src/env_pipeline/function_checker.rs

@@ -215,6 +216,10 @@ fn check_privileged_operations_on_structs(env: &GlobalEnv, fun_env: &FunctionEnv
                    | Operation::MoveFrom
                    | Operation::MoveTo => {
                        let inst = env.get_node_instantiation(*id);
+                        if inst.is_empty() {


these debug prints will be removed later I believe?

In general, debug prints can stay but they should be protected by a module flag DEBUG which is off when submitted, so people debugging other parts of the compiler are not bothered by this.

Those debug prints however look like temporary and should be removed.

Perhaps. Note that these will only be printed if the following assert will fail, so I'm leaving them in for now for debugging.

need to remove this before landing

third_party/move/move-compiler/tests/move_check/parser/invalid_call_lhs_complex_expression.exp

third_party/move/move-compiler-v2/tests/lambda/storable/doable_func.move

third_party/move/move-compiler-v2/tests/lambda/storable/registry.move

third_party/move/move-compiler/src/parser/ast.rs

third_party/move/move-compiler/src/parser/keywords.rs

third_party/move/move-compiler/src/parser/syntax.rs

third_party/move/move-model/src/ast.rs

third_party/move/move-model/src/model.rs

rahxephon89 · 2024-11-01T21:35:54Z

third_party/move/move-model/src/model.rs

@@ -2930,17 +2982,18 @@ impl<'env> ModuleEnv<'env> {
            return deps;
        }
        for fun_env in self.get_functions() {
-            let called_funs = fun_env.get_called_functions().expect("called functions");


When should we use used_functions instead of called_functions and vice versa?

I actually suspect that used_functions should subsume called_functions but there are bunch of calls under move-prover which I'm going to need help with.

third_party/move/move-model/src/builder/exp_builder.rs

wrwg

This came out more complex than I was hoping for. Major ask is to reduce back to the existing expression variants (use Operation::Closure which already existed), and change the syntax to |T| has A instead of colon. I wish we would not have done the f(_) for the MVP, this creates significant complexity all over the place, and I'm not sure whether I can check correctness of all those changes just from this PR.

aptos-move/framework/aptos-framework/tests/compiler-v2-doc/account.md

wrwg · 2024-11-05T01:32:11Z

third_party/move/move-binary-format/src/file_format.rs

@@ -786,10 +786,13 @@ impl AbilitySet {
            | (Ability::Store as u8)
            | (Ability::Key as u8),
    );
+    /// Abilities for user-defined/"primitive" functions (not closures)
+    pub const DEFINED_FUNCTIONS: AbilitySet =
+        Self((Ability::Copy as u8) | (Ability::Drop as u8) | (Ability::Store as u8));


Store doesn't seem to be right.

After our last discussion, yes, it should only be Store if it's public.

wrwg · 2024-11-05T01:50:07Z

third_party/move/move-model/src/ast.rs

-    Lambda(NodeId, Pattern, Exp),
+    Lambda(NodeId, Pattern, Exp, LambdaCaptureKind, AbilitySet),
+    /// Represents a reference to a Move Function as a function value.
+    MoveFunctionExp(NodeId, ModuleId, FunId),


The philosophy of the exp language to keep it as small as possible. We do not need this thing, it can be folded into 'Curry', and Curry can be renamed to make it more neutral, like Closure. A closure can capture 0 arguments, why not.

We furthermore do not and should not have a new ExpData variant for it. The current design uses Call(..Operation..) where possible, and so should this. There is already the Closure operation, you can simply extend it

Call(_, Operation::Closure(f, mask), vec[captured])

This is rather important to me. I took great care to design ExpData like it is today, and it benefited us already many times. Lots of the code changes you did in visitors and elsewhere should become unnecessary.

We have 2 distinct expressions we need to build:

create a function value from a defined function by (ModuleId, FunId)

create a function value from a function value and 0 or more parameters
Your Closure operation doesn't handle the latter case, as the "function value" need not be a reference to a defined function (ModuleId, FunId) but can be an arbitrary expression.

If f in Operation::Closure(f, mask) can refer to an expression, then we have bigger consistency problems.

We might conceivably have Operation::Closure(mask) with the function value as the first argument to the Call expression, though it's a bit irregular.

OTOH, we might only allow directly creating a closure based on a Move function. This is more limiting, in that |x| f(x) can only be used in MVP if f is a user function, not if it's a function value. I guess perhaps that is what you had in mind. I prefer more symmetry.

I've minimized the changes to ExpData by adding Function as a Value, and instead of Closure or Curry I have an Operation called Bind, which takes a function expr and the list of parameters, with the mask as a field in the variant: Operation::Bind(mask).

Hopefully this is more to your liking, although since i decided to call it Bind I realized we have Bind in a few places. Perhaps I can rename it as EarlyBind or something.

wrwg · 2024-11-05T01:53:03Z

third_party/move/move-model/src/ast.rs

+    Lambda(NodeId, Pattern, Exp, LambdaCaptureKind, AbilitySet),
+    /// Represents a reference to a Move Function as a function value.
+    MoveFunctionExp(NodeId, ModuleId, FunId),
+    /// Represents a Curry expression.  mask has a 1 bit for position of each delayed


I think it is more logical to set a bit if a parameter is captured and not the opposite.

With the current rep, total args = bitcount(mask) + actual args.

With the alternative you suggest, actual args = bitcount(mask), and we need to check the function type to know how many args to expect in total.

True, we need to consult the function type to check the types of remaining args, but we get more information out of this rep.

After some reflection, I agree with you that using a 1 bit here for each bound parameter makes sense here.

wrwg · 2024-11-05T01:55:49Z

third_party/move/move-compiler-v2/src/env_pipeline/function_checker.rs

-            if let Type::Fun(argt, _) = &ty {
-                if argt.deref().has_function() {
+            if let Type::Fun(args, _, _) = &ty {
+                if args.deref().has_function() {


deref is a trait function for * and not idiomatic to use, as_ref should be preferred.

wrwg · 2024-11-05T03:13:53Z

third_party/move/move-model/src/builder/exp_builder.rs

+            let fun_type = self.check_type(loc, &fun_type, expected_type, context);
+
+            let id = self.parent.parent.env.new_node(loc.clone(), fun_type);
+            return ExpData::MoveFunctionExp(id, module_id, fun_id);


This should be Call(id, Closure(module_id, fund_id, 0x0), vec![])

Reduce the number of variants in the IR is a key to maintainable and correct code.

wrwg · 2024-11-05T03:15:28Z

third_party/move/move-model/src/builder/exp_builder.rs

@@ -3778,7 +3948,9 @@ impl<'env, 'translator, 'module_translator> ExpTranslator<'env, 'translator, 'mo
                .struct_table
                .contains_key(&global_var_sym)
            {
-                self.check_language_version(loc, "resource indexing", LanguageVersion::V2_0);
+                if !self.check_language_version(loc, "resource indexing", LanguageVersion::V2_0) {
+                    return None;


Wait a minute -- why are we returning None here? (And the comment above?) This generates an error and this is all we need. The program is consistent independent of Move language version. This change here and elsewhere seems unnecessary.

Well, it returns more quickly rather than building pointless expressions and cascading errors if the feature is not supported. Here if we continue we might generate an additional error if the struct type used does not have key ability.

To minimize changes to the code, instead I will change check_language_version to return Option<()> and return None if the test fails, allowing use of ? to more concisely bail out of the enclosing functions with a None value in most cases.

wrwg · 2024-11-05T03:19:00Z

third_party/move/move-model/src/builder/exp_builder.rs

-                    if let Type::Reference(_, inner_ty) = ty {
-                        self.new_node_id_with_type_loc(
-                            &Type::Reference(ReferenceKind::Mutable, inner_ty),
+                if mask != 0u128 && !matches!(cand, AnyFunEntry::UserFun(_)) {


A comment what you are doing here would be helpful. What magic number is 0u128?

I'm worried about this change and the complexity of that we support _. The MVP doesn't need _, it would have been SO much easier to leave the type checking mostly the same, and just derive the closure from the lambda without new function during lifting, after type checking. We would be already working at VM part.

I agree, but someone thought it was a good idea originally. :-)

wrwg · 2024-11-05T03:22:11Z

third_party/move/move-model/src/builder/exp_builder.rs

+        fun_exp_or_oper: FunExpOrOper,
+        arg_types: Vec<Type>,
+        translated_args: Vec<Exp>,
+        mask: u128,


For the mask for closures, it should be only u64. More is not needed. u128 should not be put into an instruction, to large for it, but its not needed anyway.

Sound good. Also check for max 64 params in lambda_lifter.rs. I'm pretty sure that's limited elsewhere, but best to be sure.

wrwg · 2024-11-05T03:29:01Z

third_party/move/move-compiler/src/parser/syntax.rs

+    };
+    let body = Box::new(parse_exp(context)?);
+    let abilities_start = context.tokens.start_loc();
+    let abilities = parse_abilities(context)?;


The abilities of a function type should use |T|R with A and not :. It looks strange to have two colons in an argument declaration, as in f(x: |T|:copy. Thats also the reason why it is not |T|:R.

Ok, I'm changing the syntax (for both lambda expression and function type) to "with copy+store". This avoids a comma-separated list if we do "has copy, store" (as in struct decls) which would lead to parsing confusion in the case of expression or parameter lists.

third_party/move/move-binary-format/src/file_format.rs

third_party/move/move-compiler/src/parser/ast.rs

brmataptos

I rolled back the _ support for now, due to persisting type/ability resolution issues. Enjoy.

third_party/move/move-model/src/model.rs

brmataptos · 2024-11-12T20:54:03Z

third_party/move/move-model/src/model.rs

@@ -2930,17 +2982,18 @@ impl<'env> ModuleEnv<'env> {
            return deps;
        }
        for fun_env in self.get_functions() {
-            let called_funs = fun_env.get_called_functions().expect("called functions");


I actually suspect that used_functions should subsume called_functions but there are bunch of calls under move-prover which I'm going to need help with.

third_party/move/move-compiler-v2/tests/lambda/storable/doable_func.move

third_party/move/move-compiler/src/parser/ast.rs

third_party/move/move-compiler/src/parser/syntax.rs

brmataptos · 2024-11-13T19:41:10Z

third_party/move/move-model/src/builder/exp_builder.rs

@@ -891,6 +941,7 @@ impl<'env, 'translator, 'module_translator> ExpTranslator<'env, 'translator, 'mo
                                self.translate_hlir_base_types(&args[0..args.len() - 1]),
                            )),
                            Box::new(self.translate_hlir_base_type(&args[args.len() - 1])),
+                            AbilitySet::FUNCTIONS,


AbilitySet::FUNCTIONS is currently just drop and copy. Maybe will get rid of copy, so we can allow closures with captured free variables with no copy.

brmataptos · 2024-11-13T21:51:35Z

third_party/move/move-compiler/src/parser/syntax.rs

+    };
+    let body = Box::new(parse_exp(context)?);
+    let abilities_start = context.tokens.start_loc();
+    let abilities = parse_abilities(context)?;


Ok, I'm changing the syntax (for both lambda expression and function type) to "with copy+store". This avoids a comma-separated list if we do "has copy, store" (as in struct decls) which would lead to parsing confusion in the case of expression or parameter lists.

brmataptos · 2024-11-13T21:58:14Z

third_party/move/move-model/src/ast.rs

+    Lambda(NodeId, Pattern, Exp, LambdaCaptureKind, AbilitySet),
+    /// Represents a reference to a Move Function as a function value.
+    MoveFunctionExp(NodeId, ModuleId, FunId),
+    /// Represents a Curry expression.  mask has a 1 bit for position of each delayed


After some reflection, I agree with you that using a 1 bit here for each bound parameter makes sense here.

third_party/move/move-model/src/builder/exp_builder.rs

brmataptos · 2024-11-19T22:30:06Z

third_party/move/move-model/src/ast.rs

-    Lambda(NodeId, Pattern, Exp),
+    Lambda(NodeId, Pattern, Exp, LambdaCaptureKind, AbilitySet),
+    /// Represents a reference to a Move Function as a function value.
+    MoveFunctionExp(NodeId, ModuleId, FunId),


I've minimized the changes to ExpData by adding Function as a Value, and instead of Closure or Curry I have an Operation called Bind, which takes a function expr and the list of parameters, with the mask as a field in the variant: Operation::Bind(mask).

Hopefully this is more to your liking, although since i decided to call it Bind I realized we have Bind in a few places. Perhaps I can rename it as EarlyBind or something.

rahxephon89 · 2024-11-22T23:50:10Z

third_party/move/move-binary-format/src/file_format.rs

    pub const FUNCTIONS: AbilitySet = Self(Ability::Drop as u8);
+    /// Maximal abilities for all `Functions`.  This is used for UB when joining types.


What does UB mean?

rahxephon89 · 2024-11-22T23:51:07Z

third_party/move/move-binary-format/src/file_format.rs

@@ -864,6 +871,8 @@ impl AbilitySet {
    pub const VECTOR: AbilitySet =
        Self((Ability::Copy as u8) | (Ability::Drop as u8) | (Ability::Store as u8));

+    /// The empty ability set


Is this comment for singleton?

rahxephon89 · 2024-11-22T23:54:50Z

third_party/move/move-compiler-v2/src/env_pipeline/function_checker.rs

@@ -215,6 +216,10 @@ fn check_privileged_operations_on_structs(env: &GlobalEnv, fun_env: &FunctionEnv
                    | Operation::MoveFrom
                    | Operation::MoveTo => {
                        let inst = env.get_node_instantiation(*id);
+                        if inst.is_empty() {


need to remove this before landing

rahxephon89 · 2024-11-23T00:09:00Z

third_party/move/move-model/src/ast.rs

@@ -1739,6 +1814,12 @@ impl ExpRewriterFunctions for LoopNestRewriter {
 #[derive(Debug, Clone, PartialEq, Eq, Hash)]
 pub enum Operation {
    MoveFunction(ModuleId, FunId),
+    /// Build a closure by binding 1 or more leading arguments to a function value.
+    /// First argument to the operation must be a function; the reamining


nit: reaming -> remaining

…le of function type

…unnecessarily; avoid generating errors/warnings about default Loc

…ionExpr to Value::Function, got things mostly back in shape

…for abilities in lambda_lifter.rs

…_curry`

…constraints to avoid reducing set of function type abilities when unifying types

…to bind leading arguments

brmataptos mentioned this pull request Sep 28, 2024

[compiler-v2] add test cases for lambda #14791

Merged

22 tasks

brmataptos mentioned this pull request Sep 28, 2024

[move-compiler-v2] fix #14633: fix error messages for lambdas, identify change points for more complete lambda implementation #14742

Merged

22 tasks

brmataptos force-pushed the 09-27-extend_parser_for_lambda_types branch from 7f59256 to ae73f37 Compare September 30, 2024 17:09

brmataptos force-pushed the 09-27-add_parser_code_for_lambda_types branch from dbd482d to 270214e Compare September 30, 2024 17:09

brmataptos force-pushed the 09-27-extend_parser_for_lambda_types branch from ae73f37 to 243ea0f Compare September 30, 2024 18:43

brmataptos force-pushed the 09-27-add_parser_code_for_lambda_types branch from 270214e to afbad9b Compare September 30, 2024 18:44

brmataptos force-pushed the 09-27-extend_parser_for_lambda_types branch from 243ea0f to f3d30eb Compare October 3, 2024 01:42

brmataptos force-pushed the 09-27-add_parser_code_for_lambda_types branch from a40a3c9 to 71ef91f Compare October 3, 2024 01:43

brmataptos force-pushed the 09-27-extend_parser_for_lambda_types branch from f3d30eb to 0cc6890 Compare October 3, 2024 01:52

brmataptos force-pushed the 09-27-add_parser_code_for_lambda_types branch from 71ef91f to 3a1d362 Compare October 3, 2024 01:53

brmataptos force-pushed the 09-27-extend_parser_for_lambda_types branch from 0cc6890 to 1b54f30 Compare October 3, 2024 04:42

brmataptos force-pushed the 09-27-add_parser_code_for_lambda_types branch 2 times, most recently from c46a244 to b3c1106 Compare October 3, 2024 06:09

brmataptos force-pushed the 09-27-extend_parser_for_lambda_types branch from ad600f0 to 017f471 Compare October 3, 2024 17:01

brmataptos force-pushed the 09-27-add_parser_code_for_lambda_types branch from b3c1106 to a65ee0f Compare October 3, 2024 17:01

brmataptos force-pushed the 09-27-extend_parser_for_lambda_types branch from 017f471 to b7d429a Compare October 10, 2024 04:18

brmataptos force-pushed the 09-27-add_parser_code_for_lambda_types branch from a65ee0f to cbb77b0 Compare October 10, 2024 04:18

brmataptos force-pushed the 09-27-extend_parser_for_lambda_types branch from b7d429a to c99de22 Compare October 10, 2024 05:25

brmataptos force-pushed the 09-27-add_parser_code_for_lambda_types branch from cbb77b0 to b2185c2 Compare October 10, 2024 05:25

brmataptos force-pushed the 09-27-extend_parser_for_lambda_types branch from c99de22 to d3254ad Compare October 18, 2024 18:03

brmataptos force-pushed the 09-27-add_parser_code_for_lambda_types branch from b2185c2 to 3f98e56 Compare October 18, 2024 18:04

brmataptos force-pushed the 09-27-extend_parser_for_lambda_types branch from d3254ad to 7e21319 Compare October 18, 2024 18:08

brmataptos force-pushed the 09-27-add_parser_code_for_lambda_types branch from 3f98e56 to e24bf4e Compare October 18, 2024 18:08

brmataptos force-pushed the 09-27-extend_parser_for_lambda_types branch from 7e21319 to 7cfe2c4 Compare October 21, 2024 07:10

brmataptos force-pushed the 09-27-add_parser_code_for_lambda_types branch from e24bf4e to 2a740e8 Compare October 21, 2024 07:10

Base automatically changed from 09-27-extend_parser_for_lambda_types to main October 21, 2024 07:48

brmataptos force-pushed the 09-27-add_parser_code_for_lambda_types branch from 2a740e8 to dabc427 Compare October 26, 2024 00:05

brmataptos marked this pull request as ready for review October 31, 2024 04:18

brmataptos requested review from areshand, davidiw and movekevin as code owners October 31, 2024 04:18

brmataptos changed the title ~~add parser code for lambda types~~ [move-compiler-v2] add parser code for lambda types Oct 31, 2024

rahxephon89 reviewed Nov 1, 2024

View reviewed changes

rahxephon89 reviewed Nov 2, 2024

View reviewed changes

wrwg reviewed Nov 5, 2024

View reviewed changes

fEst1ck reviewed Nov 5, 2024

View reviewed changes

third_party/move/move-binary-format/src/file_format.rs Outdated Show resolved Hide resolved

fEst1ck reviewed Nov 5, 2024

View reviewed changes

third_party/move/move-compiler/src/parser/ast.rs Show resolved Hide resolved

brmataptos force-pushed the 09-27-add_parser_code_for_lambda_types branch from 5e47d93 to 626b1ed Compare November 12, 2024 19:44

brmataptos force-pushed the 09-27-add_parser_code_for_lambda_types branch from 626b1ed to f3901b3 Compare November 19, 2024 22:00

brmataptos commented Nov 19, 2024

View reviewed changes

brmataptos force-pushed the 09-27-add_parser_code_for_lambda_types branch from 4745b14 to 9b3a2af Compare November 22, 2024 01:38

brmataptos mentioned this pull request Nov 22, 2024

[move-compiler-v2] clean up a few remaining issues in lambda parser/front-end code #15365

Open

22 tasks

rahxephon89 reviewed Nov 23, 2024

View reviewed changes

brmataptos added 11 commits November 24, 2024 20:25

MVP lambda support in parser and expression builder

1b2232f

fix issue with expected_type and curry construction with local variab…

6a2ce44

…le of function type

undo some debugging tweaks to type printing that increased diff size …

94464be

…unnecessarily; avoid generating errors/warnings about default Loc

run rust_lint.sh, move_pr -2 -i

316db66

inverted mask sense, changed Curry expr to Operation::Bind, MoveFunct…

dfd693a

…ionExpr to Value::Function, got things mostly back in shape

fix a merge conflict that duplicated code, and check bound variables …

ae750aa

…for abilities in lambda_lifter.rs

undo underscore support

a987e30

handle more function values in `LambdaLifter::try_to_reduce_lambda_to…

db00255

…_curry`

add AbilitySet::MAXIMAL_FUNCTIONS and use it in some function type …

edfe1bb

…constraints to avoid reducing set of function type abilities when unifying types

fix lint

20cce5d

rename Bind to EarlyBind and remove mask in favor of just being able …

cead217

…to bind leading arguments

brmataptos force-pushed the 09-27-add_parser_code_for_lambda_types branch from 9395a8f to cead217 Compare November 25, 2024 04:53

brmataptos mentioned this pull request Nov 25, 2024

Verbatim cherry-pick of Wolfgang's draft PR 15171 = commit #d85b919 #15387

Draft

22 tasks

		pub const FUNCTIONS: AbilitySet = Self(Ability::Drop as u8);
		/// Maximal abilities for all `Functions`. This is used for UB when joining types.

[move-compiler-v2] add parser code for lambda types #14792

Are you sure you want to change the base?

[move-compiler-v2] add parser code for lambda types #14792

Conversation

brmataptos commented Sep 28, 2024 • edited Loading

Description

Current Gaps

How Has This Been Tested?

Key Areas to Review

Type of Change

Which Components or Systems Does This Change Impact?

Checklist

trunk-io bot commented Sep 28, 2024 • edited Loading

brmataptos commented Sep 28, 2024 • edited Loading

codecov bot commented Sep 28, 2024 • edited Loading

Codecov Report

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wrwg left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

brmataptos left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

brmataptos commented Sep 28, 2024 •

edited

Loading

trunk-io bot commented Sep 28, 2024 •

edited

Loading

brmataptos commented Sep 28, 2024 •

edited

Loading

codecov bot commented Sep 28, 2024 •

edited

Loading