1

Closed

CompiledNameAttribute issue

description

The normal behaviour of adding a CompiledNameAttribute to a member declaration is that the F# compiler changes its name and puts a CompilationSourceNameAttribute in its place that indicates the F# name of the member.

However, decompiling FSharp.Core made me notice the following strange code being generated for ExtraTopLevelOperators.async :

[CompilationMapping(SourceConstructFlags.Value), CompiledName("DefaultAsyncBuilder")]
public static FSharpAsyncBuilder DefaultAsyncBuilder
{
get
{
    return $Fslib-extra-pervasives.DefaultAsyncBuilder@155;
}
}

It is the only declaration in this module that carries the original CompiledNameAttribute. I tried building FSharp.Core in my own machine and got identical results. There is no apparent difference between the async declaration that fails and the others that work. This looks like a compiler bug, though it is not clear to me what is to blame.

EDIT

This behaviour seems to be occurring consistently with annotated types. Is this intentional? Or a bug?
Closed Jan 27, 2015 at 11:05 PM by KevinRansom
managed at github

comments

latkin wrote Nov 27, 2014 at 1:12 AM

Do you have a repro scenario where this actually negatively affects users?

If you are just curious about design/quirks of the compiler or runtime, I would recommend starting a discussion thread at https://visualfsharp.codeplex.com/discussions.

eiriktsarpalis wrote Nov 27, 2014 at 2:58 PM

Yes, I'm working on a small project that converts F# quotations into untyped ASTs for FSCS (https://github.com/eiriktsarpalis/QuotationCompiler). In order for the conversion to work, I need to be able to recover the CompilationSourceNameAttribute from MemberInfo. If the attribute is missing, this is impossible.

dsyme wrote Nov 29, 2014 at 11:28 AM

Hi Eirik,

This will likely be because "async" is compiled as a value-compiled-as-a-property rather than a function-compiled-as-a-method

It should be fixed, but that won't help you with older versions of FSharp.Core (4.3.0.0, 4.3.1.0 etc.) If it's the only case of the issue in FSharp.Core then just adding a special case for it seems reasonable.

Cheers
Don

eiriktsarpalis wrote Nov 29, 2014 at 6:10 PM

It might be because it is a value, but I haven't been able to replicate this in code of my own. Also, the same problem happens consistently when the attribute is applied to types, both in FSharp.Core and user code.

dsyme wrote Nov 29, 2014 at 10:11 PM

I do repro this when I compile some simple code like this:
    [<CompiledName("Foo1")>]
    let x = System.DateTime.Now

    [<CompiledName("Foo2")>]
    let f () =  System.DateTime.Now
I see a CompiledNameAttribute on the property for "x", and no CompilationMappingAttribute, and vice-verse for "f". The behaviour for "f" is correct.

So yes, the CompiledName attribute is not being filtered, and the CompilationMapping attribute is not being added. The problem area is around here https://github.com/fsharp/fsharp/blob/master/src/fsharp/ilxgen.fs#L4807

Basically, "CompiledName" really shouldn't be used with F# module-level values like this, and really should never have been applied to this specific "async" value - it isn't used for the "query" value, for example It may be that the best resolution is to add that to the documentation (CompiledName isn't used that much in F# code and is really mostly used on FSharp.Core types).

From your side I do think the best resolution is to hardwire this particular use of CompiledName on the "async" value.