compare rust type with llvm value in result, lval_result #2606
Labels
Milestone
Comments
|
Seems like this is obsolete since trans uses |
RalfJung
pushed a commit
to RalfJung/rust
that referenced
this issue
Oct 22, 2022
Magic functions for writing to stdout/stderr. This enables I/O in no_std contexts (or, really, any Miri-specific OS-independent context). Combined with the `abort` intrinsic it should allow a reasonable test framework in no_std. **Question for maintainers:** So, the `no_std` panic test needs work, for two reasons: - First, its stdout includes Miri's whole message about the abort intrinsic having been used. I guess whatever panic handler you use in `std` contexts exits cleanly without triggering this message. Comparing the entire output with backtrace as golden seems fragile. - Second, likely for the same reason, the test framework appears to expect the test to exit successfully, when in fact it exits with status 1 due to the abort. This means the test doesn't actually pass right now. What shall I do there?
Aaron1011
pushed a commit
to Aaron1011/rust
that referenced
this issue
Jan 6, 2023
Magic functions for writing to stdout/stderr. This enables I/O in no_std contexts (or, really, any Miri-specific OS-independent context). Combined with the `abort` intrinsic it should allow a reasonable test framework in no_std. **Question for maintainers:** So, the `no_std` panic test needs work, for two reasons: - First, its stdout includes Miri's whole message about the abort intrinsic having been used. I guess whatever panic handler you use in `std` contexts exits cleanly without triggering this message. Comparing the entire output with backtrace as golden seems fragile. - Second, likely for the same reason, the test framework appears to expect the test to exit successfully, when in fact it exits with status 1 due to the abort. This means the test doesn't actually pass right now. What shall I do there?
celinval
added a commit
to celinval/rust-dev
that referenced
this issue
Jun 4, 2024
rust-lang#2837) The "Auto Label" workflow correctly label our PRs; however, this action do not trigger a PR 'labeled' workflow. To automatically do that, we now changed the CI structure to have a new workflow with extra jobs that are conditional to labels and files being modified. This new workflow starts by triggering the auto-label job. The benchmark workflow is only triggered if after the auto-label job, the PR has a Z-BenchCI label. This also means that the benchmark workflow will now run after any update to a PR that has the 'Z-BenchCI' label. Resolves rust-lang#2606
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Right now in trans we have this
resultandlval_resultthat is the combination of a bcx and a value. It should also include the rust type of this value. This would make it possible to figure out, based solely onresultandlval_result, whether something is stored on the stack or not. Right now we have to check if the kind is owned and if the type is immediate.The text was updated successfully, but these errors were encountered: