jiebi/CodeConvo huggingface dataset:
Code change:
When calling in a fn that expects we currently emit: We should check whether and suggest the removal of the call. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
feel free to reach out either on this ticket or on a PR, but be warned that this has the potential to be quite involved. It is a great introduction to how some parts of fit together though.
I've been looking into this for a while now, and my idea was to: Check if there a .into() call, check if the type of self was T and finally check if the argument of the function was Into<T. However I cannot figure how to get the type of Self. As far as my understanding goes, rustc hasn't yet inferred the type.
You can query the in-progress type table with the for the expression. You're gonna have an with a . From the first argument in that variant you can take the first element and get the expression for in . Then you can use the for that expression to do I do not know if we will have populated 's type by then, but if we have, then that will give you the type of . Then, if you're in an you can use to see if the inferred type for can be coerced to in the original example. I know this is a bit vague, but for this is inherently exploratory work :)
Hi, are you still working on this issue
No, feel free to claim it if you want
release-assignment

Related discussion:
text: <ins> error[E0283]: type annotations needed --> $DIR/argument-with-unnecessary-method-call.rs:8:13 | LL |     qux(Bar.into()); |     ---     ^^^^ |     | |     required by a bound introduced by this call | = note: cannot satisfy `_: From<Bar>` note: required by a bound in `qux` --> $DIR/argument-with-unnecessary-method-call.rs:6:16 | LL | fn qux(_: impl From<Bar>) {} |                ^^^^^^^^^ required by this bound in `qux` help: try using a fully qualified path to specify the expected types | LL |     qux(<Bar as Into<T>>::into(Bar)); |         +++++++++++++++++++++++   ~ help: consider removing this method call, as the receiver has type `Bar` and `Bar: From<Bar>` trivially holds | LL -     qux(Bar.into()); LL +     qux(Bar); | error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0283`. </ins>
Code change:
This is a variant of that was not fixed by still fails with
Given that libcore and liballoc enable this feature, I am rather concerned they could inadvertently use it in a way that is still unsound. Also, unless we can fix this, the feature should probably be to to warn people against using it.
rustc bootstraps successfully with applied, so at least right now that does not seem to be the case (modulo the part of libstd that rustc never monomorphizes). Of course, that could change any time, there is no check for this.
Yes, thanks for opening this. To be specific, the issue here is centered on this line: and the fact that we have , and LLVM alloca's don't respect the alignment requirements, right? I think there may be a separate issue on that. (Link?) But: one thing we had discussed was separating out the "sound" part and the "unsound" part into distinct feature gates, so that we can enable only the former in libstd. Perhaps that's a good focus for this issue?
cc who had discussed the separate feature gate, and who might be interested in doing the follow-up work to create that gate.
Yes. Oh, I didn't know that. Let's see if someone finds it.^^ Unlike the other unsound features, this is one where we don't even have a plan for how to soundly implement it. Not sure how much I like keeping that around.
Yes, I see that argument. I'm reminded of , which limits the max alignment to 4K because of limits in dynamic linkers, though there's no real connection. It's just that part of the challenge here is that the alignment of a is totally unknown -- it's not like we can conservatively align to 64 bytes or something.
If lands we could conservatively align to 4k here. :rofl: (no I am not serious)
Assigning as , removing and nominating for discussion on our next weekly meeting.
Can't we do something dynamic where we allocate and align it ourselves? Also, this has been discussed before, hasn't it?
With being stable, this can be observed in stable compiler: EDIT: its fixed in nightly, never mind.
I don't know -- in we mostly talked about how to mitigate the effect on stable Rust. D'oh, I somehow forgot that one can manually implement "aligned" allocation on top of an unaligned allocator. Of course that would work. That's probably better than killing this part of codegen entirely.^^
, leaving the nomination up for now as requested by He wants to open some fresh issues about this.
Now that I've created more specific issues to track the important sub-tasks identified here, I think we can remove this from the nominated tickets.
Given that this feature has been removed from core/alloc and is unstable, I'm going to downgrade this to P-medium. This should obviously block stabilization of , but doesn't need special attention outside of that.

Related discussion:
text: indirect_dest: PlaceRef<'tcx, V>, ) { debug!("OperandRef::store_unsized: operand={:?}, indirect_dest={:?}", self, indirect_dest); <del> let flags = MemFlags::empty(); </del> // `indirect_dest` must have `*mut T` type. We extract `T` out of it. let unsized_ty = indirect_dest .layout
Code change:
A small demo: . I expected to see this happen The usual error message indicating that patterns and are not covered. Instead, this happened Patterns and are detected as not covered. :
If you add the suggested arms, it will in fact detect the other ones as missing. It is expected that is detected as not covered since the match guard is not taken into account when checking exhaustiveness (and couldn't be, since it's an arbitrary expression).
Closing as expected behavior.
Wouldn't you then expect that it mentions , , , and as not covered? Or is the number of outputs always restricted to two? In that case, I think it would be useful to indicate that some patterns might be missing, e.g.:
Yeah that's true

Related discussion:
text: <ins> #[derive(PartialEq, Eq)] enum X { A, B, C, } fn main() { let x = X::A; let y = Some(X::A); match (x, y) { //~^ ERROR non-exhaustive patterns: `(A, Some(A))`, `(A, Some(B))`, `(B, Some(B))` and 2 //~| more not covered (_, None) => false, (v, Some(w)) if v == w => true, (X::B, Some(X::C)) => false, (X::B, Some(X::A)) => false, (X::A, Some(X::C)) | (X::C, Some(X::A)) => false, }; } </ins>
Code change:
A small demo: . I expected to see this happen The usual error message indicating that patterns and are not covered. Instead, this happened Patterns and are detected as not covered. :
If you add the suggested arms, it will in fact detect the other ones as missing. It is expected that is detected as not covered since the match guard is not taken into account when checking exhaustiveness (and couldn't be, since it's an arbitrary expression).
Closing as expected behavior.
Wouldn't you then expect that it mentions , , , and as not covered? Or is the number of outputs always restricted to two? In that case, I think it would be useful to indicate that some patterns might be missing, e.g.:
Yeah that's true

Related discussion:
text: <ins> error[E0004]: non-exhaustive patterns: `(A, Some(A))`, `(A, Some(B))`, `(B, Some(B))` and 2 more not covered --> $DIR/issue-72377.rs:8:11 | LL |     match (x, y) { |           ^^^^^^ patterns `(A, Some(A))`, `(A, Some(B))`, `(B, Some(B))` and 2 more not covered | = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms = note: the matched value is of type `(X, Option<X>)` error: aborting due to previous error For more information about this error, try `rustc --explain E0004`. </ins>
Code change:
I've been playing around with today, and it comes in super handy in blocks. However, it seems to run into issues when combined with the feature. I tried this code: I expected to see this happen: the code should compile just fine. Instead, this happened: This is a continuation of the discussion . As , this code (following the from the label-break-value RFC) compiles: : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
So the error is generated here if I had to guess, I would assume that this function ought to be modified to check whether the and, if so, not to emit the error. (See  rust docs for a bit more info.)
Tagged as E-mentor since there are some instructions above.
claim

Related discussion:
text: use rustc_middle::ty::query::Providers; use rustc_middle::ty::TyCtxt; use rustc_session::Session; <ins> use rustc_span::hygiene::DesugaringKind; </ins> use rustc_span::Span; #[derive(Clone, Copy, Debug, PartialEq)]
Code change:
I've been playing around with today, and it comes in super handy in blocks. However, it seems to run into issues when combined with the feature. I tried this code: I expected to see this happen: the code should compile just fine. Instead, this happened: This is a continuation of the discussion . As , this code (following the from the label-break-value RFC) compiles: : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
So the error is generated here if I had to guess, I would assume that this function ought to be modified to check whether the and, if so, not to emit the error. (See  rust docs for a bit more info.)
Tagged as E-mentor since there are some instructions above.
claim

Related discussion:
text: label: &Destination, cf_type: &str, ) -> bool { <del> if self.cx == LabeledBlock { </del> <ins> if !span.is_desugaring(DesugaringKind::QuestionMark) && self.cx == LabeledBlock { </ins> if label.label.is_none() { struct_span_err!( self.sess,
Code change:
I've been playing around with today, and it comes in super handy in blocks. However, it seems to run into issues when combined with the feature. I tried this code: I expected to see this happen: the code should compile just fine. Instead, this happened: This is a continuation of the discussion . As , this code (following the from the label-break-value RFC) compiles: : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
So the error is generated here if I had to guess, I would assume that this function ought to be modified to check whether the and, if so, not to emit the error. (See  rust docs for a bit more info.)
Tagged as E-mentor since there are some instructions above.
claim

Related discussion:
text: <ins> // compile-flags: --edition 2018 #![feature(label_break_value, try_blocks)] // run-pass fn main() { let _: Result<(), ()> = try { 'foo: { Err(())?; break 'foo; } }; } </ins>
Code change:
The following code: gives the following output: The "unused lifetimes" warning is redundant - not using a lifetime parameter is a hard error, so the warning gives no additional information.
Note that this lint still makes sense for functions: But then running clippy on the following looks dumb (the lints are redundant): I don't really know the compiler internals, but should this lint just skip structs ? (is that even possible ?)
label +E-needs-test This was fixed in but no test was for nonduplication.

Related discussion:
text: <ins> // Check that `unused_lifetimes` lint doesn't duplicate a "parameter is never used" error. // Fixed in <https://github.com/rust-lang/rust/pull/96833>. // Issue: <https://github.com/rust-lang/rust/issues/72587>. #![warn(unused_lifetimes)] struct Foo<'a>; //~^ ERROR parameter `'a` is never used fn main() {} </ins>
Code change:
The following code: gives the following output: The "unused lifetimes" warning is redundant - not using a lifetime parameter is a hard error, so the warning gives no additional information.
Note that this lint still makes sense for functions: But then running clippy on the following looks dumb (the lints are redundant): I don't really know the compiler internals, but should this lint just skip structs ? (is that even possible ?)
label +E-needs-test This was fixed in but no test was for nonduplication.

Related discussion:
text: <ins> error[E0392]: lifetime parameter `'a` is never used --> $DIR/dedup.rs:6:12 | LL | struct Foo<'a>; |            ^^ unused lifetime parameter | = help: consider removing `'a`, referring to it in a field, or using a marker such as `PhantomData` error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0392`. </ins>
Code change:
I just tried the latest nightly (rustc 1.45.0-nightly ( 2020-06-01)) and noticed it can't compile one of the crates I work on. The crate does have an enum with a a huge number of variants (almost 6000), for which I use serde to derive Serialize and Deserialize. When building, even with just 'cargo check', the build fails with It works on stable 1.43.1. I tried running rustc under gdb. It didn't crash exactly the same way, I got SIGSEGV instead. Looking at the callstack in gdb, it is suspiciously deep ( functions deep). The top most functions are: If I reduce the number of enum variants to 5000, or stop using serde to derive Serialize/Deserialize, it starts working again. Since it works using stable, but not using nightly, I thought it might be some kind of regression. I totally realize this may not be a bug and that what I'm doing (Serde + giant enum) is just not a good idea. Accept my apologies if this kind of thing shouldn't be reported here!
cc -- I believe should have fixed this but I guess we're missing at least this case?
As an experiment I tried doubling the number of enum variants and compiling using stable. That still worked. So it seems the code wasn't just on the brink to stop working using the stable compiler.
Here is a github repo with a minimized test case for this issue:
It introduced a mechanism for dealing with this kind of issue, but I don’t doubt that we might have missed instances where the compiler is doing something recursive. MIR construction for matches appears to be one of these cases.
Yeah, that's what I expected, I just recalled seeing some commentary suggesting that we'd perhaps covered all cases. Definitely not unexpected that we didn't, though, nor did I intend to imply we should have :)
The beta seems to not have the problem. The problem does not occur with "rustc 1.44.0-beta.4 ( 2020-05-23)".
I saw the 'E-needs-mcve'-tag. Did you see my repro-case? (but maybe you're talking about something more self-contained, not referencing 'serde'?)
I saw the repo, but it still needs some work to be reduced to a viable regression test case that could be included into the repo along with fix. This is what I’m working on now as I already have the fix itself.
Assigning .
If anyone else gets here having the same problem, manually implementing Serialize and Deserialize rather than relying on serde-derive, is one way around the problem. I adapted the examples at for my enum and this made the compile time insignificant. It also improved performance using the old rust considerably.
Mhh, I remember having seen some other issues related to derive macros recently... cc who might know.

Related discussion:
text: use crate::build::{BlockAnd, BlockAndExtension, Builder}; use crate::build::{GuardFrame, GuardFrameLocal, LocalsForNode}; use crate::hair::{self, *}; <del> use rustc_data_structures::fx::{FxHashMap, FxHashSet}; </del> <ins> use rustc_data_structures::{fx::{FxHashMap, FxHashSet}, stack::ensure_sufficient_stack}; </ins> use rustc_hir::HirId; use rustc_index::bit_set::BitSet; use rustc_middle::middle::region;
Code change:
<!-- 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</detailsThis is a recent regression, since we run this command every day in automation.
Almost certainly a regression from /cc
looks like a duplicate of

Related discussion:
text: // As write_sub_paths, but does not process the last ident in the path (assuming it // will be processed elsewhere). See note on write_sub_paths about global. fn write_sub_paths_truncated(&mut self, path: &'tcx hir::Path<'tcx>) { <del> for seg in &path.segments[..path.segments.len() - 1] { if let Some(data) = self.save_ctxt.get_path_segment_data(seg) { self.dumper.dump_ref(data); </del> <ins> if let [segments @ .., _] = path.segments { for seg in segments { if let Some(data) = self.save_ctxt.get_path_segment_data(seg) { self.dumper.dump_ref(data); } </ins> } } }
Code change:
<!-- 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</detailsThis is a recent regression, since we run this command every day in automation.
Almost certainly a regression from /cc
looks like a duplicate of

Related discussion:
text: } } } <del> hir::ExprKind::Struct(hir::QPath::Resolved(_, path), ..) => { </del> <ins> hir::ExprKind::Struct(qpath, ..) => { let segment = match qpath { hir::QPath::Resolved(_, path) => path.segments.last().unwrap(), hir::QPath::TypeRelative(_, segment) => segment, }; </ins> match self.tables.expr_ty_adjusted(&hir_node).kind { ty::Adt(def, _) if !def.is_enum() => { <del> let sub_span = path.segments.last().unwrap().ident.span; </del> <ins> let sub_span = segment.ident.span; </ins> filter!(self.span_utils, sub_span); let span = self.span_from_span(sub_span); Some(Data::RefData(Ref {
Code change:
<!-- 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</detailsThis is a recent regression, since we run this command every day in automation.
Almost certainly a regression from /cc
looks like a duplicate of

Related discussion:
text: } _ => { // FIXME <del> bug!(); </del> <ins> bug!("invalid expression: {:?}", expr); </ins> } } }
Code change:
<!-- 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</detailsThis is a recent regression, since we run this command every day in automation.
Almost certainly a regression from /cc
looks like a duplicate of

Related discussion:
text: <ins> // compile-flags: -Zsave-analysis use {self}; //~ ERROR E0431 fn main () { } </ins>
Code change:
<!-- 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</detailsThis is a recent regression, since we run this command every day in automation.
Almost certainly a regression from /cc
looks like a duplicate of

Related discussion:
text: <ins> error[E0431]: `self` import can only appear in an import list with a non-empty prefix --> $DIR/issue-73020.rs:2:6 | LL | use {self}; |      ^^^^ can only appear in an import list with a non-empty prefix error: aborting due to previous error For more information about this error, try `rustc --explain E0431`. </ins>
Code change:
<!-- 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</detailsThis is a recent regression, since we run this command every day in automation.
Almost certainly a regression from /cc
looks like a duplicate of

Related discussion:
text: <ins> // build-pass // compile-flags: -Zsave-analysis enum Enum2 { Variant8 { _field: bool }, } impl Enum2 { fn new_variant8() -> Enum2 { Self::Variant8 { _field: true } } } fn main() {} </ins>
Code change:
I'm currently doing some benchmarks and I've seen that is taking a really long time to calculate on wasm. Turns out that none of the helper functions it uses are inlined at all, so it does a ton of unnecessary calls and misses a lot of potential optimizations: The same is probably true for the Float trait.
It seems like initially had a lot more inline annotations but removed them later on. That may have regressed the performance on wasm, but I'm not entirely sure. This makes me wonder if compiler-builtins is even compiled with LTO at all as it supposedly is meant to be?!
Looks like this is indeed a regression that started with Rust 1.44, which switched from compiler-builtins 0.1.25 to 0.1.27, which is where this PR is part of. These are the instructions in 1.43: cc
There's been a few various changes around codegen units handling and compiler-builtins recently, and it looks like this is caused by compiling this crate with . The compiler but with only one CGU.
Ok I've transferred this to the rust-lang/rust repository since this isn't a bug with compiler-builtins itself I believe but rather how we build compiler-builtins. I believe this is an accidental regression from because only part of the compiler knows that compiler-builtins is built with more than one CGU, the rest of the compiler thinks it's one CGU (respecting CLI flags). I'll be opening a PR shortly to fix this.
Assigning as and removing .

Related discussion:
text: debug = false debug-assertions = false <ins> [profile.release.package.compiler_builtins] # For compiler-builtins we always use a high number of codegen units. # The goal here is to place every single intrinsic into its own object # file to avoid symbol clashes with the system libgcc if possible. Note # that this number doesn't actually produce this many object files, we # just don't create more than this number of object files. # # It's a bit of a bummer that we have to pass this here, unfortunately. # Ideally this would be specified through an env var to Cargo so Cargo # knows how many CGUs are for this specific crate, but for now # per-crate configuration isn't specifiable in the environment. codegen-units = 10000 </ins> # We want the RLS to use the version of Cargo that we've got vendored in this # repository to ensure that the same exact version of Cargo is used by both the # RLS and the Cargo binary itself. The RLS depends on Cargo as a git repository