jiebi/CodeConvo huggingface dataset:
Code change:
/// When `is_collectin_in_band_lifetimes` is true, each lifetime is checked /// against this list to see if it is already in-scope, or if a definition /// needs to be created for it. <del> in_scope_lifetimes: Vec<Ident>, </del> <ins> /// /// We always store a `modern()` version of the param-name in this /// vector. in_scope_lifetimes: Vec<ParamName>, </ins> current_module: NodeId,

Related discussion:
text: The diagnostics ("use of undeclared lifetime name") are bad, but this indeed must be an error because the inner is an illegal use of the outer rather than an implicitly defined fresh lifetime.
Hm, I don't think that's quite what I'd expect: previously using in that context would be fine because there is no shadowing so to speak, that is, this compiles:
From Similarly, if a fn definition is nested inside another fn definition, it is an error to mention lifetimes from that outer definition (without binding them explicitly). This is again intended for future-proofing and clarity, and is an edge case. (In the second example there's an explicit definition that shadows the previous definition for following uses, in the first example there's no second definition, only use)
I see that this is in the RFC, but I think I more or less disagree with the reasoning given. Disallowing the use of inband lifetimes when nesting function seems arbitrary and not entirely helpful; it also makes a mechanical change from "old" to "new" more difficult because shadowing is visible only based on indent levels.
IMO it should be an error, with a helpful note like the one you get when writing . Let's not make in-band lifetimes any more confusing than they already are.
The distinction is that inband lifetime's selling point is that you don't need to declare lifetimes. If we say that, and then clarify it with "except" then I think the feature feels incomplete. Inband lifetimes confusion does not increase with permitting this, IMO.
The problem is if it's allowed, then has a different meaning than This seems unfortunate and confusing. Even unergonomic if I may say so. There's no way that the distinction between and won't be missed in a quick scan of the second one. But, like, the RFC process did decide that isn't important, so whatever.
Well, somewhat, but not really. Nothing outside of imports/definitions inherits into the inner function, unlike the impl where there is a history and multiple things which inherit (, lifetimes, generics).
Code change:
<ins> error: constant evaluation is taking a long time --> $DIR/do-not-ice-on-field-access-of-err-type.rs:5:24 | LL |     let array = [(); { loop {} }]; |                        ^^^^^^^ | = note: this lint makes sure the compiler doesn't get stuck due to infinite loops in const eval. If your compilation actually takes a long time, you can safely allow the lint. help: the constant being evaluated --> $DIR/do-not-ice-on-field-access-of-err-type.rs:5:22 | LL |     let array = [(); { loop {} }]; |                      ^^^^^^^^^^^ = note: `#[deny(long_running_const_eval)]` on by default error: aborting due to 1 previous error </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'error: internal compiler error: named field access on non-ADT', 'error: internal compiler error: named field access on non-ADT' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: 22 | let buf: &mut [*const dyn Foo] = &mut [&u8, &u8.0, &u32, &u32.0]; [livesymbolsandignoredderivedtraits] finding live symbols in crate [checkmod_deathness] checking deathness of variables in top-level module [analysis] running analysis passes on this crate --
mmh this bisects to cc
Code change:
if self.not_enough_args_provided() { self.suggest_adding_args(err); } else if self.too_many_args_provided() { <ins> self.suggest_moving_args_from_assoc_fn_to_trait(err); </ins> self.suggest_removing_args_or_generics(err); } else { unreachable!();

Related discussion:
text: <!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: When a user called with an annotation, it's helpful to suggest too. <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
If it's ok, I would like to give a shot. If you plan to work on it, please go ahead.
It's yours :)
claim
Hi, I would like to ask a question... I'm reading the code now and am thinking of extending the error messages by adding to . My plan is that start adding some fields (like ty::TraitRef) to and dbg! the output to get the value of trait information like for a new error message. Is my approach out of line or is there a better approach for that.
You don't have to hold information of in because we can get the info on-demand by the combination of and . Say you'd add a method of , the code will be something like this: For getting the name of the trait in question, or will be handy for you.
I appreciate your answer.
are you still working on this? :)
Code change:
Some(Node::Item(it)) => item_scope_tag(&it), Some(Node::TraitItem(it)) => trait_item_scope_tag(&it), Some(Node::ImplItem(it)) => impl_item_scope_tag(&it), <ins> Some(Node::ForeignItem(it)) => foreign_item_scope_tag(&it), </ins> _ => unreachable!(), }; let (prefix, span) = match *region {

Related discussion:
text: Repro: As of current nightly: This is the unreachable line: The same crash reproduces back to 1.47.0. Older stable compilers do not crash:
Bisect: searched nightlies: from nightly-2020-07-10 to nightly-2020-08-27 regressed nightly: nightly-2020-07-22 searched commits: from to regressed commit: () Mentioning because appears the most relevant.
Assigning .
Code change:
] [[package]] <ins> name = "compiletest_rs" version = "0.5.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "9f737835bfbbe29ed1ff82d5137520338d7ed5bf1a1d4b9c1c7c58bb45b8fa29" dependencies = [ "diff", "filetime", "getopts", "libc", "log", "miow 0.3.3", "regex", "rustfix 0.5.0", "serde", "serde_derive", "serde_json", "tempfile", "tester", "winapi 0.3.8", ] [[package]] </ins> name = "constant_time_eq" version = "0.1.3" source = "registry+https://github.com/rust-lang/crates.io-index"

Related discussion:
text: Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! And nominating for compiler team prioritization.
Code change:
<ins> error[E0382]: use of moved value: `x` --> $DIR/missing-clone-for-suggestion.rs:17:7 | LL | fn f(x: *mut u8) { |      - move occurs because `x` has type `*mut u8`, which does not implement the `Copy` trait LL |     g(x); |       - value moved here LL |     g(x); |       ^ value used here after move | note: consider changing this parameter type in function `g` to borrow instead if owning the value isn't necessary --> $DIR/missing-clone-for-suggestion.rs:13:12 | LL | fn g<T>(x: T) {} |    -       ^ this parameter takes ownership of the value |    | |    in this function error: aborting due to previous error For more information about this error, try `rustc --explain E0382`. </ins>

Related discussion:
text: <!-- 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. --: : &lt;!-- Include a backtrace in the code block by setting in your environment. E.g. . --&lt;details&lt;summary&lt;strongBacktrace&lt;/strong&lt;/summary&lt;p&lt;/p&lt;/details&lt;!-- TRIAGEBOTSTART --&lt;!-- TRIAGEBOTASSIGNSTART --&lt;!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --&lt;!-- TRIAGEBOTASSIGNEND --&lt;!-- TRIAGEBOTEND --
The real error isn't the unemitted diagnostic, it's the unwrap. The unemitted diagnostic only happens bc this unwrap occurs during diagnostics code, I think.
cc I think this might be and we try to suggest .clone() which is not available for the type though?
If you add ... to the example you no longer ICE and just hit the normalerror[E0382]: use of moved value: 'x' `
claim
Please use this minimized repro:

Every time I think "surely this will be fine", it bites me in the read as sure as the sun coming up.
Are we fixing ICEs? Not so sure we should bother...
This one was particularly easy to fix () and probably shouldn't've have been an in the first place (unwraps in diagnostics code are generally a code smell, since they should fail gracefully in strange situations) -- but I generally agree, had this fix required some large refactoring or implemented extra checks on a performance-sensitive path, then I think this should've been closed w/ a wontfix.
Code change:
// to them. We run some optimizations before that, because they may be harder to do on the state // machine than on MIR with async primitives. let optimizations_with_generators: &[&dyn MirPass<'tcx>] = &[ <ins> &reveal_all::RevealAll, // has to be done before inlining, since inlined code is in RevealAll mode. </ins> &lower_slice_len::LowerSliceLenCalls, // has to be done before inlining, otherwise actual call will be almost always inlined. Also simple, so can just do first &normalize_array_len::NormalizeArrayLen, // has to run after `slice::len` lowering &unreachable_prop::UnreachablePropagation,

Related discussion:
text: Previously: Now: <!-- 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
Inlining exposes a use of unnormalized local in a call terminator (not sure if this is more of an issue with inlining or a validator): Note: revision annotation doesn't work in an auxiliary file (so it isn't tested on CI with mir-opt-level=2). modify labels: +A-mir-opt-inlining
This ICEs again because the fix was reverted Can someone reopen please?
Due to this new requires to trigger. <details<summaryICE:</summary</details
(FWIW can also trigger this: )
fixes this for and , but it still ICEs with on its own or with mir-opt-level 1/2 cc
Code change:
<ins> #[derive(Clone)] pub struct Struct<A>(A); impl<A> Struct<A> { pub fn new() -> Self { todo!() } } </ins>

Related discussion:
text: I tried code very similar to this: and it produces some type of type checking error when uncommenting the line beginning with . : Backtrace:
The error is likely due to the fact that the trait bounds on don't include for , though the compiler/type checker crashing is still likely a bug.
That code was introduced in , cc Submitted as a quick fix.
I can't get it to work in the same crate, just with two crates, where the first one depends on the other: modify labels: -E-needs-mcve
Thanks I included a test in the PR.
Code change:
arg.cast_to(Reg { kind: RegKind::Integer, size }); } }; <del> fixup(&mut self.ret); </del> <ins> fixup(&mut self.ret, true); </ins> for arg in &mut self.args { <del> fixup(arg); </del> <ins> fixup(arg, false); </ins> } if let PassMode::Indirect(ref mut attrs, _) = self.ret.mode { attrs.set(ArgAttribute::StructRet);

Related discussion:
text: Rust should pass more structs in registers. Consider these examples: ideally, both functions would execute entirely in registers and wouldn't touch memory: Rust, as of a recent 1.2.0-dev nightly, is unable to pass either of these in registers (see LLVM IR and ASM below). It would be pretty safe to pass and return small structs (ones that fit into <=2 registers) in registers, and is likely to improve performance on average. This is what the System V ABI does. It would also be nice to exploit Rust's control over aliasing, and where possible also promote reference arguments to registers, i.e. put the values in registers for the following functions: In the case, this would mean passing two values in registers as function parameters, and returning two values in registers as the return values (ideally we'd arrange for the parameter registers to match the return registers). Uniqueness of makes this optimization valid, although we may have to give up on this optimization in cases such as when there are raw pointers present. Here's a more realistic example where I've wanted Rust to do this: This function is too large to justify inlining. I'd like the begin and end pointers of to be kept in registers across the function call. Probably not surprising to the compiler team, but for completeness here is the LLVM IR of the above snippets, as of today's Rust (1.2.0-dev), compiled in release mode / opt-level=3: and here is the ASM:
For fat pointers this has been fixed in Am 22.06.2015 07:58 schrieb "Reiner Pope"
On etc. this is currently impossible because the address of references is significant (you can e.g. print it with ).
- yes, the ability to take addresses prevents doing this for all functions. But you could see doing this as an optimization: make the compiler check whether a function uses the address of a reference, and if not then change its calling convention. The compiler can use the worker/wrapper technique (as in GHC) to support call sites which aren't aware of this change in calling convention, by splitting the function into two:
Don't do this. You will break FastISel. Fix LLVM if it's not doing the optimizations you want.
what exactly would break FastISel?
Code change:
arg.cast_to(Reg { kind: RegKind::Integer, size }); } }; <del> fixup(&mut self.ret); </del> <ins> fixup(&mut self.ret, true); </ins> for arg in &mut self.args { <del> fixup(arg); </del> <ins> fixup(arg, false); </ins> } if let PassMode::Indirect(ref mut attrs, _) = self.ret.mode { attrs.set(ArgAttribute::StructRet);

Related discussion:
text: Pretty sure that since work on niche-filling optimisation, and use a pair of registers for the argument and the return value, respectively. Cc
didn't solve this?
Yes, this appears to be fixed. The following Rust code (): generates and
Ah no, I see that this issue also suggests: We don't do that yet: . FWIW Maybe it is worth to split this issue into two. One part has been closed already AFAICT. The other part (passing as a register containing a ) is... a suggestion at most. This issue does not suggest how to do this. already raised the issue that this breaks if the address is inspected. It probably needs to handle writes through (e.g. due to ) and somehow as well, etc. So I'm skeptic that this can work.
Here's another slightly more complex example, where ABI seems to be more efficient than :
A related thread:
is this fixed? Linked code is still bigger on Rust 1.48.
my example is fixed, the return value is no longer via stack: The difference is that rust abi version now uses a vectorized add, which seems like a win?
Hi all. I've traced back the cause of 'P-high' issue to two pulls that relate to this issue, namely and . Basically, these commits break auto-vectorization post Rust version 1.48 in a way that is not easily worked around. In short, if we take: 47 yields an efficient: 48 yields an awkward: 50 yields an even more awkward cascade effect: There are other examples in . My overly simplistic analysis, I'm no expert, is . In summary, if I rebuild Rust with the above pulls neutered, auto-vectorization appears to return to normal, as per 1.47.
Code change:
<ins> error[E0283]: type annotations needed: cannot satisfy `&(): Marker` --> $DIR/overlap-marker-trait-with-underscore-lifetime.rs:6:6 | LL | impl Marker for &'_ () {} |      ^^^^^^ | note: multiple `impl`s satisfying `&(): Marker` found --> $DIR/overlap-marker-trait-with-underscore-lifetime.rs:6:1 | LL | impl Marker for &'_ () {} | ^^^^^^^^^^^^^^^^^^^^^^ LL | impl Marker for &'_ () {} | ^^^^^^^^^^^^^^^^^^^^^^ error[E0283]: type annotations needed: cannot satisfy `&(): Marker` --> $DIR/overlap-marker-trait-with-underscore-lifetime.rs:7:6 | LL | impl Marker for &'_ () {} |      ^^^^^^ | note: multiple `impl`s satisfying `&(): Marker` found --> $DIR/overlap-marker-trait-with-underscore-lifetime.rs:6:1 | LL | impl Marker for &'_ () {} | ^^^^^^^^^^^^^^^^^^^^^^ LL | impl Marker for &'_ () {} | ^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0283`. </ins>

Related discussion:
text: Not sure if we have a test for the following and rust #![feature(markertraitattr)] #[marker] trait Marker {} impl Marker for &' () {} impl Marker for &' () {} If not, we need to add them, since they would be important for special casing during canonicalization. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I can help add this test if needed. (Did not rustbot claim so as to not remove lcnr from assignee)
Sure :) would help out if nothing else
assign Rageking8
Error: Parsing assign command in failed: ...' Rageking8' ''... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
assign
label +F-markertraitattr In case this needs to be indexed in the future.
Code change:
<ins> error[E0596]: cannot borrow field of immutable binding as mutable --> $DIR/issue-52240.rs:9:27 | LL |     if let (Some(Foo::Bar(ref mut val)), _) = (&arr.get(0), 0) { |                           ^^^^^^^^^^^ cannot mutably borrow field of immutable binding error: aborting due to previous error For more information about this error, try `rustc --explain E0596`. </ins>

Related discussion:
text: I expected just a compiler error . Compiler panicked: Meta
This is fixed in the beta version (1.30).
Code change:
<ins> error[E0596]: cannot borrow field of immutable binding as mutable --> $DIR/issue-52240.rs:9:27 | LL |     if let (Some(Foo::Bar(ref mut val)), _) = (&arr.get(0), 0) { |                           ^^^^^^^^^^^ cannot mutably borrow field of immutable binding error: aborting due to previous error For more information about this error, try `rustc --explain E0596`. </ins>

Related discussion:
text: This lets you get a mutable reference to an immutable value under a specific case. Code: From what I can tell, the tuple and at least two depths of Enums are necessary, along with an on the right side. There's probably other variations, but that seems to work well enough. Expected output would be a compile error, instead output is This works on both stable and nightly
would fix this as well?
Fixed by . Off: I wonder why we can't ship nll yet. It would solve so many issues right now, because of the match ergonomics sigh Match ergonomics produces roughly 10% of all errors/unsoundness/ICEs atm (at least it feels like this)
Yes correctly fixed this issue.
Code change:
/// Whether the `def_id` is an unstable const fn and what feature gate is necessary to enable it pub fn is_unstable_const_fn(self, def_id: DefId) -> Option<Symbol> { <del> if self.is_constructor(def_id) { Some(sym::const_constructor) } else if self.is_const_fn_raw(def_id) { </del> <ins> if self.is_const_fn_raw(def_id) { </ins> self.lookup_stability(def_id)?.const_stability } else { None

Related discussion:
text: The feature allows calling any expression of a tuple-like constructor in a : cc
Implemented on 2019-06-07 by in which was reviewed by
Is there anything else needs to be done to resolve this issue?
FCP and stabilization pull request.
Do you think you have time to write a report (e.g. in the style of ) and amend the reference after?
I propose that we stabilize . Tracking issue: Version target: 1.40 (2019-11-05 =beta, 2019-12-19 =stable). Tuple struct and tuple variant constructors are now considered to be constant functions. As such a call expression where the callee has a tuple struct or variant constructor "function item" type can be called : Consistency with other . This should also ensure that constructors implement traits and can be coerced to function pointers, if they are introduced. - Tests various syntactic forms, use in both and items, and constructors in both the current and extern crates. The case in should also get a test.
Thanks! Could you embed this report in a PR with the aforementioned test there as well? I'll FCP that PR.
Code change:
/// Whether the `def_id` is an unstable const fn and what feature gate is necessary to enable it pub fn is_unstable_const_fn(self, def_id: DefId) -> Option<Symbol> { <del> if self.is_constructor(def_id) { Some(sym::const_constructor) } else if self.is_const_fn_raw(def_id) { </del> <ins> if self.is_const_fn_raw(def_id) { </ins> self.lookup_stability(def_id)?.const_stability } else { None

Related discussion:
text: When using to create an enum variant in Rust 1.37+, we get an error: results in: but if the enum is constructed explicitly, the compilation succeeds: Looking at , it looks like should be considered a with . Playground links for both variants: ,
Duplicate of (will close in a bit). It seems like folks open this issue because on stable, the error message does not point to the tracking issue, e.g. you don't see: can we fix this?
I think we should just stabilize it
Is this diagnostics problem specific to this feature gate? I meant a more general fix to const-fn related gates.
Not sure. I thought we're using the normal feature gate infra
Reopening this to make sure we add a test per
Code change:
<del> Subproject commit 56444a4545bd71430d64b86b8a71714cfdbe9f5d </del> <ins> Subproject commit 8bed48a751562c1c396b361bb6940c677268e997 </ins>

Related discussion:
text: When confusing a Fn-like struct with a regular struct in an pattern, the output leaves a lot to be desired: <details<summary<a href=""Current output</a</summary</detailsWe should probably collect all these errors into a single diagnostic error: Even better if there was only one diagnostic.