jiebi/CodeConvo huggingface dataset:
Code change:
} hir::ImplItemKind::Type(_) => false, }, <ins> Node::Expr(&hir::Expr { kind: hir::ExprKind::Closure(..), .. }) => true, </ins> _ => false, } }

Related discussion:
text: Regression in ( cc modify labels: +regression-from-stable-to-stable -regression-untriaged
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Beta backport accepted as per compiler team . A backport PR will be authored by the release team at the end of the current development cycle. label +beta-accepted
Code change:
<ins> // edition:2018 // compile-flags: -Cincremental=tmp/issue-72766 pub struct SadGirl; impl SadGirl { pub async fn call(&self) -> Result<(), ()> { Ok(()) } } async fn async_main() -> Result<(), ()> { // should be `.call().await?` SadGirl {}.call()?; //~ ERROR: the `?` operator can only be applied to values Ok(()) } fn main() { let _ = async_main(); } </ins>

Related discussion:
text: <!-- 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 may be related, but I don't think this is the same bug because the above ICEs with nightly-2020-05-29.
cc
Code change:
<ins> error[E0603]: tuple struct constructor `A` is private --> $DIR/issue-111220-2-tuple-struct-fields-projection.rs:27:13 | LL |         let Self(a) = self; |             ^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0603`. </ins>

Related discussion:
text: I tried this code: I expected to see this happen: compilation should fail because the trait impl is defined outside of the module for the type but refers to its private field. Instead, this happened: this compiled successfully This reproduces on the playground for stable Rust, version 1.69.0:
Adding a main function and attempting to call the (playground link: ) raises the compilation error: !
This can be reproduced with cross-crate (e.i., any other crate can access the private field). This means that all encapsulations that take advantage of the field being private can be bypassed. (For example, if we change Vec to a tuple struct, the same thing as setlen could be done in safe code by abusing this bug.) label +I-unsound Also, this can be reproduced in all versions where is stable (e.i., 1.32+). It's a matter of how you initialize Foo. If you provide a constructor for Foo, you won't get a compile error:
Just for completeness, turning this into a segfault without external crates/just std:
label A-visibility
this has been unsound ever since in version 1.32
WG-prioritization assigning priority (). label -I-prioritize +P-high
Code change:
//@[rust2021] edition:2021 fn main() { println!('hello world'); <del> //[rust2015,rust2018,rust2021]~^ ERROR unterminated character literal </del> <ins> //~^ ERROR unterminated character literal //[rust2021]~| ERROR prefix `world` is unknown </ins> }

Related discussion:
text: <!-- [31mICE[0m: Rustc '--edition=2021 --crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: prefix is unknown', 'error: internal compiler error: prefix is unknown' File: --snippet: 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: --
:thinking: this bisects to cc
very plausible :+1:
Reduced
Code change:
<ins> #![feature(never_type)] #![deny(dead_code)] pub struct T1(!); pub struct T2(()); pub struct T3<X>(std::marker::PhantomData<X>); pub struct T4 { _x: !, } pub struct T5<X> { _x: !, _y: X, } pub struct T6 { _x: (), } pub struct T7<X> { _x: (), _y: X, } pub struct T8<X> { _x: std::marker::PhantomData<X>, } pub struct T9<X> { //~ ERROR struct `T9` is never constructed _x: std::marker::PhantomData<X>, _y: i32, } fn main() {} </ins>

Related discussion:
text: The struct is meant to not be constructible. Also the behavior is incoherent between tuple structs (correct behavior) and named structs (incorrect behavior). Also, this is a regression, this didn't use to be the case. No response No response
label +F-never_Type +D-inconsistent
We will also get such warnings for private structs with fields of never type (): The struct is never constructed although it is not constructible. This behavior is expected and is not a regression. Did you meet any cases using this way in real world? For the incoherent behavior, we also have: This because we only skip positional ZST (PhantomData and generics), this policy is also applied for never read fields:
Can you elaborate in which sense it is expected? I can understand that it is expected given the current implementation of Rust. It seems between stable and nightly a new lint was implemented. This lint is expected for inhabited types. However it has false positives on inhabited types, i.e. types that are only meant for type-level usage (for example to implement a trait). I agree we should probably categorize this issue as a false positive of a new lint rather than a regression (technically). Thanks, I can see the idea behind it. I'm not convinced about it though, but it doesn't bother me either. So let's just keep this issue focused on the false positive rather than the inconsistent behavior.
How do you think about private structs with fields of never type?
I would consider it the same as public structs, because they can still be "constructed" at the type-level. So they are dynamic dead--code but not dead-code since they are used statically. It would be dead-code though if the type is never used (both in dynamic code and static code, i.e. types).
Actually, thinking about this issue, I don't think this is a false positive only for the never type. I think the whole lint is wrong. The fact that the type is empty is just a proof that constructing it at term-level is not necessary for the type to be "alive" (aka usable). This could also be the case with non-empty types. A lot of people just use unit types for type-level usage only (instead of empty types).
Code change:
<ins> #![feature(never_type)] #![deny(dead_code)] pub struct T1(!); pub struct T2(()); pub struct T3<X>(std::marker::PhantomData<X>); pub struct T4 { _x: !, } pub struct T5<X> { _x: !, _y: X, } pub struct T6 { _x: (), } pub struct T7<X> { _x: (), _y: X, } pub struct T8<X> { _x: std::marker::PhantomData<X>, } pub struct T9<X> { //~ ERROR struct `T9` is never constructed _x: std::marker::PhantomData<X>, _y: i32, } fn main() {} </ins>

Related discussion:
text: So my conclusion would be that linting a type to be dead-code because it is never constructed is brittle as it can't be sure that the type is not meant to be constructed at term-level (and thus only used at type-level). Adding is not a solution because if the type is actually not used at all (including in types) then we actually want the warning. Here is an example: The same thing with a private struct: And now actual dead code:
I think a better way is: is usually used to do such things like just a proof. Maybe we can add a help for this case.
But I agree that we shouldn't emit warnings for pub structs with any fields of never type (and also unit type), this is an intentional behavior.
Oh yes good point. So all good to proceed with adding never type to the list of special types.
Thanks a lot for the quick fix! Once it hits nightly, I'll give it a try. I'm a bit afraid though that this won't fix the underlying problem of understanding which types are not meant to exist at runtime. For example, sometimes instead of using the never type, I also use empty enums such that I can give a name and separate identity to that type. Let's see if it's an issue. If yes, I guess ultimately there would be 2 options: Just use in those cases. Introduce a trait (or better name) for types that are not meant to exist at runtime like unit, never, and phantom types, but could be extended with user types like empty enums. I'll ping this thread again if I actually hit this issue.
I could test it (using nightly-2024-08-01) and . I just had to change a to in a crate where I didn't have already. Ultimately, is going to be a type alias for so maybe it's not worth supporting it. And thinking about empty enums, this should never be an issue for my particular usage, which is to build empty types. Because either the type takes no parameters in which case I use an empty enum directly. Or it takes parameters and I have to use a struct with fields, and to make the struct empty I also have to add a never field. So my concern in the previous message is not an issue for me.
Code change:
return krate; } <del> krate.module.items.push(mk_decls(&mut cx, &derives, &attr_macros, &bang_macros)); </del> <ins> krate.module.items.push(mk_decls(&mut cx, &macros)); </ins> krate }

Related discussion:
text: The PR improved the situation about documenting proc macros. Thanks for that! However, I noticed a bug with it. I'm using . Running results in this: ! Looks like a simple typo or off-by-one or something like that bug. When using only and not s, everything looks good to me. CC
Oh, and also, running prints: Not sure if this warning is expected there. And not sure if related to this bug.
This is a consequence of the fact that has not yet been merged. Once it gets merged, and rust updates its Cargo submodule, this issue should go away.
It turns out that this issue was unrelated. I've opened a PR to fix it.
I see. Thanks for your work on this :)
Code change:
attrs: Vec<ast::Name>, } <ins> enum ProcMacroDefType { Attr, Bang } </ins> struct ProcMacroDef { function_name: Ident, span: Span, <ins> def_type: ProcMacroDefType } enum ProcMacro { Derive(ProcMacroDerive), Def(ProcMacroDef) </ins> } struct CollectProcMacros<'a> { <del> derives: Vec<ProcMacroDerive>, attr_macros: Vec<ProcMacroDef>, bang_macros: Vec<ProcMacroDef>, </del> <ins> macros: Vec<ProcMacro>, </ins> in_root: bool, handler: &'a errors::Handler, is_proc_macro_crate: bool,

Related discussion:
text: The PR improved the situation about documenting proc macros. Thanks for that! However, I noticed a bug with it. I'm using . Running results in this: ! Looks like a simple typo or off-by-one or something like that bug. When using only and not s, everything looks good to me. CC
Oh, and also, running prints: Not sure if this warning is expected there. And not sure if related to this bug.
This is a consequence of the fact that has not yet been merged. Once it gets merged, and rust updates its Cargo submodule, this issue should go away.
It turns out that this issue was unrelated. I've opened a PR to fix it.
I see. Thanks for your work on this :)
Code change:
let ecfg = ExpansionConfig::default("proc_macro".to_string()); let mut cx = ExtCtxt::new(sess, ecfg, resolver); <del> let (derives, attr_macros, bang_macros) = { let mut collect = CollectProcMacros { derives: Vec::new(), attr_macros: Vec::new(), bang_macros: Vec::new(), in_root: true, handler, is_proc_macro_crate, is_test_crate, }; if has_proc_macro_decls || is_proc_macro_crate { visit::walk_crate(&mut collect, &krate); } (collect.derives, collect.attr_macros, collect.bang_macros) </del> <ins> let mut collect = CollectProcMacros { macros: Vec::new(), in_root: true, handler, is_proc_macro_crate, is_test_crate, </ins> }; <ins> if has_proc_macro_decls || is_proc_macro_crate { visit::walk_crate(&mut collect, &krate); } // NOTE: If you change the order of macros in this vec // for any reason, you must also update 'raw_proc_macro' // in src/librustc_metadata/decoder.rs let macros = collect.macros; </ins> if !is_proc_macro_crate { return krate }

Related discussion:
text: The PR improved the situation about documenting proc macros. Thanks for that! However, I noticed a bug with it. I'm using . Running results in this: ! Looks like a simple typo or off-by-one or something like that bug. When using only and not s, everything looks good to me. CC
Oh, and also, running prints: Not sure if this warning is expected there. And not sure if related to this bug.
This is a consequence of the fact that has not yet been merged. Once it gets merged, and rust updates its Cargo submodule, this issue should go away.
It turns out that this issue was unrelated. I've opened a PR to fix it.
I see. Thanks for your work on this :)
Code change:
<ins> // edition:2021 // run-rustfix #![allow(dead_code)] async fn a() {} async fn foo() -> Result<(), i32> { a().await //~ ERROR mismatched types } fn main() {} </ins>

Related discussion:
text: This code: produces: Which is invalid. Looks like the span of the desugaring of uses only the part, instead of the span of the entire expression. This results in invalid suggestions when used by the code in .
I'm not entirely sure if this means that desugaring should use a bigger span, or if the suggestion diagnostic needs to be interpreted differently.
hmm.. is the only case where the desugared expr's span doesn't cover the whole piece of code it comes from? That doesn't sound right. If wonder if the expr should have the bigger span by default, and then async-specific code could grab the tighter span for diagnostics that need to point at the operator.
Some of the desugaring only uses the span, but the parts relevant for diagnostics like this do use the full span. Not sure if there's a problem there too.
I thought I might have accidentally introduced this bug in , but right after that PR was merged, the output was correct: So something changed in the last two months in what spans are used for await desugarings, it seems.
actually I think it was introduced in in , cc Do you need someone to fix this? I'm happy to put up a quick PR.
Yeah, looks like it: I just finished bisecting, which pointed at a rollup involving .
this was introduced in the PR linked earlier to try and improve other errors. It is tricky because reducing the span to only incurs these kind of bugs. On the other hand, the errors that got improved there became much less noisy, so I wouldn't want to revert the whole change. My fix above will solve this issue, but I'm sure there will be others in the future :-/
Code change:
use prelude::v1::*; use io::prelude::*; use io::{self, BufReader, BufWriter, LineWriter, SeekFrom}; <ins> use sync::atomic::{AtomicUsize, Ordering}; use thread; </ins> use test; /// A dummy reader intended at testing short-reads propagation.

Related discussion:
text: There is a panic safety issue in : after a call panics, the impl of calls again, which means the buffer contents are potentially written twice. This may cause an application to overwrite parts of a file that it did not mean to overwrite (in a DB engine written in Rust, this could cause unrecoverable data corruption!). Demonstration: The expected output of the demo program is , the actual output is: More generally, we need a story for panic safety in Rust. My takeaway from the related discussions (e.g. , , the trait) was that only code and impls should have to worry about panic safety. The demo app contains none of these, so I'd consider this a bug in . (otherwise all implementations would need to provide the strong exception safety guarantee?) Solution: could use temporarily mark the buffer as empty during the calls; so that the impl doesn't do anything after a panic. However, this doesn't help if the panic occurs during a call...
Note that Rust is normally referring to "memory safety" when talking about safety, so the issue here isn't in conflict with the related discussions. It's definitely a bug in , but I want to point out how specific it is here: the only reason you have odd behaviour is because you have a implementation that will panic after successfully writing the data it is given. I'm all for making more robust, but it's not just "if the call panics", it's "if the call panics after successfully writing data". Panicking before a successful write (or if the write fails), would not have the same issue.
If your impl is panicking in the middle of a write, it seems to me like you're in data corruption land with or without a second write. This is not quite the case - and thread locals expand that surface area. What's specifically the expected behavior here? Is the implementation specifically the thing that needs tweaking, or should the totally poison itself? For reference, Java's class has no special handling for exceptions thrown from the inner : , so adjusting alone seems like a reasonable route to take.
Without the , a panic in the middle of a write (without ) only corrupts the part of the file that the application meant to overwrite. In a DB engine context, that means the resulting corruption can be repaired when the transaction is rolled back.
Code change:
use prelude::v1::*; use io::prelude::*; use io::{self, BufReader, BufWriter, LineWriter, SeekFrom}; <ins> use sync::atomic::{AtomicUsize, Ordering}; use thread; </ins> use test; /// A dummy reader intended at testing short-reads propagation.

Related discussion:
text: But with , a panic after some data was written might corrupt parts of the file that are not saved in the rollback journal, so recovery not possible. I think we need some guideline like: If a method call panics, it's a bug to call any additional methods on the same object. Thus, the bug is in . may need something similar to a poison-flag so that the impl can detect whether a previous call panicked, but it doesn't need to protect against it's own methods being called after a panic (that would be considered a bug in the caller). The Java has the same problem, but the expectation in the Java world is different: it's trivially possible to catch an exception and continue using the potentially-invalid state; so in Java's case I would argue that all implementations should provide the strong exception safety guarantee to avoid this kind of issue. Essentially, the Rust world needs to decide between a Java/C++-style "strong exception safety guarantee" (=failing method call should not have any side effects) or a new "no-use-after-panic guarantee" (=after a failing method call, no additional method calls should occur). Some types (like BufWriter) can be compatible with at most one of the guarantees -- strong exception safety requires that a panicking call has no side effects; no-use-after-panic requires that a panicking call has the side effect of suppressing the buffer flush in the impl. The trait seems to be roughly equivalent to basic exception safety. Types that do not implement instead live in the world. Generic types implementing need to be careful not to call any functions on the type parameter from within the implementation if a previous call panicked (unless they use a bound).
triage: P-medium is fixing the data corruption in
Code change:
// this function uses `unwrap` copiously, because an already validated constant must have valid // fields and can thus never fail outside of compiler bugs <del> pub fn const_variant_index<'tcx>( </del> <ins> pub(crate) fn const_variant_index<'tcx>( </ins> tcx: TyCtxt<'tcx>, param_env: ty::ParamEnv<'tcx>, val: &'tcx ty::Const<'tcx>,

Related discussion:
text: Follow-up to agreed to move to . Generally I propose that should not contain code that is only needed by CTFE. We have and in there are they need some very deep access to Miri engine internals, but at least those are separate modules. Also, has grown pretty messy, and it does not seem like the order of definitions in that file follows any principle. We could split the file into two similar to what I did with Miri: for implementing the machine trait and defining everything that is needed during CTFE execution, and for defining the setup functions and all the glue that connects CTFE with the rest of the compiler.
Code change:
/// [`NonNull::dangling()`]: ptr::NonNull::dangling #[inline] #[stable(feature = "rust1", since = "1.0.0")] <del> pub unsafe fn from_raw_parts<'a, T>(data: *const T, len: usize) -> &'a [T] { debug_assert!(is_aligned_and_not_null(data), "attempt to create unaligned or null slice"); debug_assert!( mem::size_of::<T>().saturating_mul(len) <= isize::MAX as usize, "attempt to create slice covering at least half the address space" ); </del> <ins> #[rustc_const_unstable(feature = "const_slice_from_raw_parts", issue = "67456")] pub const unsafe fn from_raw_parts<'a, T>(data: *const T, len: usize) -> &'a [T] { debug_check_data_len(data, len); </ins> // SAFETY: the caller must uphold the safety contract for `from_raw_parts`. unsafe { &*ptr::slice_from_raw_parts(data, len) } }

Related discussion:
text: Currently,  is not , since it uses with a non- check: can't be made , since it involves ptr-int cast to check the alignment: Recently intrinsic , it allows to run different code in CTFE and runtime. This, in turn, allows us to only make the alignment check in runtime and ignore it in the CTFE where it doesn't make much sense. See also: cc and (it seems like use of requires approval of all of the above teams) label +T-lang +T-libs +A-const-eval +A-const-fn
Another approach to make const would be to disable the checks altogether, but since we already have , that seems unreasonable.
cc opinions before we escalate to lang and libs?
If a new intrinsic was in the spirit of and , this could possibly provide a solution without . Something like:
It seems useless to be able to perform any align checks in constants. The CTFE catches invalid pointer dereferences anyways.
Yes, but we also want to catch invalid pointer dereferences when we are not in CTFE, hence the idea of the function/intrinsic.
So why not use ?
It doesn't catch insufficiently aligned pointers though.
Code change:
.span_to_snippet(self.prev_span) .map(|s| s.ends_with(")") || s.ends_with("]")) .unwrap_or(false); <del> let right_brace_span = if has_close_delim { // it's safe to peel off one character only when it has the close delim self.prev_span.with_lo(self.prev_span.hi() - BytePos(1)) } else { self.prev_span.shrink_to_hi() }; self.struct_span_err( </del> <ins> let mut err = self.struct_span_err( </ins> self.prev_span, "macros that expand to items must be delimited with braces or followed by a semicolon", <del> ) .multipart_suggestion( "change the delimiters to curly braces", vec![ (self.prev_span.with_hi(self.prev_span.lo() + BytePos(1)), "{".to_string()), (right_brace_span, '}'.to_string()), ], Applicability::MaybeIncorrect, ) .span_suggestion( </del> <ins> ); // To avoid ICE, we shouldn't emit actual suggestions when it hasn't closing delims if has_close_delim { err.multipart_suggestion( "change the delimiters to curly braces", vec![ (self.prev_span.with_hi(self.prev_span.lo() + BytePos(1)), '{'.to_string()), (self.prev_span.with_lo(self.prev_span.hi() - BytePos(1)), '}'.to_string()), ], Applicability::MaybeIncorrect, ); } else { err.span_suggestion( self.prev_span, "change the delimiters to curly braces", " { /* items */ }".to_string(), Applicability::HasPlaceholders, ); } err.span_suggestion( </ins> self.prev_span.shrink_to_hi(), "add a semicolon", ';'.to_string(),

Related discussion:
text: I'm seeing an internal compiler error on the following input (found by ): My compiler version is: I also observe the error on , but not on .
Code change:
/// /// assert_eq!(n.leading_zeros(), 0); /// ``` <ins> #[doc = concat!("[`ilog2`]: ", stringify!($SelfT), "::ilog2")] </ins> #[stable(feature = "rust1", since = "1.0.0")] #[rustc_const_stable(feature = "const_int_methods", since = "1.32.0")] #[must_use = "this returns the result of the operation, 

Related discussion:
text: I was chatting with today, who mentioned it'd be helpful to mention the newly stabilized APIs from the docs. The benefit of using is that even if the type widens, the result doesn't change. It'd be nice if someone could contribute docs mentioning from . This probably just needs to be a one-liner. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim