-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Added some unit tests as requested #78963
Added some unit tests as requested #78963
Conversation
As discussed in PR rust-lang#78267, for example: * rust-lang#78267 (comment) * rust-lang#78267 (comment)
8b23016
to
bd0eb07
Compare
This was working before I rebased. I'm recompiling locally now and will resolve it shortly. |
Huh... This does not fail when I run: $ ./x.py test compiler/rustc_mir --test-args '--show-output coverage' I have to figure out what build command IS failing and why. |
Does The step above the failure I see is
Also, I doubt it's relevant that it's cross compiling, but it could be. |
I've never used $ ./x.py check and got I'll try with the |
Also succeeds for me with |
I'm trying the command shown in CI: $ ./x.py check --target=i686-pc-windows-gnu --host=i686-pc-windows-gnu --all-targets |
That also succeeds (compiling locally on linux). I see the CI failure was from But this is a Rust error, AFAICT, not something platform-dependent, right? |
You likely need to turn parallel compiler on in config.toml, it should reproduce on x.py check --all-targets after that I suspect. x.py check is the equivalent of cargo check. |
I already have this in my config.toml:
|
Hm maybe try without then? Let me also check locally. |
Yes, it fails without it. Should it? |
Hmm... I see this in compiler/rustc_span/src/lib.rs: // The interner is pointed to by a thread local value which is only set on the main thread
// with parallelization is disabled. So we don't allow `Span` to transfer between threads
// to avoid panics and other errors, even though it would be memory safe to do so.
#[cfg(not(parallel_compiler))]
impl !Send for Span {}
#[cfg(not(parallel_compiler))]
impl !Sync for Span {} |
It seems odd to allow |
Hm, I think yes, and really I think the dummy_tys function is likely UB or at least quite worrisome, we really should not be synthesizing references to mem::zeroed (or equivalent) like that. I guess we don't readily have a tcx or anything available since this is a unit test? Easiest thing might be to add a constructor in ty/mod.rs that creates a dummy value called for_unit_testing or something like that. I suspect to get the reference we can just |
Ok, I'll try that. Thanks for the suggestion! (Hopefully I understand this well enough to implement it... 😕 .) |
Per Mark's recommendation at: rust-lang#78963 (comment)
e396af9
to
eb9f2bb
Compare
@tmandry - other than addressing code review feedback, let's submit this PR with the tests included at this stage. I think it gives a reasonable starting point to help understand the code, and to build additional tests later. WDYT? |
c1cbbf6
to
29a4621
Compare
Restructured the code a little, to allow getting both the mir::Body and coverage graph.
29a4621
to
c131063
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Left a few comments but feel free to respond however you like and r=me.
} | ||
|
||
fn switchint(&mut self, some_from_block: Option<BasicBlock>) -> BasicBlock { | ||
let move_ = |place: Place<'tcx>| Operand::Move(place); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: seems a bit unnecessary if you're only using it in one place
let switchint_kind = TerminatorKind::SwitchInt { | ||
discr: move_(discriminant), | ||
switch_ty: dummy_ty(), | ||
targets: SwitchTargets::static_if(0, START_BLOCK, START_BLOCK), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One side effect of defaulting everything to point to START_BLOCK is that by default, you're wrapping everything in your function up to the current point in a loop.
One strategy to avoid this would be to make block 1 (the second block) return, and have all branches go there by default.
I think that would add some significant complexity during init though, not sure if it's worth it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure what you're concern is.
These defaults are meant to be replaced (none of them should remain as START_BLOCK) before constructing the mir::Body.
I can change this to a new constant (maybe set to the max BasicBlock index value) to make it more clear that we're setting a temporary value.
Let me know if I'm missing your point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Replaced with TEMP_BLOCK and a comment at its definition. Let me know if this doesn't resolve your concern. Thanks!
compiler/rustc_mir/src/transform/coverage/test_macros/src/lib.rs
Outdated
Show resolved
Hide resolved
@bors delegate+ |
✌️ @richkadel can now approve this pull request |
@bors r=tmandry rollup=always |
📌 Commit bb7fe84f1e761c2ba9be74993b319144a41cf1cb has been approved by |
bb7fe84
to
b4b0ef3
Compare
@bors r=tmandry rollup=always |
📌 Commit b4b0ef3 has been approved by |
…0.4, r=tmandry Added some unit tests as requested As discussed in PR rust-lang#78267, for example: * rust-lang#78267 (comment) * rust-lang#78267 (comment) r? `@tmandry` FYI: `@wesleywiser` This is pretty much self contained, but depending on feedback and timing, I may have a chance to add a few more unit tests requested against `counters.rs`. I'm looking at those now.
…0.4, r=tmandry Added some unit tests as requested As discussed in PR rust-lang#78267, for example: * rust-lang#78267 (comment) * rust-lang#78267 (comment) r? ``@tmandry`` FYI: ``@wesleywiser`` This is pretty much self contained, but depending on feedback and timing, I may have a chance to add a few more unit tests requested against `counters.rs`. I'm looking at those now.
…0.4, r=tmandry Added some unit tests as requested As discussed in PR rust-lang#78267, for example: * rust-lang#78267 (comment) * rust-lang#78267 (comment) r? ```@tmandry``` FYI: ```@wesleywiser``` This is pretty much self contained, but depending on feedback and timing, I may have a chance to add a few more unit tests requested against `counters.rs`. I'm looking at those now.
Rollup of 15 pull requests Successful merges: - rust-lang#78352 (Do not call `unwrap` with `signatures` option enabled) - rust-lang#78590 (refactor: removing alloc::collections::vec_deque ignore-tidy-filelength) - rust-lang#78848 (Bump minimal supported LLVM version to 9) - rust-lang#78856 (Explicitly checking for or-pattern before test) - rust-lang#78948 (test: add `()=()=()=...` to weird-exprs.rs) - rust-lang#78962 (Add a test for r# identifiers) - rust-lang#78963 (Added some unit tests as requested) - rust-lang#78966 (Never inline C variadics, cold functions, functions with incompatible attributes ...) - rust-lang#78968 (Include llvm-as in llvm-tools-preview component) - rust-lang#78969 (Normalize function type during validation) - rust-lang#78980 (Fix rustc_ast_pretty print_qpath resulting in invalid macro input) - rust-lang#78986 (Avoid installing external LLVM dylibs) - rust-lang#78988 (Fix an intrinsic invocation on threaded wasm) - rust-lang#78993 (rustc_target: Fix dash vs underscore mismatches in option names) - rust-lang#79013 (Clean up outdated `use_once_payload` pretty printer comment) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
As discussed in PR #78267, for example:
r? @tmandry
FYI: @wesleywiser
This is pretty much self contained, but depending on feedback and timing, I may have a chance to add a few more unit tests requested against
counters.rs
. I'm looking at those now.