jiebi/CodeConvo huggingface dataset:
Code change:
let incr_comp_session_dir: PathBuf = sess.incr_comp_session_dir().clone(); <del> if sess.has_errors() { </del> <ins> if sess.has_errors_or_delayed_span_bugs() { </ins> // If there have been any errors during compilation, we don't want to // publish this session directory. Rather, we'll just delete it.

Related discussion:
text: When compiling a testcase (e.g. the last snippet in on the current nightly, or any of the other examples in that issue on older compilers) with (or Cargo which does that by default), only the initial run will ICE. Subsequent runs will succeed without an ICE, in the absence of any regular errors. However, changing the relevant code (e.g. adding a space) can cause the query that calls to be recomputed and bring the ICE back. IIUC, incremental compilation stores diagnostics and replays them on subsequent runs, but that appears to not apply to ICEs. cc
It looks like without incremental we output artifacts (like ). Do we do this in case of errors too? It seems bad to produce artifacts after an ICE.
Nominating and proposing P-high (mostly because of potential annoyance factor). This should possibly also be labeled I-unsound under the assumption that under the general case of this issue, we might produce artifacts under subsequent runs that may produce UB traces. (However, it is probable that the user will notice the ICE at some other point in time and therefore discard the artifact.)
The current expected behavior of the compiler is to not save any incremental state if an error occurs. may slip through the cracks here.
In that case, it seems to me like it's a matter of recording the fact that we did a (which we already do, ) and then have this mean "there was an error" in terms of "should we save incremental state?".
Yep, the following check should also take into account: While we are at it, we could also add a similar check to and , as not to waste time producing values that will then be discarded anyway:
I'd like to start contributing to rustc and I wanted to ask if this is a good issue to start on (I have read the rustc book)
Sure, this is a decently good issue to start on and should be pretty interesting in terms of learning the infrastructure. If you get stuck, need help, and want to talk synchronously you can hop into https://rust- and we'll try to help out.
fixes this issue. It would still be good to have a test case for it.
I have started to write the code making this test possible, I'll open a PR shortly
Code change:
if (InstrProfileOutput) { Options.InstrProfileOutput = InstrProfileOutput; } <ins> // cargo run tests in multhreading mode by default // so use atomics for coverage counters Options.Atomic = true; </ins> MPM.addPass(InstrProfiling(Options, false)); } );

Related discussion:
text: <!-- 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.)
Code change:
if (InstrProfileOutput) { Options.InstrProfileOutput = InstrProfileOutput; } <ins> // cargo run tests in multhreading mode by default // so use atomics for coverage counters Options.Atomic = true; </ins> MPM.addPass(InstrProfiling(Options, false)); } );

Related discussion:
text: 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
Code change:
<del> Subproject commit 99faef833f890fe89f1a959d89b951954118828b </del> <ins> Subproject commit e9da96eb452aa65e79e2342be700544afe509440 </ins>

Related discussion:
text: 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.
Code change:
ty::TypeScheme { ty: ty, generics: ty_generics } } hir::ItemTy(ref t, ref generics) => { <del> let ty_generics = ty_generics_for_type_or_impl(ccx, generics); </del> <ins> let ty_generics = ty_generics_for_type(ccx, generics); </ins> let ty = ccx.icx(generics).to_ty(&ExplicitRscope, &t); ty::TypeScheme { ty: ty, generics: ty_generics } } hir::ItemEnum(ref ei, ref generics) => { <del> let ty_generics = ty_generics_for_type_or_impl(ccx, generics); </del> <ins> let ty_generics = ty_generics_for_type(ccx, generics); </ins> let substs = mk_item_substs(ccx, &ty_generics); let def = convert_enum_def(tcx, it, ei); let t = tcx.mk_enum(def, tcx.mk_substs(substs)); ty::TypeScheme { ty: t, generics: ty_generics } } hir::ItemStruct(ref si, ref generics) => { <del> let ty_generics = ty_generics_for_type_or_impl(ccx, generics); </del> <ins> let ty_generics = ty_generics_for_type(ccx, generics); </ins> let substs = mk_item_substs(ccx, &ty_generics); let def = convert_struct_def(tcx, it, si); let t = tcx.mk_struct(def, tcx.mk_substs(substs));

Related discussion:
text: If I understand correctly, type parameter defaults have no effect in the block . Just like in PR , this should have a warning and then an error. Example cc
Argh, I guess I failed to cover those?
Nominating for triage.
triage: P-high
Code change:
<ins> error: character literal may only contain one codepoint --> $DIR/issue-64732.rs:3:17 | LL |     let _foo = b'hello0'; |                 ^^^^^^^^^ help: if you meant to write a byte string literal, use double quotes | LL |     let _foo = b"hello0"; |                 ^^^^^^^^^ error: character literal may only contain one codepoint --> $DIR/issue-64732.rs:6:16 | LL |     let _bar = 'hello'; |                ^^^^^^^ help: if you meant to write a `str` literal, use double quotes | LL |     let _bar = "hello"; |                ^^^^^^^ error: aborting due to 2 previous errors </ins>

Related discussion:
text: 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!
Code change:
// aux-build:sepcomp_lib.rs // compile-flags: -C lto // no-prefer-dynamic <ins> // ignore-android FIXME #18800 </ins> extern crate sepcomp_lib; use sepcomp_lib::a::one;

Related discussion:
text: 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.
Code change:
path.push(id); } let path = ast::Path { <del> span: mk_sp(lo, self.span.hi), </del> <ins> span: mk_sp(path_lo, self.span.hi), </ins> global: false, segments: path.move_iter().map(|identifier| { ast::PathSegment {

Related discussion:
text: For 'use' items of the form . [I don't see how to assign this to myself, but I have a patch which I will make into a PR soon]
Code change:
--lldb-python $$(CFG_LLDB_PYTHON)  --gdb-version="$(CFG_GDB_VERSION)"  --lldb-version="$(CFG_LLDB_VERSION)"  <ins> --llvm-version="$$(LLVM_VERSION_$(3))"  </ins> --android-cross-path=$(CFG_ARM_LINUX_ANDROIDEABI_NDK)  --adb-path=$(CFG_ADB)  --adb-test-dir=$(CFG_ADB_TEST_DIR) 

Related discussion:
text: 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!
Code change:
<ins> // Regression test of #43913. // run-rustfix #![feature(trait_alias)] #![allow(bare_trait_objects, dead_code)] type Strings = Iterator<Item=String>; struct Struct<S: Strings>(S); //~^ ERROR: expected trait, found type alias `Strings` fn main() {} </ins>

Related discussion:
text: I managed to reproduce the problem with this snippet: The compiler yells E0404 at me, but fair enough I always ask it to a bit more about it :) However this time, it only says this: This is confusing because the snippet above doesn't involve the keyword so I didn't understand initially what I was doing wrong, then I read the error message again: I first tried this, and it worked, but having to repeat the whole syntax everywhere wasn't too compelling, hence the alias: The compiler error message makes it very clear that I can't alias a trait, but the E0404 explanation doesn't mention it at all. I hope the description could also include this use case as I've seen sometimes EXXXX explanations go over several facets of the same problem. That won't help me, but maybe others that may trip on the same problem. I would have submitted a pull request for the docs myself, but I have no idea why you can't use type aliases for traits so I can't it ;) I'm using stable Rust 1.19.0 (on Fedora).
One more thing, even though the compiler lets me create an alias for a trait, I don't know when I can use such an alias. Maybe this should be explained too.
Current output (in nightly):
Current output: No structured suggestion for the nightly feature (should be and the feature flag).
Code change:
buffer: String, } <ins> impl core::fmt::Write for Buffer { #[inline] fn write_str(&mut self, s: &str) -> fmt::Result { self.buffer.write_str(s) } #[inline] fn write_char(&mut self, c: char) -> fmt::Result { self.buffer.write_char(c) } #[inline] fn write_fmt(self: &mut Self, args: fmt::Arguments<'_>) -> fmt::Result { self.buffer.write_fmt(args) } } </ins> impl Buffer { crate fn empty_from(v: &Buffer) -> Buffer { Buffer { for_html: v.for_html, buffer: String::new() }

Related discussion:
text: 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 :)
Code change:
<ins> // compile-pass // edition:2018 // // Tests that we properly handle StorageDead/StorageLives for temporaries // created in async loop bodies. #![feature(async_await)] async fn bar() -> Option<()> { Some(()) } async fn listen() { while let Some(_) = bar().await { String::new(); } } fn main() { listen(); } </ins>

Related discussion:
text: 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.
Code change:
enum Enum1 { Variant1(isize), <del> Variant2 //~ ERROR: variant is never used </del> <ins> Variant2 //~ ERROR: variant is never constructed </ins> } enum Enum2 { Variant3(bool), #[allow(dead_code)] Variant4(isize), <del> Variant5 { _x: isize }, //~ ERROR: variant is never used: `Variant5` Variant6(isize), //~ ERROR: variant is never used: `Variant6` </del> <ins> Variant5 { _x: isize }, //~ ERROR: variant is never constructed: `Variant5` Variant6(isize), //~ ERROR: variant is never constructed: `Variant6` </ins> _Variant7, }

Related discussion:
text: I was changing some code from integer constants to a proper enum and was greeted by the following warning: The warning sounded weird to me because I was pattern-matching on that damn variant in various places of the code; but I was pointed out to the fact that I wasn't actually creating that value. Maybe the warning should be rewritten to explicitly mention value creation? Cc
cc that looks like your thing
duplicate of
Yup! Closing in favor of that.
Code change:
if !non_trait.is_empty() { let render_mode = match what { AssocItemRender::All => { <del> write!(w, "<h2 id='methods'>Methods</h2>")?; </del> <ins> write!(w, " <h2 id='methods' class='section-header'> <a href='#methods'>Methods</a> </h2> ")?; </ins> RenderMode::Normal } AssocItemRender::DerefFor { trait_, type_, deref_mut_ } => { <del> write!(w, "<h2 id='deref-methods'>Methods from  {}&lt;Target = {}&gt;</h2>", trait_, type_)?; </del> <ins> write!(w, " <h2 id='deref-methods' class='section-header'> <a href='#deref-methods'>Methods from {}&lt;Target = {}&gt;</a> </h2> ", trait_, type_)?; </ins> RenderMode::ForDeref { mut_: deref_mut_ } } };

Related discussion:
text: A page like has many things that could be useful to link to. These should be possible to link to by clicking on: [x] The header [x] 's on a page. [x] at the top On it's hit or miss: [x] Examples [x] Associated Types [x] Required Methods [x] Implementors On [x] Provided Methods I don't have any big use cases but when I want to link to these for something like this bug I can't link to any specific line. I gotta say go to vec page, scroll 75% to bottom. Squint hard to see it.
Just ran into this today; I'd really like to have links from the impls in the Implementors section to the source containing the impl.
Triage: we always need more links....
Update: Headers written in docs and (most) auto-generated headers are either fully hyperlinked or have a "section marker" symbol that shows up on hover. Major auto-generated page headers have links in the top of the sidebar of the page. Impl blocks do not have hyperlinks (yet); that's
Since got merged and closed out , that was the last major request on this issue, so i'll close this out. If you think of something else that needs a hyperlinked header, feel free to open a new issue or reopen this one.
Code change:
<del> Subproject commit 7799d03de85bcc1a7437f65d4f7adfbb267d2acb </del> <ins> Subproject commit 79d659e5699fbf7db5b4819e9a442fb3f550472a </ins>

Related discussion:
text: 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.
Code change:
_ => {} } } <ins> // Similar to operators, indexing is always assumed to be overloaded // Here, correct cases where an indexing expression can be simplified // to use builtin indexing because the index type is known to be // usize-ish fn fix_index_builtin_expr(&mut self, e: &hir::Expr) { if let hir::ExprIndex(ref base, ref index) = e.node { let mut tables = self.fcx.tables.borrow_mut(); match tables.expr_ty_adjusted(&base).sty { // All valid indexing looks like this ty::TyRef(_, ty::TypeAndMut { ty: ref base_ty, .. }) => { let index_ty = tables.expr_ty_adjusted(&index); let index_ty = self.fcx.resolve_type_vars_if_possible(&index_ty); if base_ty.builtin_index().is_some() && index_ty == self.fcx.tcx.types.usize { // Remove the method call record tables.type_dependent_defs_mut().remove(e.hir_id); tables.node_substs_mut().remove(e.hir_id); tables.adjustments_mut().get_mut(base.hir_id).map(|a| { // Discard the need for a mutable borrow match a.pop() { // Extra adjustment made when indexing causes a drop // of size information - we need to get rid of it // Since this is "after" the other adjustment to be // discarded, we do an extra `pop()` Some(Adjustment { kind: Adjust::Unsize, .. }) => { // So the borrow discard actually happens here a.pop(); }, _ => {} } }); } }, // Might encounter non-valid indexes at this point, so there // has to be a fall-through _ => {}, } } } </ins> } /////////////////////////////////////////////////////////////////////////// // Impl of Visitor for Resolver //

Related discussion:
text: Hello, today we've found some weird behaviour of array indexing. Here is the Code snippet: The question is, why is the indexing operator behaves depending on whether we evaluate in place or not.
Highly related question :
Moreover, does not compile too.
points to this being a difference in how builtin indexing works vs overloaded indexing. My cleaned up version of the transcript: Highly related to , which will cause these types of situations to occur more frequently.
As a workaround, you can write an explicit type of which will then allow builtin indexing to happen: