FSharp fixes #3357

mlaily · 2021-10-11T20:24:54Z

Hello !

This is a follow up PR for #3348.

I realized some things were not optimal or needed fixing...

I did not create a new issue. Let me know if this is ok or if you prefer I create a new one...

Changes

fix: Stop highlighting type names everywhere. Only match them in type annotations.
- Since the names are not reserved and can be re-used for variable/binding names shadowing, it can be confusing and misleading.
enh: Highlight operators. Operators are a big part of F#, so highlighting them brings a lot of value for legibility, etc...
enh: Support quoted identifiers (``...``. They can contain pretty much anything inside the double backquotes)
fix: Fix type names and symbols matching
- Type names can contain apostrophes.
- Type symbols can contain quoted identifiers, but no apostrophes.
enh: Match attributes in more places (not just at the start of a line), and match more of the things they can contain (not just basic strings and numbers).

Checklist

Added markup tests
Updated the changelog at CHANGES.md

Since the name are not reserved and can be used for variable/binding names, it can be confusing and misleading.

* Type names can contain apostrophes. * Type symbols can contain quoted identifiers, but no apostrophes.

* We now highlight operators. * Type names are no longer highlighted globally. * I added new tests (operator examples in operators.txt, identifier edge cases in types.txt)

src/languages/fsharp.js

joshgoebel · 2021-10-12T12:08:44Z

src/languages/fsharp.js

+    scope: 'operator',
+    // Try to match all valid combinations
+    match: regex.either(
+      /<?@@?>?/,


If we're not doing this in an array (is there a good reason that can't work?) please add comments above each line breaking these out for readability. This is usually much harder to maintain than a simple list/array though.

I could decompose most of the patterns in individual operators (is that what you meant?), but it would probably take a lot more space.

I'll try another approach...

Readability trumps space. This all gets gzipped for most people anyways. At some point maybe one could argue speed (of the more complex regex)... but long-term it'd still be nicer to have a "pretty" readable array and then some brains to compile that into "smart" regex (such tools exist I think)... rather than having more difficult to read regex and no pretty list.

I was offering you the choice though. 😀 If we leave them compacted I'd like to see what they are intending to match written above them as a rough "guide".

I simplified operators matching, though I had to add a CHAINED_DOT_GUARD that feels a bit hacky. Let me know what you think...

joshgoebel · 2021-10-12T12:10:06Z

src/languages/fsharp.js

        begin: /^\s*\[</,
-        excludeBegin: true,
-        end: regex.lookahead(/>\]/),
+        end: />\]/,


So you've expanded this to include the <> inside the scope now?

Yes, because now that I added operators, I didn't want the [< and >] around an attribute definition to be highlighted as operators.

Actually I had to change this because as it was before it was not symmetric: IIRC the begin part was not assigned any scope, but the end was matched as an operator.
I had to choose between matching everything as meta, matching begin and end as operators, or excluding both the begin and the end.
Matching everything as meta seems like a good compromise, and it can be changed later on if needed.

I had to choose between...

No... you could also have used a multi-matcher to match the <, content, > separately while only applying the scope to the content, if that would have been preferable. As long as the rule consumes it another rule (operator) won't match it.. ie:

match: [ /</ , ... , />/ ], scope: { 2: "meta" }

You get the idea.

Sure!
The only issue with a multi-matcher is that I don't see how to use both a multi-matcher and contains for nested modes.

Honestly I don't know what's preferable between highlighting the brackets or not. Both seem fine.

The only issue with a multi-matcher is that I don't see how to use both a multi-matcher and contains for nested modes.

Can you give a specific example you're having difficulty with? Both begin and end can individually be multi-matchers with contains in-between.

Let's say I wanted to define a beginning ([<), an end (>]), and declare that everything in between that's not in contains has a meta scope.

Would a multi-matcher be appropriate? Matching the attribute name is a bit tricky because the syntax of an attribute can be relatively complex.

Here are some examples:

[<Attribute>] // simple attribute [<Attribute("attribute with a string value and an int", 42)>] // But they can also contain a target: let function1 x : [<return: MyCustomAttributeThatWorksOnReturns>] int = x + 1 // And quoted identifiers! // (which can contain almost anything and should very much be added to `contains` // to avoid breaking everything if it looks something like ``my evil <] attribute name``) [<``module``: MyCustomAttributeThatWorksOnModules>]

I found that simply applying a meta scope on the whole mode is the easiest, but I could be missing something.

If we don't want to highlight the begin and the end, it's then easy to just add excludeBegin: true and excludeEnd: true (a look-ahead on end would allow other modes, namely the OPERATOR one, to highlight it wrongly, and I couldn't find a way to use beginScope or endScope to reset the scope just for begin and end)

I may still be lost my point was only that you're fully in charge of scopes.. if you wanted to exclude the boundaries [< and >] you could do that either with exclude* or with multi-match... but if you wanted JUST to say highlight them multi-match is good at that.

And nothing about multi-match precludes using contains... contains has a chance to run immediately after begin/match. You'd think it requires end, but every mode has an end it's just "match anything" for modes with no explicit end... but that still allows for contains rules to trigger in between begin and "match anything".

Though in this case we do have an obvious beginning and end, so if you were using contains you'd probably use the obvious begin/end combo.

Let's say I wanted to define a beginning ([<), an end (>]), and declare that everything in between that's not in contains has a meta scope.

You can't do this though... scopes are over-arching - they don't turn on and off when they find rules in the middle. So either the WHOLE construct would be meta or you'd have to individually pick things to be meta with sub-rules inside contains.

(a look-ahead on end would allow other modes, namely the OPERATOR one, to highlight it wrongly

Right I wasn't suggesting this. We use look-ahead on end when we WANT that behavior (to not consume)... when we do want to consume then a normal end is perfect. (which can be excluded or part of a non-scoped multi-match)

If you don't have this "perfect" to your satisfaction yet perhaps a small code example with the desired perfect HTML would show me what you're trying to do?

I may still be lost my point was only that you're fully in charge of scopes.

Ok, I got that^^

If you don't have this "perfect" to your satisfaction yet perhaps a small code example with the desired perfect HTML would show me what you're trying to do?

Thank you for proposing your help. I generally know how to obtain the results I want (in the worst case by trial and error). It's just that I'm never completely sure if I'm doing it by the book. (With you suggesting a multi-matcher, I was wondering if I misunderstood something)

Anyway, honestly I'm not even certain how it should be highlighted 😅
I think highlighting the whole thing — boundaries included — is best for now, so if that's ok with you I will stay with something like the following:

{ // e.g. [<Attributes("")>] or [<``module``: MyCustomAttributeThatWorksOnModules>] scope: 'meta', begin: /\[</, end: />\]/, contains: [ QUOTED_IDENTIFIER, // can contain any constant value TRIPLE_QUOTED_STRING, VERBATIM_STRING, QUOTED_STRING, CHAR_LITERAL, NUMBER ] }

(I find the biggest difficulty in all this is to refrain myself from adding unrelated adjustments each time I'm seeing a new case that's not highlighted correctly. I know I have to stop somewhere if I want you to review it, but it's very difficult!!)

I think highlighting the whole thing — boundaries included — is best for now,

We can try it and see how it works in practice... seems like a reasonable start even if later the meta needs to be toned down a bit.

I find the biggest difficulty in all this is to refrain myself from adding unrelated adjustments each time I'm seeing a new case that's not highlighted correctly. I

Yeah... but good news is you can always open a new PR after. And if you manage your commits properly you can just keep working and then pull them into a new PR after - though that's harder with lots of dependent changes.

joshgoebel · 2021-10-12T12:13:03Z

Since the names are not reserved and can be re-used for variable/binding names, it can be confusing and misleading.

Is this common though? Losing types feels like a real loss.

mlaily · 2021-10-12T12:50:15Z

Since the names are not reserved and can be re-used for variable/binding names, it can be confusing and misleading.

Is this common though? Losing types feels like a real loss.

I think naming a variable or a function parameter char or list for example happens enough that it is a problem.

Another problem is that the hard-coded list of primitive types we had previously is a bit arbitrary anyway: why should char be highlighted, but not System.Char?
I'm inclined to think doing 80% of the job is better than doing nothing, but here we are both wrongly matching things and also missing a lot of other things (types not in the list). I feel like it's more misleading than useful.

The more correct way to do this would be to highlight type annotations from the context, but it turns out it's more difficult to do properly than I initially thought...

I'd rather remove the fixed list of type names now, and maybe somebody can implement type annotation highlighting from context later.

In the meantime, I'm not sure it's actually that big of a loss: F# uses type inference extensively to assign a type to things, and type annotations are added only when the compiler cannot deduce a type based on context, which is not that often. See the tour of F# as an example, and look for type annotations (look for what's generally after a :).

We probably match some invalid combinations, but we also match custom operators better (in one span instead of several)

mlaily · 2021-10-12T18:58:32Z

Well, I thought I would give highlighting type annotations another try...

It seems to work well for the cases I tested, but the grammar is a bit complicated despite my efforts.

There is at least one documented bug for a syntax I didn't know was possible...

joshgoebel · 2021-10-17T21:47:47Z

src/languages/fsharp.js

+  const TYPE_ANNOTATION = {
+    scope: 'type',
+    begin: regex.concat( // a type annotation is a
+      /:/,               // colon


Does F sharp not using : for ternary or object attributes, etc?

There is no ternary in F#, and I'm not aware of any usage of : other than to create a type annotation.

The symbol and operator reference seems to confirm this.

BTW, I found the F# grammar used by the main F# VsCode extension: https://github.com/ionide/ionide-fsgrammar/blob/master/grammars/fsharp.json
I'm not sure how useful it is for highlight.js, but this is certainly a good resource to look at...

There is no ternary in F#, and I'm not aware of any usage of : other than to create a type annotation.

If true that's a stroke of luck... :)

joshgoebel · 2021-10-17T21:51:06Z

src/languages/fsharp.js

+  const OPERATOR = {
+    scope: 'operator',
+    // Try to match all valid combinations, maybe a bit more (but not that much since custom operators are possible)...
+    match: /[<>@~&^+=:%*!$\/\?\|\-\.]+/,


This is the opposite of what we discussed. We want the entire list broken out so we can easily read it and update it in the future - and prevent false positives, etc. Even the first iteration of OPERATOR was better (had it been commented to list the operators each regex was catching)...

Even if there is a "catch-all" for custom operators that should be separate from catching the built-in operators. Eventually we may need to manage the relevance on these things and having them broken out is a huge boon.

Sorry, I naively thought matching any combination of this list of operator characters would be a welcomed simplification.

I'll go back to an expanded list.

Perhaps welcomed until we have to debug/fix/improve it one day or try to adjust the relevance of individual operators in the future. :-) We'd probably have different policies if we were dealing with a single perfect grammar rather than 180 that have to happily co-exist with each other in complex ways. :)

joshgoebel · 2021-10-20T17:19:54Z

src/languages/fsharp.js

+
+  const CHAINED_DOT_GUARD = {
+    // Prevent the dot in Name.Name patterns from being matched as an operator.
+    match: /(\w|')\.(\w)/,


Should this match the whole expression though? This will break for something like:

Name.nkeyword

Where this would guard the e.n but then keyword would be highlighted as a keyword. No?

Yes you are absolutely right, I spotted this only after committing.

This whole mode is a hack that I hope I will be able to remove once I rewrite operator matching.

And follow the official grammar more closely

In favor of supporting some annotations that cannot be matched otherwise.

- Add the `get` built_in so it's symmetric with `set` - Fix matching the end of tupled types - Set type annotation relevance to 0 to fix language auto-detection - Fix an edge case for type definition matches The biggest changes are for attributes: - They don't have to be at the beginning of a line anymore - They can contain multiple sub-modes

mlaily · 2021-10-24T17:29:02Z

Summary of the latest commits:

I merged main into my branch.
I added a changelog since there was a release before my PR could be merged.
I decided to stop supporting multi-line type annotations. There is a comment explaining the rationale (Without more context, some type annotations can only be matched when a line ends)
I rewrote operator matching, following more closely the F# spec and official grammar (https://fsharp.org/specs/language-spec/ direct link: https://fsharp.org/specs/language-spec/4.1/FSharpSpec-4.1-latest.pdf)
- There is still a big-ish character set, but it's actually from the F# spec so I don't think splitting it more than that would be a good idea. I listed operators outside of this set explicitly in a separate list.

I left a TODO with several alternative ways to declare the range of operator characters. I'm not sure which one you prefer so let me know. The syntax currently in use has the advantage of properly escaping all the regex characters (I wasted an hour because I hadn't escaped a - before I did that...)

const OPERATOR_CHARS = Array.from("!%&*+-/<=>@^|~?");
  const OPERATOR_CHAR_RE = regex.concat('[', ...OPERATOR_CHARS.map(regex.escape), ']');
  // TODO: choose one of the alternative definitions:
  // const OPERATOR_CHAR_RE = regex.either(...OPERATOR_CHARS.map(regex.escape));
  // const OPERATOR_CHAR_RE = /[!%&*+\-\/<=>@^|~?]/;

joshgoebel · 2021-10-24T22:04:12Z

src/languages/fsharp.js

+  const PARENS_TYPE_ANNOTATION = {
+    begin: /\(/,
+    end: /\)/,
+    relevance: 0
+  };
+  const ANONYMOUS_RECORD_TYPE_ANNOTATION = {
+    begin: /{\|/,
+    end: /\|}/
+  };
+  const TYPE_ANNOTATION = {


What are these two rules accomplishing?

They prevent the TYPE_ANNOTATION mode from ending when a ) or |} that is part of a nested type annotation is found.

e.g.

// The type of myBinding is an anonymous record, // whose X label is also an anonymous record: let myBinding: {| X: {| Nested: bool |}; Y: string |} = () // f is a function returning a bool whose // first argument is a function taking a string an returning an int: let f: (string -> int) -> bool = ()

These modes are mutually recursive, so their contains are defined further down.

joshgoebel · 2021-10-25T23:01:58Z

Is &&&&&&&&&&&&&&&&&& a valid symbolic operator in f# then?

joshgoebel · 2021-10-26T00:39:55Z

I've taken a much closer look at the type stuff now. It's going to need some changes. In general (in the core library) we do not support "run-on" or large block scopes. class and function used to attempt this, but those have been deprecated and are on the way out replaced by title.class (only highlight the name, etc) - we don't care about the semantics or knowing what is an isn't the class body.

meta is one of the rare exceptions to this rule (and we're still working on that long-term). IE, a named keyword scopes should highlight a single keyword or small group and then end. Technically there are long-forms such as string, comment, etc. but it's easy to see how those are edge cases and not comparable.

Now it's possible you could still use TYPE_ANNOTATION for providing the context.. perhaps we bring back the static list of known types but only highlight them when inside TYPE_ANNOTATION, etc... but we should not be applying extended scopes that can go on and on and on...

IE:

Good: This keyword here, "string" is a primitive type.
Bad: This 150 character sequence with lots of different syntax we may like to highlight is a type [definition].

We [mostly] only care about the individual keywords. We don't care about the larger syntactic "type definition". I'm sure we break this rule in other grammars, but it's usually either historic or out of laziness and it's something we should fix there as well, not encourage further.

mlaily · 2021-10-26T06:46:35Z

Is &&&&&&&&&&&&&&&&&& a valid symbolic operator in f# then?

Yes!

Now it's possible you could still use TYPE_ANNOTATION for providing the context.. perhaps we bring back the static list of known types but only highlight them when inside TYPE_ANNOTATION, etc... but we should not be applying extended scopes that can go on and on and on...

IE:

Good: This keyword here, "string" is a primitive type.

Bad: This 150 character sequence with lots of different syntax we may like to highlight is a type [definition].

We [mostly] only care about the individual keywords. We don't care about the larger syntactic "type definition". I'm sure we break this rule in other grammars, but it's usually either historic or out of laziness and it's something we should fix there as well, not encourage further.

I would argue that a type annotation is not a type definition and it's usually much shorter, but I understand your point, and it's true annotations can get big and have a relatively complex syntax as you may have seen in the examples..

Can you confirm the issue is not the size of the grammar, but the output with type being applied to a big expression?

I decided to highlight almost the whole annotation the same way because it was easier, but I guess I could be more picky and only highlight the actual type names. The grammar would probably be a bit bigger. Would that be ok?

joshgoebel · 2021-10-26T08:32:11Z

I would argue that a type annotation is not a type definition

Forgive me, mixing up languages or terminology, but I think you got the point.

Can you confirm the issue is not the size of the grammar, but the output with type being applied to a big expression?

Well, it's not either/or exactly... though typically complexity is what I care about more than size. And when things start to smell too much like "parsers"... we try to be largely a simple pattern matcher the core grammars, we don't try to be a contextual grammar parser for individual languages.

Right now we have a single nested context ("type annotation") with clear & clearly commented start and end conditions, so that seems "ok" I think... though as soon as F# adds ternary or other uses of : all this might go out the window completely since we might lose the ability to detect one : from another :.

only highlight the actual type names. The grammar would probably be a bit bigger.

How so, other than adding the list of type name back?

mlaily · 2021-10-26T09:36:11Z

only highlight the actual type names. The grammar would probably be a bit bigger.

How so, other than adding the list of type name back?

I really wanted the hard coded type list to go. Without any context it's almost meaningless, and if we keep the TYPE_ANNOTATION for context, it would be strange to only highlight simple types.

typically complexity is what I care about more than size. And when things start to smell too much like "parsers"... we try to be largely a simple pattern matcher the core grammars, we don't try to be a contextual grammar parser for individual languages.

Ok. I was trying to keep it simple too, but there are always edge cases that don't work unless we add context.

I'll see if I can find a solution without adding more complexity, but maybe only highlighting some known type names when they are after what looks like a type annotation is indeed a good enough compromise...

joshgoebel · 2021-10-27T18:22:41Z

Yes I think I do have good heuristics, but they look a lot like the parsers you don't like, so I'm not sure what to keep. :)

Then since you have them lets keep them and try and get the insides right.

What do you mean by rules? Coloration rules?

MODES, for contains inside of TYPE_ANNOTATION.

mlaily · 2021-10-27T18:29:39Z

I'm sorry I'm not sure I follow. Do you mean you want to get rid of the mutually recursive modes inside the main TYPE_ANNOTATION?

If so, I will see what I can do yes.

joshgoebel · 2021-10-27T19:37:39Z

No, I was only saying that type needs to be removed from the context [parent] MODE and then added to all of the children modes when they represent a named type. And this may require some new modes to be added for things you weren't explicitly matching before, like custom types...

mlaily · 2021-10-27T19:39:35Z

Oh ok, thanks for the clarification.

It's impossible to do a clean job without parsing much of the grammar, so instead we are going back to a list of known types... What's new compared to before is that we now have a simple type annotation context detection, and are only matching these known type names in this context.

mlaily · 2021-11-01T16:32:29Z

Well, I tried to continue matching type annotations without a hard-coded list of types while keeping it simple, but I don't think I will be able to get to something that does not break without parsing much more of the F# grammar.

So I decided to follow your advice and stop trying to be perfect. I went back to a hard-coded list of known types that I only highlight when a type annotation context is detected.

The parsing logic is much more simple, and it does a reasonable job for known types.
It leaves all the unknown types as is, which I think is a better alternative than trying to parse everything and failing partially for no good reason xx% of the time (from the point of view of a user).

I'm awaiting your feedback. BTW there is still the // TODO: choose one of the alternative definitions: that should be addressed line 256, if you could tell me which way you prefer.

src/languages/fsharp.js

joshgoebel · 2021-11-03T01:07:10Z

Sorry to only comment on small stuff for now, I think this is looking better overall but I'll need more time to more carefully review it later.

…NNOTATION

src/languages/fsharp.js

joshgoebel · 2021-11-17T13:35:01Z

test/markup/fsharp/operators.expect.txt

 <span class="hljs-keyword">open</span> Microsoft.FSharp.Quotations
 <span class="hljs-comment">// A typed code quotation.</span>
-<span class="hljs-keyword">let</span> expr : Expr&lt;<span class="hljs-type">int</span>&gt; = &lt;@ <span class="hljs-number">1</span> + <span class="hljs-number">1</span> @&gt;
+<span class="hljs-keyword">let</span> expr <span class="hljs-operator">:</span> Expr<span class="hljs-operator">&lt;</span><span class="hljs-type">int</span><span class="hljs-operator">&gt;</span> <span class="hljs-operator">=</span> <span class="hljs-operator">&lt;@</span> 1 <span class="hljs-operator">+</span> 1 <span class="hljs-operator">@&gt;</span>


What happened to number here getting lost? Should 1 not still be a number?

Was just about ready to pull the trigger on merge until this caught my eye.

Oops! Well spotted, this is a little embarrassing...

This should be fixed now.

'=' is supposed to end a type annotation, but since the type annotation can contain operators, '=' was being consumed as content instead... I also removed the TODO with commented-out code (initially added for discussion, but it might not have been the right place)

# Conflicts: # CHANGES.md

mlaily · 2021-11-22T21:14:52Z

Hello,

Sorry for the delay.
I missed some github notifications and didn't realize I had things to change before this PR could be merged!

It should be ok now, hopefully...

joshgoebel · 2021-11-29T19:29:17Z

src/languages/fsharp.js

+  const OPERATOR = makeOperatorMode(true);
+  // This variant is used when matching '=' should end a parent mode:
+  const OPERATOR_WITHOUT_EQUAL = makeOperatorMode(false);


true and false have no meaning (in context) and as such are difficult to read... use named arguments/object literals instead:

const OPERATOR = makeOperatorMode({ includeEqual: false});

Ok!

It's the first time I use destructuring like that, so let me know if I did something wrong.

joshgoebel · 2021-11-29T21:01:01Z

@mlaily Thanks for all the time and effort!

joshgoebel · 2021-11-29T21:02:00Z

Can you confirm your change list (in the PR notes) is correct [or update it] so I can use that as the content for the squashed commit comments...

mlaily · 2021-11-29T21:22:34Z

Can you confirm your change list (in the PR notes) is correct [or update it] so I can use that as the content for the squashed commit comments...

If you are referring to the description of the PR/the first comment, I reviewed and updated it.

@mlaily Thanks for all the time and effort!

Thank you very much for reviewing this PR. I'm sorry it ended up this big and took so many back and forths.

mlaily added 6 commits October 11, 2021 22:11

fix(fsharp) Stop highlighting type names

b938810

Since the name are not reserved and can be used for variable/binding names, it can be confusing and misleading.

enh(fsharp) Highlight operators

32b3520

enh(fsharp) Support quoted identifiers

044c1de

fix(fsharp) Fix type names and symbols matching

aae45ed

* Type names can contain apostrophes. * Type symbols can contain quoted identifiers, but no apostrophes.

(chore) Fix F# markup tests

c9a4603

* We now highlight operators. * Type names are no longer highlighted globally. * I added new tests (operator examples in operators.txt, identifier edge cases in types.txt)

(chore) Fix indentation

feb36e1

joshgoebel reviewed Oct 12, 2021

View reviewed changes

src/languages/fsharp.js Outdated Show resolved Hide resolved

joshgoebel reviewed Oct 12, 2021

View reviewed changes

mlaily added 2 commits October 12, 2021 17:10

fix(fsharp) Simplify operator matching

98956cb

We probably match some invalid combinations, but we also match custom operators better (in one span instead of several)

enh(fsharp) Highlight type annotations

f0b7af9

joshgoebel reviewed Oct 17, 2021

View reviewed changes

joshgoebel reviewed Oct 20, 2021

View reviewed changes

mlaily added 6 commits October 24, 2021 18:31

enh(fsharp) Match operators more precisely

9235ddc

And follow the official grammar more closely

fix(fsharp) Drop support for multi-line type annotations

393e74e

In favor of supporting some annotations that cannot be matched otherwise.

Merge remote-tracking branch 'origin/main' into fsharp-fixes

447230f

(chore) Add changelog

01fdfe3

fix(fsharp) Fix operator character set escaping

229ee29

joshgoebel reviewed Oct 24, 2021

View reviewed changes

mlaily added 6 commits November 1, 2021 17:03

chore(fsharp) Extract type declaration mode to a const

dc375f3

enh(fsharp) Highlight type declarations better

f3b5486

doc(fsharp) Add doc and examples

34754e0

(chore) Update changelog

a155a98

chore(fsharp) Re-generate and fix tests

f7ec676

joshgoebel reviewed Nov 3, 2021

View reviewed changes

src/languages/fsharp.js Outdated Show resolved Hide resolved

joshgoebel reviewed Nov 3, 2021

View reviewed changes

src/languages/fsharp.js Show resolved Hide resolved

mlaily added 2 commits November 6, 2021 13:54

chore(fsharp) Rename DU_TYPE_ANNOTATION to DISCRIMINATED_UNION_TYPE_A…

e469da0

…NNOTATION

fix(fsharp) Fix and simplify GENERIC_TYPE_SYMBOL

e4f9ce8

joshgoebel reviewed Nov 15, 2021

View reviewed changes

src/languages/fsharp.js Outdated Show resolved Hide resolved

joshgoebel reviewed Nov 16, 2021

View reviewed changes

src/languages/fsharp.js Show resolved Hide resolved

joshgoebel reviewed Nov 17, 2021

View reviewed changes

mlaily added 2 commits November 22, 2021 22:08

Merge remote-tracking branch 'origin/main' into fsharp-fixes

8c63feb

# Conflicts: # CHANGES.md

joshgoebel reviewed Nov 29, 2021

View reviewed changes

mlaily and others added 2 commits November 29, 2021 21:17

chore(fsharp) Use named argument to make usage clearer

f851b1f

Merge branch 'main' into fsharp-fixes

998cb0c

joshgoebel approved these changes Nov 29, 2021

View reviewed changes

joshgoebel merged commit 238e073 into highlightjs:main Nov 29, 2021

FSharp fixes #3357

FSharp fixes #3357

Uh oh!

Conversation

mlaily commented Oct 11, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changes

Checklist

Uh oh!

Uh oh!

joshgoebel Oct 12, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

joshgoebel Oct 12, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

joshgoebel Oct 19, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

joshgoebel commented Oct 12, 2021

Uh oh!

mlaily commented Oct 12, 2021

Uh oh!

mlaily commented Oct 12, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mlaily commented Oct 24, 2021

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

joshgoebel commented Oct 25, 2021

Uh oh!

joshgoebel commented Oct 26, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mlaily commented Oct 26, 2021

Uh oh!

joshgoebel commented Oct 26, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

mlaily commented Oct 11, 2021 •

edited

Loading

joshgoebel Oct 12, 2021 •

edited

Loading

joshgoebel Oct 12, 2021 •

edited

Loading

joshgoebel Oct 19, 2021 •

edited

Loading

mlaily commented Oct 12, 2021 •

edited

Loading

joshgoebel commented Oct 26, 2021 •

edited

Loading

joshgoebel commented Oct 26, 2021 •

edited

Loading

joshgoebel commented Oct 27, 2021 •

edited

Loading

joshgoebel Nov 17, 2021 •

edited

Loading