Skip to content

wip: alpha release #272

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 63 commits into from
Aug 15, 2024
Merged

wip: alpha release #272

merged 63 commits into from
Aug 15, 2024

Conversation

bitwalker
Copy link
Contributor

This PR supercedes #260, and introduces a next branch on which our usual development will take place once merged.

@greenhat This is the same changes as #260, just rebased on main to pick up the few PRs of yours we merged already. I'd fork from next for all subsequent PRs.

Once this is merged, it's because the requirements for the alpha release have been met (i.e. the memory init issues have been worked out, and CI is green), hence the naming of this PR.

Until merged, stack PRs on top of this one, and we can follow our usual process that way.

This commit introduces a new `CompilerTestBuilder` type, which is used
to configure compiler tests before they are instantiated. This lets us
build up the configuration that will be used to generate compiler inputs
in multiple stages, and only instantiate it once we wish to run the
test. Prior to this, we mixed these stages together, which made it
difficult to configure the input generation step in more than one place,
which is a problem in more complex tests, or edge case tests which do
not neatly fit the mold of one of the default configurations.

In addition to `CompilerTestBuilder`, there are also two configuration
types introduced, `CargoTest` and `RustcTest`, which configure tests
based on `cargo` or `rustc` outputs (as inputs to `midenc`). These are
used in conjunction with `CompilerTestInputType` to instantiate a
`CompilerTestBuilder` for one of the three input types currently used
for compiler testing.
* Diagnostics infra is now implemented in miden-core
* Unified source code abstraction and source spans
* Compiler still retains the `DiagnosticsHandler`, with some minor
  improvements, but `CodeMap` is replaced with `SourceManager`
* Use unified spans to emit precise debug information from the compiler
* Use precise information in assembler to produce debug info useful for
  high-level languages
* Numerous cleanups along the way to try and tidy up the way we
  represent and use diagnostics throughout the compiler
…ents

Previously, the Br, CondBr, and Switch branch instructions all used
slightly different representations for their successor information, for
no real purpose. This commit unifies these, as well as provides a more
uniform API (e.g. `analyze_branch`'s `BranchInfo` is also unified in the
same manner).

The Switch instruction type is also enhanced with the ability to pass
block arguments to successor blocks in each arm, as well as the default
case. These statements will be lowered using a binary search approach on
the discriminant value, so as to lower to the least number of
conditional branches possible. Branch weights would be exceedingly
useful here, but we don't have any meaningful way to obtain that
information from Rust currently.

To better support the new Switch API, the `switch` builder has been
updated to use a specialized builder that guarantees that the `Switch`
is well-formed.

The Wasm frontend has had its lowering reworked to make use of the new
builder, and take advantage of the support for successor arguments.
@bitwalker bitwalker added the blocker This issue is one of our top priorities label Aug 6, 2024
@bitwalker bitwalker requested a review from greenhat August 6, 2024 23:03
@bitwalker bitwalker self-assigned this Aug 6, 2024
@greenhat
Copy link
Contributor

greenhat commented Aug 7, 2024

We need to make sure this branch will not be deleted after the merge.

bitwalker and others added 23 commits August 10, 2024 15:48
This commit extracts the VM executor and associated helpers from the
miden-integration-tests crate, and moves it into a new midenc-runner
crate, along with the necessary plumbing to wire up `midenc run`.

The actual implementation of the command is stubbed out, but will be
implemented in subsequent commits. The details of how this command will
be used are still up in the air, but for now I plan to use it for
debugging the compiler-emitted MASM programs, by making use of the
debugging infra I've added to our test executor.
This commit implements a TUI for an interactive debugger that builds on
top of the previous `midenc-runner` executor and its various diagnostic
tools. See the doc in `midenc-runner/README.md` for usage.

The implementation is based on `ratatui`, and uses a
model/view/controller-like architecture, where the application state is
centrally managed, the top-level `App` structure orchestrates all of the
pages and global events; each page orchestrates its panes and
page-global events; and each pane responds to events, generates its own,
and draws its UI from the current state. This makes it pretty
straightforward to add new pages/panes, keybindings, etc., without it
turning into a gigantic mess.

The initial set of functionality in this commit is actually quite rich,
but there are a few nice-to-haves mentioned in the README, if we can get
to them.
This commit also fixes some bugs around handling of commands to make the
UI more responsive.
Remove `miden-core` dependency from `midenc-tx-kernel` crate;
load the `CompiledLibrary` from the bytes.
Move the tx kernel to `masm/tx`.
…den-base-sys`

Add `bindings` and `masm-lib` features to the `miden-base-sys`
crate to separate the the user facing Rust bindings from the MASM library
needed only for the compiler.
While working on the debugger, it is occasionally useful to be able to
view debugging information about the debugger program itself, without
resorting to the usual printf tricks, this is a bit tricky. This commit
adds a `debug` command to the debugger, which opens a popup (a new
widget in our UI toolkit) that displays the current stream of events
that have been written to the `log` backend. One can use this to log
something of interest, and then pop upen the debug window to see the
event in question.

It is currently a bit noisy, with no way to meaningfully filter the log
yet, but for now it is sufficient, and servces as a useful example of
the popup functionality that we can use for other things as well.
@bitwalker bitwalker marked this pull request as ready for review August 15, 2024 07:29
@bitwalker
Copy link
Contributor Author

I'm planning to merge this later today once CI is green and I've looked at any other outstanding PRs we have. After that we can resume our usual development flow with next as our main development branch, which we've kind of been doing, but it is a bit awkward at the moment with next not being a protected branch.

@bitwalker bitwalker merged commit 15706b1 into main Aug 15, 2024
4 checks passed
@bitwalker bitwalker deleted the next branch August 15, 2024 21:51
@bitwalker bitwalker restored the next branch August 15, 2024 21:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocker This issue is one of our top priorities
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants