Skip to content
This repository was archived by the owner on Jan 7, 2022. It is now read-only.

The beginnings of a new "TIR" serialiser. #9

Merged
merged 1 commit into from
Mar 14, 2019
Merged

The beginnings of a new "TIR" serialiser. #9

merged 1 commit into from
Mar 14, 2019

Conversation

vext01
Copy link
Member

@vext01 vext01 commented Mar 14, 2019

This replaces the custom MIR serialiser, which a serde-based TIR
(tracing IR) serialiser. The change of name is to signify that we are
actually implementing our own IR now, not just a mirror of MIR.

The conversion uses a trait ToPack which is effectively a poor man's
From trait. We couldn't use the From trait since the "from" and "to"
data structures are both external crates in the eyes of the compiler,
and Rust currently disallows this.

While we are here, remove the "YK_DEBUG_SECTIONS" environment variable
switch, as we are always going to need this information. It's not just a
debugging aid.

We do not yet implement MIR to TIR statement translation. This will be
started in my next PR.

I plan to rename the file mir_cfg.rs to something more appropriate
later (say gen_tir.rs), but only once my outstanding branches have
been merged.

@vext01
Copy link
Member Author

vext01 commented Mar 14, 2019

I've not written any tests for the new serialiser btw. I'm not sure how useful such tests would be. Any thoughts?


//! MIR to TIR converter/serialiser.
//!
//! We convert Rust's MIR into our own IR we call "TIR" (tracing IR), which is then stashed away in
Copy link
Member

Choose a reason for hiding this comment

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

"Our own" feels odd. How about something like "This module converts rustc MIR into Yorick TIR (Tracing IR). TIR is more suitable for the run-time tracer: TIR is in SSA form (but it does preserve MIR's block structure)."?

@ltratt
Copy link
Member

ltratt commented Mar 14, 2019

This all looks fine to me though I'm confused by this:

We couldn't use the From trait since the "from" and "to"
data structures are both external crates in the eyes of the compiler,
and Rust currently disallows this.

From is part of the standard library so I'm surprised this is seen as an external crate. Any clues?

@vext01
Copy link
Member Author

vext01 commented Mar 14, 2019

From is part of the standard library so I'm surprised this is seen as an external crate. Any clues?

It's the data structures we want to implement From on which are external. If we try to use From we'd get an error like this:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=9a3a7cdedf31c22a13e5b581e3b3b46e

By defining the conversion trait locally, we avoid this.

@ltratt
Copy link
Member

ltratt commented Mar 14, 2019

Ah, I see what you mean. OK. I think we're ready to squash.

This replaces the custom MIR serialiser, which a serde-based TIR
(tracing IR) serialiser. The change of name is to signify that we are
actually implementing our own IR now, not just a mirror of MIR.

The conversion uses a trait `ToPack` which is effectively a poor man's
`From` trait. We couldn't use the `From` trait since the "from" and "to"
data structures are both external crates in the eyes of the compiler,
and Rust currently disallows this.

While we are here, remove the "YK_DEBUG_SECTIONS" environment variable
switch, as we are always going to need this information. It's not just a
debugging aid.

We do not yet implement MIR to TIR statement translation. This will be
started in my next PR.

I plan to rename the file `mir_cfg.rs` to something more appropriate
later (say `gen_tir.rs`), but only once my outstanding branches have
been merged.
@vext01
Copy link
Member Author

vext01 commented Mar 14, 2019

splat

@ltratt
Copy link
Member

ltratt commented Mar 14, 2019

bors r+

bors bot added a commit that referenced this pull request Mar 14, 2019
9: The beginnings of a new "TIR" serialiser. r=ltratt a=vext01

This replaces the custom MIR serialiser, which a serde-based TIR
(tracing IR) serialiser. The change of name is to signify that we are
actually implementing our own IR now, not just a mirror of MIR.

The conversion uses a trait `ToPack` which is effectively a poor man's
`From` trait. We couldn't use the `From` trait since the "from" and "to"
data structures are both external crates in the eyes of the compiler,
and Rust currently disallows this.

While we are here, remove the "YK_DEBUG_SECTIONS" environment variable
switch, as we are always going to need this information. It's not just a
debugging aid.

We do not yet implement MIR to TIR statement translation. This will be
started in my next PR.

I plan to rename the file `mir_cfg.rs` to something more appropriate
later (say `gen_tir.rs`), but only once my outstanding branches have
been merged.

Co-authored-by: Edd Barrett <[email protected]>
@bors
Copy link
Contributor

bors bot commented Mar 14, 2019

Build succeeded

@bors bors bot merged commit 81b1d97 into master Mar 14, 2019
@bors bors bot deleted the yk-tir-blocks branch March 14, 2019 15:24
bors bot pushed a commit that referenced this pull request Sep 22, 2019
remove the reference to __cxa_thread_atexit_impl
vext01 pushed a commit to vext01/ykrustc that referenced this pull request Oct 12, 2020
This is a combination of 18 commits.

Commit softdevteam#2:

Additional examples and some small improvements.

Commit softdevteam#3:

fixed mir-opt non-mir extensions and spanview title elements

Corrected a fairly recent assumption in runtest.rs that all MIR dump
files end in .mir. (It was appending .mir to the graphviz .dot and
spanview .html file names when generating blessed output files. That
also left outdated files in the baseline alongside the files with the
incorrect names, which I've now removed.)

Updated spanview HTML title elements to match their content, replacing a
hardcoded and incorrect name that was left in accidentally when
originally submitted.

Commit softdevteam#4:

added more test examples

also improved Makefiles with support for non-zero exit status and to
force validation of tests unless a specific test overrides it with a
specific comment.

Commit softdevteam#5:

Fixed rare issues after testing on real-world crate

Commit softdevteam#6:

Addressed PR feedback, and removed temporary -Zexperimental-coverage

-Zinstrument-coverage once again supports the latest capabilities of
LLVM instrprof coverage instrumentation.

Also fixed a bug in spanview.

Commit softdevteam#7:

Fix closure handling, add tests for closures and inner items

And cleaned up other tests for consistency, and to make it more clear
where spans start/end by breaking up lines.

Commit softdevteam#8:

renamed "typical" test results "expected"

Now that the `llvm-cov show` tests are improved to normally expect
matching actuals, and to allow individual tests to override that
expectation.

Commit softdevteam#9:

test coverage of inline generic struct function

Commit softdevteam#10:

Addressed review feedback

* Removed unnecessary Unreachable filter.
* Replaced a match wildcard with remining variants.
* Added more comments to help clarify the role of successors() in the
CFG traversal

Commit softdevteam#11:

refactoring based on feedback

* refactored `fn coverage_spans()`.
* changed the way I expand an empty coverage span to improve performance
* fixed a typo that I had accidently left in, in visit.rs

Commit softdevteam#12:

Optimized use of SourceMap and SourceFile

Commit softdevteam#13:

Fixed a regression, and synched with upstream

Some generated test file names changed due to some new change upstream.

Commit softdevteam#14:

Stripping out crate disambiguators from demangled names

These can vary depending on the test platform.

Commit softdevteam#15:

Ignore llvm-cov show diff on test with generics, expand IO error message

Tests with generics produce llvm-cov show results with demangled names
that can include an unstable "crate disambiguator" (hex value). The
value changes when run in the Rust CI Windows environment. I added a sed
filter to strip them out (in a prior commit), but sed also appears to
fail in the same environment. Until I can figure out a workaround, I'm
just going to ignore this specific test result. I added a FIXME to
follow up later, but it's not that critical.

I also saw an error with Windows GNU, but the IO error did not
specify a path for the directory or file that triggered the error. I
updated the error messages to provide more info for next, time but also
noticed some other tests with similar steps did not fail. Looks
spurious.

Commit softdevteam#16:

Modify rust-demangler to strip disambiguators by default

Commit softdevteam#17:

Remove std::process::exit from coverage tests

Due to Issue #77553, programs that call std::process::exit() do not
generate coverage results on Windows MSVC.

Commit softdevteam#18:

fix: test file paths exceeding Windows max path len
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants