jiebi/CodeConvo huggingface dataset:
Change:
let (lower, _) = iterator.size_hint(); let mut vector = Vec::with_capacity(lower.saturating_add(1)); unsafe { <del> ptr::write(vector.get_unchecked_mut(0), element); </del> <ins> ptr::write(vector.as_mut_ptr(), element); </ins> vector.set_len(1); } vector

Discussion:
To my knowledge, the following code is intended to be legal: However, Miri currently flags this as UB. I believe this is , but for . Discovered while writing . cc
Yeah this looks pretty similar. uses under the hood though, so I wonder why the issue still exists here. Looks like is implemented via -- and indeed, this errors, too:
The problem is in this line: The here is a slice method, so this creates a slice covering the entire , which overlaps with the mutable reference created before and thus invalidates it.
It shouldn't be too hard to locally fix this, but that duplicates some code and there are some other uses of in . Ideally, this would all use raw slices to avoid making any uniqueness promises. But without , raw slices are not very useful.
Here's a possible fix:
Fix PR is up:
Change:
pub type FILE_ACCESS_RIGHTS = u32; pub const FILE_ADD_FILE: FILE_ACCESS_RIGHTS = 2u32; pub const FILE_ADD_SUBDIRECTORY: FILE_ACCESS_RIGHTS = 4u32; <ins> #[repr(C)] pub struct FILE_ALLOCATION_INFO { pub AllocationSize: i64, } impl ::core::marker::Copy for FILE_ALLOCATION_INFO {} impl ::core::clone::Clone for FILE_ALLOCATION_INFO { fn clone(&self) -> Self { *self } } </ins> pub const FILE_ALL_ACCESS: FILE_ACCESS_RIGHTS = 2032127u32; pub const FILE_APPEND_DATA: FILE_ACCESS_RIGHTS = 4u32; pub const FILE_ATTRIBUTE_ARCHIVE: FILE_FLAGS_AND_ATTRIBUTES = 32u32;

Discussion:
Reported on discord, using will fail on Windows if the file is hidden. This also affects methods like or that open the file the same way. The reason for this is that we use , which has : So to make it work the caller needs to match the requested attributes to the existing attributes at the time of opening. It was suggested we could instead use and then manually truncate the file using to zero.
Manually truncating would require also clearing the alternate data streams too, right? And it would presumably stop erroring if another process still has the file open and instead corrupt the file fron the view of the other process.
No? The proposed solution would work the same was as in the case where the file already exists. Which we use for .
Right, got confused with .
Change:
let input = config::Input::File(options.input.clone()); let sessopts = config::Options { <del> maybe_sysroot: options.maybe_sysroot.clone().or_else( || Some(env::current_exe().unwrap().parent().unwrap().parent().unwrap().to_path_buf())), </del> <ins> maybe_sysroot: options.maybe_sysroot.clone(), </ins> search_paths: options.libs.clone(), crate_types: vec![config::CrateType::Dylib], cg: options.codegen_options.clone(),

Discussion:
On OpenBSD, the function fails if the binary is not invoked with a full path (see ). This leads to the following crash when running doc tests: Note that this using rustc/cargo 1.33.0, installed on OpenBSD 6.5 using its native package (). The offending code, I believe, must be one of the calls in , which are both unwrapped, and have to do with figuring out the sysroot, if not already known. The issue can be worked around by adjusting the command line like this: I guess solving this completely may be tricky, but I think the code should definitely not panic, and ideally cargo/rustdoc would issue an error message pointing (OpenBSD) users to the workaround.
It seems that simply using the code of from would be an improvement over using directly; the latter is patched on OpenBSD to consider the environment variable; see .
Change:
#![deny(unused_must_use)] <del> use quote::format_ident; use quote::quote; </del> use proc_macro::Diagnostic; <ins> use quote::{format_ident, quote}; </ins> use syn::spanned::Spanned; <del> use std::collections::{HashMap, HashSet}; </del> <ins> use std::collections::{BTreeSet, HashMap}; </ins> /// Implements #[derive(SessionDiagnostic)], which allows for errors to be specified as a struct, independent /// from the actual diagnostics emitting code.

Discussion:
My nightly script that checks for reproducible builds of rustc failed this morning. Git bisect pointed me to (). With that commit, about 12 rlibs have differences in my parallel builds (librustcprivacy is one) and nothing in the diff of the binaries jumps out as an obvious culprit. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The PR you linked to wasn't merged; I think you meant
Ah, yes, sorry about that. The commit should be correct, though.
cc
oops, yea this is likely (not sure if there are other hashset/hashmap iterations happening, but that's the only one I found). So the fix is twofold: First change all the and to and where possible, and second, collect to a and sort that before iterating over the set/map
Ah, my bad. I can take this. claim
Change:
<ins> // compile-pass #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash struct Generic<const V: usize>; fn main() { let _ = Generic::<0>; } </ins>

Discussion:
This very simple example (): results in: . Changing it to use curly braces around does not help.
This does work:
I was actually just experimenting locally to see if I could fix this and I think I have, I could put a PR up in a few minutes.
Change:
// interleaving, but wether UB happens can depend on whether a write occurs in the // future... let is_write = new_perm.initial_state.is_active() <del> || (new_perm.initial_state.is_resrved() && new_perm.protector.is_some()); </del> <ins> || (new_perm.initial_state.is_reserved() && new_perm.protector.is_some()); </ins> if is_write { // Need to get mutable access to alloc_extra. // (Cannot always do this as we can do read-only reborrowing on read-only allocations.)

Discussion:
You can't create pure closures right now. This is sometimes helpful in writing functions that operate on const data. I think this will just be a matter of adjusting typeck to determine purity from the expected type.

As of , we have enabled the LiveIRVariables LLVM pass which is a part of ongoing GC work for . Unfortunately, something in test/bench/task-perf-word- makes the LiveIRVariables pass unhappy. It seems that some LLVM optimization pass is producing an irreducible control flow graph, and LLVM's LoopSimplify pass isn't sophisticated enough to undo the damage. As a temporary workaround, xfails the two tests which break the liveness pass. But we should figure out what LLVM pass is causing the trouble and try to resolve that and un-xfail those tests.
Fixed in , and workaround reverted in .
Change:
current_trait_ref: Option<(Module<'a>, TraitRef)>, /// Fields used to add information to diagnostic errors. <del> diagnostic_metadata: DiagnosticMetadata<'ast>, </del> <ins> diagnostic_metadata: Box<DiagnosticMetadata<'ast>>, </ins> /// State used to know whether to ignore resolution errors for function bodies. ///

Discussion:
We should experiment with making the field in boxed and run perf to see if that improves compilation times. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Actually, I'm not sure I understand how this (alone) could yield any improvement; is there something more to the proposed changes? As it stands, purely boxing the field will surely only add heap allocation cost?
Thanks for looking into this! It depends entirely on the access patterns. Some of the diagnostic metadata substructs we have elsewhere in the compiler are accessed very rarely, while their parent struct is moved/copied/cloned often, so moving those into the heap provides improvements due to better caching/inlining. I had a hunch that this particular case might not be too impactful, but it was worth testing (and there are a handful of cases where there seems to be benefit!).
Change:
} let message = "Usage: rustc [OPTIONS] INPUT"; let nightly_help = if nightly_options::is_nightly_build() { <del> "n    -Z help             Print internal options for debugging rustc" </del> <ins> "n    -Z help             Print unstable compiler options" </ins> } else { "" };

Discussion:
Right now, The Unstable Book is just a list of unstable lang/lib features. There are other things like compiler flags which are also considered unstable that should be documented in The Unstable Book. This requires adjusting a bit to accommodate other sections. Right now I'm thinking that all sections (features, flags, etc) will live in their own subdirectory.
Relevant thread:
Reminder for future self: remove this hack
This may not be the issue, but there are a number of stable features that are actually just "stable", like target specs and llvm plugins, where we don't even try to maintain stability. It would be nice to have a discussion of those somewhere.
I'm waiting on to merge before I work on this.
Copying text from
This was partially completed in
In suggests that we should keep the library features minimal; I agree. They should exist, so you can see everything that's unstable, but there's no reason to duplicate their docs.
regarding unsafe command line options, one can see them via . it looks like the options are all defined . they seem to all be exposed on . seems like we should be able to autogenerate all the unsafe command line options pages like we do for the other unstable book sections (via )
Triage: we now have , but it doesn't talk about .
I just saw that the Unstable Book already contains a list of unstable compiler flags which I guess means that this issue is already solved right? Maybe we should create a separate issue for the missing -Z description in and close this one? Maybe also create a separate issue to autogenerate the unsafe nightly commands for the Unstable Book. That way we can keep the tasks that need to be done clearly isolated. If you agree I can create these new issues with a nice description of what needs to be done!
Yes! Alternatively, if this is something you'd like to send a PR for, we can just keep this issue open and use that PR to close it. I would prefer not to, I don't think this is the job for the unstable book.
I'll go ahead and do that then! I can understand that you have this view!

I do not really have much of a view myself on this, though I do think that we should keep duplication between the docs and other docs to a minimum (or to keep documentation duplication to a minimum in general because its easier to maintain). The docs are probably a better place to document this. However, this does lead me to the following question: Currently, there is already a in the unstable book. For example the flag. I think we should either try to complete this section or remove/move it to the docs all-together. What is your opinion on this?
Moving it to the docs seems appropriate to me!
I created an issue for this here: Then we can use this issue for adding -Z to the compiler flags section!
Change:
vec![self.doc_test(stage)] } Source::Doc { stage } => { <del> vec![self.doc_book(stage), self.doc_nomicon(stage), self.doc_style(stage), self.doc_standalone(stage), self.doc_std(stage), self.doc_error_index(stage)] </del> <ins> let mut deps = vec![ self.doc_book(stage), self.doc_nomicon(stage), self.doc_style(stage), self.doc_standalone(stage), self.doc_std(stage), self.doc_error_index(stage), ]; if build.config.compiler_docs { deps.push(self.doc_rustc(stage)); } deps </ins> } Source::Check { stage, compiler } => { // Check is just a pseudo step which means check all targets,

Discussion:
fails with: Note that there is no directory in Creating that directory fixes this problem but leads to another problem: This is because there is no directory in , which the tool tries to (checked with ). Creating that directory fixes the problem. Note that for stage 2, all directories starting at needed to be created.
Oh dear yeah this isn't tested very well so I wouldn't be surprised if it breaks every now and then, thanks for the report!
oops
Yeah, I expected that (the not very well tested) so when I needed to build the compiler docs I decided to try using rust build by that. By the way, I'm a little confused by the following: The rustbuild configuration includes a key, which is also present in the struct as , however the field .
Oh there should probably be a line in which adds that target to a dependency of the target, probably just got lost along the way somewhere by accident :(
Change:
<ins> // Copyright 2012-2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // Test that when instantiating trait default methods, typeck handles // lifetime parameters defined on the method bound correctly. pub trait Foo { fn bar<'a, I: Iterator<&'a ()>>(&self, it: I) -> uint { let mut xs = it.filter(|_| true); xs.len() } } pub struct Baz; impl Foo for Baz { // When instantiating `Foo::bar` for `Baz` here, typeck used to // ICE due to the lifetime parameter of `bar`. } fn main() { let x = Baz; let y = vec!((), (), ()); assert_eq!(x.bar(y.iter()), 3); } </ins>

Discussion:
Not exactly sure what the minimal failing test case is yet.
I think that I was running an out of date rustc. I don't think that this is a problem on master.
Actually, I hit this on rustc that I just built from master.
I talked to and he gave me access to his codebase, which I used to narrow down: Converting to a normal trait method and implementing it for stops the ICE. cc
Change:
<ins> // run-pass #![allow(dead_code)] struct Foo(()); const FOO: Foo = Foo(match 0 { 0.. => (), _ => (), }); fn main() { } </ins>

Discussion:
<!-- 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. --<!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
regressed in
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
<ins> // issue #117766 #![feature(let_chains)] fn main() { if let () = () && let () = () { //~ERROR: found a `{` in the middle of a let-chain && let () = () { } } fn quux() { while let () = () && let () = () { //~ERROR: found a `{` in the middle of a let-chain && let () = () { } } fn foobar() { while false {} { && let () = () } fn fubar() { while false { { && let () = () } } fn qux() { let foo = false; match foo { _ if foo => { && let () = () _ => {} } } fn foo() { { && let () = () } fn bar() { if false {} { && let () = () } fn baz() { if false { { && let () = () } } //~ERROR: this file contains an unclosed delimiter </ins>

Discussion:
Unmatched delimiters are hard to deal with by taking consideration of surrounding code because they actually occur during lexing. Still, it'd be nice if we detected some common sources of issues like this one. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
fn visit_block(&mut self, b: &ast::Block) { run_lints!(self, check_block, early_passes, b); ast_visit::walk_block(self, b); <ins> run_lints!(self, check_block_post, early_passes, b); </ins> } fn visit_arm(&mut self, a: &ast::Arm) {

Discussion:
For clippy's lint, I made use of a so I could stop clippy from linting the same macro multiple times while being reasonably fast. However, this unfortunately means the lint ignores .. attributes below the crate level. To solve this and other related problems, I propose any of allow a lint to check anything from anywhere in the analysis by moving up the parent chain to check the level allow a lint to opt out of calls for the duration of a specific node including its child nodes add methods to the {Early, Late}LintPass trait, so lints can decide themselves The third option is probably the easiest to implement, yet the most flexible. This would bring the trait closer to other stream parser implementations like SAX.
Seeing that we already have a few, _post methods, I think adding some more will be an acceptable solution here. I'll have a PR shortly.
Change:
pub code: ObligationCauseCode<'tcx> } <del> #[derive(Clone)] </del> <ins> #[derive(Clone, PartialEq, Eq)] </ins> pub enum ObligationCauseCode<'tcx> { /// Not well classified or should be obvious from span. MiscObligation,

Discussion:
That's a mouthful! To exemplify: This doesn't compile with , even though it does without it. Note that the only difference between the two configurations is that the function on is a free function instead of a default method. With , this fails with: Tested on
cc me
I've been running into very similar errors all day while updating my libs to the latest nightly. Here's an example of a method that works fine along with one that does not (simplest example I could come up with).
This example works now. I think this was a dup of
I just updated to master and I'm still running into the same error - perhaps my error is a separate issue?
Edwardw's PR does seem to fix my issue however, perhaps it addresses something extra?
The original issue is still present if the example on the first post is compiled with . I tested on , which contains Edit: just compiled . Still reproducible
Change:
<ins> error[E0004]: non-exhaustive patterns: type `bool` is non-empty --> $DIR/build-async-error-body-correctly.rs:4:25 | LL |     let binding = match true {}; |                         ^^^^ | = note: the matched value is of type `bool` help: ensure that all possible cases are being handled by adding a match arm with a wildcard pattern as shown | LL ~     let binding = match true { LL +         _ => todo!(), LL ~     }; | error: aborting due to previous error For more information about this error, try `rustc --explain E0004`. </ins>

Discussion:
<!-- ICE: Rustc '' 'error: internal compiler error: unexpected coroutine type Pin<&mut {async fn 3:2}', 'error: internal compiler error: unexpected coroutine type Pin<&mut {async fn 3:2}' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
regression in ping
Change:
/// Retrieves the `Node` corresponding to `id`, returning `None` if cannot be found. pub fn find(&self, hir_id: HirId) -> Option<Node<'hir>> { <del> let node = self.get_entry(hir_id).node; if let Node::Crate(..) = node { None } else { Some(node) } </del> <ins> self.find_entry(hir_id).and_then(|entry| { if let Node::Crate(..) = entry.node { None } else { Some(entry.node) } }) </ins> } /// Similar to `get_parent`; returns the parent HIR Id, or just `hir_id` if there

Discussion:
As of rustc 1.43.0-nightly ( 2020-03-15) the Travis CI builds of are failing due to rustc crashing. The crash happens when building the crate, which is a dependency of one of quiche's subcrates. Unfortunately I wasn't able to reproduce this locally, so I can't try the latest master or try to prepare a minimal reproducer, but I can reproduce this realiably on Travis CI, see e.g. https://travis- https://travis- https://travis- https://travis- Could this have something to do with Travis CI specifically? As per above, I don't have specific code that reproduces this. I can only reproduce when building the crate as part of quiche on Travis CI. : <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
FTR, the docopt crate was last updated almost a year ago, so this is not due to some new code there
Let's see if we can shrink the input to something suitable for a regression test. ping cleanup Also cc
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
This seems to be an issue with It could be we're calling with something that isn't an HIR owner, in which case it should be changed to return instead of panicking. It's odd that it can't be reproduced though.
I can reproduce it by on
I just realized I wasn't actually using rust nightly when I tried to reproduce locally :man_facepalming: so that explains that...
Minimized:
assign
Change:
<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { const X: u8 = 0; let out: u8 = match 0u8 { X => 99, b't' => 1, 1u8 => 2, _ => 3, }; assert_eq!(out, 99); } </ins>

Discussion:
For example
this actually appears to be currently fixed to me; I don't doubt that your PR has value, but can you explain which of the cases reported on this ticket is currently failing for you?
Ah, I hadn't actually checked if this issue was still valid! But it seems you're right and I don't think my PR is even relevant after the recent changes to constant evaluation. Closing, thanks.
Well, sorry, FWIW, this A-needstest.