FS0192: internal error: null: GetTRefType

[vasily-kirichenko]

I updated FSharp.Formatting package in FSharp.Configuration to 2.7.1 and tried to generate docs. It crashes with

FS0192: internal error: null: GetTRefType

on https://github.com/fsprojects/FSharp.Configuration/blob/master/docs/tools/generate.fsx#L95-L102 (I mean if I evaluate the script function-by-function, incrementally, the error appears when I evaluate the highlighted lines).

If I revert to 2.6.2, the docs are generated OK.

What I can found is only this blog post http://blog.mavnn.co.uk/strange-errors-from-the-f-compiler/index.html/ my @mavnn

[tpetricek]

You need to add #r to reference the VS PowerTools dependency. With this change it should work.

[forki]

That will break a lot of consumers, right? Can't you ilmerge?

[vasily-kirichenko]

Yes, it's helped. BTW, the snippets are too colorful for my taste. Patterns are too bright and I don't think we need to highlight operators now. My idea was to mimic Visual Studio C# editor colors + add a new color for F# DUs/active patterns. Don't get me wrong, I naturally love new coloring :) but the following snippet is a bit too much

Maybe removing patterns colorization or choosing a different color for them would make better results? (However, I don't understand dark themes in general, so maybe it's ok as is).

[tpetricek]

I suppose IL merge would make sense - @vasily-kirichenko do you have any thoughts on that? Can I get one of you guys to send a PR for this :-)?

As for the too bright colours - I agree. I experimented a bit with a version that had orange keywords and various yellow-ish tones for strings/formatters/escaped and various blue-ish tones for modules/types/DUs. I think it looked better because similar things had similar colours. I'll send a PR with that.

[tpetricek]

How about this:

It uses yellow-ish colours for strings etc. and aqua-ish colours for identifiers etc.; I made comments gray to make it a bit less colourful.

[matthid]

Just an idea/alternative to IL merge: Is the #r really required? If not just bundling the dll in the nuget package would be enough (like RazorEngine)?

If yes we could just bundle a simple .fsx script, which loads all required references in the FSharp.Formatting nuget package. Users would just #load this script (which gets updated with the package). This would break users one time though.

This would solve similar issues like this in the future (as this is not the first issue with references in FSharp.Formatting).

[tpetricek]

Using #load would be a reasonable alternative, I think (that's what Deedle, R provider and FsLab do...).

@forki Do you have an opinion on this?

[tpetricek]

Given that the change also breaks Deedle tests on Travis, I think that ILMerge would probably be nice....

[vasily-kirichenko]

@tpetricek Yes, your new colors is much better. Great. About merging. @forki uses ILRepack in Paket: https://github.com/fsprojects/Paket/blob/master/build.fsx#L135-L150. @forki do you recommend this approach? Maybe we could go with --standalone?

[forki]

As soon as https://github.com/gluck/il-repack/issues/72 gets fixed I'll always recommend ilrepack. At the moment the latest doesn't work for me.

[tpetricek]

I think ILRepack (the version 1.22.2 which works) would be good.

We don't want to merge FSharp.Core.dll into F# Formatting, because the public API exposes F#-specific types like options - so using --standalone would break things.

[tpetricek]

Hmm, I'm giving up on this.

Using ILRepack seems like a good idea, but it fails on Mono (see Travis log) - I had unspecified issues with it on Mono previously too (when trying to use it in R provider), so I just think it isn't ready yet.

--standalone isn't going to work either, because we do not want to inline FSharp.Core.dll.

I'll add the load script as a more reliable and future proof alternative though.