New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Limited Lambda Support on Immediate Pad #142

Merged
merged 12 commits into from Jan 24, 2018

Conversation

Projects
None yet
5 participants
@harukamm
Contributor

harukamm commented Jul 3, 2017

Support lambda expressions on expression evaluator.

Supported Features:

Lambdas satisfying the following conditions are supported.

  • Lambdas with cast or method invocation
    • ((Action<string>)(x => System.Console.WriteLine (x))
    • (Func<int>)(() => 50 * 100)
    • lst.Find (x => x == “bar”)
    • arr.First (x => x == "foo")
  • Public type / public method / local variables access

Non-Supported Features:

  1. Private type / private method access
  2. Lambdas in some kinds of generic methods
    • Invocation of generic methods like Method1<T> (T x, Func<T> f) are supported because a generic type T can be resolved by the type of first parameter x.
    • However, this doesn’t work: Method1<T> (Func<T> f)
    • We have to provide type arguments like Method1<int>(() => 50)
  3. Side Effect
    • ((Action<int>)(x => y = x)).Invoke(5), let y be one of local variables.
  4. Async Lambdas

Note that my patches use Microsoft.CodeAnalysis ver1.3.2, while MonoDevelop references ver2.3.0-beta1. Ver-2.3.0 is not available under the target framework version 4.5. I'd like to ask reviewers if it's alright to update the target framework version.

@jstedfast jstedfast requested review from DavidKarlas and slluis Jul 5, 2017

@jstedfast

This comment has been minimized.

Show comment
Hide comment
@jstedfast

jstedfast Jul 5, 2017

Member

I'm not sure what, if any, implications there are for bumping the target framework version.

I would so love to see lambda support, though. 👍

Hopefully we can bump it.

Member

jstedfast commented Jul 5, 2017

I'm not sure what, if any, implications there are for bumping the target framework version.

I would so love to see lambda support, though. 👍

Hopefully we can bump it.

@Therzok

This comment has been minimized.

Show comment
Hide comment
@Therzok

Therzok Jul 5, 2017

Member

For MonoDevelop, it should have no implication. We bumped it already.

Member

Therzok commented Jul 5, 2017

For MonoDevelop, it should have no implication. We bumped it already.

@jstedfast

This comment has been minimized.

Show comment
Hide comment
@jstedfast

jstedfast Jul 5, 2017

Member

Right, but MonoDevelop might not be the only consumer of debugger-libs

Member

jstedfast commented Jul 5, 2017

Right, but MonoDevelop might not be the only consumer of debugger-libs

@harukamm

This comment has been minimized.

Show comment
Hide comment
@harukamm

harukamm Jul 5, 2017

Contributor

Thanks for your comments:) As for the target framework version, I'd like to defer decision to others because I'm new to this project.
I've added unit tests for this patches per suggestion from @Therzok.

Contributor

harukamm commented Jul 5, 2017

Thanks for your comments:) As for the target framework version, I'd like to defer decision to others because I'm new to this project.
I've added unit tests for this patches per suggestion from @Therzok.

@Therzok

This comment has been minimized.

Show comment
Hide comment
@Therzok

Therzok Jul 6, 2017

Member

I love where this is going! Thanks for the unit tests!

Member

Therzok commented Jul 6, 2017

I love where this is going! Thanks for the unit tests!

@harukamm

This comment has been minimized.

Show comment
Hide comment
@harukamm

harukamm Jul 31, 2017

Contributor

Thank you for the review!
@DavidKarlas and I talked offline, and we've decided to update the target framework version.

This patch is far behind my local change. It supports:

  1. delegate type other than System.Func (e.g., Action/Predicate/public user-delegate)
  2. access to outside the context

Should I close this PR and create new one, or push the changes to this PR?

Contributor

harukamm commented Jul 31, 2017

Thank you for the review!
@DavidKarlas and I talked offline, and we've decided to update the target framework version.

This patch is far behind my local change. It supports:

  1. delegate type other than System.Func (e.g., Action/Predicate/public user-delegate)
  2. access to outside the context

Should I close this PR and create new one, or push the changes to this PR?

@dnfclas

This comment has been minimized.

Show comment
Hide comment
@dnfclas

dnfclas Dec 14, 2017

CLA assistant check
All CLA requirements met.

dnfclas commented Dec 14, 2017

CLA assistant check
All CLA requirements met.

@DavidKarlas

This comment has been minimized.

Show comment
Hide comment
@DavidKarlas

DavidKarlas Jan 23, 2018

Member

@harukamm can you fix merge conflict?

Member

DavidKarlas commented Jan 23, 2018

@harukamm can you fix merge conflict?

harukamm and others added some commits Jun 29, 2017

Value and type for lambda expression
This represents a temporary value/type for lambda. We'd like to determine the type
of a lambda based on its context.
Create byte array without wrapper objects
In order to support lambda expression, we have to send compiled assembly for
the lambda to runtime. It costs much time if we create wrapper objects like
ValueImpl and Value for each byte in the compiled assembly. This patch avoids
it by sending those bytes without creating wrappers.
Support lambda expression with cast
in Immediate Pad only if the lambda satisfies following conditions
- Lambda must be used with cast
- Not access to any variables nor methods defined in user code
For example, `(Func<int>)(()=>50)` can be evalueated, but `() => 50` is not
supported.
Support lambda expressions as method parameters
on Immediate Pad.
- Not access to local variables nor methods defined in user code
For example, `intlst.Max(a => -a)`, `intlst.Any(x => x < 0)` can be evaluated.
Support this/base reference and local variables
inside lambda on Immediate Pad.
- Enable to use this/base reference and local variables only if its type is public
Fully qualify method names automatically
inside lambda on Immediate Pad. For example, if the current instance of the class
has an instance metthod, and an user inputs `(x => InstanceMethod(x))`, it will be
evaluated as `(x => this.InstanceMethod(x))`. Similarly, a lambda expression
`(x => StaticMethod(x))` in static context of `ClassA` will become
`(x => ClassA.StaticMethod(x))`
Fix a bug in evaluation of lambda types
which have nested class in their argument types.
ex) System.Func<int, Namespace1.ClassA+ClassB+ClassC>
Resolve implicit type arguments in array parameter
ex) Method<T>(T[]), System.Array.IndexOf<T>(T[], T)
@harukamm

This comment has been minimized.

Show comment
Hide comment
@harukamm

harukamm Jan 24, 2018

Contributor

@DavidKarlas I've resolved the conflicts!

Contributor

harukamm commented Jan 24, 2018

@DavidKarlas I've resolved the conflicts!

@DavidKarlas DavidKarlas merged commit 2e1c4ea into mono:master Jan 24, 2018

1 check passed

license/cla All CLA requirements met.
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment