Skip to content
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

Allow F# assemblies to run in .NET Native #593

Closed
ovatsus opened this issue Aug 15, 2015 · 3 comments
Closed

Allow F# assemblies to run in .NET Native #593

ovatsus opened this issue Aug 15, 2015 · 3 comments

Comments

@ovatsus
Copy link

ovatsus commented Aug 15, 2015

I guess this is probably not the right place to put this, but as there was an item for supporting CoreCLR already, I think this one also makes sense.

Is there anything that could be done in the compiler to fool the .NET Native compiler to be able to handle F# assemblies, by avoiding the use of specific constructs?

@jack-pappas
Copy link
Contributor

In addition to looking for a technical workaround for this issue, everyone who's interested in running F# on .NET Native should make sure to vote up these UserVoice issues to make their interest known to Microsoft:

@ovatsus I suspect you've already seen these, I just figured I'd post them here to remind anyone who finds this issue and hasn't voted.

@manofstick
Copy link
Contributor

I have potentially made. Net native more difficult with #513 (currently in limbo, but I think it is going to be sucked into the main code base). Basically the change does for comparison identity.structural and hashIdentity.Structural what comparer.default/equalitycomparer.default do i.e. make efficient comparison interfaces but using the more complex f#rules of equality. This also affects relationship operators and equality.

Now late in the day .net native was mentioned and I have a couple of ideas how to proceed:

  1. have a different profile which doesn't implement any of the above functionality
  2. possibly be able to detect if we're in .net native and just return the standard comparers (not sure if technically possible to detect it were running in .net native)
  3. run a profile like step to determine calls to makegenerictype (the problematic function) and then generate the metadata required for .net native to successfully compile. (But it you couldn't exercise your app with 100℅ line coverage then this has the potential to be inefficient; although I'm guessing that it shouldn't be too bad)

Anyway just polling if any of these are palatable, or if you have any other ideas?

@dsyme
Copy link
Contributor

dsyme commented Jul 11, 2016

Duplicate of #1096

@dsyme dsyme closed this as completed Jul 11, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants