jiebi/CodeConvo huggingface dataset:
Change:
| = help: to escape `[` and `]` characters, just add '/' before them like `/[` or `/]` <ins> warning: `[error]` cannot be resolved, ignoring it... --> $DIR/intra-links-warning.rs:61:30 | LL |  * time to introduce a link [error]*/ |                              ^^^^^ cannot be resolved, ignoring | = help: to escape `[` and `]` characters, just add '/' before them like `/[` or `/]` warning: `[error]` cannot be resolved, ignoring it... --> $DIR/intra-links-warning.rs:67:30 | LL |  * time to introduce a link [error] |                              ^^^^^ cannot be resolved, ignoring | = help: to escape `[` and `]` characters, just add '/' before them like `/[` or `/]` warning: `[error]` cannot be resolved, ignoring it... --> $DIR/intra-links-warning.rs:71:1 | LL | #[doc = "single line [error]"] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: the link appears in this line: single line [error] ^^^^^ = help: to escape `[` and `]` characters, just add '/' before them like `/[` or `/]` warning: `[error]` cannot be resolved, ignoring it... --> $DIR/intra-links-warning.rs:74:1 | LL | #[doc = "single line with /"escaping/" [error]"] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: the link appears in this line: single line with "escaping" [error] ^^^^^ = help: to escape `[` and `]` characters, just add '/' before them like `/[` or `/]` warning: `[error]` cannot be resolved, ignoring it... --> $DIR/intra-links-warning.rs:77:1 | LL | / /// Item docs. LL | | #[doc="Hello there!"] LL | | /// [error] | |___________^ | = note: the link appears in this line: [error] ^^^^^ = help: to escape `[` and `]` characters, just add '/' before them like `/[` or `/]` warning: `[error1]` cannot be resolved, ignoring it... --> $DIR/intra-links-warning.rs:83:11 | LL | /// docs [error1] |           ^^^^^^ cannot be resolved, ignoring | = help: to escape `[` and `]` characters, just add '/' before them like `/[` or `/]` warning: `[error2]` cannot be resolved, ignoring it... --> $DIR/intra-links-warning.rs:85:11 | LL | /// docs [error2] |           ^^^^^^ cannot be resolved, ignoring | = help: to escape `[` and `]` characters, just add '/' before them like `/[` or `/]` </ins> warning: `[BarA]` cannot be resolved, ignoring it... --> $DIR/intra-links-warning.rs:24:10 |

Discussion:
Given the following source: The span conversion calculation in the error reporting will give the wrong offset when reporting the resolution failure, leading to a confusing report: Strangely enough, putting either the leading or the closing on its own line will cause the report to change to something that looks correct, if a little too broad: I believe the code at fault is this section here: Because it assumes that every doc comment will have a padding of 3 characters (the or ), it includes that in its calculation of each line's offset. However, for block-style comments, this assumption is false.
I'm working on this.
You can also reproduce this with unsugared docs:
Change:
test_abi_compatible!(wrap1, $t, Wrapper1<$t>); test_abi_compatible!(wrap2, $t, Wrapper2<$t>); test_abi_compatible!(wrap3, $t, Wrapper3<$t>); <del> #[cfg(not(target_arch = "loongarch64"))] </del> test_abi_compatible!(wrap4, $t, WrapperUnion<$t>); } };

Discussion:
The types and do not have the same ABI, as demonstrated by this testcase: The first is The second is RISC-V had , so the fix will likely . I couldn't find an O-loongarch label. Cc'ing the people listed on
The loongarch ABI seems to be pretty much exactly like the RISC-V ABI, so I wonder if it would make sense to share some of that code so that bugs like this only have to be fixed once.
Thanks for the report! The LoongArch ABI is indeed closely modeled after that of RISC-V, so yeah the fix should look similar. should be able to follow up tomorrow.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
I don't think you meant to tag me. Don't know much about rust.
Doh, the correct Rust/LoongArch person is who happens to have another handle of "hev". Sorry for the noise!
Thanks for your pointing out. I don't think the types and would have the same ABI on LoongArch64. The key point of the problem is that is a , which is different from a : For types and , they are same ABI: The first is: The second is: And it seems that the current ABI of is the same as that of C language on LoongArch64: The first is: The second is:
I haven't studied the LoongArch psABI as closely, but from a Rust semantics perspective: is "a -sized area that may or may not hold an initialized ", so and really should behave the same when that's the case -- implying the two must have the same ABI. So this is something to look into and fix after all...
It's a Rust union, but it doesn't have , so whatever applies to C unions is completely irrelevant. For instance, many ABIs (e.g. x86) treat structs different from integers, and still has the same ABI as -- that's because is not a struct, so its ABI doesn't have to match that of a C struct. We promise that has the same ABI as for all on all targets, so this is really not optional. Your C example, when translated to Rust, needs on all types. The ABI of those types obviously needs to match the C types. But that's completely compatible with also treating types differently.

Thank you for your explanation. Hmm, I'm not familiar with Rust ABI, and it seems to have less relevance to psABI. OK, I will follow the RISC-V patches to fix LoongArch.
It's the same problem we have on all targets: there is a target ABI that is defined in terms of C types, and now every other language has to figure out how to map their types to C types to then compute the ABI from that. Unfortunately the Rust compiler has no central infrastructure for that (there's no function to "give me the C type that describes the ABI of a given Rust type"), and so each target has to implement that mapping itself, and they are all making similar mistakes...
label +O-loongarch
Change:
<ins> warning: cannot specify lifetime arguments explicitly if late bound lifetime parameters are present --> $DIR/issue-83466.rs:11:14 | LL |     fn func<'a, U>(self) -> U { |             -- the late bound lifetime parameter is introduced here ... LL |     S.func::<'a, 10_u32>() |              ^^ | = note: `#[warn(late_bound_lifetime_arguments)]` on by default = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #42868 <https://github.com/rust-lang/rust/issues/42868> error[E0747]: constant provided when a type was expected --> $DIR/issue-83466.rs:11:18 | LL |     S.func::<'a, 10_u32>() |                  ^^^^^^ error: aborting due to previous error; 1 warning emitted For more information about this error, try `rustc --explain E0747`. </ins>

Discussion:
This is ICE since 1.50.0, error -ICE. Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Bisected: searched nightlies: from nightly-2020-01-01 to nightly-2021-03-17 regressed nightly: nightly-2020-11-18 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Thanks for bisecting, I believe is the cause.
Assigning and removing as in the prioritization working group. label: +P-medium -I-prioritize
claim
Change:
<ins> // check-pass use std::fmt::{self, Display}; struct Mutex; impl Mutex { fn lock(&self) -> MutexGuard { MutexGuard(self) } } struct MutexGuard<'a>(&'a Mutex); impl<'a> Drop for MutexGuard<'a> { fn drop(&mut self) { // Empty but this is a necessary part of the repro. Otherwise borrow // checker is fine with 'a dangling at the time that MutexGuard goes out // of scope. } } impl<'a> MutexGuard<'a> { fn write_fmt(&self, _args: fmt::Arguments) {} } impl<'a> Display for MutexGuard<'a> { fn fmt(&self, _formatter: &mut fmt::Formatter) -> fmt::Result { Ok(()) } } fn main() { let _write = { let out = Mutex; let mutex = Mutex; write!(out.lock(), "{}", mutex.lock()) /* no semicolon */ }; let _writeln = { let out = Mutex; let mutex = Mutex; writeln!(out.lock(), "{}", mutex.lock()) /* no semicolon */ }; let _print = { let mutex = Mutex; print!("{}", mutex.lock()) /* no semicolon */ }; let _println = { let mutex = Mutex; println!("{}", mutex.lock()) /* no semicolon */ }; let _eprint = { let mutex = Mutex; eprint!("{}", mutex.lock()) /* no semicolon */ }; let _eprintln = { let mutex = Mutex; eprintln!("{}", mutex.lock()) /* no semicolon */ }; let _panic = { let mutex = Mutex; panic!("{}", mutex.lock()) /* no semicolon */ }; } </ins>

Discussion:
https://crater- https://crater- https://crater- https://crater- https://crater- https://crater- is likely cause (cc
I'll fix this.
Fixed on beta with and on master. will be a more complete change and will likely land in 1.63 (or later).
Change:
- env: IMAGE=dist-x86_64-linux DEPLOY_ALT=1 if: branch = try OR branch = auto <del> # FIXME: The macOS dist images are temporarily disabled until Travis bug is fixed # https://github.com/travis-ci/travis-ci/issues/8821 </del> - env: > RUST_CHECK_TARGET=dist RUST_CONFIGURE_ARGS="--enable-extended --enable-profiler"

Discussion:
Happened for these PRs so far:
Thanks for the report. This is a Travis CI issue, currently tracked in travis-ci/travis-ci. A temporary workaround that disables all Xcode 7.3 () is currently testing.
Change:
let local_id = self.var_local_id(var, for_guard); let source_info = self.source_info(span); self.cfg.push(block, Statement { source_info, kind: StatementKind::StorageLive(local_id) }); <del> let region_scope = self.region_scope_tree.var_scope(var.local_id); if schedule_drop { </del> <ins> // Altough there is almost always scope for given variable in corner cases // like #92893 we might get variable with no scope. if let Some(region_scope) = self.region_scope_tree.var_scope(var.local_id) && schedule_drop{ </ins> self.schedule_drop(span, region_scope, local_id, DropKind::Storage); } Place::from(local_id)

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. --: <!-- 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 --
I was just looking at the parsing code for const generic exprs.. claim
actually, so this isn't related to incorrectly parsing , since we're parsing in expr position to allow if-let chains.. -- this is due to const eval lowering to MIR and the fact that const generic parameters have no enclosing scope. Adding around the generic args works, but I don't know where exactly to hack in a scope for these params. release-assignment label A-const-eval A-mir
Maybe fixing this also fixes :slightlysmilingface:
This gives an error without ICE in 1.55
It was unclear to me - I think meant that changing to gives a compile error instead of an ICE. So the proper fix here is probably to add somewhere instead of panicking.
Then this should be easy. claim
Change:
[dependencies] std = { path = "../../libstd" } <ins> core = { path = "../../libcore" } </ins> # Reexport features from std [features]

Discussion:
This looks weird. Isn't a .dll the right thing for this target? cc
Could you try passing ? Seems like may not be making its way to Cargo, or the shim is really messing up here (probably the latter)

Because that's what the old build system does: but rustbuild and rsbegin.o ends up being an ELF on linux: The fix should be simple in theory. You just have to pass to the in the code linked above. But then you run in problems with the order of the operations: " not found for $TARGET". cc
FWIW, trying to cross compile to i686-pc-windows-gnu I get this: Trying to cross compile to x86_64-pc-windows-gnu results in
Yeah not passing would do it, should be easy to add though! (I think that's all that's necessary)
Actually, the solution is the opposite. rustbuild is building these startup files for linux but it should compile them for windows hence the has to be .
Oh right sorry "it" there was "would cause this problem", we should indeed pass !
Change:
/// Part of a hack to make PathBuf::push/pop more efficient. #[inline] pub(crate) fn as_mut_vec_for_path_buf(&mut self) -> &mut Vec<u8> { <ins> // FIXME: this function should not even exist, as it implies violating Wtf8Buf invariants // For now, simply assume that is about to happen. self.is_known_utf8 = false; </ins> &mut self.bytes } }

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 this code: I expected to see this happen: Instead, this happened: (Obviously, s can't contain .) <img width="1087" alt="1" src=""<!-- 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. --:
Nice catch!
Change:
renamed: Option<Symbol>, parent_id: Option<LocalDefId>, ) { <del> self.modules .last_mut() .unwrap() .items .insert((item.owner_id.def_id, renamed), (item, renamed, parent_id)); </del> <ins> if self.is_importable_from_parent // If we're inside an item, only impl blocks and `macro_rules!` with the `macro_export` // attribute can still be visible. || match item.kind { hir::ItemKind::Impl(..) => true, hir::ItemKind::Macro(_, MacroKind::Bang) => { self.cx.tcx.has_attr(item.owner_id.def_id, sym::macro_export) } _ => false, } { self.modules .last_mut() .unwrap() .items .insert((item.owner_id.def_id, renamed), (item, renamed, parent_id)); } </ins> } fn visit_item_inner(

Discussion:
If we run with the option on this code: Both and are documented, but not being accessible outside of , it shouldn't be documented.
probably knows this, but for others seeing this issue, I think it's probably due to (which was reverted in , and later re-applied in ). It has to do with the fact that we're using a HIR visitor now, so we're visiting nested items unconditionally.
Yes I know where it's coming from. :smile: I was just thinking today that since we were going through the whole HIR without checking whether or not we were in a block, all elements inside the block could be visible. Tested and... :fearful: Should be pretty easy to fix.
For reference, I put up because this was causing documentation to become really verbose with serde + . If you fix this such that we no longer document those items, we could probably revert that PR.
Indeed. Don't hesitate to come to me if you have such issues with rustdoc. Such problems should definitely not go unnoticed.
The thing is, it was not particularly clear from the PRs whether this was intentional or not.
Unfortunately it wasn't. The goal was to retrieve the missing impl blocks. But if anything isn't clear, don't hesitate to ask too. :wink:
Change:
<ins> #![crate_type = "lib"] pub fn vec() -> Vec<u8> { vec![] } </ins>

Discussion:
I'm sorry, I haven't reduced this at all, and I'm sure the code is awful, but the error message said you'd appreciate a bug report. I tried this code: jeremyBanks/0dmg using I expected to see this happen: my program would run, or the compiler would give one of its typical helpful error messages! Instead, this happened: I am using the Windows Linux Subsystem thing with Debian or Ubuntu, I think. : : Backtrace:
If I use cargo doc I get a different stack trace:
The crash stopped occurring in my code when I fixed an invalid import: see jeremyBanks/0dmg
I'm pretty certain this is caused by being directly indexed without being checked here: But, really, it'd be nice to have a reduced test case so we can confirm the bug is fixed afterwards.
Makes sense. I'll try to pare it down to something useful.
I'm failing to reproduce this crash without using multiple crates, so I can't figure out how to put it in a Playground example or doc test, but here's a reduced example ().
Okay, I've got the failure occurring in a compiler test at jeremyBanks/rust Result: If I understand correctly, it will be possible to turn this into a regression test by annotating it with the desired non-panic output, once this issue has been fixed and we know what the fixed output looks like. But since we're not sure what the will look like, there'd be no point trying to get this merged yet.
now that is merged and should be in the next Nightly, could you check your test-case again to see whether it's fixed? I didn't have time to add your test case before it was merged. Thanks!
I think it's fixed. My stand-alone test case produces the same initial error message of "no type-dependent def for method call", but it no longer displays any panic; it seems to exit cleanly. Using built from : Using : (Now running in a normal Debian VM. Sorry for the constantly-changing platform. :P)
Sorry! I didn't mean to submit the post yet, or close the issue, but I mis-clicked. I'm still trying to figure out the appropriate annotations to make this pass as a test.

If I get the test working behaving properly, would it be useful to send a PR to add my regression test, or is this too small of an issue to warrant one?
yes, a regression test would be useful here. Actually, I don't think the behaviour is even correct here — it shouldn't be displaying that error at all, even if it's not actually crashing.
Did a test ever get here?

Compiling this code results in: There is no backtrace. If I disable specialization feature, rustc reports an error: ` Rustc details:
This seems to compile as of the most recent nightly.
Good to hear that! Would it make sense to add this example to the test suite to prevent regressions in the future?
Change:
<ins> #![crate_type = "lib"] pub fn vec() -> Vec<u8> { vec![] } </ins>

Discussion:
I wanted to test our handling of slices that are "too big" (bigger than the largest possible allocation), so I wrote: I expected an ICE or so, but I got a timeout. On nightly, here's what a stacktrace looks like: looks like the interning could do with a fast path for integer slices similar to what validation does? And maybe it could also check that the reference is dereferencable before walking it, that would avoid finding out later that we are going to produce an error anyway.
This now finishes in milliseconds with an error:

rustc crashes ungracefully when given the following input (found by ): I'm seeing this behavior on stable, beta, and nightly.
cc
Interesting: I'm not familiar with but that's where we are aborting:
cc
If I change the body of to this: then the compiler aborts how you would expect. I caught the panic in gdb (with ). It is coming from . Here's the stack trace: So it seems like this is a "legitimate" panic from the parser that the compiler would normally catch gracefully somewhere... except that assumes the closure it calls never panics and just aborts immediately if so. 's current implementation arose out of . any thoughts on how could let the panic pass through in a memory-safe manner? Or is that not possible?
I think there’s no magic trick here. Afaik the only safe way to do this is to mem::replace t with a dummy value, apply f, and swap the result back, but that requires that t has a dummy value. Does the code break if you add T: Default bound? Also, when suggesting that change I was 80% sure that it’s pure pedantry because, clearly, we don’t panic anywhere :) I am fascinated by how conspicuous and shallow such “benign” problems become in rust!
cc re:macros/ being ky.
Yes. Unfortunately, lots of the involved types lack a bound, and adding one doesn't make sense. wants the commit that introduced to be reverted anyway. Perhaps that's the best path forward, even though it'll be a perf hit. If I'd stuck with the original code that didn't handle panics it would have been a double-free without warning. One of those " is trickier than you might think" moments.
Or we just accept the current behaviour, because it's a benign abort on a very obscure case, and is being phased out anyway...
What's the plan post-? Benign to , but it will kill RLS or any other long lived tool. (Not that I disagree that we can live with this in the medium term.)
Just in case it's useful: here is a variation that causes (what I assume is) the same abort with only the macro:
I am unable to reproduce this crash on the latest releases. I was curious what fixed it, so I tried bisecting with nightlies.

The crash still happens on but no longer happens on . Unfortunately, it looks like nightlies are not available in between those two. In any case, as far as I'm concerned, this issue may be closed now.
Let's close this with a PR containing these repro cases as regression tests.
Change:
}; let trait_did = bound.def_id(); <del> let (assoc_ident, def_scope) = tcx.adjust_ident_and_get_scope(assoc_ident, trait_did, hir_ref_id); // We have already adjusted the item name above, so compare with `ident.normalize_to_macros_2_0()` instead // of calling `filter_by_name_and_kind`. let item = tcx.associated_items(trait_did).in_definition_order().find(|i| { i.kind.namespace() == Namespace::TypeNS && i.ident(tcx).normalize_to_macros_2_0() == assoc_ident }); // Assume that if it's not matched, there must be a const defined with the same name // but it was used in a type position. let Some(item) = item else { </del> <ins> let Some(assoc_ty_did) = self.lookup_assoc_ty(assoc_ident, hir_ref_id, span, trait_did) else { // Assume that if it's not matched, there must be a const defined with the same name // but it was used in a type position. </ins> let msg = format!("found associated const `{assoc_ident}` when type was expected"); let guar = tcx.sess.struct_span_err(span, &msg).emit(); return Err(guar); }; <del> let ty = self.projected_ty_from_poly_trait_ref(span, item.def_id, assoc_segment, bound); </del> <ins> let ty = self.projected_ty_from_poly_trait_ref(span, assoc_ty_did, assoc_segment, bound); </ins> let ty = self.normalize_ty(span, ty); <del> let kind = DefKind::AssocTy; if !item.visibility(tcx).is_accessible_from(def_scope, tcx) { let kind = kind.descr(item.def_id); let msg = format!("{} `{}` is private", kind, assoc_ident); tcx.sess .struct_span_err(span, &msg) .span_label(span, &format!("private {}", kind)) .emit(); } tcx.check_stability(item.def_id, Some(hir_ref_id), span, None); </del> if let Some(variant_def_id) = variant_resolution { tcx.struct_span_lint_hir( AMBIGUOUS_ASSOCIATED_ITEMS,

Discussion:
In the following code, I can successfully refer to the private inherent associated type : I expected to see an error denying the access. If the associated item was a constant, this would indeed be the case: : label T-compiler requires-nightly A-associated-items A-visibility F-inherentassociatedtypes <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim