jiebi/CodeConvo huggingface dataset:
Change:
<del> error: expected one of `!`, `::`, or `;`, found `(` --> $DIR/issue-60933.rs:2:43 </del> <ins> error: casts cannot be followed by a function call --> $DIR/issue-60933.rs:2:20 </ins> | LL |     let u: usize = std::mem:size_of::<u32>(); <del> |                            -              ^ expected one of `!`, `::`, or `;` </del> <ins> |                    ^^^^^^^^-^^^^^^^^^^^^^^ </ins> |                            | |                            help: maybe write a path separator here: `::` | = note: `#![feature(type_ascription)]` lets you annotate an expression with a type: `<expr>: <type>` = note: see issue #23416 <https://github.com/rust-lang/rust/issues/23416> for more information <del> error: aborting due to previous error </del> <ins> error[E0423]: expected value, found module `std::mem` --> $DIR/issue-60933.rs:2:20 | LL |     let u: usize = std::mem:size_of::<u32>(); |                    ^^^^^^^^- help: maybe you meant to write a path separator here: `::` |                    | |                    not a value error[E0412]: cannot find type `size_of` in this scope --> $DIR/issue-60933.rs:2:29 | LL |     let u: usize = std::mem:size_of::<u32>(); |                            -^^^^^^^ not found in this scope |                            | |                            help: maybe you meant to write a path separator here: `::` error: aborting due to 3 previous errors Some errors have detailed explanations: E0412, E0423. For more information about an error, try `rustc --explain E0412`. </ins>

Discussion:
Summary: Parsing leads to the error: It is currently impossible for a cast expression to have a trailing index expression without surrounding the cast expression by parenthesis. This however seems to be a parser limitation, not a grammar limitation. As currently the macro language guarantees that ty/path expressions can be followed by a "[", this seems like a bug in the parser to me, as it seems to be parsing it as which makes no grammatical sense, compared to parsing it as (value as Type)[index] which should be valid if I read the lexical structure specification correctly.
I think it's parsed correctly, but should get a tailored error message to suggest surrounding the cast with parens.
Considering that a trailing "[" is never valid in the type syntax (otherwise macros break) and the fact that and variants are perfectly legal (even which is another symbol that occurs in type syntax). But if a tailored error message will be made instead, then this should also include other postfix operators like which are currently rejected even though technically being legal by the lexical grammar specification. (another one is the proposed "?" operator)
This is still lacking a tailored error message, and as far as I know no movement has been made here.
Submitted a pull request to fix this!
Thanks!
Change:
<ins> // run-pass #![allow(dead_code)] struct Foo { foo: i32, bar: i32, baz: (), } fn use_foo(x: Foo) -> (i32, i32) { let Foo { foo, bar, baz } = x; //~ WARNING unused variable: `baz` //~| help: try ignoring the field return (foo, bar); } fn main() {} </ins>

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:
self.inside_public_path &= self.cx.tcx.visibility(def_id).is_public(); for &i in m.item_ids { let item = self.cx.tcx.hir().item(i); <ins> if matches!(item.kind, hir::ItemKind::Use(_, hir::UseKind::Glob)) { continue; } </ins> self.visit_item(item, None, &mut om); } <ins> for &i in m.item_ids { let item = self.cx.tcx.hir().item(i); // To match the way import precedence works, visit glob imports last. // Later passes in rustdoc will de-duplicate by name and kind, so if glob- // imported items appear last, then they'll be the ones that get discarded. if matches!(item.kind, hir::ItemKind::Use(_, hir::UseKind::Glob)) { self.visit_item(item, None, &mut om); } } </ins> self.inside_public_path = orig_inside_public_path; om }

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 glob reexport reexports module and there is already module , the documentation duplicates. Current behaviour: ! ( module is duplicated, though both module links point to as expected) The expected behaviour: module is only shown once. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim
Change:
object_ty: Ty<'tcx>, trait_id: ast::DefId, method_offset_in_trait: uint) <del> -> ValueRef </del> <ins> -> (ValueRef, Ty<'tcx>) </ins> { let _icx = push_ctxt("trans_object_shim"); let tcx = ccx.tcx();

Discussion:
Discovered this ICE in the rollup that I'm preparing:
In Grust, I tried to change to: The crate compiles without an issue, but compiling another crate where this is used results in an ICE that looks to be this one.
Looks like I missed a case in
Nominating for 1.0 beta.
Are there any known workarounds for this problem? I ran into this in a hard way trying to update to the newest nightlies.
not sure, I'll try to get a PR up today
a new type wrapper around the object would probably work, ping me on irc () for more details
I just wanna run iron example on MAC 10.10 with rust-nightly, the same error occurs, I don't know if it's of the same case: error: internal compiler error: static call to invalid vtable: VtableObject(VtableObject(object_ty=error::Error + 'static))
This is also blocking Iron, which itself compiles well, but using the crate fails:
Fix in , sorry for the delay.
thanks for the work! I pulled your PR and built with it, and my code compiles again. Hooray!
Change:
// resolve fn def_key(&self, def: DefId) -> DefKey; <ins> fn def_kind(&self, def: DefId) -> DefKind; </ins> fn def_path(&self, def: DefId) -> DefPath; fn def_path_hash(&self, def: DefId) -> DefPathHash; fn all_def_path_hashes_and_def_ids(&self, cnum: CrateNum) -> Vec<(DefPathHash, DefId)>;

Discussion:
Found in the crater run: ICEs: ` This ICE happens on: but only shows a compiler error.
Assigning as and removing .
This is because an integration gets checked, which relies on the feature to be enabled. Once it is enabled, does not fail anymore, and yet the ICE persists . I'll thus kindly ask for this to be "re-prioritized", if possible, thanks. modify labels: +I-prioritize
Assigning and removing as in the prioritization working group.
ping cleanup This needs mcve and bisection
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
searched nightlies: from nightly-2020-07-20 to nightly-2020-08-25 regressed nightly: nightly-2020-07-28 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summary
Minimized:
Change:
<ins> running 1 test test $DIR/doc-comment-multi-line-cfg-attr.rs - Bar (line 6) ... ok test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in $TIME </ins>

Discussion:
With following doctest, where the cfg attribute spans multiple lines, the final program is invalid: the wrapping method doesn't take into account the dangling line that closes the attribute. rust /// # #![cfgattr(not(dox), feature(cfgtargetfeature, targetfeature, /// # stdsimd))] /// /// fn foo() { /// let mut dst = [0]; /// addquickly(&[1], &[2], &mut dst); /// asserteq!(dst[0], 3); /// } ///
cc
cc
I don't see a message associated with the stack trace, is that missing?
The problem lies in how rustdoc parses doctests. It scans lines for crate-level attributes and statements, but it doesn't do anything more intelligent than checking the beginning of each line: We recently changed the parsing for and detection to use the libsyntax parser, but this initial scan is still a string-based search. The way to fix the test in the OP is to actually remove the part of it - rustdoc doesn't pass on any information into doctest compilation, so those features are going to be enabled regardless.
This is the associated message:
Change:
<del> //@ known-bug: #124031 trait Trait { type RefTarget; } impl Trait for () {} struct Other { data: <() as Trait>::RefTarget, } fn main() { unsafe { std::mem::transmute::<Option<()>, Option<&Other>>(None); } } </del>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: SizeSkeleton::compute(&Other): layout errored (Unknown(Alias(Projection, AliasTy { args: [Other], defid: DefId(2:2049 ~ core[a6f4]::ptr::metadata::Pointee::Metadata) }))), yet tail is not a type parameter or a projection', 'error: internal compiler error: SizeSkeleton::compute(&Other): layout errored (Unknown(Alias(Projection, AliasTy { args: [Other], defid: DefId(2:2049 ~ core[a6f4]::ptr::metadata::Pointee::Metadata) }))), yet tail is not a type parameter or a projection' File: --auto-reduced (treereduce-rust): original: 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<!-- query stack: [typeck] type-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
that's true, it's a type error (should be a quick fix)
you may also enjoy this gem: (found somewhere else)
Ah, this ( ) one bisects to fyi ^^
claim
Change:
<ins> error: hidden lifetime parameters in types are deprecated --> $DIR/issue-91763.rs:8:20 | LL | fn f() -> Ptr<Thing>; |                    ^ expected named lifetime parameter | note: the lint level is defined here --> $DIR/issue-91763.rs:3:9 | LL | #![deny(elided_lifetimes_in_paths)] |         ^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>

Discussion:
<details<summary<strongBacktrace</strong</summary<p</p</details
This bisects to &mdash; regressed nightly: nightly-2021-12-03 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
There was an issue with similar ICE that has been fixed recently Does this problem still repro with latest nightly ?
Yes this one still reproduces as of that nightly, which contains .
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Change:
If specified, the compiler will save more files (.bc, .o, .no-opt.bc) generated throughout compilation in the output directory. .TP <del> fBno-rpathfR If specified, then the rpath value for dynamic libraries will not be set in </del> <ins> fBrpathfR If specified, then the rpath value for dynamic libraries will be set in </ins> either dynamic library or executable outputs. .TP fBno-prepopulate-passesfR

Discussion:
Followup to and . Can we completely eliminate our usage of rpath? Doing so would make our linkage more consistent across platforms since it doesn't work on windows. Nominating.
I think that the largest difficulty for this is that we build dynamically, and this means that if you have a fresh install of rust in a new location it won't work by default (you'll have to munge your os library path). If we could print out some helpful instructions of what to do, then I think that would be a much better situation, but I'm also not entirely sure how we'd do that.
If we defaulted to static linking then there would it would be easier to justify making people use LDLIBRARYPATH when they opt in to dylibs.
The only consideration that I have about static linking is that you'll install 5 copies of (as opposed to 3): with static linking rustdoc rustc rustpkg without static linking That being said, our distributions are already pretty big, so maybe this isn't much of a concern? I agree though that if we statically linked everything then we could easily take this route of action
IMO this is a concern. What's wrong with the current approach (link rust's own tools dynamically)? It works fine on windows since the DLLs are in the bin folder and for everything else it will soon link statically ().
Another use case for this came up on IRC. If you've got a rust installed locally in , then when you try to recompile rust again, the rpath for all the stage0-produced libraries will have something pointing into /usr/local. Apparently on some platforms when you run the stage1 , this means that you'll pick up all the /usr/local libs at runtime instead of the stage0-produced libs (causing errors until you uninstall rustc).
Accepted for 1.0, P-backcompat-lang.
Rust now builds and passes tests with . This feature could be disabled by default or completely removed, with as a suggestion for those who want to use a dynamically linked in their home directory on *nix.
Change:
} impl BcbCounter { <del> fn is_expression(&self) -> bool { matches!(self, Self::Expression { .. }) } </del> pub(super) fn as_term(&self) -> CovTerm { match *self { BcbCounter::Counter { id, .. } => CovTerm::Counter(id),

Discussion:
<!-- [31mICE[0m: Rustc '-Cinstrument-coverage -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'attempt to add a to a BCB target with existing incoming edge counters'', 'thread 'rustc' panicked at 'attempt to add a to a BCB target with existing incoming edge counters'' File: --auto-reduced (treereduce-rust): original: 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<!-- query stack: [mirpromoted] promoting constants in MIR for [mirborrowck] borrow-checking [typeofopaque] computing type of opaque [typeof] computing type of [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
cc ^_^
Further reduced:
(Also note that even before this presumably would have still ICEd, because the only thing we did with that error was unwrap it.)
I think the assertion is just incorrect in this case. Normally a BCB will only have a physical counter if it has exactly one in-edge. If it has multiple in-edges, it will get an expression that sums up all of its in-edges, most of which will have physical counters. That's what the assertion is verifying. However, if a BCB has an out-edge back to itself (i.e. ), it gets a physical counter regardless. The assertion doesn't account for this, and fails. Perhaps the reason we haven't seen this before is that the other in-edge to the loop node usually happens to be the one chosen to get an expression, so the assertion never sees the two-counters case.
I tried to fix the assertion itself, but that ended up being pretty complicated. The information we'd need isn't readily available in the place that we need it, and there's also a related assertion in that has the same problem. Given that these assertions aren't load-bearing (the code should work fine even if it's violated), I'm inclined to just rip them out. They only exist as a holdover from the original implementation anyway.
Change:
`thumbv4t-none-eabi` | * |  | ARMv4T T32 `x86_64-apple-ios-macabi` | ✓[^apple] |  | Apple Catalyst `x86_64-apple-tvos` | *[^apple] | | x86 64-bit tvOS <del> `x86_64-linux-kernel` | ? |  | Linux kernel modules </del> <ins> `x86_64-linux-kernel` | * |  | Linux kernel modules </ins> `x86_64-pc-solaris` | ? |  | `x86_64-pc-windows-msvc` | ✓ |  | 64-bit Windows XP support `x86_64-unknown-cloudabi` | ✓ |  | 64-bit CloudABI

Discussion:
The tier 3 platform x86_64-linux-kernel has support for core + alloc, and we test it in CI at , so I think it should be marked **.
Thank you for your issue! We just moved the platform support table to the rustc book, so I'm going to transfer this issue to rust-lang/rust.
Hi, I'm Sasha, I've never contributed to Rust before, and I'd like to know if I can work on this issue. If I understand correctly, this issue is just about fixing the Tier 3 table in [the platform support file][platform-]. Is that correct? Are there some other details that should be discussed before? Edit: fixed link. [platform-]:
That sounds right to me, Welcome! Thanks for moving, apparently I checked right before it was moved :)
Change:
<ins> // compile-pass fn main() { let _ = &[("", ""); 3]; } const FOO: &[(&str, &str)] = &[("", ""); 3]; const BAR: &[(&str, &str); 5] = &[("", ""); 5]; const BAA: &[[&str; 12]; 11] = &[[""; 12]; 11]; </ins>

Discussion:
Minimized as best I could: With Full error:
cc
Cc
Even more minimal example:
Const eval is drunk (note the gap of relocations between the second and fourth element and again after the fourth elemen): Validation is doing everything correctly
Change:
val: Value, ty: Ty<'tcx>, ) -> &'tcx ty::Const<'tcx> { <del> let layout = ecx.tcx.layout_of(ty::ParamEnv::reveal_all().and(ty)).unwrap(); </del> <ins> let layout = ecx.layout_of(ty).unwrap(); </ins> match (val, &layout.abi) { (Value::Scalar(Scalar::Bits { defined: 0, ..}), _) if layout.is_zst() => {}, (Value::ByRef(..), _) |

Discussion:
Building the crate causes an ICE in beta 1.28. Looking at the backtrace seems like that's caused by the const evaluator. regressed from stable to beta () cc cc
is fixing so not going to bisect this
Change:
candidate_impls: &[ImplCandidate<'tcx>], span: Span, ) { <del> // We can only suggest the slice coersion for function arguments since the suggestion // would make no sense in turbofish or call let ObligationCauseCode::FunctionArgumentObligation { .. } = obligation.cause.code() else { </del> <ins> // We can only suggest the slice coersion for function and binary operation arguments, // since the suggestion would make no sense in turbofish or call let (ObligationCauseCode::BinOp { .. } | ObligationCauseCode::FunctionArgumentObligation { .. }) = obligation.cause.code() else { </ins> return; };

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 (while debugging): Where is the corresponding type from the crate (and everything else is my types). It has an associated function , which returns a 16-byte slice containing the UUID. Because the right-hand-side of the comparison is not a byte slice but an array, the two expressions can't be compared and I get error E0277, shown below. Of interest is the help message at the end, which has the correct solution, but proposes a fix with invalid syntax. It should suggest placing before . <!-- 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. --: I could not test on nightly, as I got a different compile error, apparently related to procedural macros: <details<summaryError</summary<p</p</details
For the error, see . Could you try to bump your version? Also, could you maybe provide either the full code or a smaller reproduction of the suggestion (if possible), I can't seem to reproduce the suggestion for your pattern on stable.
Thanks for the notice. I just bumped to and retried on nightly: Unfortunately the exact same misleading help message still appears. I managed to reproduce it here: The import or argument is actually necessary to cause the bug. If you remove both, the help message doesn't appear. Perhaps this is related to the crate, which I noticed uses a type alias called (), unrelated to .
Smaller repro but still requires dependency: Am investigating how to get rid of the dependency.
Repro without dependencies:
Change:
<ins> // check-pass fn load<L>() -> Option<L> { todo!() } fn main() { while let Some(tag) = load() { match &tag { b"NAME" => {} b"DATA" => {} _ => {} } } } </ins>

Discussion:
This code previously compiled fine, but as of ~2 weeks ago it began to fail on nightly and has continued to do so since. p.s. Is the output of suppose to be one day behind compared to the toolchain name? In any case, was the last working version, and onward trigger the error. modify labels: +regression-from-stable-to-nightly -regression-untriaged
cc
I can put up a fix for this. I suspected this might cause an issue but couldn't think how.
Change:
/// with different restrictions when looking up the resolution. /// This enum is currently used only for early resolution (imports and macros), /// but not for late resolution yet. <del> #[derive(Clone, Copy)] </del> <ins> #[derive(Clone, Copy, Debug)] </ins> enum ScopeSet<'a> { /// All scopes with the given namespace. All(Namespace),

Discussion:
Exact code unknown code. The error was generated by using . Rerunning after did not fix this. Did not resolve this yet at the time of writing this. This might be related to: But I think this was because I compiles first and got this error: This was expected to give an error (needed to be ) <details<summary<strongFull backtrace on the fist check:</strong</summary<p</p</details: Problem persists after updating to last nightly: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace (After trying to recheck it)</strong</summary<p</p</details
I just found out the problem exists because of: If I comment out that line it will not report an internal error anymore. I had a function but I also use the crate  I now renamed the function but still getting errors. So it is likely because of a ambiguity issue. Trying to reproduce it in minimal code example, but not yet been able to do so.
After some testing a narrowed it down to the following: : : My guess why this fails: The macro uses inside of it. But when I try to export this it can not find it. commenting out/removing any line will give a normal compile error. I hope this helps to find out the problem. The error always happens and can thus be reliably reproduced. I tested this on latest nightly too:
reduced:
Hi can you assign it to me? I would like to give it a try and solve it.
Change:
<ins> // run-pass // // Test that we can handle unsized types with an extern type tail part. // Regression test for issue #91827. #![feature(const_ptr_offset_from)] #![feature(const_slice_from_raw_parts)] #![feature(extern_types)] use std::ptr::addr_of; extern "C" { type Opaque; } unsafe impl Sync for Opaque {} #[repr(C)] pub struct List<T> { len: usize, data: [T; 0], tail: Opaque, } #[repr(C)] pub struct ListImpl<T, const N: usize> { len: usize, data: [T; N], } impl<T> List<T> { const fn as_slice(&self) -> &[T] { unsafe { std::slice::from_raw_parts(self.data.as_ptr(), self.len) } } } impl<T, const N: usize> ListImpl<T, N> { const fn as_list(&self) -> &List<T> { unsafe { std::mem::transmute(self) } } } pub static A: ListImpl<u128, 3> = ListImpl { len: 3, data: [5, 6, 7], }; pub static A_REF: &'static List<u128> = A.as_list(); pub static A_TAIL_OFFSET: isize = tail_offset(A.as_list()); const fn tail_offset<T>(list: &List<T>) -> isize { unsafe { (addr_of!(list.tail) as *const u8).offset_from(list as *const List<T> as *const u8) } } fn main() { assert_eq!(A_REF.as_slice(), &[5, 6, 7]); // Check that interpreter and code generation agree about the position of the tail field. assert_eq!(A_TAIL_OFFSET, tail_offset(A_REF)); } </ins>

Discussion:
A slightly different reproducer that doesn't rely on constant propagation pass, and so should be more robust: label +A-const-eval +F-extern_types
Error: Malformed in master branch. missing field for key at line 156 column 1 Please let know if you're having trouble with this bot.