jiebi/CodeConvo huggingface dataset:
Change:
// @has user/type.BareAmbiguousBoundStatic.html // @has - '//*[@class="rust item-decl"]//code' "dyn AmbiguousBoundTrait<'o, 'o> + 'static;" pub use dyn_trait::BareAmbiguousBoundStatic; <ins> // Regression test for issue #115179: // @has user/type.NestedTraitObjects.html // @has - '//*[@class="rust item-decl"]//code' "dyn Outer<dyn Inner>;" pub use dyn_trait::NestedTraitObjects; // @has user/fn.apit_rpit.html // @has - '//pre[@class="rust item-decl"]'  //     "apit_rpit(o: impl Outer<dyn Inner>) -> impl Outer<dyn Inner>" pub use dyn_trait::apit_rpit; // @has user/type.AssocTy.html // @has - '//*[@class="rust item-decl"]//code' "<() as Base>::Type<dyn Inner>" pub use dyn_trait::AssocTy; </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. --I found out about the ICE when my crate could not have its documentation online on (). I managed to narrow it down to the code below. All of the code here builds fine (, ), but on the latest stable and nightly it fails when doing . Originally, came from a separate crate, . To my surprise, using the dependency instead of replicating the symbols to this crate results in a more informative top-level error message of the ICE. With we can instead do: The full project can also be found in . Reproduced on more than one toolchain and platform, among which: Without the dependency: with the dependency : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
this went build -ice in Regression in
is , cc author:
claim
Minimized: label S-has-mcve A-cross-crate-reexports
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Keeping it open until the fix is backported to beta.
The fix has been backported to beta () and to stable (). Closing.
Change:
<ins> // check-pass // edition:2021 // aux-build:test-macros.rs #![no_std] // Don't load unnecessary hygiene information from std extern crate std; #[macro_use] extern crate test_macros; macro_rules! foo { ($($path:ident)::*) => ( test_macros::recollect!( $($path)::* ) ) } macro_rules! baz { () => ( foo!($crate::BAR) ) } pub const BAR: u32 = 19; fn main(){ std::println!("{}", baz!()); } </ins>

Discussion:
I tried -ing this proc macro crate: rust /// pub extern crate procmacrocrate; /// /// #[macroexport] /// macrorules! foo { /// (path:ident)::) =( /// $crate::procmacrocrate::identity!{ /// path):: /// } /// ) /// } /// /// #[macroexport] /// macrorules! baz { /// () =( /// crate::BAR) /// ) /// } /// /// pub const BAR: u32 = 19; /// /// fn main(){ /// println!("{}", crate::baz!()); /// } /// /// I expected to see this happen: The test completes successfully Instead, this happened: The test fails compilation with this error: It most recently worked on: : This also fails in 1.62 and 1.63. This appears to be fixed in the beta channel, but I could not find a mention of this bug or a related one. It's entirely possible that the bug will trigger again in future versions if this code isn't used in tests. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Bisection shows it regressed in and got fixed in . Looks like this issue wasn’t deliberately fixed, since doesn’t call out any issue being fixed. Also did involve minor breakage, as discussed in its thread, but I haven’t looked into it enough to tell whether those cases of breakage were similar to this issue or different.
label A-macros, A-proc-macros
cc (author of ) and (author of ) (read above to see how these PRs are relevant)
Looking at the code changes from it makes sense that this regressed, as the call to () would have done a check and rejected creating . The code (which was originally introduced in : ), should've probably avoided the constructor from the get-go, but it wasn't an issue because wasn't a possible identifier in that case previously. In , I changed the logic there to avoid going through that constructor when re-building the tokens internally, so we don't do the broken validation on that side anymore, and the problem wouldn't happen anymore.

I don't think there's much more to be done here, as it's fixed already on beta, and isn't likely to regress with the new design.
Thanks a lot for your insights!
label E-easy. (We only need a test to close this issue.)
For someone wanting to add a test for this, you should be able to add the use code in . You can see for an idea of what the test might look like.
claim
Change:
FieldDoesNotImplementCopy(ast::Name), VariantDoesNotImplementCopy(ast::Name), TypeIsStructural, <ins> TypeHasDestructor, </ins> } pub fn can_type_implement_copy<'a,'tcx>(param_env: &ParameterEnvironment<'a, 'tcx>,

Discussion:
Basically, it's now possible to write: and have everything work. This unfortunately means that doing something like with a will zero b, but not move it. /cc
I noticed this possibility too and was debating if this is a problem. It's not clear to me. Probably best to disallow it for now.
at the very least, it's causing incorrect behaviour at runtime, since it's zeroing out types like a move, but not forbidding the use of them like a copy.
Looks unsafe to me: Program received signal SIGSEGV, Segmentation fault. 0x0000555555598e5c in ()
I agree that combining it with zeroing is unsafe. If zeroing did not occur, or we did not zero for types that were copy, there wouldn't necessarily be a problem.
Anyhow, it's easiest to forbid it for now. We can always make it legal later if someone comes up with a persuasive use case. Idempotent destructors seem like a bit of an odd thing.
Change:
validate_generic_param_order( self.session, self.err_handler(), <del> generics.params.iter().map(|param| { let ident = Some(param.ident.to_string()); let (kind, ident) = match &param.kind { GenericParamKind::Lifetime => (ParamKindOrd::Lifetime, ident), GenericParamKind::Type { default: _ } => (ParamKindOrd::Type, ident), GenericParamKind::Const { ref ty, kw_span: _ } => { let ty = pprust::ty_to_string(ty); let unordered = self.session.features_untracked().const_generics; ( ParamKindOrd::Const { unordered }, Some(format!("const {}: {}", param.ident, ty)), ) } }; (kind, Some(&*param.bounds), param.ident.span, ident) }), </del> <ins> &generics.params, </ins> generics.span, );

Discussion:
results in: when it should be: This should be easy to fix: just replace in the following line with an appropriate format string. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
For the record, it's not quite this simple, as doing so results in incorrect output when the parameter also has bounds. For example, it would render as because bounds are printed after the
Change:
#![feature(associated_type_bounds)] #![feature(rustc_attrs)] #![feature(hash_raw_entry)] <ins> #![feature(int_error_matching)] </ins> #![recursion_limit = "512"] #[macro_use]

Discussion:
The following code since it exceeds the default recursion limit. Using as the recursion limit works as expected. This is because we don't check for integer overflow errors when parsing limits: There's a few options here. My preference would be to silently default to when overflow occurs. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Hi! I'd like to try and handle this. If I understand this correctly, we should check if there is an , and if that error is an overflow. If it's an overflow, we default to ? claim
correct
Change:
<ins> // compile-flags: -Z mir-opt-level=2 // build-pass #![feature(type_alias_impl_trait)] use std::marker::PhantomData; trait MyIndex<T> { type O; fn my_index(self) -> Self::O; } trait MyFrom<T>: Sized { type Error; fn my_from(value: T) -> Result<Self, Self::Error>; } trait F {} impl F for () {} type DummyT<T> = impl F; fn _dummy_t<T>() -> DummyT<T> {} struct Phantom1<T>(PhantomData<T>); struct Phantom2<T>(PhantomData<T>); struct Scope<T>(Phantom2<DummyT<T>>); impl<T> Scope<T> { fn new() -> Self { unimplemented!() } } impl<T> MyFrom<Phantom2<T>> for Phantom1<T> { type Error = (); fn my_from(_: Phantom2<T>) -> Result<Self, Self::Error> { unimplemented!() } } impl<T: MyFrom<Phantom2<DummyT<U>>>, U> MyIndex<Phantom1<T>> for Scope<U> { type O = T; fn my_index(self) -> Self::O { MyFrom::my_from(self.0).ok().unwrap() } } fn main() { let _pos: Phantom1<DummyT<()>> = Scope::new().my_index(); } </ins>

Discussion:
Compiling with I get since two nightlies:
Triage: It's now compiled fine with the latest nightly, I think it's fixed by .
It works now, thank you.
This should be open until the test is .

<!-- 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. --Code is from glaciers , original ticket: The code still ICEs when checking with <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --repo is @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Triage: It's now compiled fine with the latest nightly, perhaps it's fixed by .

As , the MIR inliner seems to fail when dealing with opaque return types. Test case: Invocation: <details<summaryICE:</summary</details
I'm not sure how async closures desugar, so this could be way off base, but this looks very similar to the other ICEs tracked in . Does this look like another instance of that issue to you?
The immediate cause of this is the fact that we call during inlining: If we do this, we should also be normalizing the substs we pass to , so that we reveal any opaque types. However, it looks like the opaque type occurs within a binder (due the opaque type appearing in the return type of an fn pointer), so I think lazy normalization may be required to fix this in the general case.
Triage: It's now compiled fine with the latest nightly, I think it's fixed by .
Change:
<ins> // ignore-android: FIXME(#10381) // ignore-windows // compile-flags:-g // gdb-command: run // gdb-command: print slice // gdbg-check: $1 = struct &[i32](size=3) = {0, 1, 2} // gdbr-check: $1 = &[i32](size=3) = {0, 1, 2} // gdb-command: print mut_slice // gdbg-check: $2 = struct &mut [i32](size=4) = {2, 3, 5, 7} // gdbr-check: $2 = &mut [i32](size=4) = {2, 3, 5, 7} // gdb-command: print str_slice // gdb-check: $3 = "string slice" // gdb-command: print mut_str_slice // gdb-check: $4 = "mutable string slice" // lldb-command: run // lldb-command: print slice // lldb-check: (&[i32]) $0 = size=3 { [0] = 0 [1] = 1 [2] = 2 } // lldb-command: print mut_slice // lldb-check: (&mut [i32]) $1 = size=4 { [0] = 2 [1] = 3 [2] = 5 [3] = 7 } // lldb-command: print str_slice // lldb-check: (&str) $2 = "string slice" { data_ptr = [...] length = 12 } // lldb-command: print mut_str_slice // lldb-check: (&mut str) $3 = "mutable string slice" { data_ptr = [...] length = 20 } fn b() {} fn main() { let slice: &[i32] = &[0, 1, 2]; let mut_slice: &mut [i32] = &mut [2, 3, 5, 7]; let str_slice: &str = "string slice"; let mut mut_str_slice_buffer = String::from("mutable string slice"); let mut_str_slice: &mut str = mut_str_slice_buffer.as_mut_str(); b(); // #break } </ins>

Discussion:
Currently, support for pretty-printing slice types is missing for rust-gdb.
Can you describe in more detail?
provides pretty-printing function for some Rust types, such as , , , etc. This allows gdb to display values of some types in a more readable way. I think it is implemented in the following files: , , Currently, slices can only be displayed as a pointer and a length value in the debugger. I hope rust-gdb can support displaying slices. I also noticed that already supports pretty-printing const slices (), but not mutable slices (). Maybe rust-lldb can also add pretty-printing support fur mutable slices.
label A-slice C-enhancement T-dev-tools
Change:
match expr.node { hir::ExprPath(..) => { match bcx.def(expr.id) { <del> Def::Const(did) => { </del> <ins> Def::Const(did) | Def::AssociatedConst(did) => { </ins> let empty_substs = bcx.tcx().mk_substs(Substs::trans_empty()); let const_expr = consts::get_const_expr(bcx.ccx(), did, expr, empty_substs);

Discussion:
The following code produces an internal compiler error when compiled with rustc 1.8.0-nightly (2016-01-27) through the Rust playground: Here's a sample of the error output from the playground: The error occurs regardless of the type of the array's elements. The error seems to be related to the type of array constructor used, since the following code compiles just fine: The error does not occur when associated constants are not involved: Now with backtrace!
Change:
ast::ExprVstoreMutSlice => ast::MutMutable, _ => ast::MutImmutable, }; <del> let t = fcx.infcx().next_ty_var(); check_expr_has_type(fcx, &**element, t); </del> <ins> check(fcx, &**element, t); </ins> let arg_t = fcx.expr_ty(&**element); if ty::type_is_error(arg_t) { ty::mk_err()

Discussion:
fails to compile: cc
What does the l-wrong label mean here?
It means that the current behavior of the compiler is incorrect.
Change:
<ins> // run-rustfix fn main() { let x = 2; //~ ERROR unexpected `==` println!("x: {}", x) } </ins>

Discussion:
<!-- 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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should suggest replacing the with where appropriate as the suggestion for incorrect usage of in place of already exist. <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
// Trait methods are always all public. The only controlling factor // is whether the trait itself is accessible or not. ty::TraitContainer(trait_def_id) => { <del> self.report_error(self.ensure_public(span, trait_def_id, None, "source trait")); </del> <ins> let msg = format!("source trait `{}`", self.tcx.item_path_str(trait_def_id)); self.report_error(self.ensure_public(span, trait_def_id, None, &msg)); </ins> } } }

Discussion:
This was working previously before . If this is an intended change, we should probably give the error where the re-export is defined and not on use of the trait.
I've noticed this too while compiling nphysics, I've narrowed it to The error is I'm using .
I'm facing the same problem for quite some time now (currently rustc 1.0.0-nightly ( 2015-01-20 23:03:09 +0000)). Is this a bug or is it intended behavior?
is this expected?
Just ran into this bug in my code, would love to see a fix for this!
Im also still running into this from time to time (rustc 1.3.0). I'd love to see it fixed or clarified whether this is intended or a bug.
I also have this with rustc nightly (from PPA: "~~wily")
I think this is a bug, actually. do you agree?
yes I realize I'm responding to a comment from Jan 28 :) a bit late, I know
this was "fixed" by but reverted by due to a regression. Personally, I think that the correct fix for the regression should be to make a privacy error, but as far as I can tell, it's not easy to implement this currently, and it's likely to cause further regressions. Trait privacy is hard :(
better late than never :heart:
yeah this looks like a bug to me, and I think is right in that is probably the right fix if we deal with , which I think is the cause of some other visibility/privacy bug around here...
This can be simplified even further to: Also an additional note, this only affects usage in the same crate. Other crates are able to use the re-exports fine.
Still a bug in 1.6 :cry:
+1
still a bug in cargo 0.8.0-nightly ( 2016-01-17)
For those who may fall on this issue, it can be bypassed by using the UFCS syntax: . For example becomes
Change:
/// /// error: aborting due to previous error /// ``` <del> fn report_missing_field( </del> <ins> fn report_missing_fields( </ins> &self, adt_ty: Ty<'tcx>, span: Span,

Discussion:
Test example (): Only in the top level should say "cannot construct ... due to inaccessible fields", the other 3 errors should be "missing field ... in initializer", but it seems like it's treating the field as private (even though it inherits from the ). The "cannot construct ... due to inaccessible fields" error seems to be new in 1.48, as part of , and unmodified since. It's using which seems correct, but it's possible fields are incapable of giving the right result, if they don't track the 's own privacy (and they only know they inherit it, whatever it is). cc
I would also suspect
I ran into this too, but I couldn't make a repro. Thanks eddyb!
P-high: I've run into this a bunch of times and I imagine others have too. It's really annoying and confusing, likely even more so for newcomers!
searched nightlies: from nightly-2020-08-01 to nightly-2020-10-15 regressed nightly: nightly-2020-09-11 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
Seems very likely that this is due to , as eddyb said. EDIT: Though, as jyn514 suggested, the underlying bug could be , which was then surfaced in .
Update: I've been reading the source code and print-debugging and I think the issue was not introduced in either of those two PRs, but rather that they surfaced a pre-existing issue.
Well, it took a while, but I think I fixed it!
Does this necessitate a 1.48.1 release or shall I wait for 1.49?
it will be in 1.50 unless backported:
Ok. Thank you for the quick reply.
Change:
<del> Subproject commit 99ec9c1707aad74b4a4a6d301f27fb1c19733f58 </del> <ins> Subproject commit 042cbf175bfdad6524fd00d7570b2297a0426063 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. 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!
I think this is what's necessary to fix the issue, but I'll test more tomorrow when a nightly with is released
There are more failures in tests (which are not run when tests fail): and fail with . Revision of fails with -- unwinding past a function seems to abort instead of triggering UB now. does not trigger the error anymore. Adding fixes it. All tests fail with this error: Which seems to be an ABI mismatch between and : Opened to fix that.
Ah ok in that case I think I unfortunately don't think I have time to personally look more into this.
The fix is ready at , but bors is broken so we can't land it.
Change:
.emit(); }, ) <ins> } else if can_remove { self.ir.tcx.struct_span_lint_hir( lint::builtin::UNUSED_VARIABLES, first_hir_id, hir_ids_and_spans.iter().map(|(_, pat_span, _)| *pat_span).collect::<Vec<_>>(), |lint| { let mut err = lint.build(&format!("unused variable: `{}`", name)); err.multipart_suggestion( "try removing the field", hir_ids_and_spans .iter() .map(|(_, pat_span, _)| { let span = self .ir .tcx .sess .source_map() .span_extend_to_next_char(*pat_span, ',', true); (span.with_hi(BytePos(span.hi().0 + 1)), String::new()) }) .collect(), Applicability::MachineApplicable, ); err.emit(); }, ); </ins> } else { let (shorthands, non_shorthands): (Vec<_>, Vec<_>) = hir_ids_and_spans.iter().copied().partition(|(hir_id, _, ident_span)| {

Discussion:
I got this error message recently: will work, but just removing completely from the pattern would be better. E.g. the suggestion could be . The particular example was within rustc, but it should be very easy to replicate in a self-contained example. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Is this ? Where does this suggestion come from? Can I please get the path for it!
claim
It's been 3 months - are you still working on this? If not, I'd like to claim it instead.
There was no activity for a while, so I took a liberty of implementing this. claim
Change:
libc::ERROR_ALREADY_EXISTS => ErrorKind::AlreadyExists, libc::ERROR_BROKEN_PIPE => ErrorKind::BrokenPipe, libc::ERROR_FILE_NOT_FOUND => ErrorKind::NotFound, <ins> c::ERROR_PATH_NOT_FOUND => ErrorKind::NotFound, </ins> libc::ERROR_NO_DATA => ErrorKind::BrokenPipe, libc::ERROR_OPERATION_ABORTED => ErrorKind::TimedOut,

Discussion:
read_dir returns ErrorKind::Other for inexistent file. I tried this code I expected to see . Instead it shows Rust version
Change:
} else if self.look_ahead(1, |t| *t == token::OpenDelim(token::Paren)) { let ident = self.parse_ident().unwrap(); self.bump();  // `(` <del> let kw_name = if let Ok(Some(_)) = self.parse_self_arg_with_attrs() { "method" } else { "function" </del> <ins> let kw_name = match self.parse_self_arg_with_attrs() { Ok(Some(_)) => "method", Ok(None) => "function", Err(mut err) => { err.cancel(); "function" } </ins> }; self.consume_block(token::Paren); let (kw, kw_name, ambiguous) = if self.check(&token::RArrow) {

Discussion:
I see the following error on the and channels, but not on : Found with the help of .
triage: P-high, because errors being swallowed, even in the presence of other errors, scares me a bit.
Perhaps might be a good candidate to investigate?
The error that is not being emitted is ~Looking.~ Found, incoming PR shortly.
Change:
<ins> // Check that borrowck ensures that `static` items have the expected type. static FOO: &'static (dyn Fn(&'static u8) + Send + Sync) = &drop; fn main() { let n = 42; FOO(&n); //~^ ERROR does not live long enough } </ins>

Discussion:
<!-- 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 tried : I expected to see this: Instead, happens undefined behavior. Program successfully compiles in the Rust but fails to compile in (thats what I want).
Regressed in , likely cc
Visited in the compiler team triage meeting. It would be good to look into closing this ASAP. do you think you'll have time to investigate? If not, I'd want to find someone else.
We've assigned this speculatively to -- if you think you won't be able to investigate promptly, though, feel free to unassign and ping t-compiler for reassignment,
I expected the behavior to match that of this example (which still errors): I wonder if the gets erased somehow. Maybe an "user type annotation" is required on the from a , to give it a lifetime'd type?