jiebi/CodeConvo huggingface dataset:
Code 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. // no-prefer-dynamic #[crate_id = "collections#0.10-pre"]; #[crate_type = "rlib"]; </ins>

Related discussion:
text: Built glfw-rs using rust 0.10-pre. When referencing this crate in another source file and building, I get error: internal compiler error: unexpected failure This message reflects a bug in the Rust compiler. We would appreciate a bug report: note: the compiler hit an unexpected failure path. this is a bug Ok(task 'rustc' failed at 'assertion failed: ()', ) This is on OSX 10.9: rustc 0.10-pre ( 2014-02-18 10:16:48 -0800) host: x8664-apple-darwin
This means that you've got two versions of the same lying around, and doesn't like having two versions. This will be fixed by , I just need to land it :(
I have just build the library for the first time, and I can only find one dylib for it on my system (next to the rlib, but I gues that shouldn't cause any problems). Is there another possibility for this error? Gesendet: Mittwoch, 19. Februar 2014 um 01:09 UhrVon: "Alex Crichton" : mozilla/rust hhildebr : Re: [rust] Compiler error when referencing crate "glfw-rs" () This means that you've got two versions of the same libglfw- lying around, and rustc doesn't like having two versions. This will be fixed by , I just need to land it :( — Reply to this email directly or view it on GitHub.
my reading of is that having a dylib and an rlib simultaneously is a problem.
Having a dylib and an rlib simultaneously should not be a problem, it is in fact quite common. Having 2 dylibs and 1 rlib or 2 rlibs and 1 dylib however is a problem.
sorry, my mistake in parsing the title of .
Yes, indeed, I had several identical dylibs, but it wasn't the glfw-rs.. there were rust libs in /usr/local/lib and /usr/local/lib/rustlib/... Thanks! Gesendet: Mittwoch, 19.
Code 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. // no-prefer-dynamic #[crate_id = "collections#0.10-pre"]; #[crate_type = "rlib"]; </ins>

Related discussion:
text: Februar 2014 um 17:15 UhrVon: "Alex Crichton" : mozilla/rust hhildebr : Re: [rust] Compiler error when referencing crate "glfw-rs" () Having a dylib and an rlib simultaneously should not be a problem, it is in fact quite common. Having 2 dylibs and 1 rlib or 2 rlibs and 1 dylib however is a problem. — Reply to this email directly or view it on GitHub.
so can we close this ticket now, in that case? Or do you want to wait for alexcrichton's patches to land, and see what things look like for you then?
Nono, the ticket can be closed for now. Thanks for your help! Gesendet: Mittwoch, 19. Februar 2014 um 21:30 UhrVon: "Felix S Klock II" : mozilla/rust hhildebr : Re: [rust] Compiler error when referencing crate "glfw-rs" () so can we close this ticket now, in that case? Or do you want to wait for alexcrichton's patches to land, and see what things look like for you then? — Reply to this email directly or view it on GitHub.
Code change:
} #[inline] <ins> fn fold<Acc, F>(self, init: Acc, f: F) -> Acc where F: FnMut(Acc, Self::Item) -> Acc, { ZipImpl::fold(self, init, f) } #[inline] </ins> unsafe fn __iterator_get_unchecked(&mut self, idx: usize) -> Self::Item where Self: TrustedRandomAccessNoCoerce,

Related discussion:
text: <!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: same codegen or similar in performance Instead, this happened: array has way worse codegen <details<summaryAssembly</summary<p</p</details<!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.64 <!-- Provide the version you are using that has the regression. --65 till now. Regressed in nightly-2022-08-13, maybe LLVM 15 ?: : <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. -- modify labels: +regression-from-stable-to-stable -regression-untriaged <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
WG-prioritization assigning priority (). cc since this regressed in the LLVM 15 update label -I-prioritize +P-medium +T-compiler
I've seen llvm doing these strange 1-byte-at-a-time "vectorizations" in other places too. This might be a more general problem. In this case we can probably paper over it by implementing TrustedRandomAccess for the array iter.
Unfortunately, the array iterator is fundamentally worse right now, because indexing into it -- a fundamental part of being a by-value array iterator -- keeps it from SRoAing and thus doesn't optimize well. This is why when I was making better I ended up making to not have to use . Sadly, for the foreseeable future you're better off using the "weaker" slice iterator when you can.
My guess is that the SROA is missing something in the opaque pointer mode.
Code change:
} #[inline] <ins> fn fold<Acc, F>(self, init: Acc, f: F) -> Acc where F: FnMut(Acc, Self::Item) -> Acc, { ZipImpl::fold(self, init, f) } #[inline] </ins> unsafe fn __iterator_get_unchecked(&mut self, idx: usize) -> Self::Item where Self: TrustedRandomAccessNoCoerce,

Related discussion:
text: claim
It's not about vectorization. This optimization can be restored by using . But highly unrecommended. Upstream issue:
The upstream issue is closed. claim
Code change:
/// # Examples /// /// ``` <del> /// #![feature(osstring_ascii)] </del> /// use std::ffi::OsString; /// /// assert!(OsString::from("Ferris").eq_ignore_ascii_case("FERRIS")); /// assert!(OsString::from("Ferrös").eq_ignore_ascii_case("FERRöS")); /// assert!(!OsString::from("Ferrös").eq_ignore_ascii_case("FERRÖS")); /// ``` <del> #[unstable(feature = "osstring_ascii", issue = "70516")] </del> <ins> #[stable(feature = "osstring_ascii", since = "1.53.0")] </ins> pub fn eq_ignore_ascii_case<S: AsRef<OsStr>>(&self, other: S) -> bool { self.inner.eq_ignore_ascii_case(&other.as_ref().inner) }

Related discussion:
text: <!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilization. Make sure to include the relevant RFC for the feature if it has one. If the new feature is small, it may be fine to skip the RFC process. In that case, you can use use in your initial implementation PR. The reviewer will ask you to open a tracking issue if they agree your feature can be without an RFC. --Feature gate: <!-- For most library features, it'd be useful to include a summarized version of the public API. (E.g. just the public function signatures without their doc comments or implementation.) --<!-- For larger features, more steps might be involved. If the feature is changed later, please add those PRs here as well. --- [x] - Stabilized traits necessary to obtain [x] - Added ASCII methods on [x] Final commenting period (FCP) [x] - Stabilization PR <!-- Once the feature has gone through a few release cycles and there are no unresolved questions left, the feature might be ready for stabilization. If this feature didn't go through the RFC process, a final commenting period (FCP) is always needed before stabilization. This works as follows: A library team member can kick off the stabilization process, at which point the rfcbot will ask all the team members to verify they agree with stabilization. Once enough members agree and there are no concerns, the final commenting period begins: this issue will be marked as such and will be listed in the next This Week in Rust newsletter. If no blocking concerns are raised in that period of 10 days, a stabilzation PR can be opened by anyone. --<!-- Include any open questions that need to be answered before the feature can be stabilised. If multiple (unrelated) big questions come up, it can be a good idea to open a separate issue for each, to make it easier to keep track of the discussions. It's useful to link any relevant discussions and conclusions (whether on GitHub, Zulip, or the internals forum) here. --- None yet.
Just needed to manipulate paths on windows -- I need to lower case driver letter, -.
Currently, SQLx contains The UTF-8 check that is included in there, while not a problem in practice, seems pointless. Changing to lands me here because of the .
Code change:
/// # Examples /// /// ``` <del> /// #![feature(osstring_ascii)] </del> /// use std::ffi::OsString; /// /// assert!(OsString::from("Ferris").eq_ignore_ascii_case("FERRIS")); /// assert!(OsString::from("Ferrös").eq_ignore_ascii_case("FERRöS")); /// assert!(!OsString::from("Ferrös").eq_ignore_ascii_case("FERRÖS")); /// ``` <del> #[unstable(feature = "osstring_ascii", issue = "70516")] </del> <ins> #[stable(feature = "osstring_ascii", since = "1.53.0")] </ins> pub fn eq_ignore_ascii_case<S: AsRef<OsStr>>(&self, other: S) -> bool { self.inner.eq_ignore_ascii_case(&other.as_ref().inner) }

Related discussion:
text: Also, if somebody did a similar thing with instead of , the version could drop that and would then be a bit less noisy.
is a stabilization PR. Since lib team wants to do fcp in the tracking issue. could you start one ?
merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [x] [x] [ ] Concerns: resolved by Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
Slight question about -- normally when dealing with AsRef args, they come in without an explicit reference in the signature (), except when necessary to support a lifetime in the return value (). Currently is declared as: Is this supposed to be instead? concern eqignoreasciicase &amp;S
I think it should be. I'm not sure why I wrote it like I did originally, but this makes more sense to me. I can make that PR if needed. Or can it be done in the stabilization PR? Not sure what the process is from here.
resolve eqignoreascii_case &amp;S reviewed Fixed in .
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
you can tick the FCP box, as the FCP is complete.
Code change:
let outdir = if let Some(mut path) = rustdoc_options.persist_doctests.clone() { path.push(&test_id); <del> std::fs::create_dir_all(&path) .expect("Couldn't create directory for doctest executables"); </del> <ins> if let Err(err) = std::fs::create_dir_all(&path) { eprintln!("Couldn't create directory for doctest executables: {}", err); panic::resume_unwind(box ()); } </ins> DirState::Perm(path) } else {

Related discussion:
text: When setting the directory to persist doctests to if an UNC path is used on windows there's a segfault. The offending setting of persist-doctests: . cargo-tarpaulin sets this programatically using a path it gets for the target directory from cargo-metadata. The path from cargo-metadata is an UNC path and this then causes a segfault. I'm going to detect UNC paths in my code and remove the on windows, but I felt this warrants a bug report as someone else will hit it eventually. Also, I'm not sure if other parts of the compiler fall prey to this issue? Compiler version is: the latest nightly (1.64.0-nightly 2022-06-28) The stack trace: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
This panic is also triggered in Linux if e.g. trying to write into a directory that the user has no permission to write. I PR'd fix to change the unwrap to more orderly panic and relaying the underlying error detail via eprintln! ~/gg/rust/build/x86_64-unknown-linux-gnu/stage2/bin/rustdoc --test -Z unstable-options --persist-doctests /tmp/foobar Couldn't create directory for doctest executables: Permission denied (os error 13) instead of:
The lack of ICE is definitely nicer, but this still won't handle UNC paths on windows will it? Which is the main issue I personally have with the code
That's a problem for std::fs::createdirall(&path) me thinks has to be fixed there
Makes sense looking at the code, should I raise another issue for the libs team?
Actually, yes it would be great to raise another issue targeting std::fs::createdirall - as it is wider issue. you are right. Thanks!
So isn't this an issue with the tool generating an incorrect argument?
So the paths are weirding me out (I normally only use linux), because they seem to sometimes print differently given different display methods. It shows up as printing the path in my rust code before making the env var, and if I print the rustdocflags I'm setting it's correct.
Code change:
let outdir = if let Some(mut path) = rustdoc_options.persist_doctests.clone() { path.push(&test_id); <del> std::fs::create_dir_all(&path) .expect("Couldn't create directory for doctest executables"); </del> <ins> if let Err(err) = std::fs::create_dir_all(&path) { eprintln!("Couldn't create directory for doctest executables: {}", err); panic::resume_unwind(box ()); } </ins> DirState::Perm(path) } else {

Related discussion:
text: But if I do it returns false, I have to do for it to return true. I'll raise the other issue and after work look into it more properly try to make a better MRE for windows
do you mind changing title s/UNC/invalid/ to address the panic on this issue, thanks! :)
also please remove s/on windows// thanks a lot :+1:
Done, and I realised what was wrong with the path, it's correct in the code, it's just when it got set into the environment variable it seems it needed the first slash to be escaped and that caused the invalid path (so no issues in std::fs need fixing)
claim label +I-ICE +T-RUSTDOC
Code change:
for (hir, ty) in hir_sig.inputs.iter().zip(ty_sig.inputs().iter()) { try_visit!(visitor.visit(hir.span, ty.map_bound(|x| *x))); } <del> for (pred, span) in tcx.predicates_of(item).instantiate_identity(tcx) { </del> <ins> for (pred, span) in tcx.explicit_predicates_of(item).instantiate_identity(tcx) { </ins> try_visit!(visitor.visit(span, pred)); } }

Related discussion:
text: https://crater-
searched nightlies: from nightly-2024-02-01 to nightly-2024-03-20 regressed nightly: nightly-2024-02-10 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.8</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsprobably
WG-prioritization assigning priority (). label -I-prioritize +P-high
MCVE
Code change:
use rustc_errors::Applicability; use rustc_hir as hir; use rustc_middle::ty::subst::InternalSubsts; <del> use rustc_middle::ty::{Ref, Ty}; </del> <ins> use rustc_middle::ty::{Adt, Ref, Ty}; </ins> use rustc_session::lint::builtin::RUST_2021_PRELUDE_COLLISIONS; use rustc_span::symbol::kw::Underscore; use rustc_span::symbol::{sym, Ident};

Related discussion:
text: For generic types, the prelude collision lint can produce suggestions that do not compile: Code: Suggestion from the prelude collision lint: Error after applying the suggestion: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
My guess is this should be a simple fix, just copying the code the lint already uses for adding unspecified generics (). Will try implementing a fix soon.
assign
release-assignment
The code related to this lint lives in the . The relevant suggestion is generated here: The "self type" string comes from here: The code for traits is here: This is actually just a touch tricky, because currently we are getting the "self type" just by copying the text the user wrote. Probably the most correct thing for us to do would be to examine the 'self expression' HIR and, if it is a plain path, then to append the and otherwise skip it. Specifically, the other case that I am thinking about is code like this: Currently , meaning that it offers the suggestion "disambiguate the associated function: ".
claim
great! Let us know if you need anything or make progress. This issue is fairly time sensitive.
release-assignment
claim
Code change:
let out = cargo.output() .expect("We already ran `cargo miri setup` before and that worked"); assert!(out.status.success(), "`cargo miri setup` returned with non-0 exit code"); <del> // Output is "MIRI_SYSROOT=<str>n". </del> <ins> // Output is "<sysroot>n". </ins> let stdout = String::from_utf8(out.stdout) .expect("`cargo miri setup` stdout is not valid UTF-8"); <del> let stdout = stdout.trim(); builder.verbose(&format!("`cargo miri setup --env` returned: {:?}", stdout)); let sysroot = stdout.splitn(2, '=') .nth(1).expect("`cargo miri setup` stdout did not contain '='"); </del> <ins> let sysroot = stdout.trim_end(); builder.verbose(&format!("`cargo miri setup --print-sysroot` said: {:?}", sysroot)); </ins> sysroot.to_owned() };

Related discussion:
text: Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
Code change:
set -ex source shared.sh <del> curl https://www.python.org/ftp/python/3.9.1/Python-3.9.1.tgz |  </del> <ins> curl https://www.python.org/ftp/python/2.7.12/Python-2.7.12.tgz |  </ins> tar xzf - mkdir python-build

Related discussion:
text: When I install the latest master toolchains via and try to build with them, linking fails: I did some bisection, and it looks like the problem started happening with Cc
The error is actually already mentioned in However, I am building Miri with cargo, so I don't know how I'd "use LLD instead".
Hm, we probably need to revert that PR. I did not realize we'd need lld downstream too, I thought that was only on our builder. cc
Yes, a revert seems appropriate. We're going to have to figure out where that's actually coming from. The only change I saw between 10 and 11 by grepping was the removal of llgo, but maybe there's some bad remnant.
Yeah, I thought this issue would be limited to the rustc build, but it makes sense that it can also affect project linking against rustc shared objects. I've looked a bit into what the root cause is, and what I have so far as that the symbol comes from and is present as a weak symbol both when compiling with clang-10 and clang-11. The only difference I see from is this: So apparently was treated as a symbol of the library, while now it's treated as a symbol of -- I'm not sure what that actually means, but presumably that refers to the compiler runtime libraries. My guess is that previously it just ended up being nulled out as a missing weak symbol, but now it's actually being found and linking fails because ... reasons. I'm not good at linkers :) Edit: shows these as:
can you prepare a revert PR?
Done in . If nobody has an idea on how to avoid the linker error, two more options would be to comment out the symbol in our llvm-project fork, or to avoid upgrading clang altogether and just build both Python 2 and Python 3 for that image.
The issue is probably going to be in how exactly the objects that comprise are compiled, not linked. I suspect just ends up ignoring the malformed object or otherwise not reporting the issue, but the object and the relevant symbols ultimately end up in the anyway. Alas, reasons these obscure failures can occur are many – I've seen them occur from things as trivial as forgetting to . The question is: is there perhaps a way to disable ExecutionEngine entirely? Intuitively nothing we do should depend on that code.
Code change:
set -ex source shared.sh <del> curl https://www.python.org/ftp/python/3.9.1/Python-3.9.1.tgz |  </del> <ins> curl https://www.python.org/ftp/python/2.7.12/Python-2.7.12.tgz |  </ins> tar xzf - mkdir python-build

Related discussion:
text: And if not, I'm comfortable patching out in our fork as we get closer to Feb 11 and continue having trouble pinpointing exact cause of this problem.
We normally don't link ExecutionEngine, but dist-x8664-linux in particular builds LLVM with ThinLTO, in which case we link as shared, instead of statically linking individual components into rustcllvm.
It seems to be possible to configure the components in using , but I'm not sure to what degree we can restrict those (not sure if this job also ships LLVM tools).
So, I think we could have used to exclude unnecessary parts from , as LLVM tools can still statically link the parts not in the dylib. But in the end, we can't use the option anyway due to
Looks like I'm getting this locally when trying to bootstrap rustc (while building ), might happen since the llvm upgrade but I'm not 100% sure. Are there some workarounds I can put into my for this? I'm using lld to link. <details<summaryBacktrace</summary<p</p</details
which commit are you trying to build?
latest git master
Probably best to open a new issue then; this one has been closed and the steps to reproduce it still work without error -- you might be having a different problem.
Opened
Did anyone file an upstream bug report about this? I'm observing it outside of Rust, but with a similar setup ( with lld+ThinLTO, then linking it into a binary with ). If not, I'd try to build a reproducer.
I've opened for this.
The bug has been fixed, the fix will be in LLVM 12.0.1.
Thanks! We can try updating clang again once the 12.0.1 tag is there.