fix line directive application for caller info

[Martin521]

Description

This fixes the regression regarding caller info with line directives that was reported here.

So, this adds a 6th place to this list of applications of line directives.

Checklist

• Test cases added
• Performance benchmarks added in case of performance changes
• Release notes not needed

[T-Gro]

Thanks for spotting and fixing this.
Let's get this in before .NET 10 RC1 closes for main development 👍

[majocha]

Not a showstopper, but FsharpQA test probably needs adjusting:

Conformance\SpecialAttributesAndTypes\Imported\CallerInfo (CallerFilePath.fs) -- failed

[Martin521]

Not a showstopper, but FsharpQA test probably needs adjusting:

Conformance\SpecialAttributesAndTypes\Imported\CallerInfo (CallerFilePath.fs) -- failed

Yes, thank, I know. I am struggling doing that with my Linux environment. I have fixed one of the two errors blindly, but there is still a remaining one. It is not so easy to move it to ComponentTests because of the C# lib.

[majocha]

Not a showstopper, but FsharpQA test probably needs adjusting:

Conformance\SpecialAttributesAndTypes\Imported\CallerInfo (CallerFilePath.fs) -- failed

Yes, thank, I know. I am struggling doing that with my Linux environment. I have fixed one of the two errors blindly, but there is still a remaining one. It is not so easy to move it to ComponentTests because of the C# lib.

I'm on Windows, I'll take a look!

[Martin521]

Thanks!!
Even just knowing the failure message will probably be enough for me to fix it.

[Martin521]

Ok, I succeeded in bringing it to ComponentTests, I guess I will be ok now to find the issue.

[majocha]

Original error:

+++ Conformance\SpecialAttributesAndTypes\Imported\CallerInfo (CallerFilePath.fs) +++
PRECMD: [E:\packages\nuget\Microsoft.Net.Compilers\4.3.0-1.22220.8\tools\csc.exe /t:library CSharpLib.cs]
Microsoft (R) Visual C# Compiler version 4.3.0-1.22220.8 (e2dd6e2d)

Copyright (C) Microsoft Corporation. All rights reserved.


--------------------------------------------------------
Results from hosted compiler
msg: Compiling
cmd: fsc   -r CSharpLib.dll --test:ErrorRanges CallerFilePath.fs 
Exit code: 0
Error:     0
Microsoft (R) F# Compiler version 14.0.100.0 for F# 10.0
Copyright (c) Microsoft Corporation. All Rights Reserved.
--------------------------------------------------------
Microsoft (R) F# Compiler version 14.0.100.0 for F# 10.0
Copyright (c) Microsoft Corporation. All Rights Reserved.
Peverify: [PEVerify.exe CallerFilePath.exe ]


Microsoft (R) .NET Framework PE Verifier.  Version  4.0.30319.0

Copyright (c) Microsoft Corporation.  All rights reserved.



All Classes and Methods in CallerFilePath.exe Verified.
Running: [ CallerFilePath.exe ]

Unhandled Exception: System.Exception: Unexpected C# result with multiple parameter types: ("E:\repos\fsharp\tests\fsharpqa\source\Conformance\SpecialAttributesAndTypes\Imported\CallerInfo\qwerty1",
 345, "main")
   at Microsoft.FSharp.Core.PrintfModule.PrintFormatToStringThenFail@1448.Invoke(String message)
   at Test.Program.main(String[] _arg1)

Generated Test EXE Failed 
FAIL

[Martin521]

It was just a typo in the test case that I overlooked while checking it ten times.
@majocha Thanks for helping!

[Martin521]

This is ready

[github-actions]

❗ Release notes required

---

✅ Found changes and release notes in following paths:

Change path	Release notes path	Description
src/Compiler	docs/release-notes/.FSharp.Compiler.Service/10.0.100.md

[majocha]

Not sure if this is covered already by this PR, but I just noticed in another branch, WindowsNoRealsig_testCoreclr > Test diagnostics with line directives active fail:
https://dev.azure.com/dnceng-public/public/_build/results?buildId=1120100&view=ms.vss-test-web.build-test-results-tab&runId=30768512&resultId=105627&paneView=debug

[Martin521]

Not sure if this is covered already by this PR, but I just noticed in another branch, WindowsNoRealsig_testCoreclr > Test diagnostics with line directives active fail: https://dev.azure.com/dnceng-public/public/_build/results?buildId=1120100&view=ms.vss-test-web.build-test-results-tab&runId=30768512&resultId=105627&paneView=debug

I have not been able to reproduce it yet (neither locally nor in CI), but let me look further into it.
It is not affected by this PR.

[T-Gro]

@Martin521 :

Not sure if you know, but the AzDo artifacts contain a log file with all failed FSharpQA tests and their logs.
I think it also creates a setup file to launch with .fsx, but you are right that most tests assume Windows (some even launch WindowsForms GUIs) and likely will not work elsewhere.

[Martin521]

@Martin521 :

Not sure if you know, but the AzDo artifacts contain a log file with all failed FSharpQA tests and their logs.

@T-Gro:
Thanks, I didn't know. This could be very useful. However, I do see the artifacts folder list, but I cannot get to the contents (at least not by clicking on the folder). Does one need other access rights to get there?

EDIT: Sorry, I just found the download menus

[Martin521]

@T-Gro
I still think this PR should be merged. Even if the failed test reported by @majocha was related to my line directive work, the issue would be in the original #18553 PR (which I am investigating), not in this fix.

[majocha]

@T-Gro I still think this PR should be merged. Even if the failed test reported by @majocha was related to my line directive work, the issue would be in the original #18553 PR (which I am investigating), not in this fix.

Yes, it was a random one-time thing. I also cannot repro it locally.

[majocha]

@Martin521 I think I know what's going on.
Just add an attribute to both Test diagnostics with line directives tests:
[<Fact; RunTestCasesInSequence>]

We're using a shared state (the test project) concurrently.

So this is not a bug (or rather a bug in tests only).

[Martin521]

We're using a shared state (the test project) concurrently.

Thanks! I did check and see that the project uses unique file names. But, yes, the two tests use the same project, so, getting diagnostics from the other test is possible.

[Martin521]

Still good that this happened. While checking again carefully all my changes, I found another issue that I will also fix :-).
(I still did not listen well enough to mighty copilot when doing this.)