jiebi/CodeConvo huggingface dataset:
Change:
| LL | #[derive(rustfmt::skip)] |          ^^^^^^^^^^^^^ not a derive macro <ins> | help: remove from the surrounding `derive()` --> $DIR/tool-attributes-misplaced-2.rs:1:10 | LL | #[derive(rustfmt::skip)] |          ^^^^^^^^^^^^^ = help: add as non-Derive macro `#[rustfmt::skip]` </ins> error: expected macro, found tool attribute `rustfmt::skip` --> $DIR/tool-attributes-misplaced-2.rs:5:5

Discussion:
(The actual desired output should have colours and minuses on the removed derive, but to give the idea) Many users are not familiar with the terminology being used by the compiler error (i.e. the different flavours of procedural macro, derive vs attribute) and might be confused as to what they need to do in order to fix the error. Since the fix is straight-forward (i.e. remove the ), the compiler should show a code snippet that fixes the issue. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I have a partially functional implementation of this, though I've run into a bit of trouble, some guidance would be appreciated. Currently I'm implementing this next to the existing error in in . My trouble comes with knowing what the macro is invoked on, (function, struct), and sending the help message selectively based on that. Is there a way to get this information in , or is my approach wrong and the error should be elsewhere? As far as I can tell I am trying to implement this in a place before the AST is fully parsed, so this may be unviable
Change:
ty::TyStruct(def, substs) | ty::TyEnum(def, substs) => { let did = def.did; <del> let fqn = cx.tcx().sess.cstore.item_path(did); let fqn: Vec<_> = fqn.into_iter().map(|i| i.to_string()).collect(); </del> let kind = match self.sty { ty::TyStruct(..) => TypeStruct, _ => TypeEnum, }; <del> let path = external_path(cx, &fqn.last().unwrap().to_string(), </del> <ins> inline::record_extern_fqn(cx, did, kind); let path = external_path(cx, &cx.tcx().item_name(did).as_str(), </ins> None, vec![], substs); <del> cx.external_paths.borrow_mut().as_mut().unwrap().insert(did, (fqn, kind)); </del> ResolvedPath { path: path, typarams: None,

Discussion:
The [src] link on these pages is broken: The links are also broken in the stable docs version of these pages.
I think this should be fixed by . The links wrongly point to instead of because the crate is linked in std like
I've built the docs locally and the issue somehow persists.
Change:
<ins> error[E0412]: cannot find type `X` in this scope --> $DIR/type_not_in_scope.rs:1:6 | LL | impl X { |      ^ not found in this scope error[E0573]: expected type, found built-in attribute `cfg_attr` --> $DIR/type_not_in_scope.rs:7:18 | LL | fn getn<const N: cfg_attr>() -> [u8; N] {} |                  ^^^^^^^^ not a type error[E0308]: mismatched types --> $DIR/type_not_in_scope.rs:7:33 | LL | fn getn<const N: cfg_attr>() -> [u8; N] {} |    ----                         ^^^^^^^ expected array `[u8; N]`, found `()` |    | |    implicitly returns `()` as its body has no tail or `return` expression error: aborting due to 3 previous errors Some errors have detailed explanations: E0308, E0412, E0573. For more information about an error, try `rustc --explain E0308`. </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. --<!-- 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
's parameter doesn't have to have an error type; it appears it can be any type (that doesn't trip the full feature gate error.) This version ICEs without any prior diagnostics: Neither version ICEs on beta or stable. (const generics aren't stable on 1.50, but after reporting an error for use of unstable features the compiler reports the same errors as beta and doesn't ICE.) label A-const-generics regression-from-stable-to-nightly
Bisected, this is a weird one:
I've attempted a second bisection using the snippet from the , I got a different result (not sure why, unsure if it helps) searched nightlies: from nightly-2021-02-15 to nightly-2021-03-18 regressed nightly: nightly-2021-03-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
I guess that was a lie I'm looking into this
Assigning and removing as in the prioritization working group. label: +P-high -I-prioritize
Change:
| = note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait = note: required by `std::convert::From::from` <ins> help: consider converting the `Option<T>` into a `Result<T, _>` using `Option::ok_or` or `Option::ok_or_else` | LL |     x.ok_or_else(|| /* error value */)?; |      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ </ins> error[E0277]: the `?` operator can only be used in a function that returns `Result` or `Option` (or another type that implements `std::ops::Try`) --> $DIR/try-on-option.rs:13:5

Discussion:
It seems that should provide a better error message or hint when one tries to use the operator on an in a function returning a or vice-versa. Currently this is the error you get: However, it would be better to suggest the use of or , or , instead of referencing something dependent on the feature (). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This error is emitted here: We could look at whether the is , and if so, provide a more targeted error, including a structured suggestion for .
Can I claim this issue?
claim
Change:
<ins> error: expected derive macro, found built-in attribute `inline` --> $DIR/macro-path-prelude-fail-5.rs:4:17 | LL | #[derive(Debug, inline)] |                 ^^^^^^ not a derive macro | help: remove from the surrounding `derive()` --> $DIR/macro-path-prelude-fail-5.rs:4:17 | LL | #[derive(Debug, inline)] |                 ^^^^^^ = help: add as non-Derive macro `#[inline]` error: expected derive macro, found built-in attribute `inline` --> $DIR/macro-path-prelude-fail-5.rs:7:10 | LL | #[derive(inline, Debug)] |          ^^^^^^ not a derive macro | help: remove from the surrounding `derive()` --> $DIR/macro-path-prelude-fail-5.rs:7:10 | LL | #[derive(inline, Debug)] |          ^^^^^^ = help: add as non-Derive macro `#[inline]` error: aborting due to 2 previous errors </ins>

Discussion:
(The actual desired output should have colours and minuses on the removed derive, but to give the idea) Many users are not familiar with the terminology being used by the compiler error (i.e. the different flavours of procedural macro, derive vs attribute) and might be confused as to what they need to do in order to fix the error. Since the fix is straight-forward (i.e. remove the ), the compiler should show a code snippet that fixes the issue. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I have a partially functional implementation of this, though I've run into a bit of trouble, some guidance would be appreciated. Currently I'm implementing this next to the existing error in in . My trouble comes with knowing what the macro is invoked on, (function, struct), and sending the help message selectively based on that. Is there a way to get this information in , or is my approach wrong and the error should be elsewhere? As far as I can tell I am trying to implement this in a place before the AST is fully parsed, so this may be unviable
Change:
use std::marker::PhantomData; struct B<T, const N: T>(PhantomData<[T; N]>); //~ ERROR const generics are unstable <del> //~^ ERROR the types of const generic parameters must derive `PartialEq` and `Eq` </del> <ins> //~^ ERROR `T` is not guaranteed to `#[derive(PartialEq, Eq)]` </ins> fn main() {}

Discussion:
I tried this code: This produces the following error on rustc 1.44.0-nightly: I guess that const generics with a generic type isn't supported/allowed. If that's the case, this should be mentioned in the error message. :
The type needs to derive , not just implement them. This is because only types can be used for const generics at the moment, but we don't expose that to the user. Maybe we could improve the diagnostic here by actually mentioning .
thanks for fixing this so quickly! Is there a chance that this restriction will be lifted, so the above code compiles?
We would like to lift the restriction, but probably not in the first stabilised version of const generics, as it's not easy to get right: we need to be very careful in making sure that we don't accidentally allow unsoundness to sneak in, and there are many subtleties.
Change:
let (prov, offset) = pointer.into_parts(); let alloc_id = prov.alloc_id(); intern_const_alloc_for_constprop(ecx, alloc_id).ok()?; <del> if matches!(ecx.tcx.global_alloc(alloc_id), GlobalAlloc::Memory(_)) { // `alloc_id` may point to a static. Codegen will choke on an `Indirect` with anything // by `GlobalAlloc::Memory`, so do fall through to copying if needed. // FIXME: find a way to treat this more uniformly // (probably by fixing codegen) </del> <ins> // `alloc_id` may point to a static. Codegen will choke on an `Indirect` with anything // by `GlobalAlloc::Memory`, so do fall through to copying if needed. // FIXME: find a way to treat this more uniformly (probably by fixing codegen) if let GlobalAlloc::Memory(alloc) = ecx.tcx.global_alloc(alloc_id) // Transmuting a constant is just an offset in the allocation. If the alignment of the // allocation is not enough, fallback to copying into a properly aligned value. && alloc.inner().align >= op.layout.align.abi { </ins> return Some(ConstValue::Indirect { alloc_id, offset }); } }

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
cc I suspect this might be related to
I did not know where to add this is the template but this may be useful: Build works in debug mode, but not in release mode.
Regression in nightly-2023-12-31 (...)
Change:
impl File { pub fn open(path: &Path, opts: &OpenOptions) -> io::Result<File> { let path = maybe_verbatim(path)?; <ins> let creation = opts.get_creation_mode()?; </ins> let handle = unsafe { c::CreateFileW( path.as_ptr(), opts.get_access_mode()?, opts.share_mode, opts.security_attributes, <del> opts.get_creation_mode()?, </del> <ins> creation, </ins> opts.get_flags_and_attributes(), ptr::null_mut(), ) }; let handle = unsafe { HandleOrInvalid::from_raw_handle(handle) }; <del> if let Ok(handle) = handle.try_into() { </del> <ins> if let Ok(handle) = OwnedHandle::try_from(handle) { // Manual truncation. See #115745. if opts.truncate && creation == c::OPEN_ALWAYS && unsafe { c::GetLastError() } == c::ERROR_ALREADY_EXISTS { unsafe { // Setting the allocation size to zero also sets the // EOF position to zero. let alloc = c::FILE_ALLOCATION_INFO { AllocationSize: 0 }; let result = c::SetFileInformationByHandle( handle.as_raw_handle(), c::FileAllocationInfo, ptr::addr_of!(alloc).cast::<c_void>(), mem::size_of::<c::FILE_ALLOCATION_INFO>() as u32, ); if result == 0 { return Err(io::Error::last_os_error()); } } } </ins> Ok(File { handle: Handle::from_inner(handle) }) } else { Err(Error::last_os_error())

Discussion:
Reported on discord, using will fail on Windows if the file is hidden. This also affects methods like or that open the file the same way. The reason for this is that we use , which has : So to make it work the caller needs to match the requested attributes to the existing attributes at the time of opening. It was suggested we could instead use and then manually truncate the file using to zero.
Manually truncating would require also clearing the alternate data streams too, right? And it would presumably stop erroring if another process still has the file open and instead corrupt the file fron the view of the other process.
No? The proposed solution would work the same was as in the case where the file already exists. Which we use for .
Right, got confused with .
Change:
<ins> // Copyright 2015 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. // Check we reject structs that mix a `Drop` impl with `#[repr(C)]`. // // As a special case, also check that we do not warn on such structs // if they also are declared with `#[unsafe_no_drop_flag]` #![feature(unsafe_no_drop_flag)] #![deny(drop_with_repr_extern)] #[repr(C)] struct As { x: Box<i8> } #[repr(C)] enum Ae { Ae(Box<i8>), _None } struct Bs { x: Box<i8> } enum Be { Be(Box<i8>), _None } #[repr(C)] struct Cs { x: Box<i8> } //~^ NOTE the `#[repr(C)]` attribute is attached here impl Drop for Cs { fn drop(&mut self) { } } //~^ ERROR implementing Drop adds hidden state to types, possibly conflicting with `#[repr(C)]` #[repr(C)] enum Ce { Ce(Box<i8>), _None } //~^ NOTE the `#[repr(C)]` attribute is attached here impl Drop for Ce { fn drop(&mut self) { } } //~^ ERROR implementing Drop adds hidden state to types, possibly conflicting with `#[repr(C)]` #[unsafe_no_drop_flag] #[repr(C)] struct Ds { x: Box<i8> } impl Drop for Ds { fn drop(&mut self) { } } #[unsafe_no_drop_flag] #[repr(C)] enum De { De(Box<i8>), _None } impl Drop for De { fn drop(&mut self) { } } fn main() { let a = As { x: Box::new(3) }; let b = Bs { x: Box::new(3) }; let c = Cs { x: Box::new(3) }; let d = Ds { x: Box::new(3) }; println!("{:?}", (*a.x, *b.x, *c.x, *d.x)); let _a = Ae::Ae(Box::new(3)); let _b = Be::Be(Box::new(3)); let _c = Ce::Ce(Box::new(3)); let _d = De::De(Box::new(3)); } </ins>

Discussion:
(imported from improperly closed bug ) As suggested by Until is done, we really should lint for this scenario.
triage: P-low
oops. triage: P-high (but nonetheless not 1.0)
I feel like this should be stronger than a medium-priority lint. I feel like rustc should reject programs that attempt to on a struct, for as long as that changes the size of that struct. In particular, not fixing this by 1.0 would foreclose the ability to change the drop flag after 1.0, since that would change the size / ABI of structs, right? Or is ABI stability not a guarantee of ?
Yeah this label got auto renamed. I'm up'ing the priority
triage: P-high I'll assign to self too
( I'm pretty confident we could fix this post 1.0, e.g. adding new warnings is allowed, and the representation issue would be "just a bug to be fixed." Nonetheless I I do I do want I do want to fix.)
Change:
DEFAULT_UNEXPECTED_INNER_ATTR_ERR_MSG }; let inner_parse_policy = <del> InnerAttributeParsePolicy::NotPermitted { reason: inner_error_reason }; </del> <ins> InnerAttributeParsePolicy::NotPermitted { reason: inner_error_reason, saw_doc_comment: just_parsed_doc_comment, prev_attr_sp: attrs.last().and_then(|a| Some(a.span)) }; </ins> let attr = self.parse_attribute_with_inner_parse_policy(inner_parse_policy)?; attrs.push(attr); just_parsed_doc_comment = false;

Discussion:
Given the following we currently emit We should emit at least the following We might also want to provide suggestions when it makes sense (like turning the attr into an outer attr).
Hey , I tried to solve this with a little help of on a rust meetup. I wasn't able to run because of the following message. But I started to add some code you can read here: is this going into the right direction?
thank you for taking a look at this! You should be able to run the tests with . Use to update the relevant files. The code you've written would generate the following output: Instead, we'd want this to be a single error. What you'd want to do is 1) get the span for the prior attribute from 2) expand to also hold an extra field and 3) change the following to be This lets you point at the prior span in the same error. The second part of this ticket is changing the linked code to no longer use , but rather synthesize a new span from the first 's span to the closing . You can use to do so. Finally, we change the above to be something like
Are you still working on this? I'm thinking of giving it a try.
Go on! I don’t have so much time atm so just go there step by step while learning rust. If you want so solve it - awesome
Change:
//~^ ERROR zero-sized fields in `repr(transparent)` cannot contain external non-exhaustive types //~| WARN this was previously accepted by the compiler <ins> #[repr(transparent)] pub struct T17(NonExhaustive, Sized); //~^ ERROR zero-sized fields in `repr(transparent)` cannot contain external non-exhaustive types //~| WARN this was previously accepted by the compiler #[repr(transparent)] pub struct T18(NonExhaustive, NonExhaustive); //~^ ERROR zero-sized fields in `repr(transparent)` cannot contain external non-exhaustive types //~| WARN this was previously accepted by the compiler #[repr(transparent)] pub struct T19(NonExhaustive, Private); //~^ ERROR zero-sized fields in `repr(transparent)` cannot contain external non-exhaustive types //~| WARN this was previously accepted by the compiler #[repr(transparent)] pub struct T19Flipped(Private, NonExhaustive); //~^ ERROR zero-sized fields in `repr(transparent)` cannot contain external non-exhaustive types //~| WARN this was previously accepted by the compiler #[repr(transparent)] pub struct T20(NonExhaustive); // Okay, since it's the only field. #[repr(transparent)] pub struct T21(NonExhaustive, InternalNonExhaustive); // Okay, since there's only 1 foreign non-exhaustive type. #[repr(transparent)] pub struct T21Flipped(InternalNonExhaustive, NonExhaustive); // Okay, since there's only 1 foreign non-exhaustive type. #[repr(transparent)] pub struct T22(NonExhaustive, InternalPrivate); // Okay, since there's only 1 foreign non-exhaustive type. #[repr(transparent)] pub struct T22Flipped(InternalPrivate, NonExhaustive); // Okay, since there's only 1 foreign non-exhaustive type. </ins> fn main() {}

Discussion:
Lifted from I believe this future compatibility warning was badly affected by . Minimal repro: As far as I understand what this issue is about, this code should be 100% fine. This issue is about preventing a previously-accepted struct from ending up with contents which a transparent struct is not allowed to have, after a permissible size increase of a non-exhaustive formerly-ZST from a different crate. That's not possible in the code above. continues to be a valid struct if increases in size. Regression in nightly-2023-09-18: Originally posted by in
Ah... good catch. When a type is not "stably 1-ZST" we should just consider it the one non-1-ZST field. Though given that this is a lint right now the logic is a bit trickier... we need to remember if there was a non-1-ZST field, and then if there was, all 1-ZST fields need to be stably 1-ZST if there wasn't, all but one 1-ZST field need to be stably 1-ZST. Having a nice diagnostic for this could be tricky because ideally we'd point it at two 1-ZST fields that are not stable, and explain "both of these might become non-1-ZST in the future and then this wouldn't build any more". Sadly I won't have the time to work on fixing this quickly. Let me know if you want me to revert the PR.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
/// scratch space that it may use however it wants. It will generally just do /// whatever is most efficient or otherwise easy to implement. Do not rely on /// removed data to be erased for security purposes. Even if you drop a `Vec`, its <del> /// buffer may simply be reused by another `Vec`. Even if you zero a `Vec`'s memory </del> <ins> /// buffer may simply be reused by another allocation. Even if you zero a `Vec`'s memory </ins> /// first, that might not actually happen because the optimizer does not consider /// this a side-effect that must be preserved. There is one case which we will /// not break, however: using `unsafe` code to write to the excess capacity,

Discussion:
The states: Here, "its buffer may simply be reused" is simply meant to refer to the behavior of the underlying allocator. But I have seen people with low-level experience be misled by this into thinking that the implementation of itself has its own global allocation cache. They then thought this cache was responsible for excess memory usage in their programs. I'm not sure what the best way to clarify this would be. Part of the reason the current wording can be misleading is that "reused by another " suggests a mechanism specific to . On the other hand, it would also help to just explicitly mention the allocator. Here is a possible version that addresses both points, but it's more wordy than the current version: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I guess this also includes in-place iteration?
In-place iteration is a fancy case of type-conversion. Simpler examples are conversions to , and which also keep the allocation.
Maybe it would be more clear to say "may be reused by another allocation"? That doesn't imply it has to be a Vec that reuses the memory.
label +A-collections +C-enhancement +T-libs
claim
Change:
<ins> // run-rustfix fn main() { let demo = 1; //~ ERROR cannot find value `demo` in this scope dbg!(demo); //~ ERROR cannot find value `demo` in this scope let x = "x"; //~ ERROR cannot find value `x` in this scope println!("x: {}", x); //~ ERROR cannot find value `x` in this scope if x == "x" { //~^ ERROR cannot find value `x` in this scope println!("x is 1"); } let y = 1 + 2; //~ ERROR cannot find value `y` in this scope println!("y: {}", y); //~ ERROR cannot find value `y` in this scope } </ins>

Discussion:
As a python programmer, forgetting a in an assignment to a variable that didn't exist before is an easy mistake to make. () Rust sees two uses of an undefined variable here (E0425 twice): While the second one is fine, in the first case I would have really appreciated a sentence like this: This would helped me as a newcomer to the language, because it does an educated guess what the problem might be and tells me how to fix it. I think the hint should be if the value is assigned to (first error), but not if it is used as an argument (second error). I hope this is the right place and format to file this suggestion, I would appreciate hints if this is not the case. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is the right place, however you should use the "diagnostic" template when creating issues like this. Thanks for the issue though. label +T-compiler +A-diagnostics
claim