Skip to content

Conversation

@auduchinok
Copy link
Member

An experiment with in-memory setting a test source that is used for parsing.

The current approach seems to rely on writing a file into temp directory and then trying to read it. It have never worked for me during debug. We could try to fix that, but not writing it to disk seems a better thing to do.

@0101
Copy link
Contributor

0101 commented Oct 21, 2022

It wasn't writing it to disk before either:

let parseResults = checker.ParseFile(filePath, SourceText.ofString code, options) |> Async.RunImmediate

Which is probably the reason it didn't work for you during debug, because Range.DebugCode relies on reading it from disk.

I don't like that this seems to be adding another obstacle to eventually being able to run tests in parallel.

@T-Gro
Copy link
Member

T-Gro commented Oct 21, 2022

It wasn't writing it to disk before either:

let parseResults = checker.ParseFile(filePath, SourceText.ofString code, options) |> Async.RunImmediate

Which is probably the reason it didn't work for you during debug, because Range.DebugCode relies on reading it from disk.

I don't like that this seems to be adding another obstacle to eventually being able to run tests in parallel.

If/Once we are ready for parallelism, the storage could be turned into an (WeakMap option), keyed by randomly generated filename per test case. ?


let internal setTestSource source =
testSource <- Some source
{ new IDisposable with
Copy link
Contributor

Choose a reason for hiding this comment

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

Could we maybe make the source accessible from this object? So that we can pass it to parseTestSource directly in the tests. That would make the test code a bit clearer and if we ever need to change how we store this we wouldn't need to change the tests.

@auduchinok auduchinok requested a review from a team as a code owner January 16, 2024 15:53
@psfinaki
Copy link
Contributor

Hey @auduchinok, is this still something of your interest?

@github-actions
Copy link
Contributor

❗ Release notes required

@auduchinok,

Caution

No release notes found for the changed paths (see table below).

Please make sure to add an entry with an informative description of the change as well as link to this pull request, issue and language suggestion if applicable. Release notes for this repository are based on Keep A Changelog format.

The following format is recommended for this repository:

* <Informative description>. ([PR #XXXXX](https://github.com/dotnet/fsharp/pull/XXXXX))

See examples in the files, listed in the table below or in th full documentation at https://fsharp.github.io/fsharp-compiler-docs/release-notes/About.html.

If you believe that release notes are not necessary for this PR, please add NO_RELEASE_NOTES label to the pull request.

You can open this PR in browser to add release notes: open in github.dev

Change path Release notes path Description
src/Compiler docs/release-notes/.FSharp.Compiler.Service/8.0.300.md No release notes found or release notes format is not correct

@github-actions
Copy link
Contributor

github-actions bot commented Mar 7, 2024

Caution

Repository is on lockdown for maintenance, all merges are on hold.

@abonie
Copy link
Member

abonie commented Aug 12, 2024

Doing clean up in PRs - please reopen if you deem appropriate

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Archived in project

Development

Successfully merging this pull request may close these issues.

6 participants