jiebi/CodeConvo huggingface dataset:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I have a large-ish project with ~6000 testcases, and for a long time now, code coverage has been hit-or-miss. The issue is that some of the test cases don't seem to get their data included in the files, and so don't show up as having an effect on coverage. The unrecorded tests seem to be essentially random, but with thousands of tests, single-digit-percentage failures are noticed on every test run. It's been annoying. So I finally sat down to try and reduce to a simplest error, but it still takes multiple files, so is difficult to include inline in a GitHub issue. The tree: When I run a test via: which shows 2 tests run: Then report on that particular function via: Most of the time, I see the correct result: But sometimes (about 1 in 170 times), I see this: It seems to be related to having multiple source files; I could not get similar behavior with only a . I've seen the problem appear on both MacOS (Mohave) and on Windows (in Windows Subsystem for Linux 2) The two-source-file tree mentioned up above (including the script I run to repeat the test until a failure happens), is on a bug-report branch here: This really feels like whichever thread is controlling writes to the file is missing messages. Queue overrun maybe? (I haven't looked.) <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --:
label A-code-coverage
I see you are using the placeholder for the profile file, which talks about locking and merging these files at runtime. Maybe adding the PID placeholder as well might avoid conflicts here. Can you give that a try?
Gave it a try; still exhibits the same behavior.
is definitely an indication to "please merge"; and doesn't do that, but is really about processes, not threads. I suspect whatever is doing the merging of thread data is what's got the issue here. (Though I get the same effect when I tell the test runner to just use one thread, as well.)
Just learned that the option of is not the same thing as (which sends that flag to the test-runner). Adding to my harness removes the intermittent results. Not closing this issue, though. Rust is supposed to be "fearless concurrency" so this should work correctly even if the test runner is using multiple threads.
Still reproducible with I used such script to run against , because of I can not find : at step 854, coverage changed from 4 to 2.
This is in cargo-binutils.
I created bug against upstream llvm/llvm-project
Looks like this is not llvm bug. There is bool flag , that is by default, and depend on it llvm generates different code: So if set it to true via option , then C++ variant of test is unable to reproduce problem. So is any way to set via rustc command line?
or another atomic-counter flag may work, but I have not tested it yet.
I can not see how any of this options can reach here . So I create PR to set to by default.
Looks like should also works. where
At various points, rustc may use to get a backtrace of the current thread such as if or similar functions are called. On Windows, this results in attempting to load the hardcoded path of rustc's PDB which, on normal user machines, never exists. Normally, this is fine and we just simply don't have debug symbols, but in some environments like build systems such as , filesystem accesses are monitored to enable fine-grained caching. If we try to load rustc's PDB in this environment, it will trigger build system errors: Since these paths won't generally resolve (unless you build rustc from source with debuginfo yourself), it would be nice to provide a way to turn this behavior off.
Modifying this to focus specifically on the behavior of as trying to load PDBs during an ICE isn't actually problematic for the stated use case.
When creating a byte literal with single quotes, like , The error message says: But following the directions would not give us a literal, it would give a literal.
This should be easy to fix, by replacing the message with: when the literal is prefixed by . You may need to see work out which call is originating from (in ) to pass information about the nature of the literal.
Can I work on this?
go ahead! :) Let me know if you have any questions.
Hi, I have been doing some work in this issue, cause this is the first time I'm sending PR to rust, can you give me some feedback. Thanks!
The test run-pass/sepcomp-lib- can fail on android apparently due to the fact that a pthread shim dependency is present in libstd (as part of librust_builtin), but it stripped out early. It may be possible to work around this by moving the dependency into liballoc instead, but a more thorough examination is needed.
cc
The problem here on android was as follows: jemalloc requires the symbol, which android does not provide. jemalloc is also statically linked to liballoc We provide a dummy definition of in , which is assembled into and is statically linked to . When building with LTO, we remove all rust-generated code from an rlib (it's all in the LTO object), but we still link the rlib. When linking, we pass libstd's rlib first, then liballoc's rlib on the command line. The linker detects that we're not using any symbols from the libstd's rlib by the time its reached on the command line (scans from left-to-right) because we actually aren't using any symbols from or any other objects in the archive. The linker then strips from the linkage step, which then later yields an unresolved reference. The solution here is to break apart to be less of a conglomerate and instead link specific symbols to specific libraries wherever necessary. For example all of the time-related functionality should be a lib linked directly to , not to . In this example we need to link the symbol directly to , not to , because is not the one that needs it. Just some general cleanup, most things should still work as advertised!
Triage: this test is still ignored on android, but I don't know what is nowadays.
! So I guess this can be closed, but should we check if the affected test was actually fixed?
Yeah I think this is all taken care of, so closing.
I believe this is due to travis using system llvm which misses the fix backported in . cc
Can we do anything about this?
Our best bet is to add a for tests, I think (alternative is to drop support for LLVM pre 3.9, which would be a shame, even if its buggy in certain cases). Implementation of such directive could be implemented by injecting an environment variable or some such (done ) and checking for that in
There's no need to set an extra environment variable, just check if is set (or if you're boring :wink: )
but… but… what if people have on their own systems too?
cc
no we do not have existing infrastructure for this. I'd prefer to avoid as that's not the relevant piece here, but rather something like or . Distros or anyone else building with an older LLVM are likely to hit this and we'd need a solution for them as well. That being said I think it's fine to temporarily disable the test until we get that. There's basically a 0% chance of us regressing that test as it's just an LLVM bug, and they already have a regression test upstream as well.
Another option would be to create a base Docker image (publishing it to Docker Hub) that is just and the appropriate steps to build whatever version of LLVM we want.
We currently advertise ourselves as supporting LLVM 3.7+, and Travis is kinda our test for that, so I'd prefer to not pull that forward just yet (but instead just fix this)
For the record, I downgraded our LLVM version in a botched rebase and only this test stopped it at bors. Hopefully, someone would have noticed the absence of a fix, but you can't count of that.
touche!
A further performance improvement here would be to make sure that impls , in which case we could use rather than , avoiding the allocation of a temporary here. internally seems to just hold a and it has and methods already, so perhaps it would make sense to implement that trait? I'm not sure how big/relevant the performance improvement would be. Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Since implementers get a generated for them by Askama's macro, the simpler way to get the meat of this change would probably be to call
claim Let me take a stab at it :)
Attempting to shim futures-preview Stream to a tokio futures 0.1 Stream results in ICE when done this way. Most minimal example I can give
Minimized:
The ICE goes away if you assign (or whatever type you create in the loop body) to a variable. Looking at the generated MIR, it seems that we never emit / statements for the temporary created by the statement, leading later analysis to incorrectly conclude that it lives across a yield point.
I believe this will be fixed by
This is indeed fixed-- I've opened with a regression test.
Backtrace:
Well, this is interesting. It's broken all the way back to 0.10. I think it's been a bug in the type id implementation since it first landed. Here's a smaller test case:
is there a particular reason explicitly checks that all regions it encounters are ? Trans doesn't seem to go out of its way to erase late-bound regions in fn type signatures, which results in this ICE. I could add a call to in trans to fix this, but it would be cheaper to just ignore regions during hashing.
Ended up catching me
It seems we actually want to take late-bound regions into account when hashing. For example, the following should hold:
First seen on as , looks like: compilefail,E0422nfn main () {n let x = Foo { x: 1, y: 2 };n}ncompilefailnfn main () {n let foo = 1;n let x = foo { x: 1, y: 2 };n}n cc
Also hit this on Travis (same test) in .
cc me
This is causing lots of CI failures. Should this test be disabled until a fix can be found?
We believe a fix is pending in , once that lands we should be good to go.
I just saw this again, reopening...
These haven't shown up in quite some time, so closing.
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --This is a much abbreviated version of the code from my experiments with adding a shuffle API to the stdsimd repo, it probably needs further reduction but I wanted to file this before I forgot: I expected to see this happen: it works, provides a useful error, or even just ICEs. Instead, this happened: I got a request to input a type instead! And no, that doesn't work either if you put it in, because instead you get: : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The fix is Due to parsing ambiguities generic arguments currently need to be put into braces, unless they are really simple (like or ), is not simple enough.
Oh, cool! That does compile! I knew about that but wasn't sure if that was the problem because I thought that was just for expressions? I guess that's technically an array expression? That is none of the errors I was presented with, though, which makes this a diagnostics problem I suppose?
I believe diagnostic for const generic (example taken from ) needs to be improved too before release, at least I thought that can be used instead, if one didn't know about then they need to search it up.
Arrays as const parameters still have bad error messages. same with tuples
claim
moved the file to over 3k LOC, but I didn't fix it there and instead just annotated the file so tidy ignores it. We should probably split the mir types into separate submodules by the way they are used in MIR. I think we can start by pulling out e.g. terminators and all their sub-types to a submodule <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim Will be interested in picking this up
These two code snippets should functionally be doing the same thing, but the type checker seems to think one has a destructor. The difference seems to be in the reliance on an associated type. complains that cannot be declared a mutable static because it has a desctructor: While this, unsurprisingly, works: Here are links to non-compiling/compiling examples on non-working: working:
( expressed interest in working on this, I will mentor.)
Triage: still relevant.
I'm still interested in helping to fix this. you mentioned at one point that you had a hunch for where the problem was. Perhaps a pointer would be enough to get the ball rolling?
Hmm. So, the error is emitted by the "constant qualification" code, which walks the MIR for generating a constant value and looks for things that should be disallowed. One of those things is the creation of a struct which has a destructor. This code is in . I think where I would start is trying to insert some to track out exactly what is happening. My guess would be that we are walking down , but I'm actually not sure. cc author of the code in question
It might be the type contents, if we use them for "needs drop". Aren't they conservative wrt projections?
that was my first assumption, that it was something like that. When I was poking about in the code I didn't see the place where we branch into that, but maybe I just wasn't reading very carefully.
which references . cc This could at least try to normalize projections, which would fix the problem here. Btw we can now remove "type contents" and replace it with two cached flags ( & needs-drop).
This doesn't seem to be an issue anymore. Running the provided "non-working" code doesn't trigger a compiler error.
Indeed, this not longer seems to be an issue. Happy to close the issue :)
Should we add a regression test first?
Reproduction branch: When applying the change from the last commit I get a panic in my code during the call to . <details<summaryBacktrace</summary</details
Cannot reproduce on my linux. Can you provide a small ? Is that possible? Maybe without all the externals :/
I can reproduce a very similar problem (appears to involve the same origin and failing assertion of ) compiling rust-lang/regex with and compiler flags: For me, setting to 2 or greater is required to present this failure. <details<summarybacktrace</summary<code<preRUSTBACKTRACE=1 cargo build Compiling regex v1.1.2 (/home/kent/rust/regex) thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32', stack backtrace: 0: std::sys::unix::backtrace::tracing::imp::unwindbacktrace at 1: std::syscommon::backtrace::print at 2: std::panicking::defaulthook::{{closure}} at at 3: std::panicking::defaulthook at 4: rustc::util::common::panichook 5: std::panicking::rustpanicwithhook at 6: std::panicking::beginpanic 7: syntax::sourcemap::SourceMap::bytepostofilecharpos 8: syntax::sourcemap::SourceMap::lookupcharpos 9: <rustccodegenssa::mir::FunctionCx<'a, 'tcx, Bx::scopemetadataforloc 10: <rustccodegenssa::mir::FunctionCx<'a, 'tcx,
Bx::debugloc 11: rustccodegenssa::mir::codegenmir 12: rustccodegenssa::base::codegeninstance 13: rustccodegenssa::monoitem::MonoItemExt::define 14: rustccodegenllvm::base::compilecodegenunit::modulecodegen 15: rustc::depgraph::graph::DepGraph::withtask 16: rustccodegenllvm::base::compilecodegenunit 17: rustccodegenssa::base::codegencrate 18: <rustccodegenllvm::LlvmCodegenBackend as rustccodegenutils::codegenbackend::CodegenBackend::codegencrate 19: rustc::util::common::time 20: rustcdriver::driver::phase4codegen 21: rustcdriver::driver::compileinput::{{closure}} 22: <std::thread::local::LocalKey<T::with 23: rustc::ty::context::TyCtxt::createandenter 24: rustcdriver::driver::compileinput 25: rustcdriver::runcompilerwithpool 26: <scopedtls::ScopedKey<T::set 27: rustcdriver::runcompiler 28: syntax::withglobals 29: rustmaybecatchpanic at 30: <F as alloc::boxed::FnBox<A::callbox 31: std::sys::unix::thread::Thread::new::threadstart at at at 32: <unknown33: clone query stack during panic: end of query stack error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: rustc 1.34.0-nightly ( 2019-02-26) running on x86_64-unknown-linux-gnu note: compiler flags: -Z mir-opt-level=2 -C debuginfo=2 -C incremental --crate-type lib </pre</code</details
With the help of , I've found a tiny test that reproduces this crash on Linux and Mac:
Got another one: <details</detailsHappens when compiling regex tests with and calling on every span found in the mir of the functions needing codegen.
According to glaicer, the ICE from this example has been gone.
can you confirm that your example does not crash on nightly anymore?
I realize it's kinda nonsensical, but here:
Why didn't WF catch this?
That's because only checks statics/constants.
Still reproducible with .
This ought to be a mostly easy fix. The problem is that the well formedness check, which ought to be rejected this code, is ignoring things in an : They fall through to this `` case: We would need to add support for the HIR item: which in turn has a number of items: which are defined here: presumably we want the to check that the types of are well-formed, roughly analogous to how we current check normal static items: (We probably want similar checks on foreign item fns, though?) One tricky part might be compatibility, we may need to turn this into a compatibility lint in case there is lots of broken code in the wild.
I am trying to fix this bug, and need help moving forward. function is modified to accept a and a , yet it doesn't report any additional errors and the ICE prevails. Test file: Commit: Should I create a pull request or is it too early?
Looks like suggestions are incomplete ( does not require ). Also, I left a comment on your commit about how you can avoid adding . I suspect the only reason regular s are required to be is they have an initializer (and that, not the type, requires ), i.e. for we have these errors:
Oddly, the PR that were previously posted to fix this (PR , following on PR ) was subsequently closed as inactive ... but the bug itself seems like it may have been resolved in the meantime?
I'm going to assume this was fixed. Tagging as E-needstest, but if someone wants to take the time, it'd be even better to bisect to where this was fixed, and see if a regression test for this was at that time.
Compiler no longer panics, tested with
Currently with const generics you can create a "specialized" implementation, such as: Which has the following output: (playground link: ) However, when using such a type in another crate this causes a stack overflow in the compiler. For example, with the following code (full example: ): I would expect it to produce the same output as the playground link above, however it produces the following:
A bisect shows this stopped crashing after , marked as needing a test
I was still encountering this in my code with and after trying to minimize it seems that the original example is fixed but the stack overflow still occurs when the const expression in the has braces around it. After experimenting I found some more examples of what works and what doesn't: (see to try it) compiles and runs successfully while and (or ) crash the compiler with the same error as the original: :
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --The code fails to pass <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --Repo is at <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Oh that is interesting: is that expected? The other way around would make sense (assigning a into anything, really), but with a on the left, that seems odd? Or maybe the message just gets the sides wrong.
Yeah, that MIR looks really broken: Cc
This is probably due to this line: , and shouldn't have this, since they have type , not .
This is a super old issue going back all the way to the initial MIR implementation and I’m somewhat confident is documented somewhere, though I cannot find an issue for this. IIRC these invalid assignments only happen in unreachable basic blocks, so however wrong it looks in isolation, it is dead code and I think it never was a priority to fix either generation or the MIR validation we had back then for exactly that reason. Looks like is a new take on validation? Perhaps the easy fix would be to not validate unreachable blocks.
The docs currently claim that the minimum Linux kernel version for is 2.6.18 (released September 20th, 2006). This is because RHEL 5 used that kernel version. However, RHEL 5 entered ELS on March 31, 2017. Should we continue to support RHEL 5 for , or should we increase the minimum Linux Kernel version to 2.6.27 (2nd LTS) or 2.6.32 (RHEL 6, 3rd LTS)? . Even bumping the min-version to 2.6.27 would allow us to remove most of the Linux-specific hacks in . Example: .
Given that RHEL is the only reason we keep comically old kernel versions around, I would propose that Rust only support RHEL until Maintenance Support ends. This is (essentially) what we already did for RHEL 4. Rust never supported RHEL 4, and back when RHEL 5 still had maintenance support. It would be nice to get someone from Red Hat or a RHEL customer to comment. This policy would allow us to increment the minimum kernel from 2.6.18 to 2.6.32 (and remove a lot of Linux-specific hacks). Note that RHEL has a weird (and very long) support system for RHEL 4, 5, and 6 (sources: and ). It has 5 major steps: Full Support Normal support of the OS Maintenance Support 1 Bug/Security fixes Limited hardware refresh Maintenance Support 2 Bug/Security fixes The end of this phase is considered "Product retirement" Extended Life Cycle Support (ELS) Additional paid product from Red Hat Gives updates for a longer period of time No additional releases/images Extended Life Phase (ELP) No more updates Limited Technical Support End date not given by Red Hat Current status of RHEL versions: RHEL 4 Not supported by Rust Currently in ELP (no end date specified) ELS ended March 31, 2017 RHEL 5 Supported by Rust Currently in ELS Maintenance Support ended March 31, 2017 ELS ends November 30, 2020 RHEL 6 Supported by Rust Currently in Maintenance Support 2 Maintenance Support ends November 30, 2020
cc which I think they could be related.