Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Further enhancements to nameof #8754

Merged
merged 20 commits into from
Aug 4, 2020
Merged

Further enhancements to nameof #8754

merged 20 commits into from
Aug 4, 2020

Conversation

Tarmil
Copy link
Contributor

@Tarmil Tarmil commented Mar 19, 2020

Feature suggestion: https://github.com/fsharp/fslang-design/blob/master/FSharp-5.0/FS-1085-nameof-pattern.md

  • Implementation
  • Add tests
  • Check syntax coloring
  • Check code completion

@dnfclas
Copy link

dnfclas commented Mar 19, 2020

CLA assistant check
All CLA requirements met.

@CartBlanche
Copy link

@Tarmil Will you be updating this?

@Tarmil
Copy link
Contributor Author

Tarmil commented Jun 2, 2020

Yeah I'll get back to this soon, hopefully the conflict shouldn't be too hard to resolve.

@dsyme
Copy link
Contributor

dsyme commented Jun 19, 2020

I've merged master into this. I'll likely integrate the changes into a final PR for nameof

@dsyme
Copy link
Contributor

dsyme commented Jun 19, 2020

This is now ready - it now contains all the design adjustments for nameof

  • nameof in patterns
  • nameof for operators returns the source text
  • Further testing for nameof on generic parameters

@cartermp cartermp changed the title [WIP] Allow using nameof in pattern matching Further enhancements to nameof Jun 19, 2020
@KevinRansom
Copy link
Member

Error on neg16.fs:


 + neg16.fs(116,9,116,13): typecheck error FS0879: Volatile fields must be marked 'mutable' and cannot be thread-static
diff between [D:\a\1\s\tests\fsharp\typecheck\sigs\neg16.bsl] and [D:\a\1\s\tests\fsharp\typecheck\sigs\neg16.vserr]
line 92
 - neg16.fs(113,9,113,11): typecheck error FS0879: Volatile fields must be marked 'mutable' and cannot be thread-static
 + neg16.fs(130,10,130,11): typecheck error FS0935: Types with the 'AllowNullLiteral' attribute may only inherit from or implement types which also allow the use of the null literal
diff between [D:\a\1\s\tests\fsharp\typecheck\sigs\neg16.bsl] and [D:\a\1\s\tests\fsharp\typecheck\sigs\neg16.vserr]
diff at line 92
- 
- neg16.fs(116,9,116,13): typecheck error FS0879: Volatile fields must be marked 'mutable' and cannot be thread-static
- 
- neg16.fs(130,10,130,11): typecheck error FS0935: Types with the 'AllowNullLiteral' attribute may only inherit from or implement types which also allow the use of the null literal
"
  Stack Trace:
     at Microsoft.FSharp.Core.PrintfModule.PrintFormatToStringThenFail@1639.Invoke(String message) in D:\a\1\s\src\fsharp\FSharp.Core\printf.fs:line 1639
   at SingleTest.singleVersionedNegTest@451-41.Invoke(String arg60) in D:\a\1\s\tests\fsharp\single-test.fs:line 451
   at SingleTest.singleVersionedNegTest(TestConfig cfg, String version, String testname) in D:\a\1\s\tests\fsharp\single-test.fs:line 451
   at SingleTest.singleNegTest(TestConfig cfg, String testname) in D:\a\1\s\tests\fsharp\single-test.fs:line 453
   at FSharp.Tests.Core.TypecheckTests.type check neg16() in D:\a\1\s\tests\fsharp\tests.fs:line 2399
  Standard Output Messages:
 ------------------ D:\a\1\s\tests\fsharp\typecheck\sigs ---------------

@dsyme
Copy link
Contributor

dsyme commented Jul 15, 2020

@KevinRansom @cartermp this is ready

Copy link
Contributor

@cartermp cartermp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is missing test cases for patterns - at a minimum, the example from fsharp/fslang-suggestions#841 should be used

@dsyme
Copy link
Contributor

dsyme commented Jul 17, 2020

This is missing test cases for patterns - at a minimum, the example from fsharp/fslang-suggestions#841 should be used

thanks, will add those now

@cartermp cartermp closed this Jul 23, 2020
@cartermp cartermp reopened this Jul 23, 2020
@abelbraaksma
Copy link
Contributor

From the original post by @Tarmil here I noticed two unchecked items that I didn't see in the commits, are these tracked/added elsewhere or already part of this PR? Namely, syntax coloring and code completion.

image

@cartermp
Copy link
Contributor

@cartermp
Copy link
Contributor

Same failure - I feel like it should either be deleted or moved to non-FSharpQA since there's no diagnostics on why it failed

@dsyme
Copy link
Contributor

dsyme commented Jul 27, 2020

@cartermp I agree

Tbh I've confirmed the case by hand, I think we can deal with this separately.

So as far as I'm concerned this is now ready

Copy link
Contributor

@cartermp cartermp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can see where #7416 is resolved in the code. Is there a way to verify #8661 in tests at all? I guess it's tricky since everything has the same name in source, so it's a name resolution test and not an integration test. I don't quite understand name resolution enough to see how that gets resolved. But the test coverage here is adequate for the scenario so I'd like to get this in for people to use in the next round of previews.

let resolvedToModuleOrNamespaceName =
if delayed.IsEmpty then
let id,rest = List.headAndTail longId
match ResolveLongIndentAsModuleOrNamespaceOrStaticClass cenv.tcSink ResultCollectionSettings.AllResults cenv.amap m false true OpenQualified env.eNameResEnv ad id rest true with
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that with open type declarations coming in this call may no longer do what is assumed, see here: https://github.com/dotnet/fsharp/pull/9513/files#diff-dbb9e59b8ac1e1e04e1b00282a91ec97R2192

Does that have any impact? I would expect not...

@TIHan
Copy link
Contributor

TIHan commented Jul 29, 2020

I'm going to be looking at this today.

Copy link
Contributor

@TIHan TIHan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of having nameof be a special case in name resolution, couldn't we just add an Obsolete attribute with this message?:

[<Obsolete("'nameof' is not supported in this version of your compiler.")>]
let nameof<'T> = ..

This will prevent older compilers from calling it.
Newer compilers will ignore the Obsolete attribute. When it detects it's using an older language version, just throw an error saying it's not supported in this version, use tryLanguageFeatureErrorRecover from ErrorLogger to perform the check and raise the error.

It feels a bit icky to have nameof be a special case in name resolution. Ultimately, we just want an error at the end of the day.

@KevinRansom
Copy link
Member

Instead of having nameof be a special case in name resolution, couldn't we just add an Obsolete attribute with this message?:

nameof has existed in FSharp.Core for over a year, so deprecating it will not reliably work. :-(

Copy link
Member

@KevinRansom KevinRansom left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this work.

Kevin

@TIHan
Copy link
Contributor

TIHan commented Jul 30, 2020

nameof has existed in FSharp.Core for over a year, so deprecating it will not reliably work. :-(

nameof is preview and its implementation throws an exception as it's treated specially by the compiler. It's fine that we put an Obsolete attribute on it.

@dsyme
Copy link
Contributor

dsyme commented Jul 31, 2020

@KevinRansom shouldn't nameof have this?

        [<Experimental(ExperimentalAttributeMessages.RequiresPreview)>]

@cartermp
Copy link
Contributor

The experimental attribute is only while things are in preview. Since we are moving nameof to F# 5 (which is still in preview, so no guarantees about current behavior as-shipped yet), that attribute was removed. We're also removing it for most other things now that we're nearing the end of the development cycle.

@cartermp
Copy link
Contributor

The current experience today is that you can still call nameof in non-F# 5 code, but it's a compile error. So if Obsolete makes that a bit clearer, that's great. If it filters nameof out of a completion list for older F# users, then that's also great.

@dsyme
Copy link
Contributor

dsyme commented Jul 31, 2020

I am trialling this, it should do the trick for giving a reasonable message to old compilers a25541a

@dsyme
Copy link
Contributor

dsyme commented Jul 31, 2020

I am trialling this, it should do the trick for giving a reasonable message to old compilers a25541a

If this doesn't give the result we need then we can forget it I think

@dsyme
Copy link
Contributor

dsyme commented Jul 31, 2020

THis is ready to go

@KevinRansom
Copy link
Member

KevinRansom commented Jul 31, 2020

@dsyme , attributes on nameof are not going to be particularly helpful, because the method has already shipped in fsharp.core.dll since I think 4.7.0. I suppose it would help, when trying to build an updated fsharp.core, however, it would be a breaking change due to the fact it's already shipped. Even though a successful build against an old library is merely a runtime error.

@cartermp
Copy link
Contributor

I'm fine with the outcome of this. nameof was only ever supported as preview and subject to change. Anyone who is bitten by this will simply have to make a change due to the preview nature of the feature.

I think in practice people aren't going to really be hit by this though.

@dsyme
Copy link
Contributor

dsyme commented Aug 1, 2020

Yes, I think adding the attribute is best regarded as a good bug fix.

@KevinRansom
Copy link
Member

Certainly there is no harm doing so.

@dsyme
Copy link
Contributor

dsyme commented Aug 1, 2020

Let's merge this baby and enable this in 5.0

Copy link
Contributor

@TIHan TIHan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes look good. Thank you @Tarmil for kick-starting the enhancements.

I think this is now ready.

@TIHan TIHan merged commit ae5c1db into dotnet:master Aug 4, 2020
abelbraaksma pushed a commit to abelbraaksma/fsharp that referenced this pull request Aug 9, 2020
* Implement `nameof x` as a constant pattern

* Resolve ident to find `nameof` in patterns

* fix build

* fix build

* re-enable tests

* fix test

* fix operators

* align code

* test and fix pattern matching

* fix 8661, 7416

* fix tests and error messages

* 'fix test'

* 'fix test'

* add message for C# and old compilers

* fix build

* suppress error 3501 when a compiler supports nameof

Co-authored-by: Don Syme <dsyme@microsoft.com>
nosami pushed a commit to xamarin/visualfsharp that referenced this pull request Feb 23, 2021
* Implement `nameof x` as a constant pattern

* Resolve ident to find `nameof` in patterns

* fix build

* fix build

* re-enable tests

* fix test

* fix operators

* align code

* test and fix pattern matching

* fix 8661, 7416

* fix tests and error messages

* 'fix test'

* 'fix test'

* add message for C# and old compilers

* fix build

* suppress error 3501 when a compiler supports nameof

Co-authored-by: Don Syme <dsyme@microsoft.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants