jiebi/CodeConvo huggingface dataset:
Code change:
// aux-build:struct_variant_privacy.rs extern crate struct_variant_privacy; <del> fn f(b: struct_variant_privacy::Bar) { //~ ERROR enum `Bar` is private </del> <ins> fn f(b: struct_variant_privacy::Bar) { //~^ ERROR enum `Bar` is private </ins> match b { struct_variant_privacy::Bar::Baz { a: _a } => {} //~ ERROR enum `Bar` is private }

Related discussion:
text: <!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Seems to be the indicated function:
.
Assigning as discussed as part of the and removing . label -I-prioritize +P-medium
Oh this is ugly x) Reading the PR, the problem is that there are two ways to match a Box: via a box-pattern or via . But we can't know which will be used based on the type only. Current code assumes box-patterns, hence the error. The PR works because luckily all the fields of are private. If you tried pattern-matching within the module that defines , you'd get crazy results like (actually wouldn't even typecheck): We'll need to figure out a real solution when we implement generalized Deref patterns...
in that case we should open a new ticket for that work, tagged something like or something.
Code change:
"type name" }; <del> let msg = format!("use of undeclared {} `{}`", kind, path_names_to_string(path, 0)); </del> <ins> let self_type_name = special_idents::type_self.name; let is_invalid_self_type_name = path.segments.len() > 0 && maybe_qself.is_none() && path.segments[0].identifier.name == self_type_name; let msg = if is_invalid_self_type_name { "use of `Self` outside of an impl or trait".to_string() } else { format!("use of undeclared {} `{}`", kind, path_names_to_string(path, 0)) }; </ins> self.resolve_error(ty.span, &msg[..]); } }

Related discussion:
text: is a keyword, this error message indicates that it can be used to define type, which is misleading.
There is a similar issue: file.
No, that's a different issue. At the time that issue was filed, was not a keyword, just a confusing type. That said, at the time that issue was reported, it's fine to say the compiler was implemented properly. But my issue is about wrong error message, not bad(confusing) error message.
Do you mean is not a special ident now? I found the example code can be compiled, and there is excluding self type code
My point is that we are in different situation now. See and notice that it happened after the time the issue we discuss was filed.
Actually, IIRC we're moving towards a direction where can be used everywhere in a trait or impl context. I'm not sure though. any idea?
Yes we can use it in traits or impls. is totally legal for instance. But inside global functions can not be explained if I understand correctly.
Oh, sorry, this was a global fn. Makes sense.
Code change:
<ins> #![crate_type = "lib"] use super::A; //~ ERROR failed to resolve mod b { pub trait A {} pub trait B {} } /// [`A`] pub use b::*; </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '--crate-type=lib --edition=2021 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'internal error: entered unreachable code'', 'thread 'rustc' panicked at 'internal error: entered unreachable code'' File: --code: 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 nightly-2023-02-12 found 8 bors merge commits in the specified range commit[0] 2023-02-10: Auto merge of - flip1995:clippyup, r=Manishearth commit[1] 2023-02-10: Auto merge of - JulianKnodt:arrayconstval, r=cjgillot commit[2] 2023-02-11: Auto merge of - BoxyUwU:deferredprojectionequality, r=lcnr commit[3] 2023-02-11: Auto merge of - Dylan-DPC:rollup-fkl9swa, r=Dylan-DPC commit[4] 2023-02-11: Auto merge of - petrochenkov:doclink2, r=oli-obk commit[5] 2023-02-11: Auto merge of - the8472:rawvec-simpler-layout, r=thomcc commit[6] 2023-02-11: Auto merge of - matthiaskrgr:rollup-qnn380r, r=matthiaskrgr commit[7] 2023-02-11: Auto merge of - cjgillot:sroa-const, r=oli-obk ERROR: no CI builds available between and within last 167 days maybe ? ping
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. // ignore-pretty #![feature(unsafe_destructor)] use std::rc::Rc; use std::cell::Cell; struct Field { number: uint, state: Rc<Cell<uint>> } impl Field { fn new(number: uint, state: Rc<Cell<uint>>) -> Field { Field { number: number, state: state } } } #[unsafe_destructor] // because Field isn't Send impl Drop for Field { fn drop(&mut self) { println!("Dropping field {}", self.number); assert_eq!(self.state.get(), self.number); self.state.set(self.state.get()+1); } } struct NoDropImpl { _one: Field, _two: Field, _three: Field } struct HasDropImpl { _one: Field, _two: Field, _three: Field } #[unsafe_destructor] // because HasDropImpl isn't Send impl Drop for HasDropImpl { fn drop(&mut self) { println!("HasDropImpl.drop()"); assert_eq!(self._one.state.get(), 0); self._one.state.set(1); } } pub fn main() { let state = Rc::new(Cell::new(1)); let noImpl = NoDropImpl { _one: Field::new(1, state.clone()), _two: Field::new(2, state.clone()), _three: Field::new(3, state.clone()) }; drop(noImpl); assert_eq!(state.get(), 4); state.set(0); let hasImpl = HasDropImpl { _one: Field::new(1, state.clone()), _two: Field::new(2, state.clone()), _three: Field::new(3, state.clone()) }; drop(hasImpl); assert_eq!(state.get(), 4); } </ins>

Related discussion:
text: When a type has no impl, it fields appear to be destructed in order of declaration. When a type does have a impl, that order is apparently reversed. This is very surprising. Example: Prints:
cc who first hit this bug.
The LLVM IR for the Drop glue for : The LLVM IR for the Drop glue for : I don't know why it's getting pointers to each field before calling , they're not used until the cleanup, and they're cleaned up in reverse order. It's also, for some reason, grabbing a pointer to the drop flag (), even though it doesn't use it.
Nominating. Seems pretty strange.
I have an approved commit for this already, it's just failing on the pretty-rpass test at the moment.
I'm OK with disabling the test. Going forward the pretty printer should mainly be used for compiler diagnostics and rustfmt should cover the reformatting use cases, IMO.
Code change:
/// # Example /// /// ```rust <ins> /// # #![allow(deprecated)] </ins> /// use url::decode; /// /// let url = decode("https://example.com/Rust%20(programming%20language)");

Related discussion:
text: Users should use the cargo-ified Deprecate for a release or two then delete. cc
:+1:
Related:
I tried this: Hoping to deprecate the whole crate, but then building this program does not emit any warning: I expected a deprecation warning on the line. Is there another way to achieve this, or do I need to annotate individual items in the crate?
That should have worked, but you may need to remove the annotation above (they may be conflicting). I would also personally find it very helpful to annotate methods in particular what the path forward is (or just a general post about how to migrate).
Removing worked, thanks. Should this deprecation go through the RFC process, or can I assume that the team wants it since filed this issue? The documentation at explains how to use rust-url, and in particular the concept of relative v.s. non-relative URL schemes (e.g. vs ) which is a bit unusual. I believe this sufficient to make migration straightforward, but I’m obviously biased. Any feedback on the documentation is welcome. (I’ll make the deprecation message include the documentation’s URL, it seems more useful landing page than the github repo.)
Having an issue is sometimes considered a "todo item" rather than "everyone has approved this", you'll find both styles of issues on the issue tracker. We don't have much precedent for deprecating an in-tree crate, so we're forging new territory here. I'd like to start moving crates out of the repo, however, so I hope to have some more on this topic soon.
Code change:
<del> [target.thumbv7m-none-eabi] # uncomment this to make `cargo run` execute programs on QEMU </del> <ins> [target.thumbv6m-none-eabi] # FIXME: Should be Cortex-M0, but Qemu used by CI is too old </ins> runner = "qemu-system-arm -cpu cortex-m3 -machine lm3s6965evb -nographic -semihosting-config enable=on,target=native -kernel" <del> [target.thumbv6m-none-eabi] # uncomment this to make `cargo run` execute programs on QEMU # For now, we use cortex-m3 instead of cortex-m0 which are not supported by QEMU </del> <ins> [target.thumbv7m-none-eabi] </ins> runner = "qemu-system-arm -cpu cortex-m3 -machine lm3s6965evb -nographic -semihosting-config enable=on,target=native -kernel" <ins> [target.thumbv7em-none-eabi] runner = "qemu-system-arm -cpu cortex-m4 -machine lm3s6965evb -nographic -semihosting-config enable=on,target=native -kernel" [target.thumbv7em-none-eabihf] runner = "qemu-system-arm -cpu cortex-m4 -machine lm3s6965evb -nographic -semihosting-config enable=on,target=native -kernel" [target.thumbv8m.base-none-eabi] # FIXME: Should be the Cortex-M23, bt Qemu does not currently support it runner = "qemu-system-arm -cpu cortex-m33 -machine lm3s6965evb -nographic -semihosting-config enable=on,target=native -kernel" [target.thumbv8m.main-none-eabi] runner = "qemu-system-arm -cpu cortex-m33 -machine lm3s6965evb -nographic -semihosting-config enable=on,target=native -kernel" [target.thumbv8m.main-none-eabihf] runner = "qemu-system-arm -cpu cortex-m33 -machine lm3s6965evb -nographic -semihosting-config enable=on,target=native -kernel" </ins> [target.'cfg(all(target_arch = "arm", target_os = "none"))'] # uncomment ONE of these three option to make `cargo run` start a GDB session # which option to pick depends on your system

Related discussion:
text: I was working on making a run-make test today for a particular thumb target. While looking over how we do this elsewhere, I found this bit of code: From my local testing, it seems like having multiple lines of this form has the net effect of making the test a no-op that does not test anything: since a target matching line 13 will not match line 14, and vice versa, there are no targets that can run on this test. We should either revert the portion of the commit that did this: or figure out some other way to express the desired property here (or change the semantics of when multiple targets are provided to make it gather all such targets up in a set before doing the check for membership... but I am wary of making such a change since doing it right would require differentiating e.g. processor target vs OS target, for example...)
Also, It looks like there may be other instances of the same mistake elsewhere in the test suite, such as in:
Oof, not good. It shouldn't be hard to make rustbuild outright reject this scenario though.
Further effort on has led me to conclude that these lines do not work at all, at least not for cross-compilation.
Code change:
&& key.ns == MacroNS && nonglob_binding.expansion != LocalExpnId::ROOT { <del> resolution.binding = Some(self.ambiguity( </del> <ins> resolution.binding = Some(this.ambiguity( </ins> AmbiguityKind::GlobVsExpanded, nonglob_binding, glob_binding,

Related discussion:
text: <!-- 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. --With the latest nightly, the bytemuck crate fails to compile. This was compiling yesterday and the issue seems to be traits are not imported with super::*. Please see the issue in the bytemuck repository: <!-- 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. --: </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regression in searched nightlies: from nightly-2023-06-10 to nightly-2023-06-20 regressed nightly: nightly-2023-06-20 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: cc
<details<summaryi made a mistake making the example, see below </summaryThis should error in coherence, but instead errors with It looks like if there is a derive macro and trait with the same name, glob imports don't resolve the trait anymore. Note that works correctly </details
Maybe the reduced it incorrect? I found that it also throw an error for 1.70?
hm, maybe your change simply exposed an existing bug in more cases
I will check it later claim
ah no, I made a stupid mistake, i should have used :D, my example only got from the prelude which only contains the macro.
This is resolved, of course. Only tagging this with Nilstrieb's estimated priority for historical analysis later.
Now that this fix is merged, what time tonight should we expect a new nightly release?
0:00 according to a server somewhere. In practice, usually UTC 0:00. So it should be being cut sometime soon. Or 24 hours from now. Either one.
Code change:
use rustc_infer::infer::type_variable::{TypeVariableOrigin, TypeVariableOriginKind}; use rustc_infer::infer::DefineOpaqueTypes; use rustc_infer::infer::InferOk; <ins> use rustc_infer::traits::query::NoSolution; </ins> use rustc_infer::traits::ObligationCause; use rustc_middle::middle::stability; use rustc_middle::ty::adjustment::{Adjust, Adjustment, AllowTwoPhase};

Related discussion:
text: I tried this code (): I expected to see this happen: rustc outputs an error saying that I need to add the and traits on . Instead, this happened: which is jarring to see, and unhelpful, because HashMap does support Index, but only with particular trait bounds on . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The reduced case: works as expected, perhaps it is caused when the implementer is not from the local crate?
claim
Code change:
debug!("(building reduced graph for external  crate) building type {}", final_ident); <ins> let modifiers = match new_parent.kind.get() { NormalModuleKind => modifiers, _ => modifiers & !DefModifiers::IMPORTABLE }; </ins> child_name_bindings.define_type(def, DUMMY_SP, modifiers); } DefStruct(def_id) => {

Related discussion:
text: with rustc 1.0.0-nightly ( 2015-03-01) (built 2015-03-01)
This is still an issue
Still an issue in 1.0.0.
This is still an issue in 1.3.0-nightly: $ rustc error: internal compiler error: unexpected panic thread 'rustc' panicked at 'assertion failed: <= ()', stack backtrace: 1: 0x7fd6c19bd5ee - sys::backtrace::write::h04a6ced565b26815Lqs 2: 0x7fd6c19c5214 - panicking::onpanic::h521f84b604e22dfel8w 3: 0x7fd6c198804e - rt::unwind::beginunwindinner::hd3dee614a0e1c16cZNw 4: 0x7fd6c1988d7c - rt::unwind::beginunwindfmt::ha4ce6704c81423045Mw 5: 0x7fd6c19c4dd6 - rustbeginunwind 6: 0x7fd6c1a15bb4 - panicking::panicfmt::he89ea3094b3178e919B 7: 0x7fd6c1a0f9dd - panicking::panic::h9e565ee21070221by8B 8: 0x7fd6c11f8271 - astconv::finishresolvingdeftoty::h03670159ac2fefe7aTv 9: 0x7fd6c11b6340 - astconv::asttytoty::hb2c49d2cf31c029bYUv 10: 0x7fd6c1189eed - check::closure::checkexprclosure::hbce85e7beaf0ebd52zl 11: 0x7fd6c11d360b - check::checkexprwithunifier::h16314096699859592584 12: 0x7fd6c11f998b - check::checkdeclinitializer::h491ede37e45bce9e84r 13:
Code change:
debug!("(building reduced graph for external  crate) building type {}", final_ident); <ins> let modifiers = match new_parent.kind.get() { NormalModuleKind => modifiers, _ => modifiers & !DefModifiers::IMPORTABLE }; </ins> child_name_bindings.define_type(def, DUMMY_SP, modifiers); } DefStruct(def_id) => {

Related discussion:
text: 0x7fd6c11f9a4d - check::checkdecllocal::h1c782249285c9ae3m6r 14: 0x7fd6c11f9c79 - check::checkstmt::h48bf6ea3f412b86bf8r 15: 0x7fd6c11a91b3 - check::checkblockwithexpected::h072b2c4702c43b1cjcs 16: 0x7fd6c118bef4 - check::checkfn::h8218f9adb3734183iQn 17: 0x7fd6c11a35ca - check::checkbarefn::h3c567a2d1339f838RFn 18: 0x7fd6c11a1523 - check::checkitembody::h8e17e6521c30131ay6n 19: 0x7fd6c11a31e4 - check::checkitemtypes::h62e908b1d9f74b39oDn 20: 0x7fd6c12609b8 - checkcrate::h594ee0148d251222uZC 21: 0x7fd6c1f1dc69 - driver::phase3runanalysispasses::closure.
Code change:
debug!("(building reduced graph for external  crate) building type {}", final_ident); <ins> let modifiers = match new_parent.kind.get() { NormalModuleKind => modifiers, _ => modifiers & !DefModifiers::IMPORTABLE }; </ins> child_name_bindings.define_type(def, DUMMY_SP, modifiers); } DefStruct(def_id) => {

Related discussion:
text: 22: 0x7fd6c1f1c633 - middle::ty::ctxt<'tcx::createandenter::h349256048753845929 23: 0x7fd6c1f17a17 - driver::phase3runanalysispasses::h15521018079403107052 24: 0x7fd6c1efa266 - driver::compileinput::hbf698b02349f7ce3Tba 25: 0x7fd6c1fd3ed3 - runcompiler::hd724b5fef3441688y7b 26: 0x7fd6c1fd18ae - boxed::F.FnBox<A::callbox::h6609070342514802751 27: 0x7fd6c1fd10f9 - rt::unwind::try::tryfn::h10774555836369096370 28: 0x7fd6c1a3ed48 - rusttryinner 29: 0x7fd6c1a3ed35 - rusttry 30: 0x7fd6c19b08a7 - rt::unwind::try::innertry::hb0d7a3eb324339ceSJw 31: 0x7fd6c1fd130b - boxed::F.FnBox<A::callbox::h18179817771297192954 32: 0x7fd6c19c3e71 - sys::thread::Thread::new::threadstart::hf8c7448e27294ed0PTv 33: 0x7fd6bb60f353 - startthread 34: 0x7fd6c161ebfc - _clone 35: 0x0 - <unknown
$ rustc --version rustc 1.3.0-nightly ( 2015-06-30)
This problem has gone away for me now. It may have been from mixing versions? It may have gone away after a .
It is still an issue on nightly according to the playpen:
You're right. I must have been in the wrong project.
I just ran into the same assertion (with both stable 1.1 and nightly 1.3), but with different code.
Code change:
debug!("(building reduced graph for external  crate) building type {}", final_ident); <ins> let modifiers = match new_parent.kind.get() { NormalModuleKind => modifiers, _ => modifiers & !DefModifiers::IMPORTABLE }; </ins> child_name_bindings.define_type(def, DUMMY_SP, modifiers); } DefStruct(def_id) => {

Related discussion:
text: Would it help if I try to create another minimal working example and post it here or a new bug report? This is my backtrace: didn't help.
Okay here it is: Unfortunately it has something to do with glium, so I guess this doesn't help much :/
May be related, not sure: (rustc 1.2.0 ( 2015-08-03))
minimized:
Code change:
Some(false) => { cvt(unsafe { unlinkat(fd, child.name_cstr().as_ptr(), 0) })?; } <del> None => match cvt(unsafe { unlinkat(fd, child.name_cstr().as_ptr(), 0) }) { // type unknown - try to unlink Err(err) if err.raw_os_error() == Some(libc::EISDIR) || err.raw_os_error() == Some(libc::EPERM) => { // if the file is a directory unlink fails with EISDIR on Linux and EPERM everyhwere else remove_dir_all_recursive(Some(fd), Path::new(&child.file_name()))?; } result => { result?; } }, </del> <ins> None => { // POSIX specifies that calling unlink()/unlinkat(..., 0) on a directory can succeed // if the process has the appropriate privileges. This however can causing orphaned // directories requiring an fsck e.g. on Solaris and Illumos. So we try recursing // into it first instead of trying to unlink() it. remove_dir_all_recursive(Some(fd), Path::new(&child.file_name()))?; } </ins> } }

Related discussion:
text: The fix for CVE-2022- (, ) appears to have introduced a regression that can cause file system corruption on some UNIX systems. The new code will attempt to use in any case where it does not know what type of file a directory entry represents. Some systems do not provide that information along with the entry names returned while reading a directory, and even on systems which provide a type hint, that hint may be . In cases where we do not know the type of the entry, the code tries first to unlink it as if it were something other than a directory: The code assumes that on a directory will fail with , or on Linux with the non-standard , but this is not always the case. POSIX does suggests as a failure in some, but not all cases: (See in The Open Group Base Specifications Issue 7, 2018 edition) Implementations are not required to prohibit on directories, and indeed UFS file systems on present day illumos and presumably at least some Solaris systems allow of a directory if the user has sufficient privileges. Other platforms may as well. Unfortunately unlinking a directory on UFS causes a sort of file system corruption that requires an unmount and a trip through to correct. Any code that uses on UFS has since started causing that kind of corruption, which took a bit of work to track down. I think the fix is probably relatively simple, and has the benefit of not touching the code path where we believe we know what sort of entry we are removing: In short, we should try to first, rather than first, as that always fails in a safe way that we can detect. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc (as you're the one how wrote the new code)
Thanks for the ping claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
Was this issue reported upstream? Filesystems corrupting themselves seem like a poor failure mode in any case, and in some ways is a violation of the sandboxing that the kernel ought to provide for the user-space applications.
Code change:
Some(false) => { cvt(unsafe { unlinkat(fd, child.name_cstr().as_ptr(), 0) })?; } <del> None => match cvt(unsafe { unlinkat(fd, child.name_cstr().as_ptr(), 0) }) { // type unknown - try to unlink Err(err) if err.raw_os_error() == Some(libc::EISDIR) || err.raw_os_error() == Some(libc::EPERM) => { // if the file is a directory unlink fails with EISDIR on Linux and EPERM everyhwere else remove_dir_all_recursive(Some(fd), Path::new(&child.file_name()))?; } result => { result?; } }, </del> <ins> None => { // POSIX specifies that calling unlink()/unlinkat(..., 0) on a directory can succeed // if the process has the appropriate privileges. This however can causing orphaned // directories requiring an fsck e.g. on Solaris and Illumos. So we try recursing // into it first instead of trying to unlink() it. remove_dir_all_recursive(Some(fd), Path::new(&child.file_name()))?; } </ins> } }

Related discussion:
text: We can try to avoid this case by default, as is switching to try unknown as a directory first, but you should note that this is still going to be racy. If there's an unprivileged adversary like the CVE supposes, then they can try to race changes between "try (and fail) as a directory" to "unlink as a file", to make it unlink a directory after all and induce corruption. IOW, it sounds like it's not safe for a privileged process to unlink paths at all if they may be changed by lesser privileges .
It should not really cause corruption according to the , just orphaned directories: Of course this can lead to resource exhaustion since the disk space and the inodes cannot be reclaimed until the next .
And that user is only root or otherwise root-like? i.e. it's not just talking about regular access privileges?
For Illumos the process must have root privileges or needs to be in the process privilege set (). Solaris has at some point abolished this privilege and apparently does not allow unlinking directories anymore ().