Bug? Code-completion uses superfluous fully-qualified type-name for generic type parameter arguments

DaiPlusPlus
DaiPlusPlus
edited July 2021 in General

If I use Linqpad 6's code-completion to complete a variable declaration of a generic-type it won't simplify the type's generic parameter's type-names.

For example:

  1. Open a new Linqpad 6 query. I'm using Linqpad 6.14.10 x64 with .NET 5 right now.
  2. Be in "C# Statement(s)" or "C# program" mode.
  3. Right-click > Namespace Imports, ensure System, System.Collections.Generic, and System.IO is in the list.
  4. Type in Dictionary<String,FileInfo> dict = new
  5. Right after typing new the completion list appears with Dictionary<string, System.IO.FileInfo> preselected.
  6. Pressing [Tab] will cause "Dictionary<string, System.IO.FileInfo>()" to be inserted.
    • I expected Dictionary<String,FileInfo>() to be inserted instead. There are 3 differences from actual behaviour from what I expected:
    1. string was inserted instead of String (though Linqpad does not currently have a setting to specify C# keywords or actual type-names, but I wish it would at least preserve my left-hand declaration type verbatim).
    2. It added a space after the comma (again, there's no option to control this, but my preference is to not have spaces between generic type parameters in most cases).
    3. And the main bug/issue: it inserted System.IO.FileInfo even though System.IO is in the list of imported namespaces.

Screenshot proof:

· Share on FacebookShare on Twitter

Comments

  • sdflysha
    sdflysha
    edited July 2021

    I agree with the FileInfo instead of System.IO.FileInfo, but I think other 2 point is Ok, since it's also a existing behavior in Visual Studio:


    · Share on FacebookShare on Twitter
  • JoeAlbahari
    JoeAlbahari

    Perhaps it would be best to remove that code completion, given that its actually now redundant:

    Dictionary<String,FileInfo> dict = new();    // From C# 9
    · Share on FacebookShare on Twitter
  • sdflysha
    sdflysha

    Hey @JoeAlbahari , although the C# 9 new() is workable for this example, but I found another bug when deal with internal types, let's say this code:

    // Note: namespace `ExternalNs` is imported

void Main()
{
    DoWork(
}

void DoWork(External.Colors color)
{
}

namespace ExternalNs
{
    public class External
    {
        public enum Colors
        {
            Red, Black, White
        }
    }
}

    Cursor at right of DoWork(, hit Ctrl+Space trigger intellisense, the namespace ExternalNs will shown:

    Please also aware that for those non-internal-types, this bug will not shown.

    · Share on FacebookShare on Twitter
  • DaiPlusPlus
    DaiPlusPlus

    @sdflysha said:
    I agree with the FileInfo instead of System.IO.FileInfo, but I think other 2 point is Ok, since it's also a existing behavior in Visual Studio:

    Indeed, it is - but VS is wrong in this case because my .editorconfig settings are set-up to always use actual type-names instead of C# keywords (e.g. String and Int32 instead of string and int), and VS gets it right most of the time but not all the time, and tab-completing an auto-suggested generic-type constructor is one of the few edge cases still not respecting my .editorconfig.

    So I'm "okay" with Linqpad using C# keywords - but only because Linqpad doesn't have an option for it - as soon as LinqPad does start respecting .editorconfig or at least having an option for it then it should use type-names and not keywords when tab-completing generic type parameters for suggested constructors.

    · Share on FacebookShare on Twitter

Categories