Transparent Compiler returns no completions after a dangling dot
Maintainer thường phản hồi trong vòng 3 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 72/100
Hướng nghiên cứu
Run ./run.sh to reproduce the difference between the transparent and default compilers. Start in Harness, where ParseAndCheckFileInProject and GetDeclarationListInfo are called, and use Library/Questions.fs and Library/Use.fs as the minimal case. Done means the transparent compiler returns the two expected completions after Questions. without requiring an unrelated reference to Questions.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Hello,
While working on a project of mine I discovered some strange behavior in the intellisense results.
After some investigation, here is what I found:
Investigation# Transparent Compiler returns no completions after a dangling dot
With the transparent compiler enabled, GetDeclarationListInfo returns an empty list for Questions. when Questions is a module declared in an earlier file of the project and the namespace holding it declares no type of its own.
The default background compiler returns the expected list for the same input.
Reproduces on FSharp.Compiler.Service 43.9.300, 43.10.103, 43.12.400, and 43.1001.125 (the build shipped in FsAutoComplete 0.83.0).
Run
./run.sh
transparentCompiler=false 2 completions [|"singleton"; "count"|]
transparentCompiler=true 0 completions [||]
Pass -p:FcsVersion=43.9.300 to run.sh to use a different FCS build.
Input
Library/Questions.fs
namespace Demo
module Questions =
let singleton = 1
let count = 2
Library/Use.fs
namespace Demo
module Use =
let f () =
Questions.
()
Use.fs has one parse error, FS0599: Missing qualification after '.'. The harness asks for completions at the end of the Questions. line.
Observations
Editing Library/Questions.fs and rerunning gives:
Questions.fs shape |
default | transparent |
|---|---|---|
| namespace holds only the module (as checked in) | 2 | 0 |
a type added to the namespace, after the module |
2 | 2 |
a type added to the namespace, before the module |
2 | 2 |
a type added inside the module |
3 | 0 |
Writing Demo.Questions. in Use.fs instead of Questions. changes nothing.
These are correct under both compilers, so the failure is not general to the dangling dot:
- a module declared in the same file as the dot
- an FSharp.Core module, such as
String. - a .NET type, such as
System.Console. - an instance member, such as
s.on astring
Adding an unrelated statement to f does not help. Adding one that mentions Questions does:
let f () =
Questions.
Questions.singleton |> ignore
()
With that line present the transparent compiler returns the 2 expected completions.
Effect in an editor
FsAutoComplete passes --use-fcs-transparent-compiler when the VSCode setting FSharp.fcs.transparentCompiler.enabled is true.
Typing a dot after such a module then offers nothing.
Layout
Library/- the project being analysed. ItsDumpFscArgstarget writes the compiler arguments of a design-time build toLibrary/obj/args.txt.Harness/- console app that callsParseAndCheckFileInProjectandGetDeclarationListInfoagainstLibrary, once per compiler.run.sh- runs the target, then the harness.
fcs-transparent-completion-repro.zip
Related information
Provide any related information (optional):
- Operating system: Omarchy (Arch Linux based), kernel 7.2.3-arch1-3, x86_64
- .NET Runtime kind: .NET (Core)
- SDK 10.0.102, harness and repro project both target
net8.0and run on .NET 8.0.19 - Installed runtimes: 6.0.36, 8.0.19, 9.0.11, 10.0.0, 10.0.1, 10.0.2, 10.0.8
- SDK 10.0.102, harness and repro project both target
- Editing Tools: VSCode 1.137.0 with Ionide-fsharp 7.31.1 (FsAutoComplete 0.83.0), setting
FSharp.fcs.transparentCompiler.enabledset totrue - FSharp.Compiler.Service: reproduces on 43.9.300, 43.10.103, 43.12.400, and 43.1001.125 (the build inside FsAutoComplete 0.83.0)
- Ngôn ngữ chính
- F#
- Star
- 4.3k
- Fork
- 880
- Merge trung bình
- 4 ngày 14 phút
- Pull request đã merge (30 ngày)
- 99
Chuẩn bị môi trường
Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của dotnet/fsharp
-
Semantic classification cache for opened documents is never populated (written to the unopened-documents cache)Có thể đã có người làm @xperiandri đã nhận 37 ngày trước. Đang mởNeeds-Triage
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 90/100
Maintainer thường phản hồi trong vòng 3 ngày
-
Needs-Triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
dotnet/fsharp#20265 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 3 ngày
-
Bug Needs-Triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 3 ngày
-
Feature Request Needs-Triage
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 57/100
Maintainer thường phản hồi trong vòng 3 ngày
-
Feature Request Needs-Triage
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
Maintainer thường phản hồi trong vòng 3 ngày
Tất cả issue của dotnet/fsharp
Issue tương tự
-
flang:semantics
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 73/100
llvm/llvm-project#231051 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug derived types format I/O medium priority semantics
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
webgpu-tools/wesl-rs#329 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
compiler/runtime
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
golang/go#82141 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày