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

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

Description

Extend syntax

lambda expression: move |args| body has copy, store
function types: |T1, T2| T3: copy+store
curry construction:
- from lambda: |a, b| f(a, x, b, 3)
- from call syntax with "holes": f(_, x, _, 3)
- as discussed in offsite (and move-model/src/ast.rs), curry expression takes a bitmask whose 1 bits indicate argument positions which receive lambda parameters (in order); 0 bits in mask entry correspond to curry parameters (in order).
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 exp_builder.rs: several paths with function calls are modified to check for _ in function call parameters, in which case the call becomes a curry operation.
- translate_possible_curry_exp_list is like translate_exp_list but also generates a mask based on the _ operands,
- translate_curry_or_call unifies some repeated code for function calls (if mask == 0) or curry construction (if mask != 0). (This includes some freeze code for call arguments that previously seemed applied only in some cases, now applied more uniformly for the Call case.)
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 (each either a unique lambda parameter or a constant/free var).

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.

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

rahxephon89 · 2024-11-01T17:26:30Z

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

+                let z = 11;
+                move |x| alt_multiply(x, z)
+            } else if (key == 11) {
+                let g = move |x, y| mod3::multiply(x, y);


Could you add a test for move |x, y| { ... } if the syntax is supported?

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

rahxephon89 · 2024-11-01T17:58:09Z

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

@@ -488,7 +488,7 @@ pub enum Type_ {
    // &mut t
    Ref(bool, Box<Type>),
    // (t1,...,tn):t


may need to update the comment to reflect ability set?

Why not |t1, ..., tn|: t as in the concrete syntax?

There's actually no : in the current function type. I'm going to follow Wolfgang's suggestion and make it |t1,...tn|t has store+copy to continue avoiding :.

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

rahxephon89 · 2024-11-01T18:09:06Z

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

 fn parse_call_args(context: &mut Context) -> Result<Spanned<Vec<Exp>>, Box<Diagnostic>> {
    let start_loc = context.tokens.start_loc();
-    let args = parse_comma_list(
+    consume_token(context.tokens, Tok::LParen)?;


Is there any difference after this refactor?

No, this was residue from the removed .. notation.

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

rahxephon89 · 2024-11-01T18:42:29Z

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

+        let mut used = BTreeSet::new();
+        let mut visitor = |e: &ExpData| {
+            match e {
+                ExpData::Call(_, Operation::MoveFunction(mid, fid), _) => {


Why these two cases cannot be merged like the one below?

No reason. Fixed.

rahxephon89 · 2024-11-01T21:29:50Z

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

@@ -2180,6 +2224,9 @@ impl GlobalEnv {
    /// Allocates a new node id.
    pub fn new_node_id(&self) -> NodeId {
        let id = NodeId::new(*self.next_free_node_id.borrow());
+        // if id == NodeId(425) {


Comments for debugging

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?

rahxephon89 · 2024-11-01T21:51:58Z

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

@@ -136,6 +136,52 @@ pub(crate) enum OldExpStatus {
    InsideOld,
 }

+#[derive(Debug, PartialEq, Eq, Copy, Clone)]
+pub enum ModelCallKind {


Could you explain more on the difference between ModelCallKind and CallKind and when to use them?

Same question -- why do we now need to distinguish UnOp/BinOp, and what has that todo with lambdas?

This relates to the _ notation. It really would be confusing if _ + 3 turns into a function.

Maybe I should try to remove the _ changes. It may be more trouble than it's worth.

rahxephon89 · 2024-11-01T21:56:30Z

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

+
+    /// Translate a list of expressions and deliver them together with their types.
+    ///
+    /// If Move Language Version >= 2.1, then if any expressions are `_`, then the positions are


maybe 2.2 instead of 2.1?

rahxephon89 · 2024-11-02T01:50:15Z

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

+                AbilitySet::FUNCTIONS,
+            );
+
+            // Problematic


What does this comment mean?

It is a legacy from debugging. I previously had a call to check_types here, and with much effort found that it was causing some problems. After I changed it to unify it was working better.

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.

wrwg · 2024-11-05T01:29:42Z

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

@@ -276,6 +277,40 @@ Resource representing an account.
 </dl>


+</details>


Why in this PR? Just joking...

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.

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.

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.

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.

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.

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.

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

fEst1ck · 2024-11-05T05:10:05Z

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

@@ -1834,6 +1866,12 @@ impl AstDebug for Exp_ {
                w.comma(rhs, |w, e| e.ast_debug(w));
                w.write(")");
            },
+            E::ExpCall(arg, sp!(_, rhs)) => {


Wondering where is ast_debug tested?

Heh. It's used for debugging code, so it's tested when you debug. 😏

…le of function type

…unnecessarily; avoid generating errors/warnings about default Loc

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 force-pushed the 09-27-add_parser_code_for_lambda_types branch from dabc427 to 11fec45 Compare October 31, 2024 00:31

brmataptos assigned wrwg, vineethk, rahxephon89 and fEst1ck and unassigned vineethk, rahxephon89, wrwg and fEst1ck Oct 31, 2024

brmataptos requested review from fEst1ck, rahxephon89, vineethk and wrwg October 31, 2024 04:14

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 Show resolved Hide resolved

fEst1ck reviewed Nov 5, 2024

View reviewed changes

brmataptos added 4 commits November 12, 2024 11:42

MVP lambda support in parser and expression builder

0b43333

fix issue with expected_type and curry construction with local variab…

ac4db4a

…le of function type

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

189b1d8

…unnecessarily; avoid generating errors/warnings about default Loc

run rust_lint.sh, move_pr -2 -i

626b1ed

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

		@@ -276,6 +277,40 @@ Resource representing an account.
		</dl>


		</details>

[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

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

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

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