-
Notifications
You must be signed in to change notification settings - Fork 40
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
wip: alpha release #272
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
greenhat
approved these changes
Aug 7, 2024
We need to make sure this branch will not be deleted after the merge. |
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.
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 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 fromnext
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.