dotnet / fsharp Goto Github PK

Opened by:vandroiy on Codeplex

F# debug compilation in Visual Studio sometimes fails with the error "Incorrect number of type arguments to local call". A lot of seemingly unrelated circumstances influence the appearance of the error.

See this question on Stackoverflow

Shortest reproduction I know of:
◾Use VS2013 (reproduced in Community, also with F# 3.1.2 installed) or VS2012 (reproduced in Pro)
◾Make a project that compiles to an executable or library (not interactive/scripting)
◾Use debug configuration (no optimizations enabled)
◾Add the following code and attempt to compile (The code editor won't predict the error)

type R<[<Measure>] 'u> (f : float<'u>) =
    member r.Member = f

let get (r : R<_>) = r.Member
let foo =
    let problem _ = List.map get
    problem // Error: Incorrect number of type arguments to local call

The error disappears from various attempts to simplify the example code (see the Stackoverflow question). Declaring problem functions as inline can serve as a workaround.

comments
latkin wrote Dec 17, 2014 at 4:18 PM [x]
I can reproduce this on Windows with 3.0, 3.1, and 4.0.

Current devguide is focused on simply getting to the point of being able to make changes. What is needed is additional content for the points beyond - the code organization, which things do what and why, what the performance considerations are for certain areas, suggested style for given regions and lastly we need something that describes the characteristics of great PRs which contain experiments vs. bug fixes vs. features etc.

mmjb submitted this via CodePlex

Error message uses 'attributes' too many times.
"This type uses an invalid mix of the attributes 'NoEquality', 'ReferenceEquality', 'StructuralEquality', 'NoComparison' and 'StructuralComparison' attributes"

Should be:
"This type uses an invalid mix of the attributes 'NoEquality', 'ReferenceEquality', 'StructuralEquality', 'NoComparison' and 'StructuralComparison'"

[from fsbugs, and Stack Overflow]

The WSDL type provider erroneously generates too many overloads for creating the simplified data context types in the case where the service URI provided hosts multiple endpoints.

The TP ends up generating a number of overloads which differ only in return type, which is not valid. The compiler encounters an internal error when this occurs.

Cause:
TypeProviders.fs line ~1075
The static methods for all endpoints are generated for all context types. This is incorrect - each WSDL endpoint only corresponds to 1 context type. We should be filtering the endpoints here to use only the one which matches the current serviceInterfaceType.

File attachments

For those who are actually running all of the tests, current defaults for the FSharpQA suite are to use parallel execution + hosted compiler server. This results is a new compiler server console popping up and dying away every few seconds, which is rather disruptive if you are trying to do other work.

It's a simple change to make those windows hidden, just update constant in runall.pl to CREATE_NO_WINDOW.

Hosted compiler was initially very unreliable, so it was nice to be able to see the output. But it seems sturdy enough now, I think I will change the behavior to something less disruptive.

This is a common annoyance when using Visual Studio together with FAKE. Running a FAKE build while the solution is open in Visual Studio invariably results in the following error:

FSC : error FS0193: Access to the path 'path_to_bin_folder\project.XML' is denied. ['path_to_project\project.fsproj']

The error persists even if the solution is closed from within Visual Studio. The IDE needs to be restarted in order for the problem to go away.

opened by ovatsus at CodePlex

When we have a member like this:

 [<EditorBrowsableAttribute(EditorBrowsableState.Never)>] 
 [<CompilerMessageAttribute("This method is intended for use in generated code only.", 10001, IsHidden=true, IsError=false)>] 
 member x._Print = x.XElement.ToString() 

It doesn't show up on IntelliSense, but it still does show up on the tooltip:

If someone can point where this code is located I can take a shot at submiting a PR with a fix

Originally opened by @ctaggart on Codeplex. Seems like a weird/severe enough problem that we should get eyes on it asap.

I've been troubleshooting this issue with Visual Studio 2015 Preview the last couple of nights and created a very simple FSharp.Data.SqlClient project to reproduce the issue. The project that uses the type provider ends up referencing both 4.4.0.0 and 4.3.1.0 of FSharp.Core. I was expecting it to only reference 4.3.1.0 that the project is set to. We figured out that we can still get it to run on 4.3.1.0 by doing a binding redirect down.

Please have a look at this issue:
fsprojects/FSharp.Data.SqlClient#79

It is super easy to reproduce:

PS> git clone https://github.com/ctaggart/Paket09x.git -b PeopleSql
PS> .\Paket09x\PeopleSql.sln

cheers,
Cameron

KevinRansom wrote Nov 19, 2014 at 9:16 AM [x]

Thanks for this report we will take a look to try to figure out what makes sense to do here.

Kevin

latkin wrote Nov 26, 2014 at 4:58 PM [x]

At the project level, everything is working as expected, and 4.3.1.0 is the only FSharp.Core referenced in the compiler command line.

At some point when the provided types are generated during compilation, various F#-specific types are required (unit, async...) and the compiler assumes those come from the same FSharp.Core version that it is using (4.4.0.0 in this case). A reference is somehow injected to 4.4.0.0 due to this, as best as I can tell. Reproing with the OSS compiler results in unintentional reference to 4.4.0.9055, which follows the same pattern.

Opened at CodePlex by ovatsus

This should give a compile time error, but doesn't:
[File1.fs]

namespace MyApp

module private Module1 =
    let f x = x

[Program.fs]

namespace MyApp

module Module2 =
    open Module1
    let y = f 1

    do
        printfn "%O" y

When evaluating in fsx the error is correctly issued

This was already discussed here, but the issue was closed with the note that it is already under review on UserVoice.
I would be very happy to get further information on the progress of this issue.

A Universal App or unit test executing code like <@ System.Exception() @> in an F# 3.1 / Profile 259 portable class library will result in an AmbiguousMatchException at runtime. Stacktrace looks something like

at Microsoft.FSharp.Core.ReflectionAdapters.commit[a](a[] results)
at Microsoft.FSharp.Core.ReflectionAdapters.Type.GetConstructor(Type this, Type[] parameterTypes)
at Microsoft.FSharp.Quotations.PatternsModule.bindCtor(Type tc, FSharpFunc2 argTypes, FSharpList1 tyargs)
at Microsoft.FSharp.Quotations.PatternsModule.u_constSpec@1424-40.Invoke(FSharpList1 tyargs) at [email protected](BindingEnv env) at [email protected](BindingEnv env) at Microsoft.FSharp.Quotations.PatternsModule.deserialize(Type localAssembly, FSharpList1 types, FSharpList1 splices, Byte[] bytes) at Microsoft.FSharp.Quotations.FSharpExpr.Deserialize(Type qualifyingType, FSharpList1 spliceTypes, FSharpList`1 spliceExprs, Byte[] bytes)
at ...

I know it's a lawers question, but CLAHub would make things much easier than the current process.
https://www.clahub.com/

https://twitter.com/Codecutterman/status/555772302692872192 shows that previews are still published on Codeplex. One day this should move to Github. Very low prio - just as reminder ;-)

[originally from Connect]

This kind of F# code doesn't work when passing unit as a type argument. If this is an intentional design restriction, the error message should reflect this.

type EDF<'S> =
    abstract member Apply : int -> 'S
type SomeEDF1 () =
    interface EDF<int> with
        member this.Apply d = // OK
            123
type SomeEDF2 () =
    interface EDF<unit> with
        member this.Apply d = 
            // [ERROR] The member 'Apply : int -> unit' does not have the correct type to override the corresponding abstract method.
            ()

comments
dsyme wrote May 29, 2014 at 6:58 AM [x]
Yes, for F# 3.x this is an intentional design restriction, see http://stackoverflow.com/questions/4485445/f-interface-inheritance-failure-due-to-unit/4485677#4485677 for a longer analysis.

You might like to add an issue to http://fslang.uservoice.com to track this, as the F# language spec and implementation could in theory be adjusted to do the appropriate insertion of a "unit" value in the implementation of the override.

I agree that the error message should be improved here.

dsyme wrote May 29, 2014 at 7:17 AM [x]
To summarize - in F#, an abstract slot with declared return type of "unit" gets compiled in .NET IL as a return type of "void". In contrast, an abstract slot with declared return type of "T" gets compiled in .NET IL as a generic return type of "T", which when T is instantiated by "unit" becomes "unit". This means these two slots have logically different characteristics. This difference is one of the few places where the unit<->void translation performed by F# is visible and yes, it affects the overriding rules of the F# language.

@antofik asked about the compiler implementation here, specifically IsExactMatch and the check "returnTypesAEquiv" (here in the GitHub code: https://github.com/fsharp/fsharp/blob/6ac6318858da25fe4f1d4728901c5824e9f3bf3a/src/fsharp/tastops.fs#L874 - when will codeplex support links to individual lines :) ).

This operation compares optional TType values representing the return type of the member. None indicates that the return type is logically "void" from the perspective of F# overriding rules, Some(unit-type) or Some (T) indicates the return type is logically "unit" or "T" from the perspective of F# overriding rules.

In terms on nomenclature in the compiler:

• "CompiledForm" of a method signature means that return types are TType options,
  "None = type void", and "Some(T) = type T", and "Some(T) under substitution T-->unit = type unit".
• "FSharpForm" of a method signature means that return types are TType, and where "void" doesn't occur at all

Note that in the debugger, "None" shows as "null".

dsyme wrote May 29, 2014 at 7:21 AM [x]
To add a better error message, the logical place to put it would be here: https://github.com/fsharp/fsharp/blob/6ac6318858da25fe4f1d4728901c5824e9f3bf3a/src/fsharp/typrelns.fs#L1191

"IsExactMatch" would need to be duplicated and adjusted to a "IsExactMatchUpToInstantiatedUnitReturnType". If an override exists satisfying that predicate, then a better error message can then be given, much as for code already present to give a better error message when there is an override satisfying IsPartialMatch or IsNameMatch.
Cheers!
don

latkin wrote Jun 20, 2014 at 6:24 AM [x]

Updating the title to capture specific goal for short term. fslang uservoice can be used to track this as a potential change to the language itself.

[from fsbugs]

If one defines a generative type provider with some fields/properties, then creates 2 identical versions of that provided type:

type T2 = Samples.ShareInfo.TPTest.TPTestType
type T  = Samples.ShareInfo.TPTest.TPTestType

the resulting assembly contains invalid IL.

file attachments

• reproSln.zip

comments
latkin wrote Mar 24, 2014 at 4:22 PM [x]

[investigation from Vlad]
It looks like a bug in type relocation code in fsc.fs around ~1531.

Here we have 2 type reference T and T2 that point to one actual type definition so the final copy-and-update expression below will create 2 different ILTypeDefs that originate from the same ILTypeDef => they will share same set of members (up to reference equality) => later it will lead to unexpected consequences in codegen because we'll generate normal type T2 and type T where property definition uses metadata token of getter from the type T2 => invalid IL.

 let generatedILTypeDefs = 
    let rec buildRelocatedGeneratedType (ProviderGeneratedType(ilOrigTyRef, ilTgtTyRef, ch)) = 
        let isNested = ilTgtTyRef.Enclosing |> nonNil
        if allTypeDefsInProviderGeneratedAssemblies.ContainsKey ilOrigTyRef then 
            let ilOrigTypeDef = allTypeDefsInProviderGeneratedAssemblies.[ilOrigTyRef]
            if debugStaticLinking then printfn "Relocating %s to %s " ilOrigTyRef.QualifiedName ilTgtTyRef.QualifiedName
            { ilOrigTypeDef with 
                  Name = ilTgtTyRef.Name
                  Access = (match ilOrigTypeDef.Access with 
                            | ILTypeDefAccess.Public when isNested -> ILTypeDefAccess.Nested ILMemberAccess.Public 
                            | ILTypeDefAccess.Private when isNested -> ILTypeDefAccess.Nested ILMemberAccess.Assembly 
                            | x -> x)
                  NestedTypes = mkILTypeDefs (List.map buildRelocatedGeneratedType ch) }

Reported by a user on Twitter, but they have not followed up, so I'll open it here. The below code compiles, despite the illegal access:

module A =
    let mutable private x = 0

module B = 
    let test () =
        // let _ = A.x  // accessibility error on read, as expected
        A.x <- 1     // but write works!

This repros at least as far back as 3.0.

Originally opened by drvink on Codeplex

#I "/include1";;
#I "/include2";;
#r "assembly_expected_to_be_found_in_include1.dll";;
#r "assembly_expected_to_be_found_in_include2.dll";;

Only the second assembly will be found. This differs from the behavior of #I within FSI, where multiple #I invocations will add to the search path. The problem here is that from within a script file, you can only add a single directory to the search path, since neither of these work:

#I "/dir1;/dir2";;
#I "/dir1" "/dir2";;

The workaround is to use --lib on the command line, which allows separating multiple directories with semicolons, but then you need to write a wrapper script just to launch your real script file.

latkin wrote Nov 24, 2014 at 4:46 PM [x]

I do not repro this. Setting up the scenario as I understand it leads to expected behavior of both libraries being resolved without issue.

Can you attach a complete repro solution or provide additional details? Are you using Windows/Visual F# or *nix with a different distribution?

drvink wrote Nov 26, 2014 at 8:05 AM [x]

Sorry, I should have given more details. I'm on Windows 8.1 x64, F# 3.1.2. I have a file containing only the following:

#I @"C:\Users\msjp_000\Documents\Visual Studio 2013\Foo\packages\ExtCore.0.8.43\lib\net40";;
#I @"C:\Users\msjp_000\Documents\Visual Studio 2013\Foo\Foo\bin\Debug";;
#r "ExtCore.dll";;
#r "Foo.dll";;

open Foo

Both files exist and are valid assemblies. If I move the assemblies to a different directory (e.g. C:\Users\msjp_000\Desktop\foo and C:\Users\msjp_000\Desktop\foo2), it works.

latkin wrote Nov 26, 2014 at 5:51 PM [x]

Thanks for the clarification. So it appears the path itself might be part of what makes this repro or not?

It would be very helpful if you could attached a repro solution, or provide steps for anyone to deterministically repro.

drvink wrote Dec 3, 2014 at 3:34 PM [x]

OK, I've attached a project which reproduces it. Sorry for the delay.

Download here.

latkin wrote Dec 17, 2014 at 3:50 PM [x]

I have downloaded the project but I do not see any bug.
The sln builds fine.
I edited Compiled_scratch.fsx to use #I paths local to my box
Compiled_scratch.fsx then runs fine
Reference_bug.fsx contains invalid #loads for files that don't exist, so I assume that's not related
Scratch.fsx #loads Reference_bug.fsx, so it, too, understandably doesn't work
I'm still looking for a repro, would be interested to see if anyone else can reproduce the problem.

latkin wrote Dec 17, 2014 at 3:55 PM [x]

FWIW building the project drops Both ExtCore and Reference_bug into bin\debug, which I think defeats the purpose of the repro.

But it still works for me if I remove ExtCore.dll from bin\debug

Opened by: latkin

In the below code, intellisense no longer pops up at the specified point. It used to work ok in 3.1.X, but has stopped working in 4.0

type GT<'a> =
  static member P = 12
  static member Q = 13

let _ = GT<int>. <--- no intellisense here now, expecting list with 'P','Q'
let _ = GT.   <---- intellisense does still appear here

Testing it out on some older builds, this appears to have been introduced with the "constructors as first-class functions" feature.

comments

dsyme wrote Dec 11, 2014 at 1:35 PM [x]

What's the name of the specific IDE unit test that's failing? I'll aim to run them and make the fix tomorrow

latkin wrote Dec 11, 2014 at 2:12 PM [x]
UnitTests.Tests.LanguageService.AutoCompletionListTests, testcase Generics.GenericTypeMembers

latkin wrote Dec 11, 2014 at 2:30 PM [x]
Note that you'll need a build of VS 2015, plus the VS 2015 SDK, installed to run the IDE tests for fsharp4. You can get both from here http://www.visualstudio.com/en-us/downloads/visual-studio-2015-downloads-vs.aspx

[from fsbugs]
Repros in VS 2012, VS 2013.

Simplified repro

type T1<'TError>(xx:'TError) =
    member x.Foo() = T2.Bar(xx)
and T2 =
    static member Bar(arg) = 0

Original repro

type T1<'TError>(thisActuallyHasToBeHere:'TError) =
  member x.Foo() = T2.Bar(failwith "!" : option<'TError>)
and T2 =
  static member Bar(arg:option<_>) = 0;;

Causes error:
~vs9B68.fsx(7,17): error FS0073: internal error: Undefined or unsolved type variable: 'TError

comments
latkin wrote Mar 24, 2014 at 2:40 PM [x]
Workaround, move Foo to type augmentation:

type T1<'TError>(thisActuallyHasToBeHere:'TError) =
  member x.Foo1() = 0
and T2 =
  static member Bar(arg:option<_>) = 0;;
type T1<'TError> with
  member x.Foo() = T2.Bar(failwith "!" : option<'TError>)

Enable the distribution of Fsharp.Data.TypeProvider as a nuget package.

Opened by: eiriktsarpalis

The definition

type Foo =
    val foo : string

currently generates the following code (decompiled):

    public class Foo
    {
        internal string foo@;
        [CompilationMapping(SourceConstructFlags.Field, 0)]
        public string foo
        {
            get
            {
                return this.foo@;
            }
        }
    }

Is this correct behaviour? It does not seem to be recorded in the documentation (http://msdn.microsoft.com/en-us/library/dd469494.aspx) or the language spec.

I should note that this goes away as soon as I add the mutable keyword in the declaration. This might be intentional, since fields are always supposed to be mutable. But this feels wrong, particularly in the context of F# where the mutable keyword comes with a declaration of intention.

comments
dsyme wrote Today at 2:16 AM [x]
Yes, this is correct. We should make it clearer in the spec.

Opened at codeplex by latkin

Say I have a script that just prints out its arguments:

printfn "Args are: %A" fsi.CommandLineArgs

If I invoke this script via FSI using a full long path, it works as expected:
C:\Users\latkin> Source\Repos\visualfsharp\Debug\net40\bin\fsi.exe --exec test.fsx 1 2
Args are: [|"test.fsx"; "1"; "2"|]
But if I invoke with the 8.3 short path, it goes wrong:
C:\Users\latkin> Source\Repos\visual1\Debug\net40\bin\fsi.exe --exec test.fsx 1 2
Args are: [|"Source\Repos\visual1\Debug\net40\bin\fsi.exe"; "--exec"; "test.fsx"; "1"; "2"|]
This repros 100%, on 2 different machines, both debug and release, for open source output. It does not repro with official VS bits.

I spent some time debugging, and it’s not a problem with the command line arg parser. In the repro case, the InteractiveSession instance is being re-initialized a second time after CommandLineArgs is set, thus reverting back to its default value of Environment.GetCommandLineArgs(). I verified the dynamically generated IL for both cases is exactly the same.

Output with debug tracing:
C:\Users\latkin> Source\Repos\visualfsharp\Debug\net40\bin\fsi.exe --exec test.fsx 1 2
Initializing to Environment.GetCommandLineArgs
Just set fsi.CommandLineArgs to [|"test.fsx"; "1"; "2"|]
Args are: [|"test.fsx"; "1"; "2"|]

C:\Users\latkin> Source\Repos\visual1\Debug\net40\bin\fsi.exe --exec test.fsx 1 2
Initializing to Environment.GetCommandLineArgs
Just set fsi.CommandLineArgs to [|"test.fsx"; "1"; "2"|]
Initializing to Environment.GetCommandLineArgs
Args are: [|"Source\Repos\visual1\Debug\net40\bin\fsi.exe"; "--exec"; "test.fsx"; "1"; "2"|]
Fsi.fs

fsiaux.fs

comments
vladima wrote Apr 7, 2014 at 3:44 PM [x]
Seems that FSharp.Compiler.Interactive.Settings.dll was loaded twice and thus 2 instances of InteractiveSession were created.

• During fsi initialization FSharp.Compiler.Interactive.Settings.dll is loaded in Load context from .. visual~1/fsharp/Debug/net40/bin/
• When executing dynamically generated code FSharp.Compiler.Interactive.Settings is requested to be loaded to the LoadFrom context. During lookup it will be resolved in …/visualfsharp/fsharp/Debug/net40/bin/FSharp.Compiler.Interactive.Settings.dll. Here comes the juicy part (from FUSLOGW):

LOG: Attempting download of new URL file:///...visualfsharp/fsharp/Debug/net40/bin/FSharp.Compiler.Interactive.Settings.dll.
LOG: Assembly download was successful. Attempting setup of file: …\visualfsharp\fsharp\Debug\net40\bin\FSharp.Compiler.Interactive.Settings.dll
LOG: Entering run-from-source setup phase.
LOG: Assembly Name is: FSharp.Compiler.Interactive.Settings, Version=4.3.1.9055, Culture=neutral, PublicKeyToken=f536804aa0eb945b
LOG: Re-apply policy for where-ref bind.
LOG: Post-policy reference: FSharp.Compiler.Interactive.Settings, Version=4.3.1.9055, Culture=neutral, PublicKeyToken=f536804aa0eb945b
LOG: GAC Lookup was unsuccessful.
LOG: Where-ref bind Codebase does not match what is found in default context. Keep the result in LoadFrom context.
LOG: Binding succeeds. Returns assembly from …\visualfsharp\fsharp\Debug\net40\bin\FSharp.Compiler.Interactive.Settings.dll.
LOG: Assembly is loaded in LoadFrom load context.
WRN: The same assembly was loaded into multiple contexts of an application domain:
WRN: Context: Default | Domain ID: 1 | Assembly Name: FSharp.Compiler.Interactive.Settings, Version=4.3.1.9055, Culture=neutral, PublicKeyToken=f536804aa0eb945b
WRN: Context: LoadFrom | Domain ID: 1 | Assembly Name: FSharp.Compiler.Interactive.Settings, Version=4.3.1.9055, Culture=neutral, PublicKeyToken=f536804aa0eb945b
WRN: This might lead to runtime failures.

vladima wrote Apr 7, 2014 at 3:45 PM [x]

seems that workaround is simple: given that problem appears when ApplicationBase has 8.3 shape we can create a helper domain with an updated value of ApplicationBase and run all fsi code in it.

Smth like:

 [<EntryPoint>]
 [<STAThread()>] 
 let MainMain argv = 
ignore argv

let appDomainSetup = System.AppDomain.CurrentDomain.SetupInformation
appDomainSetup.ApplicationBase <- Path.GetFullPath(appDomainSetup.ApplicationBase)
let helperDomain = AppDomain.CreateDomain("helper-domain", null, appDomainSetup)
helperDomain.DoCallBack(fun() ->
let argv = System.Environment.GetCommandLineArgs()
…

>>>srivatsn wrote Apr 9, 2014 at 10:16 AM [x] 


>>>@vladima, if you've investigated this, we would welcome a pull request :)
>>>vladima wrote Apr 9, 2014 at 10:52 AM [x] 
>>>already done :)

>>>>KevinRansom wrote Jun 2, 2014 at 6:41 PM [x] 
>>>>This is a bug in the CLR, the pr is a neat work around, Howe er we would prefer the correct.fix.
>>>> ** Closed by KevinRansom 06/02/2014 6:41PM

>>>>>forki wrote Jun 3, 2014 at 1:46 AM [x] 
>>>>>I'd argue that a fix which works around a CLR bug is valuable since it might take a while to get the CLR changed. How is the process now? Can we track the CLR bug issue somehow? 

>>>>>>latkin wrote Jun 5, 2014 at 9:46 AM [x] 
>>>>>>I agree proposed workaround is not ideal and real CLR fix is preferred. That being said, the issue still exists, so it would be good to leave this open until we have a fix or resolution to offer - either a workaround in F#, or a patch from CLR team.

opened at CodePlex by: lasandell

I found what I think is a bug in the compiler, as demonstrated in the following F# Interactive session:

let () = raise (Exception("test")) "extra1" "extra2";;

System.Exception: test
at Microsoft.FSharp.Core.Operators.Raise[T](Exception exn)
at Microsoft.FSharp.Core.FSharpFunc2.InvokeFast[V,W](FSharpFunc2 func, T arg1, TResult arg2, V arg3)
at <StartupCode$FSI_0106>.$FSI_0106.main@()
Stopped due to error
As you can see, raise accepts and ignores an arbitrary number of additional arguments after the exception.
This also affects all functions based on raise, such as failwith. The way I initially found this was that I typed failwith when I meant to use failwithf, which caused my formatting arguments to be ignored even though it still compiled.

comments
StronglyTyped wrote Apr 9, 2014 at 8:40 PM [x]
It is not a bug, but the way the unification algorithm works.

failwith;;
val it : (string -> 'a)

value returned by failwith gets unified as a func of 2 args if you use it as

failwith "2121" 1 1;;

but it doesn't get applied.
In OCaml you can observe the same behavior:
% ocaml [0]
OCaml version 4.01.0

failwith "212" 1;;

Warning 20: this argument will not be used by the function.
Exception: Failure "212".

failwith "212" 1 2;;

Warning 20: this argument will not be used by the function.
Warning 20: this argument will not be used by the function.
Exception: Failure "212".

lasandell wrote Apr 9, 2014 at 8:50 PM [x]
Ah, I guess you're right. Seems a bit dangerous if you mistype failwithf as failwith, but what can you do?

lasandell wrote Apr 9, 2014 at 9:28 PM [x]
I guess printing the warning like OCaml does would be a solution.

StronglyTyped wrote Apr 10, 2014 at 9:57 AM [x]
It would be interesting to know an opinion of someone knowledgeable on having such a warning and if it does make sense create a work item for it.

JonHarrop wrote Apr 16, 2014 at 7:56 AM [x]
You could certainly add a warning for this and I think it would be valuable.

dsyme wrote Apr 16, 2014 at 8:34 AM [x]
Yes, it is reasonable to add a warning for this.
One approach would be to add the check in in check.fs (which performs checks in the TAST tree after type checking), looking specifically for raise, failwith and failwithf as "known functions" and checking that these are not applied to additional results. Breakpointing in check.fs would be one way to examine the TAST trees encountered. You may have to add the known functions to the TcGlobals in env.fs, using valRefEq to determine value reference equality.

latkin wrote Jun 5, 2014 at 10:35 AM [x]
Updating title to reflect current sentiment

Opened by: pavelhritonenko (contact)

Error while installing Visual F# Tools

[1D8C:14E0][2015-01-13T14:28:43]i338: Acquiring package: Preparation_Uninstall_FSharp_Bundle, payload: Preparation_Uninstall_FSharp_Bundle, download from:  http://go.microsoft.com/fwlink/?LinkId=451280&clcid=0x409
 [1BCC:0AA4][2015-01-13T14:28:46]e000: Error 0x800b0003: Failed authenticode verification of payload: C:\ProgramData\Package Cache.unverified\Preparation_Uninstall_FSharp_Bundle
 [1BCC:0AA4][2015-01-13T14:28:46]e000: Error 0x800b0003: Failed to verify signature of payload: Preparation_Uninstall_FSharp_Bundle
Full log in attach

file attachments

◾ dd_FSharp_Bundle_20150113142839.log [x] 

comments
KevinRansom wrote Today at 10:04 AM [x]

Hmm looks like they were unsigned bits. Let me investigate.

Hmmm I seem to be unable to attach a file that is not an image.:
Still there is always CodePlex :-)
Log file

Opened at CodePlex by: latkin

In F# queries with groupBy clauses, invalid query translation can occur.

Repro: Download bmovie-data.mdf from F# 3.0 Sample Pack, path OtherSamples\BMovieMadness\CSharpMvcApp\App_Data\bmovie-data.mdf

Run the following in script or console app

#r "FSharp.Data.TypeProviders"
#r "System.Data.Entity"

[<Literal>]
let connectionString = @"Data Source=(LocalDb)\v11.0;Initial Catalog=bmovie-data;Integrated Security=SSPI;AttachDBFilename=D:\en\fs3sample\OtherSamples\BMovieMadness\CSharpMvcApp\App_Data\bmovie-data.mdf"
type internal T = Microsoft.FSharp.Data.TypeProviders.SqlEntityConnection<ConnectionString = connectionString, ForceUpdate=false>

open System.Linq

let internal db = T.GetDataContext()
let userIds = [| System.Guid() |]

let topGenres = query {
    for u in db.Users do
    where (userIds.Contains u.UserId)
    for g in u.UserGenres do
    groupBy (g.GenreId) into gr
    let k = gr.Count()
    sortBy k
    select gr.Key
    }
topGenres |> Seq.take 1 |> Seq.toArray

Result: System.NotSupportedException: Only parameterless constructors and initializers are supported in LINQ to Entities.

Opened by ovatsus at CodePlex

EditorBrowsable(EditorBrowsableState.Never) doesn't work for F#. We can use CompilerMessageAttribute("message", IsHidden=true), but it's not exactly the same as it will also generate a warning message when that member is used. It also doesn't apply to C#, so that means we always have to have 2 attributes to achieve the same thing when working on libraries intended for use by both C# and F#

[from fsbugs]

Simplified repro:

type Frame = 
  class 
  end
module X =
  type Frame with
    member frame.GroupRowsBy(key) = ()
    member frame.GroupRowsBy(key) = ()

Issue: Signatures in extrinsic type extensions are not validated for uniqueness.

Opened at codeplex by: latkin

When F# queries which return tuples are composed or nested, the queries are not translated efficiently, resulting in client-side filtering where server-side filtering should have been possible.

This becomes very problematic in big-data scenarios: you test with a small data set and results look correct, but when you move to big data set you are unintentionally sucking down tons of data to the client when you thought the query resulted in server-side filtering.

Issue is related to the gymnastics done to swap in mutable tuples required during query translation, then switching back to immutable tuples on the output end.

Repro:

#r "FSharp.Data.TypeProviders"
#r "System.Data.Entity"
#r "System.Data.Services.Client"

open Microsoft.FSharp.Data.TypeProviders

type Northwind = ODataService< "http://services.odata.org/V2/Northwind/Northwind.svc/" >
let client = Northwind.GetDataContext()

client.DataContext.SendingRequest.Add (fun x -> printfn "requesting %A" x.Request.RequestUri)

Proper server-side filtering done here:
requesting http://services.odata.org/V2/Northwind/Northwind.svc/Customers()?$filter=substringof('S',ContactName)& $top=10 &$select=*
'''fsharp
let r =
query { for g in client.Customers do
where (g.ContactName.Contains "S")
take 10
select (g, 1) }

for (g, _) in r do
printfn "Name %s" g.ContactName

Improper client-side filtering done here when query is composed: 
requesting http://services.odata.org/V2/Northwind/Northwind.svc/Customers()?$filter=substringof('S',ContactName)&$select=*
```fsharp
let r1 = 
    let a = 
        query 
            { for g in client.Customers do  
              where (g.ContactName.Contains "S")            
              select (g, 1) }
    let b = 
        query { for g in a do take 10}
    b
for (g, _) in r1 do
    printfn "Name %s" g.ContactName

Similarly with nested queries:

let r2 = 
    let b = 
        query {
          for g in
            (query {
              for g in client.Customers do  
              where (g.ContactName.Contains "S")            
              select (g, 1) }
              ) do  
              take 10 }
    b

for (g, _) in r2 do
    printfn "Name %s" g.ContactName

I'm not sure if its just me but I had issues running tests on 64 windows.
It would be good to fix this or at least put notes in the Dev and Test guides.

Opened by: rojepp

When building, the file app.config gets copied to the output directory with a new name, programname.exe.config.

The up-to-date checker regards app.config as an output, causing needless rebuilds, here's what gets logged after enabling up-to-date check logging:

Output: 12/9/2014 9:44:03 AM C:\DEV\VGR\VUF\VUFCONSOLE\OBJ\X86\RELEASE\VUFCONSOLE.EXE
Output: 11/15/2013 1:48:33 PM C:\DEV\VGR\VUF\VUFCONSOLE\APP.CONFIG
Output: 12/9/2014 9:44:03 AM C:\DEV\VGR\VUF\VUFCONSOLE\BIN\RELEASE\NIBBLERCONSOLE.XML
Output: 12/9/2014 9:44:03 AM C:\DEV\VGR\VUF\VUFCONSOLE\OBJ\X86\RELEASE\VUFCONSOLE.PDB
Output: 12/9/2014 9:44:03 AM C:\DEV\VGR\VUF\VUFCONSOLE\BIN\RELEASE\VUFCONSOLE.EXE
Input: 12/9/2014 9:44:02 AM C:\DEV\VGR\VUF\VUFCONSOLE\VUFCONSOLE.FSPROJ
Input: 5/20/2014 8:54:02 PM C:\DEV\VGR\VUF\VUFCONSOLE\VUFCONSOLE.FS
Input: 6/2/2014 8:17:24 PM C:\PROGRAM FILES (X86)\REFERENCE ASSEMBLIES\MICROSOFT\FSHARP.NETFRAMEWORK\V4.0\4.3.0.0\FSHARP.CORE.DLL
Input: 3/18/2010 7:31:26 PM C:\PROGRAM FILES (X86)\REFERENCE ASSEMBLIES\MICROSOFT\FRAMEWORK.NETFRAMEWORK\V4.0\MSCORLIB.DLL
Input: 3/18/2010 7:31:26 PM C:\PROGRAM FILES (X86)\REFERENCE ASSEMBLIES\MICROSOFT\FRAMEWORK.NETFRAMEWORK\V4.0\SYSTEM.DLL
Input: 3/18/2010 7:31:26 PM C:\PROGRAM FILES (X86)\REFERENCE ASSEMBLIES\MICROSOFT\FRAMEWORK.NETFRAMEWORK\V4.0\SYSTEM.DATA.DLL
Input: 3/18/2010 7:31:26 PM C:\PROGRAM FILES (X86)\REFERENCE ASSEMBLIES\MICROSOFT\FRAMEWORK.NETFRAMEWORK\V4.0\SYSTEM.NUMERICS.DLL
Input: 12/9/2014 9:39:42 AM C:\DEV\VGR\VUF\VUF\BIN\RELEASE\VUF.DLL
Freshest input: 12/9/2014 9:44:02 AM
Stalest output: 11/15/2013 1:48:33 PM
Up to date: False

Note that app.config is listed as an output, when really it should be an input, and VufConsole.exe.config should be regarded an output. This means this console app rebuilds every time after app.config hasn't been touched in a while.

comments
latkin wrote Dec 9, 2014 at 10:22 AM [x]

Fixed with cb97ccb
BTW this is the same as #184

latkin wrote Dec 9, 2014 at 10:23 AM [x]
** Closed by latkin 12/09/2014 10:23AM

rojepp wrote Dec 9, 2014 at 11:37 PM [x]
I built the latest bits, and the fix seems to work. Thanks!

rojepp wrote Dec 9, 2014 at 11:41 PM [x]
ProgramName.exe.config should be counted as an output when checking for staleness.
This means a rebuild won't be triggered by manually editing the built config. To be fair, it works the same in C#, but I'd say it is a bug there as well.

latkin wrote Dec 17, 2014 at 4:39 PM [x]
This looks like an easy fix, item type is "AppConfigFileDestination", should be able to just add to the list of input item types.

latkin wrote Dec 17, 2014 at 4:40 PM [x]
Err, sorry. Need to include as an outpu

[From fsbugs]

When compiling below code with --optimize+, get internal error:
Program.fs(27,9): error FS0073: internal error: Undefined or unsolved type variable: 'TRange

namespace QuotationsProblem

open Microsoft.FSharp.Quotations

type Class1() =

    member private this.CompileQuery<'T>() =
        let kernel = System.Activator.CreateInstance<'T>()
        kernel

    member this.X (query: Expr<'TRange ->'a>) =
        let rng = ref Unchecked.defaultof<'TRange>
        let getStarterFuncton qExpr =
            let rec go expr vars =
                match expr with
                | Patterns.Lambda (v, body) -> Expr.Lambda(v, go body (v::vars))
                | e ->
                    let arr =
                        let c = Expr.NewArray(typeof<obj>,vars |> List.rev
                            |> List.map (fun v -> Expr.Coerce (Expr.Var(v), typeof<obj>)))
                        <@@
                            let x = %%c |> List.ofArray
                            rng := (box x.Head) :?> 'TRange
                        @@>
                    arr
            1
        getStarterFuncton query

(I know this is being considered. Just want to make it explicit for discussion.)

Setting up a public Continuous Integration would benefit both maintainers and contributors. It reduces workloads for maintainers in the long term. Once the solution works on CI, it's likely to work on arbitrary dev machines as well.

Since we have VS integration part, I suggest to use AppVeyor CI. It has been used on multiple VS extensions e.g. VsVim, Visual F# Power Tools with success.

I see a few immediate problems at the moment.

• We require quite a lot of prerequisite software https://github.com/Microsoft/visualfsharp/wiki/Required-Software.
• There isn't a single-click build and test process. It should be addressed by #15.
• VS integration build and testing requires extra work. But since VS unit tests use mocks; we don't need real VS instances in testing. We can make this work on CI by supplying correct dependencies.

Any ideas/thoughts?

[from fsbugs] Ported from Codeplex

Simplified repro of root cause:

let rec foo< > c = bar c
and bar c = 0

changing the order of lines 1 and 2 fixes the problem

Original repro:

 C:\Users\latkin\Desktop\FSharp.DataFrame-typar-error\FSharp.DataFrame-typar-error\src\Frame.fs(251,28): warning FS0073: internal error: Typar not found during XmlDoc generation

/// [category:Series operations]
member frame.SeriesApply<'T>(strict, f:Func<Series<'TRowKey, 'T>, ISeries<_>>) = 
    frame.Columns
    |> Series.mapValues (fun os ->
        match os.TryAs<'T>(strict) with
        | OptionalValue.Present s -> f.Invoke s
        | _ -> os :> ISeries<_>)
    |> Frame<'TRowKey, 'TColumnKey>.FromColumnsNonGeneric

Opened by jackfoxy on codeplex

12/18/14 daily build found this issue at runtime:

System.MissingMethodException : Method not fournd: SystemCollections.Generic IEqualityComparer'1

 let checkForColumnHeaderDifference (expected: seq<string>) (actual: seq<string>) =
    let expected = HashSet(expected, HashIdentity.StringIgnoreCase)

fails on "let expected = ..." 
 System.Collections.Generic.HashSet 

(Having problems getting the debugger to run to the affected line (VM issue) ...so I can't currently tell you the values of "expected" and "actual" coming into the function.)

comments
jackfoxy wrote Dec 23, 2014 at 7:55 PM [x]
Update: fixed my VM, and there is nothing remarkable about the data coming into the function, simply a string sequence of length 13.

latkin wrote Dec 23, 2014 at 10:20 PM [x]
Can you provide a ZIP of a repro solution?

A few other questions -- What version of FSharp.Core are you using? What .NET version/profile are you targeting? What is HashIdentity.StringIgnoreCase?

jackfoxy wrote Dec 24, 2014 at 10:13 AM [x]

I researched this issue on a VM on my work machine. I won't have access again until 1/5/15. If this issue is still open then I will attempt a repro solution.

The original app was built on FSharp.Core, 4.3.1.0. I simply changed the Target F# runtime to F#4.0 within the project property page of VS 2015 preview and rebuilt the solution within VS.

A repro app "should" just consist of the following:

open System.Collections.Generic

let checkForColumnHeaderDifference (expected: seq) (actual: seq) =
let expected = HashSet(expected, HashIdentity.StringIgnoreCase)
expected

>>>>vladima wrote Dec 24, 2014 at 11:14 AM [x] 

>>>>Given that FSharp.Core does not expose StringIgnoreCase on  HashIdentity module I suspect that repro should include something else (that presumably defines this extrinsic extension property)

>>>>>jackfoxy wrote Dec 24, 2014 at 11:33 AM [x] 

>>>>>@vladima right you are. I found this additional code:
````fsharp
module HashIdentity =
        let ByProjection (f: 'A -> 'B) (eq: IEqualityComparer<'B>) : IEqualityComparer<'A> =
            let hasher x = eq.GetHashCode(f x)
            let equality x y = eq.Equals(f x, f y)
            HashIdentity.FromFunctions hasher equality
        let StringIgnoreCase =
            HashIdentity.Structural<string>
            |> ByProjection (fun (x: string) -> x.ToLower())

vladima wrote Dec 24, 2014 at 11:51 AM [x]

Is this code located in the same project or in different dll? For the latter case - what version of FSharp.Core is referenced in this assembly?

vladima wrote Dec 24, 2014 at 12:01 PM [x]

Ok, I have a guess: can you check if autogeneration of binding redirects is enabled in the repro project (http://msdn.microsoft.com/en-us/library/2fc472t2%28v=vs.110%29.aspx), enable it if it is disabled and check if the problem still exists

jackfoxy wrote Dec 24, 2014 at 2:20 PM [x]
All the code is in the same project, and in fact in the same file.

There is no specified in the fsproj file, but there is true

Like I said above, I will not be able to work on the VM I have created for testing F#4.0 again until 1/5/15.

dsyme wrote Today at 1:23 AM [x]

It looks important to get to the bottom of this in case it is somehow related to the perf improvements for hash/compare/equality in F# 4.0 (though I think the likely solution is to add AutoGenerateBindingRedirects)

jackfoxy wrote Today at 5:00 PM [x]

My most recent research led me to suspect this issue involves the Target Framework .NET Portable Subset (.NET Framework 4.5, Windows 8) and Target F# runtime F# 4.0 (FSharp.Core, 3.7.4.0), but in attempting to set up a simple problem replication project that target framework is not available to me in VS2015, and the only target runtime available is F# 4.0 (FSharp.Core, 4.4.0.0).

As another issue in creating a replication project, my test environment somehow regressed to where I am failing on issue https://visualfsharp.codeplex.com/workitem/176, and I currently cannot replicate this reported issue. Fixing 176 should take precedence.

Opened by tomasp on CodePlex

When answering this StackOverflow question, I came across an odd behavior that appears to be a bug:

#r "FSharp.Data.TypeProviders.dll"
#r "System.Data.Linq.dll"
open System
open System.Data
open System.Linq
open Microsoft.FSharp.Data.TypeProviders

type dbSchema = SqlDataConnection< @"Server=.\SQLExpress;AttachDbFilename=C:\Temp\Northwind.mdf;Database=dbname;Trusted_Connection=Yes;">
let db = dbSchema.GetDataContext()

query {
    for p in db.Products do
    join c in db.Categories on (p.ProductID = c.CategoryID)
    groupBy p.CategoryID.Value into g
    select (g.Key, g.Select(fun (p, c) -> if p.ProductName = c.CategoryName then 1.0 else 0.0).Average()) }
|> Array.ofSeq

Running this gives the following message:

System.InvalidOperationException: Member access 'Products Item1' of 'System.Tuple2[Products,Categories]' not legal on type 'Microsoft.FSharp.Linq.RuntimeHelpers.Grouping2[System.Int32,System.Tuple`2[Products,Categories]].

It appears that somewhere during the translation, the translator attempts to generate (or process) code that accesses the Item1 property (which should be a property of the elements in the collection) as if it was a property of the entire grouping.

Is the F# library doing some pre-processing here? I remember that tuples were always a problem in F# queries, because they are immutable and so they behave differently than C# anonymous types (which the translator handles well)...

comments
latkin wrote Apr 24, 2014 at 12:56 PM [x]
Yes, we have rather nasty issues that arise due to immutable/mutable tuple conversions in queries. See this issue, for example.

tomasp wrote Apr 25, 2014 at 8:44 AM [x]
Thanks for the clarification! This makes sense - I remember trying to get that to work in some earlier versions of F# LINQ and it was pretty messy.
Could someone who knows the code share a few pointers to the relevant bits in the F# codebase? >>This sounds like an issue that people from the F# community could help to fix (because it is quite separate stand-alone component that can be modified without knowing everything about the compiler :-)).
I'm sure that with a bit of help & starting points, we could get a nice pull request for this one!

dsyme wrote Apr 28, 2014 at 7:28 AM [x]
The general area is here:
https://github.com/fsharp/fsharp/blob/65eb229125713caa2a97d85e6541313f9da4d9f7/src/fsharp/FSharp.Core/Query.fs#L1065
The implementation is non-trivial I'm afraid, one of the hardest parts of FSharp.Core

vladima wrote Apr 28, 2014 at 9:21 AM [x]
Some time ago I've prototyped implementation that 1) converts quotations to the shape similar to ETs produced by C# compiler 2) delays translation Tuple <-> AnonymousObject to the last step so query composition should not be affected by it. Maybe it is time to publish it as possible alternative that can replace existing implementation somewhere in the future (far far away)

Opened by henke

In Fsi:
[Loading X:\logary\src\Logary\WinPerfCounters.fs]
error FS0192: internal error: binding null type in envBindTypeRef: Generic IKEv1, AuthIP, and IKEv2

In C:\Program Files (x86)\Microsoft SDKs\F#\3.0\Framework\v4.0\Fsi.exe, Windows 8.1.
On this line of code:

Steps to repro:

1. start fsi
2. #load "WinPerfCounters.fs"

comments
henke wrote Aug 11, 2014 at 9:36 AM [x]
Also, IntelliSense doesn't show the symbols even after changing the commas to underscores.

Opened by: latkin

for loops over list seq and string all exhibit nice, consistent debug stepping behavior, but for loops over arrays don't work well at all. We should correct the debug range assignments here so that this is consistent.

See example here (VS 2013, "just my code" off, "managed compat mode" disabled)

Loops over ranges are also inconsistent, but at least usable, so as a lower priority item we should fix those, too.

Creating a [<CLIEvent>] within a module does not get exposed to C# the same as when they are on a class (either static or instance level): -

// On a module
module Foo =
    let private onBoo = new Event<string>()
    [<CLIEvent>]
    let Boo = onBoo.Publish

// On a class, instance level
type Bar() =
    let onBoo = new Event<string>()
    [<CLIEvent>]
    member __.Boo = onBoo.Publish 

// On a class, static
type Blah() =
    static member onBoo = new Event<string>()
    [<CLIEvent>]
    static member Boo = Blah.onBoo.Publish 

The last two can be consumed from C#, but the first one cannot: -

Foo.Boo += (o, e) => { }; // gives three compiler errors, see below
Blah.Boo += (o, e) => { }; // compiles
new Bar().Boo += (o, e) => { }; // compiles

Errors are: -

Cannot convert lambda expression to type 'Microsoft.FSharp.Control.IEvent<Microsoft.FSharp.Control.FSharpHandler<string>,string>' because it is not a delegate type
Operator '+=' cannot be applied to operands of type 'Microsoft.FSharp.Control.IEvent<Microsoft.FSharp.Control.FSharpHandler<string>,string>' and 'lambda expression'
Property or indexer 'Foo.Boo' cannot be assigned to -- it is read only

Indeed VS2013 in C# shows it as a property rather than an event in the intellisense.

[from auto-reported crashes]

Minimal repro:

type [<Measure>] N = foo // foo is undefined
type M2 = float<N>

This causes fsc to explode.

A number of internal errors are reported, then fsc crashes with Unhandled Exception: System.ArgumentException: not a measure abbreviation, or incorrect kind. Parameter name: tcref.

[investigation from Vlad]
Presumably error in reduceTyconRefAbbrevMeasureable is a cascading failure caused by some error upstream => it should be made more robust so exceptions won't be raised if abbreviation contains stub type created to handle errors.

Some of the F# PCL libraries support profiles 78 and 259 (support for consumption by Xamarin projects) but this isn't obvious when looking at the project descriptions when looking at them in visual studio. Someone developing a platform independent library intending to support Xamarin has no way of knowing these profiles will do what they want. I had to ask in a chat room in order to find out. Some sort of indication that these projects support profiles 78 and 259 would vastly improve discoverability.

comments

KevinRansom wrote Jan 2 at 10:49 AM [x]
I agree we should do something to make this clearer, after all Android and IOS programming are >very important use cases these days. Also the Visual Studio 2015 previews ship with a breadcrumb >to download the Xamarin VS add-in.

What do others think ?

Kevin

latkin wrote Jan 5 at 9:12 AM [x]
I agree it would be helpful to include the profile number in the project description. We could just >>add "(profile 259)" or similar at the end.

mydogisbox wrote Jan 5 at 9:43 AM [x]
Is there some way to make it more obvious than just the profile number? Unless someone is >>>familiar >with the meaning of profile numbers (I'm not), then they're just going to go off of the list >>>of supported >platforms which imply that it won't be consumable by Xamarin projects.

latkin wrote Jan 5 at 10:09 AM [x]
We have no control over how or if Xamarin chooses to use various portable profiles. They might >>>>add/drop/modify support for how these map to iOS or Android. And Xamarin is not, generally >>>>speaking, the only consumer of these libraries. So I think we should just stick to the facts.

mydogisbox wrote Jan 5 at 10:39 AM [x]
Ah, I didn't think of that. I guess that would be on Xamarin's end to publish which profiles they >>>>>support then.

Opened by antofik at codeplex

Currently, I rarely use the |> operator because of their opaqueness in the debugger, and instead have to resort to series of var names that end with more and more prime symbols. The latter is error-prone, and I'd like to be able to use |>s more confidently in my code.

This issue suggests that |> be made to generate a sequence point, at least in debug builds, so that break points can be placed on them. Additionally, the intermediate results of |> chains would have to be represented as a specially-named variable in VS's Locals variable viewer window.

Here's the CC'd conversation as Don and I discussed it on Twitter - https://twitter.com/bryanedds/status/460140352213504000

comments
KevinRansom wrote Apr 28, 2014 at 11:13 AM [x]
This is a great suggestion, we would certainly be interested in seeing PRs to address this.

antofik wrote Nov 24, 2014 at 12:29 AM [x]
Changing match case for SynExpr.Iden in UntypedParseInfo.ValidateBreakpointLocationImpl(range), ServiceUntypedParse.fs:124 enables us to set breakpoint on |> while in "Edit" mode. But while you are in "Debug" mode, breakpoint continues to slide to the whole line. It looks as if breakpoint changes location while changing state from Pending to Bind.
And I cannot find in code nor implementation of IVsDebugger, nor implementation of IDebugPendingBreakpoint2. Am I correct assuming that F# uses some default debug engine?

brodyberg wrote Nov 24, 2014 at 7:43 AM [x]
That's interesting, I'll see if I can repro that and look for the other interfaces you mention.

brodyberg wrote Nov 24, 2014 at 7:59 AM [x]
Oh, one thing I gathered from speaking with Don Syme is that information is being lost at optimization time - for this reason I have been investigating this from the point of view of opt.fs, with a view toward identifying the information the structure has before and after optimization such that we can preserve information so the breakpoint remains after being optimized away.

antofik wrote Nov 25, 2014 at 12:35 PM [x]
brodyberg, it's quite easy to reproduce. Replace SyncExpr.Ident with following snippet (ServiceUntypedParse.fs163, walkExpr function:

                 | SynExpr.Ident op ->
                    if rangeContainsPos op.idRange pos then
                        match op.idText with
                        | "op_PipeRight" -> yield! checkRange op.idRange
                        | _ -> ()
                    else ()

Optimization - that's quite understandable, though several questions arise. First, who is revalidating breakpoint after LanguageService has validated them? Second, we certainly would like to see intermediate results when stopped on |> instruction, so we need to add some autos (like $exception). But I cannot see how it can be done without direct access to the debug engine. Any ideas?

antofik wrote Nov 26, 2014 at 5:43 AM [x]
Or, while in DEBUG mode, we can substitute |> definition with something like

let (|>) x f = 
     let intermediate_result = f x
     ignore() // here we will place breakpoint
     intermediate_result

Ovatsus opened this at CodePlex

On this line:
https://github.com/fsharp/FSharp.Data/blob/a28caf225e4165acc0088ee2d24c470b139586f7/tests/FSharp.Data.Tests/JsonProvider.fs#L595

InteliSense instead of showing the actual fields (ApprovedBy, Author, ..., SubredditId, Ups) shows fields related to SI units that I have no idea where they are coming from:

Both compilation and fsi evaluation is fine, though

For more details see fsprojects/FSharp.Data#591

Opened by: swlaschin2

I can reproduce this error in FSI in VS2012 , VS2013 and in tryFsharp.org

• In VS2012 and VS2013
  error FS0192: internal error: binding null type in envBindTypeRef
• In tryFsharp.org (as of 2014-12-09)
  error FS0193: internal error: Error 0x2115.
  Here is a minimal example that causes the error:

// fails to compile
// error FS0192: internal error: binding null type in envBindTypeRef
let ``1,`` x = 
    [||] |> Array.fold (+) ","

But minor variants of the code do compile!

// remove comma from function name and it compiles, so the function name is involved?        
let ``1`` x = 
    [||] |> Array.fold (+) ","
// change fold to map and it compiles, so something to do with fold as well?        
let ``1,`` x = 
    [||] |> Array.map ((+) "")

Not sure if it is related to: #10

Opened by corado at codeplex

Given a generative type provider. Take the example from the sample pack: GeneratedTypeProvider
And the following usage of it:

module FSharpLib

type Test = Samples.ShareInfo.TPTest.TPTestType

type Test with
    member x.Extension = 42

let t = Test()
printfn "%i" (t.F1(1))

The type Test should be Intrinsically extended with the Extension property as the type is defined in the same file but this will fail to build with the error:

/SampleProviders/GeneratedTypeProvider/ConsoleApplication2: Error FS0192: internal error: FindTypeDefBuilder: Test not found (FS0192) (ConsoleApplication2)

comments
ReedCopsey wrote Apr 25, 2014 at 12:03 PM [x]
Using VS 2013, I get the same issue with my XAML Type provider. However, the error message is slightly different. Given:

 type App = XAML<"App.xaml">

 type App with
member self.Foo = 42

[<STAThread>]
 [<EntryPoint>]
 let main argv = 
let app = App()
printfn "%d" app.Foo
app.CreateRoot().Run()

I get:
Error 3 The field, constructor or member 'Foo' is not defined

7sharp9 wrote Apr 25, 2014 at 1:12 PM [x]
Is that error given on build?

ReedCopsey wrote Apr 25, 2014 at 1:50 PM [x]
Yes. I get that at compile time.

Nunit has released a stable version 2.6.4 when I try to build the tests with 2.6.4 installed it fails, because it can't load the 2.6.3 version of the nunit assembly.

comments

forki wrote Jan 6 at 7:14 PM [x]

This should better be solved like in the FAKE pull request. The test framework is solution dependent >and I should not have to install it at all. Otherwise it will always conflict with other solutions.

Opened at CodePlex by ovatsus
[from https://github.com/fsharp/fsharp/issues/278](from fsharp/fsharp#278)

Let's say we have an F# project consistent of two files (this is the minimum to be able reproduce this):

File A.fs:

namespace Project

type DU = A | B

File B.fs:

namespace Project

type B = { Prop : DU }

This compiles fine. If you now want to test this on a script file:

#load "A.fs"
#load "B.fs"

If you evaluate this, you'l get this error:

[Loading c:\users\guguer\documents\visual studio 2013\Projects\ConsoleApplication2\A.fs]

namespace FSI_0002.Project
  type DU =
    | A
    | B

> 
[Loading c:\users\guguer\documents\visual studio 2013\Projects\ConsoleApplication2\B.fs]


B.fs(3,19): error FS0039: The type 'DU' is not defined
> 

There is a workaround, which is to include open Project on B.fs, but it's not obvious. On big projects, and for new users, this is a stumbling block that makes things look broken.

Similar issues happen with modules instead of namespaces.

Opened on codeplex by ovastus:
Existing F# projects won't open if only VS2015 is installed

These 2 conditions present on most projects will fail if only VS2015 is installed:

<PropertyGroup Condition="Exists('$(MSBuildExtensionsPath32)\..\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.FSharp.Targets')">`
     <FSharpTargetsPath>$(MSBuildExtensionsPath32)\..\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.FSharp.Targets</FSharpTargetsPath>
     </PropertyGroup>
     <PropertyGroup Condition="Exists('$(MSBuildExtensionsPath32)\..\Microsoft SDKs\F#\3.1\Framework\v4.0\Microsoft.FSharp.Targets')">
     <FSharpTargetsPath>$(MSBuildExtensionsPath32)\..\Microsoft SDKs\F#\3.1\Framework\v4.0\Microsoft.FSharp.Targets</FSharpTargetsPath>
</PropertyGroup>

The workaround is simple, install the F# 3.1 bundle, but for a new user trying the language for the first time this can be a blocker. This sort of thing never happens in C#, but whenever there is a new F# version we always bump into these kinds of problems :(
Could the installer maybe bundle F# 3.0 and 3.1 together with 4.0?

comments
latkin wrote Jan 5 at 9:06 AM [x]

Those conditions are not present in the standard project templates included in VS. Where are you >getting that config from?

The standard project imports the targets file like so:

<Choose>
    <When Condition="'$(VisualStudioVersion)' == '11.0'">
      <PropertyGroup Condition="Exists('$(MSBuildExtensionsPath32)\..\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.FSharp.Targets')">
        <FSharpTargetsPath>$(MSBuildExtensionsPath32)\..\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.FSharp.Targets</FSharpTargetsPath>
      </PropertyGroup>
    </When>
    <Otherwise>
      <PropertyGroup Condition="Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\FSharp\Microsoft.FSharp.Targets')">
        <FSharpTargetsPath>$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\FSharp\Microsoft.FSharp.Targets</FSharpTargetsPath>
      </PropertyGroup>
    </Otherwise>
  </Choose>
  <Import Project="$(FSharpTargetsPath)" />

There is a backcompat check for 3.0 that points directly at the targets file, but everything since then (3.1+) has been picked up by a shim file that's dropped to C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v%VSVERSION%\FSharp. It's this file that actually points to the real targets file. You automatically get the latest targets file when you open in the latest VS.

The "Rational Units of Measure" feature changes encoding of existing F# 3.x metadata.

This causes strong failure when using FSharp.Core 4.4.0.0 with F# 3.x tools (was: using fsharp.sln with VS2013 Update 3/4)

For example, when using src\fsharp.sln with Visual Studio 2013 I get no Intellisense in any project. This is relatively new - previously I've always been able to use this combination to develop F#.

Opened by: hmemcpy on codeplex
Hello,

I noticed I had an update for FSharp Tools in my VS2013, so I downloaded and installed it.
After that, I could no longer compile ANY F# projects - even creating a new console app/library would fail compilation with the following:

Same exact thing happened on my other machine also running VS2013 Update 4 - after installing the latest F# tools and rebooting the machine, I had the same exact problem!

I changed the version of FSharp.Core (under references) to 4.3.0.0 instead of 4.3.1.0, and the problem went away!

What am I doing wrong?

Please let me know if you need additional information.

comments

KevinRansom wrote Dec 4, 2014 at 10:23 AM [x]

Did you install VS 2014 preview 3 or 4 on your machine. We had a bug where we were placing the wrong Fsharp.core.dll in the 4.3.1.0 reference and that unfortunately broke VS 2013. Because of the way setup works it wasn't even repairable. The work around was to copy the correct 4.3.1.0 dll into the references directory.

The thread is here: https://visualfsharp.codeplex.com/workitem/154 could you check to see if this was the same issue for you?

latkin wrote Dec 4, 2014 at 10:25 AM [x]
I changed the version of FSharp.Core (under references) to 4.3.0.0 instead of 4.31.1.0, and the problem went away!

Do you mean 4.3.1.0, not 4.31.1.0?

Errors like that will occur when for whatever reason the compilation ends up referencing FSharp.Core out of the GAC, rather than from proper place in %programfiles%\Reference Assemblies...

Curious, does the same issue occur if you do command-line build with msbuild? If so, you can try to get more info by running msbuild /verbosity:Detailed, and it will dump out the reference resolution logic as it goes. That might point to where the failure is.

Opened by steffen on codeplex

Hi,

first of all congratulations to making this big step and taking contributions. Kudos.

I wonder if you are interested in changing the current build scripts to a FAKE build script. I think it is pretty successful in the F# open source world (e.g FSharp.Compiler.Services) and might help here too. I know there are lots of things to consider and the F# compiler is much more important.

Please tell me what you think.

Cheers Steffen

comments
bleis wrote Apr 4, 2014 at 3:03 AM [x]
Hi,
I don't think that we should use FAKE.
FAKE is a good tool, but FAKE has many problems to be used widely.
1.FAKE.exe runs too slowly.
.FAKE uses AutoOpen too much. It makes difficult to understand the build script. In the build script, "commit" and "Commit" has entirely a different meaning.
3.FAKE uses AutoOpen too much. Then, we always have to be very carefully to extend FAKE.
4.FAKE script is hard to read, because it does not have a variable expansion. So we have to use sprintf.
5.FAKE has record types for each external tools. However it does not cover all the parameter.
6.When an external tool is updated, we need extra work to modify the corresponding record type that is defined in the FAKE.
7.When we don't want to set some parameters, we have to set null for them explicitly.

I think that we should use MSBuild. It is enough extensible, and already integrated with Visual Studio and NuGet.

igeta wrote Apr 4, 2014 at 3:10 AM [x]
@bleis +1

Gab_km wrote Apr 4, 2014 at 4:09 AM [x]
I agree with @bleis, but I think we can argue freely about better build tools for F#.

dsyme wrote Apr 4, 2014 at 5:22 AM [x]
My feeling is that FAKE isn't quite right for this repo (though I love the tool and don't feel any of the problems mentioned above).

First, this repo isn't a packaging repo: the Visual F# Team do their own build+packaging, and https://github.com/fsharp/fsharp will be the packaging repo for the OSX/... edition of F# for some time to come. The thing I love about FAKE is how easy it makes packaging.
Second, we need to get a few other things sorted out first (like how to flow changes from here to https://github.com/fsharp/fsharp, what bug fixes to accept, how to enable automated cross-platform testing etc. etc.)

pocketberserker wrote Apr 4, 2014 at 5:53 AM [x]
I don't think that we should use FAKE.
1.The compiler projects should adopt a standard build tool for that environment.
2.FAKE is not a standard build tool for F#.

forki wrote Apr 7, 2014 at 12:09 AM [x]

Actually I don't propose to replace MSBuild in any way. It's still the best tool to compile .NET projects.

That said, browse through the issues on this repo. You will find lots of issues where someone copies 10 or more MSBuild calls to reproduce the problem. I don't think that makes it easy to compile and test your code contributions. What I really want to see is a scripted version of this magic MSBuild/testrunner/ngen invocation. It doesn't need to be FAKE.

yukitos wrote Apr 7, 2014 at 5:53 AM [x]
@forki
What I really want to see is a scripted version of this magic MSBuild/testrunner/ngen invocation.
+1
How about creating a master MSBuild file to invoke all other MSBuild files?
Optional: I want to have a *.bat to run the master file without starting up Developer Command Prompt for VS.

latkin wrote Jun 5, 2014 at 9:57 AM [x]
Updating the title to reflect current sentiment - that there should be a single "BuildAll.bat" or similar that groups together all of the separate compilations that are required today.