JetBrains
Open namespace issues
Few issues I've come across repeatedly:
- Rider sometimes adds the open above the first line (above namespace/module), not sure why
- Rider cannot deal very well with multiple namespaces in the same file, it gets confused where to put the open causing the open to have no effect on the code you're writing.
- Rider does not take
AutoOpeninto account when it opens from a function suggestion, causing the auto opened module to be added unnecessarily into the completion too.
There's a related issue at the Rider tracker for it: RIDER-27924.
I'm trying to fix/workaround most of the known problems with symbols import in 2020.1, and 1 and 2 are already fixed in a branch.
Ah that's welcome.
About 3, I guess similarly it should take into account RequireQualifiedAccess if it doesn't already.
Fixes for 1 and 2 are now in: 696ddaf.
@NinoFloris Could you share some particular repros for the AutoOpen and RequireQualifiedAccess case you're seeing so I could check it as well?
namespace Foo
[<AutoOpen>]
module Operators =
let foo x = ()
namespace Bar
module Bar =
let bar x = foo // try to import this, result will be Operators.foo, while foo is enough.
For RequireQualifiedAccess I don't have an example but there may be cases where today an import isn't qualified enough for DUs/modules that are annotated with RequireQualifiedAccess. It's just somewhat of a dual to AutoOpen so it may have similar issues.
I did find another issue related to imports:
4. Importing a non generic symbol living in another namespace as its generic one, say when implementing IEnumerable (IEnumerator<T> IEnumerator) is impossible, this is the same vice versa (opening non generic namespace first). You will see a red symbol but won't get any import suggestions.
5. While exploring 4. I found that import also ignores any generic argument syntax you may have written, and gives you a non generic suggestion as well. I could see that being useful but I'm not sure if there's any ranking that takes the fact you wrote a generic type into account when ordering these suggestions?
// try to import this, result will be Operators.foo, while foo is enough.
Thanks, I see. The text to insert is currently coming from FCS items provider. I'll be looking into it as a part of RIDER-27924 fix.
Trying to import a nested class (so, defined in C#) causes a compiler error because it just tries to import the parent class, which is not allowed until open static is out of preview.
@NinoFloris Could you also attach some minimal repro snippets? It's also important to note which import method is used: code completion or a quick fix, since the first one is currently provided by FCS and the second one is done on our side.
So quick fix ignores the parent class and imports just the namespace which is wrong in its own way without symbol fixup at the import site, while code completion tries to import the parent class like I said.
it's super simple
namespace ReproCs
{
public class Foo
{
public class Bar
{
}
}
}
module ReproFs
let bar() = Bar // try either quick fix or code completion for the fireworks.
- While exploring 4. I found that import also ignores any generic argument syntax you may have written, and gives you a non generic suggestion as well.
It's also fixed now. If there are any type arguments given, the suggested types are filtered based on the type parameters count.
Nested types qualifiers are also inserted via quick fix now.
Before:
After:
All completion-related issues currently need separate fixes in FCS and completion side though, but I'm aiming to reusing the logic implemented for the quick fix instead.
It seems like all of these issues have been fixed in code completion too. @NinoFloris If you see other cases, please file a separate issue, and I'll work on it.