Osy#betaRun it on Osyrin: osyrin.com

Reference / Project

Compiler bug reports (what is asked, what is sent, and what Osyrin keeps)

When the Osy# compiler hits a bug of its own — a crash, or a rule it broke about itself, never an error in your code — `osy validate`, `compile`, `check` and `test` ask once whether to send it to Osyrin, after showing exactly what would go. Nothing is asked or sent when nobody is there to answer. Osyrin keeps only the smallest part of your code that still shows the bug, deletes the rest at once, and deletes that too once the fix is released. You can be told when it is.

previewprojecttoolchainprivacy

Summary#

A compiler is a program, and it has bugs. When the Osy# compiler hits one — it crashed, or two of its own passes disagreed about your program — the error is ours, not yours, and the fastest way to get it fixed is for us to see it with the code it happened on. So the toolchain asks, once, whether it may send it, and shows you exactly what would go before you answer. An ordinary error in your code is never a compiler bug and is never offered.

Description#

When you are asked. After osy validate, osy compile, osy check or osy test has printed its own answer, if the compiler hit a bug of its own along the way. The question comes after the error it is about, never in the middle of it:

The Osy# compiler hit a bug of its own. Your code did not cause it.
Sending it to Osyrin helps get it fixed. This is what would be sent:
  compiler     0.9.18
  where        resolve
  what failed  NullReferenceException in OsySharpExpressionResolver.ResolveCall
  your code    12 file(s), 48 KB: app.osy, model/orders.osy, model/people.osy, pages/home.osy, and 8 more
Every byte of it is in ~/.osy/compiler-bugs/20261021-101500-3f9a1c2e.json
We keep only the smallest part of your code that still shows the bug, and delete it once the fix is released.
Report this compiler bug to Osyrin? [y/N]

The file it names is the report itself, written before you are asked — open it to read every byte that would leave your machine. Anything but y keeps it on your machine and sends nothing. The same bug is not asked about again.

What is sent. The compiler's version; where in the compiler it failed (parse, resolve, emit…); what failed and the compiler's own frames (method names inside the compiler, never your names); and your app's .osy files and its osyrin.lock, as compiled. Never your .secrets, your data, environment files, or anything outside the app's source.

Being told when it is fixed. If you are signed in to Osyrin, you hear through your account. If not, you are asked for an e-mail address after you say yes — leave it empty and nobody is told anything:

Want an e-mail when the fix is released? Type your address, or press Enter to skip:

Never asked when nobody can answer. With --json, when the output goes to a pipe or a file, when input is not a terminal, or in a CI job, nothing is asked and nothing is sent or written. One line says the bug was ours and that osy bug-reports always would send reports like it.

Always, never, or ask. osy bug-reports always sends without asking (still showing where the report is); osy bug-reports never stops it; osy bug-reports ask is the default. The choice is stored in ~/.osy/config.json. For one run — a script, a CI job — OSY_REPORT_COMPILER_BUGS=always|never|ask decides instead. And DO_NOT_TRACK or OSY_TELEMETRY=off always means never, whatever the setting says: you have already answered for every tool.

osy bug-reports status     # what happens to the next compiler bug, and why
osy bug-reports always     # send without asking
osy bug-reports never      # never send
osy bug-reports ask        # ask each time (the default)

What Osyrin keeps. A report arrives with your whole app, and that is more than anyone needs. On arrival it is cut down automatically to the smallest source that still makes the compiler fail in exactly the same way — usually a few lines — and the upload is deleted from our storage the moment that is done, and never later than a day after it arrived. Only that smallest repro is kept, readable by Osyrin's platform administrators and nobody else. It is deleted, with your address, 30 days after the release carrying the fix is out (or a year after the bug was last reported, if it never is). If the bug does not happen on our compiler at all, none of your code is kept.

Builds on Osyrin. A build that runs on Osyrin's servers (Studio, a deploy) reports a compiler bug it hits without asking, under the terms of service, with the same minimising and the same deletion — and the account that ran it is told when it is fixed. Until those terms are published this is switched off, and the build answers the bug as one so the CLI can offer to send it with your say-so.

See also#

Related

Usage statistics (what is sent, and the three random ids — one per installation, project and session)

The toolchain sends usage counts — command names and their flag names, versions, OS, error codes, durations, the size…

The local loop (running your app on your own machine)

Everything the `osy` CLI does to the project in front of you — run it, look at what it did, check it before you ship…