jiebi/CodeConvo huggingface dataset:
Change:
<del> //@ known-bug: #123693 #![feature(transmutability)] mod assert { use std::mem::{Assume, TransmuteFrom}; pub fn is_transmutable<Src, Dst>() where Dst: TransmuteFrom<Src, { Assume::NOTHING }>, { } } enum Lopsided { Smol(()), Lorg(bool), } fn should_pad_variants() { assert::is_transmutable::<Lopsided, ()>(); } </del>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'Size::sub: 0 - 1 would result in negative size'', 'thread 'rustc' panicked at 'Size::sub: 0 - 1 would result in negative size'' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: [evaluateobligation] evaluating trait selection obligation [typeck] type-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
On it! Thanks for the report.
Further minimized:
The cause here is neat. here is niche optimizable, with its second variant being subject to niche optimization. Typically, a niche-optimized enum has one tagless variant, and zero or more tagged variants laid out in the usual manner: the tag is placed, and then the rest of the fields follow. But reveals that's not what happens here. Because is a ZST, is placed at offset , rather than (following the tag). In other words: the tag is co-located with the field. This produces an ICE, because our assumption that fields follow tag is violated (a checked sub panics).
claim
Change:
<del> // Make sure that the mono-item collector does not crash when trying to // instantiate a default impl for DecodeUtf16<<u8 as A>::Item> // See https://github.com/rust-lang/rust/issues/58375 // compile-flags:-C link-dead-code #![crate_type = "rlib"] pub struct DecodeUtf16<I>(I); pub trait Arbitrary { fn arbitrary() {} } pub trait A { type Item; } impl A for u8 { type Item = char; } impl Arbitrary for DecodeUtf16<<u8 as A>::Item>  { } </del>

Discussion:
With the change in function shouldrunsuccessfully() of commit : RunPass =true, Ui == Some(PassMode::Run), RunPass | Ui =self.effectivepass_mode() == Some(PassMode::Run), The test cases under run-pass directory are tested for building only, the compiled test cases are not running any more. Does it work as design?
Oh. This is bad. Will fix today. cc (on vacation)
Fixed in
Change:
<ins> error[E0308]: mismatched types --> $DIR/mismatched-types-numeric-from.rs:2:18 | LL |     let _: u32 = i32::from(0_u8); |                  ^^^^^^^^^^^^^^^ expected u32, found i32 error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
I updated a dependency and the type of a struct field changed from an to a . I am assigning a value to this struct field. Before, I was calling to convert the to an . With the upgrade this is unnecessary since the field and the value are both . The rust compiler suggests this fix: But it should really suggest removing the and using the directly. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I am using Rust 1.37.0.
cc
Similarly, this code should suggest replacing with .
For the case where we have and an was expected, what should be the correct behavior? I believe simply suggesting is appropriate, if funny looking, because the could_ be coming from outside a macro, and the error be inside of one. Thoughts?
that sounds good to me
claim
Which of these options makes more sense? Check if the new (suggested) conversion is infallible always (doesn't make sense in the 1st case?) only in the 2nd case (if the new conversion is fallible, I presume we fall back to other suggestions and should be suggested, which makes a bit of sense, since it highlights the possible panic?) never (if is detected, always suggest to replace with ) Seems like the user already opted in for panicking if the conversion fails, so conversion was fallible and will stay so:The conversion is infallible but will become fallible if the suggestion is applied:
release-assignment
sorry, didn't see your claim before I pushed my PR :-|
Change:
// Those in 2. are warned via walk_generics and this // call here. visit::walk_path(self, &tr.path); <ins> // Those in 3. are warned with this call. for impl_item in impl_items { match *impl_item { ast::MethodImplItem(..) => {}, ast::TypeImplItem(ref typedef) => { self.visit_ty(&typedef.typ); } } } </ins> } } } else if trait_ref.is_none() && self_is_public_path {

Discussion:
AFAIK, you can't put private types in "public" items (public as in marked with ). is not explicitly marked with , but for all intent and purposes all the methods in a trait are public if the trait is public. So, I think the should be rejected by the privacy checker. (Or, I could be wrong and this is "correct" behavior - and this wouldn't be the first time that the privacy/module system allows things that I find ) cc
I agree, I think this may have just been accidentally overlooked when implementing associated types.
On Sat, Feb 28, 2015 at 10:59:14PM -0800, Alex Crichton wrote: Yes, that. There was language in the RFC describing trait item signatures and how they should be treated, and I think we just failed to extend that to associated types. Definitely a bug.
triage: P-backcompat-lang (1.0 beta)
Note also that is still open.
Change:
<ins> warning: the feature `non_lifetime_binders` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/non-lifetime-via-dyn-builtin.rs:5:12 | LL | #![feature(non_lifetime_binders)] |            ^^^^^^^^^^^^^^^^^^^^ | = note: see issue #108185 <https://github.com/rust-lang/rust/issues/108185> for more information = note: `#[warn(incomplete_features)]` on by default warning: 1 warning emitted </ins>

Discussion:
The type is not inferred to be by the above mentioned nightly release, c.f. Using the stable, the code compiles with out issue. EDIT: It seems to be related to GAT, i.e. a more minimal reproducer is: which similarly fails on nightly and builds on stable. <details<summaryMore details</summaryon the above-mentioned nightly version whereas stable is happy Simply asserting that is via e.g. works on stable and nightly. </details
The reproducer wouldn't compile on stable though?
Sorry, I must have messed something up when trying to whittle it down as the reproducer I started with definitely did compile on stable. Will try to trace my steps backwards.
And indeed using instead of makes it compile on stable. (I wanted to avoid to avoid the standard library but indeed is closer to the original code in question.) I updated the reproducer in the OP accordingly.
Great, thank you. So I believe this to be a different manifestation of from cc -- and therefore also to be fixed by
Stumbled on this separately in my own code. The simplest reproduction I was able to come up with is Removing makes it compile on nightly as well. Putting a bound on does not help.
Change:
<ins> // check that we don't generate a span that points beyond EOF // error-pattern: unclosed delimiter // error-pattern: unclosed delimiter // error-pattern: unclosed delimiter fn a(){{{ </ins>

Discussion:
[ ] Previous Stable [ ] Current Stable [ ] Current Beta [ ] Current Nightly No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
reduced:
reduced further claim I think try to get a span from to but we work around and assume that since we don't have a , it must be somewhere near EOF. When we then try to point at it via diagnostics, we get the error that we don't have anything to actually point to.
Change:
<ins> // aux-build:issue-76736-1.rs // aux-build:issue-76736-2.rs #![crate_name = "foo"] extern crate issue_76736_1; extern crate issue_76736_2; // @has foo/struct.Foo.html // @!has - '//*[@class="impl"]//h3[@class="code-header"]' 'MaybeResult' pub struct Foo; // @has foo/struct.Bar.html // @!has - '//*[@class="impl"]//h3[@class="code-header"]' 'MaybeResult' pub use issue_76736_2::Bar; </ins>

Discussion:
This is a regression from stable to beta, although this issue will be P-low. The problem is ignored documenting unstable traits for non-local types, fixes some regressions caused by it but the regression in nightly-rustc / compiler docs still opens. For example: Compare and . The doc in 1.46.0 has impl, while on nightly it doesn't have. A way to fix this issue is ignoring this check when the compiling-crates are being passed flag or the crate/module has feature: : Version 1.48.0-nightly ( 2020-09-14)
Hey! I would like to check this out if that is okay
Is this actually a regression?
Dropping regression label. nightly-rustc docs are, well, not really important on non-nightly channels, as they cannot be used by normal consumers.
if you're still interested in working on this we'd love to have the help! If you have trouble, feel free to ask for help in or :)
Thanks! Yes, I am still interested, I have been busy that past few weeks. I will give it a shot this weekend and will reach out if I can't figure it out!
Since zulip is lag in my region at night, I post a respond here. You could use to check for flag passed during compilation.
I think I'll hop onto this if that's OK. I've always wanted to contribute :)
Go for it!
It doesn't seem to be fixed by I'll check the cause
Change:
LL |     mac!(); |     ------ in this macro invocation | <ins> note: if you're trying to build a new `Box<_, _>` consider using one of the following associated functions: Box::<T>::new Box::<T>::new_uninit Box::<T>::new_zeroed Box::<T>::try_new and 18 others --> $SRC_DIR/alloc/src/boxed.rs:LL:COL </ins> = note: this error originates in the macro `mac` (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to 2 previous errors

Discussion:
Consider the following code: This fails with an error that simply states that is not available: The intent is fairly clear: we want to construct a new using a method that follows the for constructors, but that method is not available. Instead the solution is likely to be either or : When is not available it'd be ideal if the compiler could suggest alternatives. A first heuristic for which methods to suggest be methods on the same struct that don't take any params, have as their return type, and aren't implemented through any trait. For this would include and . But not , , and . I'm not too sure how to structure the help message exactly, but I could imagine something along these lines might work: cc/
Seems like es should be to the standard library to fix this.
This seems to be the same as
Closing in favor of that.
For the example I brought up, how would an work? The method does not exist on . So it shouldn't qualify as an alias? Additionally this is intended as an automated mechanism to improve the quality of diagnostics, rather than a manual mechanism (like attributes) which would need to be opted into. While both cases do touch on improving diagnostics for missing methods, I don't think these are equivalent.
No but does exist, so e.g., on it could add the information necessary (see e.g. on ) for the compiler to provide the diagnostic. But I suppose the heuristic you've suggested might work without attributes, although I suspect it would suggest too many false positives, but let's reopen I guess.
what do you think of the following? <img width="779" alt="Screenshot 2023-10-20 at 6 13 57 PM" src=""
oh I love it!
Change:
rendering_params: ImplRenderingParameters, ) { for trait_item in &t.items { <del> // Skip over any default trait items that are impossible to call </del> <ins> // Skip over any default trait items that are impossible to reference </ins> // (e.g. if it has a `Self: Sized` bound on an unsized type). if let Some(impl_def_id) = parent.item_id.as_def_id() && let Some(trait_item_def_id) = trait_item.item_id.as_def_id() <del> && cx.tcx().is_impossible_method((impl_def_id, trait_item_def_id)) </del> <ins> && cx.tcx().is_impossible_associated_item((impl_def_id, trait_item_def_id)) </ins> { continue; }

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. --The command causes an ICE error. This happens when we use the features of () in different workspaces. workspace- : workspace- : <!-- 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 --<!-- TRIAGEBOT_END --
label T-rustdoc
label -needs-triage A-cross-crate-reexports Ah lol, just noticed that we're also leaking the desugared form of RPITITs (the assoc ty) for a slightly altered non-icing version of this code (still cross-crate tho). Also needs to be addressed at some point, taking a mental note. claim
Change:
<ins> // Copyright 2018 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. #![feature(optin_builtin_traits)] // @has issue_55321/struct.A.html // @has - '//*[@id="implementations-list"]/*[@class="impl"]//*/code' "impl !Send for A" // @has - '//*[@id="implementations-list"]/*[@class="impl"]//*/code' "impl !Sync for A" pub struct A(); impl !Send for A {} impl !Sync for A {} // @has issue_55321/struct.B.html // @has - '//*[@id="synthetic-implementations-list"]/*[@class="impl"]//*/code' "impl<T> !Send for  // B<T>" // @has - '//*[@id="synthetic-implementations-list"]/*[@class="impl"]//*/code' "impl<T> !Sync for  // B<T>" pub struct B<T: ?Sized>(A, Box<T>); </ins>

Discussion:
Hi, I noticed a weird internal error using . The smallest example I could make to reproduce the bug is an basic library project () whose contains: , , and all work fine; and as mentioned in the code, the place where is declared seems to matter. Here is the output and trace of : [log was from an out of date nightly rust, see my comment below for the log for the latest nightly as of this edit] Have a nice day.
My bad, I appear to have accidentally used a version of rust that wasn't up to date. The bug still occurs in the latest nightly, here's the backtrace: Sorry again about that.
It looks like is only checking for explicit negative impls at the very beginning, and not throughout the process. I should have a fix for this later today.
Looks like this error has been there the whole time that synthetic impls have been there - that sample fails all the way back to 1.26.0.
Change:
return "VecDeque(size={})".format(self.size) def children(self): <del> for index in xrange(0, self.size): value = (self.data_ptr + ((self.tail + index) % self.cap)).dereference() yield "[{}]".format(index), value </del> <ins> return _enumerate_array_elements( (self.data_ptr + ((self.tail + index) % self.cap)) for index in xrange(self.size) ) </ins> @staticmethod def display_hint():

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:
parent_scope: ParentScope<'a>, /// The current set of local scopes for types and values. <del> /// FIXME #4948: Reuse ribs to avoid allocation. </del> ribs: PerNS<Vec<Rib<'a>>>, /// Previous poped `rib`, only used for diagnostic.

Discussion:
As per comment in
The original fixme comment was introduced in (in the file in that commit; github does not show it for me in the commit, you need to do view file, or not use github. :) From looking at the resolve code, it seems like we indeed push and pop rib objects in a pretty regular fashion, and may also only use it like a stack... (maybe fixing this is actually easy; I do not immediately see a case where the elements of escape from their containing vector...)
I believe resolve has changed quite a bit since this was opened, and I think it's best to track the implementation details of resolve inside of resolve itself to make sure they stay up to date.
This issue is still relevant. That is, we still do allocations (pushes) and deallocations (pops). Maybe we should move from vector to some implementation of stack instead (not that it would decrease amount of allocations much)?
Change:
[sym::coroutine, ..] => { self.check_coroutine(attr, target); } <ins> [sym::linkage, ..] => self.check_linkage(attr, span, target), </ins> [ // ok sym::allow

Discussion:
I tried this code: I expected to see this happen: compilation failure because of attribute on an item where it makes no sense Instead, this happened: compiled successfully : cc see for where to fix this issue <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<del> // Copyright 2012 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. enum test { thing = 3u } //~ ERROR mismatched types //~^ ERROR expected signed integer constant fn main() { error!(thing as int); assert_eq!(thing as int, 3); } </del>

Discussion:
Currently, the following fails to compile, with errors about expecting int instead of uint: Is there any reason why this should be disallowed?
Linking to issue
Fixed by
Change:
} } <del> let mut collector = OpaqueTypeLifetimeCollector { variances }; </del> <ins> let mut collector = OpaqueTypeLifetimeCollector { tcx, root_def_id: item_def_id.to_def_id(), variances }; </ins> let id_substs = ty::InternalSubsts::identity_for_item(tcx, item_def_id.to_def_id()); for pred in tcx.bound_explicit_item_bounds(item_def_id.to_def_id()).transpose_iter() { let pred = pred.map_bound(|(pred, _)| *pred).subst(tcx, id_substs);

Discussion:
The following compiles on the current nightly (1.67.0-nightly (2022-12-03 )) although it shouldn't: It is correctly rejected by the current beta: 1.66.0-beta.2 (2022-11-20 ). This is most likely (I haven't bisected though!). Cc label C-bug T-compiler I-unsound regression-from-stable-to-nightly A-impl-trait
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
[[package]] name = "cc" <del> version = "1.0.37" </del> <ins> version = "1.0.47" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "39f75544d7bbaf57560d2168f28fd649ff9c76153874db88bdbdfd839b1a7e7d" </del> <ins> checksum = "aa87058dce70a3ff5621797f1506cb837edd02ac4c0ae642b4542dce802908b8" dependencies = [ "jobserver", "num_cpus", ] </ins> [[package]] name = "cfg-if"

Discussion:
Do we have plan to get rid of this restriction recently? A newer version of cc-rs is needed for VxWorks
can't currently be updated due to a build problem with riscv. More info at I think the issue is that rustbuild uses cc to discover cc toolchains, and gained riscv support, and so now it thinks it should use a gcc toolchain that doesn't exist. The detection is in and Alex mentioned just setting a env var in the riscv container might be enough. It's been on my todo list for a while, but I haven't had a chance to look at it. I can maybe try to look at it this weekend.
Thanks for working on this issue. Enjoy your weekend, it is not that urgent.
Change:
<ins> error: items in `extern` blocks cannot use non-ascii identifiers --> $DIR/extern_block_nonascii_forbidden.rs:5:10 | LL | extern "C" { | ---------- in this `extern` block LL |     type 一; |          ^^ | = note: This limitation may be lifted in the future; see issue #83942 <https://github.com/rust-lang/rust/issues/83942> for more information error: items in `extern` blocks cannot use non-ascii identifiers --> $DIR/extern_block_nonascii_forbidden.rs:6:8 | LL | extern "C" { | ---------- in this `extern` block LL |     type 一; LL |     fn 二(); |        ^^ | = note: This limitation may be lifted in the future; see issue #83942 <https://github.com/rust-lang/rust/issues/83942> for more information error: items in `extern` blocks cannot use non-ascii identifiers --> $DIR/extern_block_nonascii_forbidden.rs:7:12 | LL | extern "C" { | ---------- in this `extern` block ... LL |     static 三: usize; |            ^^ | = note: This limitation may be lifted in the future; see issue #83942 <https://github.com/rust-lang/rust/issues/83942> for more information error: aborting due to 3 previous errors </ins>

Discussion:
It was mentioned in that in the original RFC text, there's text that said the non-ASCII identifiers should be disallowed within extern blocks. This is a niche use-case and i believe this doesn't need to block stablization. Creating this issue here to track it.
What will something like actually link against? This seems like it might be a forward-compatiblity hazard when linking to external code, since the precise mangling/encoding isn't clear
I think we should just disallow for now; and later check out what C does and match that.
do you want to implement this? Should be a simple check in the parser.
Sure, let me give it a try.
Implemented in .
On the other hand the use of non-ASCII symbol names is already stable through link_name attribute.
Out of curiosity, I checked how Clang and GCC mangle the symbol: they simply use UTF-8. MSVC doesn't seem to allow non-ascii in identifier. (Notice how the byte-length encoding in C++ is using the UTF-8 byte count, and not the code point count, as I would expect)
Yeah I feel like the functionality can be re- with an FCP without much work, there just needs to be some research on how stable those mangling schemes are around this.
As for , my take on that is that once you're using that you're trying something weird and know what you're doing; there is no point restricting it further since it's very easy to accidently block out legit use cases.
Inversely, I've just noticed that despite usage of a properly-ASCII-ed , if the "Rust name" is non-ASCII then it is still rejected: