jiebi/CodeConvo huggingface dataset:
Code change:
<ins> error[E0308]: `if` and `else` have incompatible types --> $DIR/issue-82361.rs:10:9 | LL | /     if true { LL | |         a | |         - expected because of this LL | |     } else { LL | |         b | |         ^ | |         | | |         expected `usize`, found `&usize` | |         help: consider dereferencing the borrow: `*b` LL | |     }; | |_____- `if` and `else` have incompatible types error[E0308]: `if` and `else` have incompatible types --> $DIR/issue-82361.rs:16:9 | LL | /     if true { LL | |         1 | |         - expected because of this LL | |     } else { LL | |         &1 | |         -^ | |         | | |         expected integer, found `&{integer}` | |         help: consider removing the `&` LL | |     }; | |_____- `if` and `else` have incompatible types error[E0308]: `if` and `else` have incompatible types --> $DIR/issue-82361.rs:22:9 | LL | /     if true { LL | |         1 | |         - expected because of this LL | |     } else { LL | |         &mut 1 | |         -----^ | |         | | |         expected integer, found `&mut {integer}` | |         help: consider removing the `&mut` LL | |     }; | |_____- `if` and `else` have incompatible types error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

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. --I tried this code: I expected to see this happen: I expected that the help text would give syntactically correct code, or that there would be no help text. Instead, this happened: The provided code snippet is not valid - it tries to deference the else-block, which is impossible. Better would be to put the inside the else-block. <!-- 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. --: Also occurs on stable, 1.50.0. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim I have a fix for this bug + an improvement. Gotta got for now but will submit the PR later today.
Code change:
// `match ::std::future::IntoFuture::into_future(<expr>) { ... }` let into_future_span = self.mark_span_with_reason( DesugaringKind::Await, <del> await_span, </del> <ins> dot_await_span, </ins> self.allow_into_future.clone(), ); let into_future_expr = self.expr_call_lang_item_fn(

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:
fn get_str() -> &str; // ILLEGAL, no inputs fn frob(s: &str, t: &str) -> &str; // ILLEGAL, two inputs <ins> fn frob<'a, 'b>(s: &'a str, t: &'b str) -> &str; // Expanded: Output lifetime is unclear </ins> fn get_mut(&mut self) -> &mut T; // elided fn get_mut<'a>(&'a mut self) -> &'a mut T; // expanded

Related discussion:
text: Reading over the Ownership section in TRPL and came across the example As a newbie, this was very confusing. I believe the situation could be explained by simply adding another line. I'm not sure if this is the best way to do this.
This sounds like a great fix to me, (although I would add the to the signature for clarity). PR welcome! :smile:
I've been waiting for input on my PR for several days. Still have no response. The ? didn't compile, and so I'm not sure what to change it to. I thought this section was ignored by the compile, but it doesn't seem that way.
How about:
Oh, sorry. I didn't even parse that there was a PR referring back to this issue :sweat_smile:
That's what the original is, I was very confused by that, and I was trying to update the docs to sufficiently explain the problem with just a short bit of code. The second bit of code was much better at explaining the problem to me, as the question mark implies that the return lifetime is ambiguous.
It's also the only place that this notation is used, which makes it confusing.
So what should I change it to? suggested
I think that's fine
Code change:
-> Option<(Level, LintSource)> { self.id_to_set.get(&id).map(|idx| { <del> self.sets.get_lint_level(lint, *idx) </del> <ins> self.sets.get_lint_level(lint, *idx, None) </ins> }) } }

Related discussion:
text: The following snippet works fine before but now it reports a warning: Steps to reproduce: clone rustup override set nightly-2017-08-11 cargo test Is this an expected behavior, or a bug? Thank you!
cc -- probably related to the new lint implementation
Yes this was caused by The bug is on . The check for whether is in scope is not checking the current set of attributes being linted. For example this does not warn: but this warns: (as you've noticed) The fix is to just take the local variable into account which has the up-to-that-point set of lint attributes collected.
I've opened a PR for this at
Code change:
use crate::hir::def_id::DefId; use crate::hir; use crate::ty::TyCtxt; <del> use syntax_pos::symbol::{sym, Symbol}; </del> <ins> use syntax_pos::symbol::Symbol; </ins> use crate::hir::map::blocks::FnLikeNode; use syntax::attr;

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:
use crate::hir::def_id::DefId; use crate::hir; use crate::ty::TyCtxt; <del> use syntax_pos::symbol::{sym, Symbol}; </del> <ins> use syntax_pos::symbol::Symbol; </ins> use crate::hir::map::blocks::FnLikeNode; use syntax::attr;

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:
fn collect_bang_proc_macro(&mut self, item: &'a ast::Item) { if self.in_root && item.vis.node.is_pub() { <del> self.bang_macros.push(ProcMacroDef { </del> <ins> self.macros.push(ProcMacro::Def(ProcMacroDef { </ins> span: item.span, function_name: item.ident, <del> }); </del> <ins> def_type: ProcMacroDefType::Bang })); </ins> } else { let msg = if !self.in_root { "functions tagged with `#[proc_macro]` must 

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> // check-pass #![feature(allocator_api)] fn main() { Box::new_in((), &std::alloc::Global); } </ins>

Related discussion:
text: While working on , I've run into the following ICE. On further consideration, the issue also appears with as long as is non zero sized. This ICE was likely not encountered during testing of because in the case of , is zero sized. In the example below, removing the borrow of will cause the compilation to succeed. could you take a look at this? :) cc you may run into this as well on <!-- 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<pFrom playground </p</details
This ice is still showing up in . We are using it over in in embedded programming to allocate from heaps located on externally mounted sdram.
Vec is not affected by this, and can even be used to get a Box. This code did not ICE on playground.
Interestingly, trying to print the Box created in that way gives the same ICE as
Hello, I get this error in two flavor: By ref: Produce the following: Without ref: Cause: Where does implement both and traits.
I'm hitting this issue too, on code that basically equates to this: Seems like there are plenty of ways to reproduce this in here, but if a minimal test case is needed, I would be happy to try to provide one. I just made a repro, wasn't really that tricky.
As far as I understand it, the issue is as follows: std is special cased, it has the attribute This corresponds to , which returns true if the type as been annotated to be a Somewhere, some code which uses makes an assumption that such a box data type only contains one field, the inner pointer itself. This causes the allocator struct field to be removed. This breaks when there is a non ZST allocator field that needs to be accessed in generated code. I'm guessing this might be related to the special deref move semantics for boxes?
Code change:
<ins> // check-pass #![feature(allocator_api)] fn main() { Box::new_in((), &std::alloc::Global); } </ins>

Related discussion:
text: Is the case where the compiler should call for the for the box in the case where a deref move is performed even handled correctly as is today?
It seems that is the one that developed the feature, in He had been warned of the incomming issue, , and opt for a "workaround", can you give us more information about the problem you , the workaround you choose, any hint for why it isn't working, and maybe give us possible path to explore ?
Code change:
= help: add #![feature(generic_associated_types)] to the crate attributes to enable error[E0658]: generic associated types are unstable (see issue #44265) <del> --> $DIR/feature-gate-generic_associated_types.rs:24:5 </del> <ins> --> $DIR/feature-gate-generic_associated_types.rs:25:5 </ins> | LL |     type Pointer2<u32> = Box<u32>; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: add #![feature(generic_associated_types)] to the crate attributes to enable <del> error: aborting due to 4 previous errors </del> <ins> error[E0658]: where clauses on associated types are unstable (see issue #44265) --> $DIR/feature-gate-generic_associated_types.rs:30:5 | LL |     type Assoc where Self: Sized; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: add #![feature(generic_associated_types)] to the crate attributes to enable error: aborting due to 6 previous errors </ins> For more information about this error, try `rustc --explain E0658`.

Related discussion:
text: clauses on associated types don't work yet so should be feature gated, presumably with . cc . Happens on versions = 1.24
Code change:
(cfg, _) => cfg.as_deref().cloned(), }; <del> debug!("Portability {:?} - {:?} = {:?}", item.cfg, parent.cfg, cfg); </del> <ins> debug!("Portability name={:?} {:?} - {:?} = {:?}", item.name, item.cfg, parent.cfg, cfg); </ins> if let Some(ref cfg) = cfg { tags += &tag_html("portability", &cfg.render_long_plain(), &cfg.render_short_html()); }

Related discussion:
text: From Given the following Rust code with in-line annotations of the expected behaviour: On: does not seem to be able to generate feature requirement labels on types in private modules () that are publicly reexported (). The labels do not show up on the module overview nor page, but do propagate into items like functions for the given type. This renders the type without any feature requirement, neither in the module overview: ! Nor on the page: ! Note that the label is propagated onto (does not have an explicit ), at least understood that! It is supposed to render the feature requirement for like , both in the module overview above as on the page: ! It seems tricky to combine feature requirements on the and reexport. In the case above they are the same, but what if: The type is only publicly available when and are specified. Specifying is fine but makes the contents of unreachable through the current module, specifying only should result in a "module not found" error. CC
This also affects re-exports of entire crates. Unfortunately there the fix is not clear at all, since the "parent" crate is obviously not guaranteed to have the same features as the crate being re-exported.
Within the same crate as well; it's not about the features that are enabled (though it is relevant which are available) but about the combined restrictions that are placed on the definition and reexport. Simplest I can think of is a union of all features (but gets complicated quick when inversions and vs is used) and later perhaps simplifying based on feature relations (if implies there is no need to display as requirement, if either definition or reexport requires ). That's necessary to cleanly solve crate reexports, since you effectively want to ensure that the top-level crate feature implies feature and hide it. If the whole resolver is made smart enough (perhaps this already exists, I'm not too familiar with Cargo) it could even throw warnings when there exist feature combinations that would lead to a compiler error (ie. explicitly reexporting a symbol that is not available for a certain set of features).
I wonder if this is just an ordering issue of the passes: The private modules have disappeared by the point where we pass all the data down so we don't see them.
Code change:
(cfg, _) => cfg.as_deref().cloned(), }; <del> debug!("Portability {:?} - {:?} = {:?}", item.cfg, parent.cfg, cfg); </del> <ins> debug!("Portability name={:?} {:?} - {:?} = {:?}", item.name, item.cfg, parent.cfg, cfg); </ins> if let Some(ref cfg) = cfg { tags += &tag_html("portability", &cfg.render_long_plain(), &cfg.render_short_html()); }

Related discussion:
text: Thanks for the suggestion - I moved before and (I've never built rustc/rustdoc from source, pleasantly surprised that only took just under 7min on a ThreadRipper :partyingface:) but it doesn't change anything to the generated output unfortunately :(
I observe this on public items as well: Does not show the badge at re-exports.
So from the following code: is stripped and then inlined. The stripped version contains all the correct information but the inlined one doesn't. Checking what's the best course here: either cloning the stripped item or propagating when inlining.
Code change:
14 | } | - immutable borrow ends here <del> error: aborting due to 2 previous errors </del> <ins> error: aborting due to previous error </ins>

Related discussion:
text: Minimal example: Error message (ran in playground): Tested on nightly as well ()
Related:
twice without checking the return value. Modify it to return and check where it is being called ether both calls have returned an (cancel one, emit the other, return ), wether only one was created (emit it, return ) or none has (return ).
I'll fix this, thanks for the instruction!
I would happily have a go at this, if that's ok with
Sure go for it!
have you had time to work on this? If not could I give it a go? :)
I totally thought I was going to have time, but I had a crazy week at work this week. Go ahead and give it a go :) I'll find another bug to work on when I definitely have time
It looks like the PR to fix this was merged but has a few dangling threads. There seems to be some confusion about short-circuiting functionality and the necessity of the patch and also the error count still reads 2 rather than 1. Should a new issue be opened with those issues and this issue closed?
Code change:
--> $DIR/privacy-struct-ctor.rs:20:9 | LL |         Z; <del> |         ^ constructor is not visible here due to private fields help: a tuple struct with a similar name exists | LL |         S; </del> |         ^ <del> help: possible better candidate is found in another module, you can import it into scope | LL |     use m::n::Z; | </del> <ins> |         | |         constructor is not visible here due to private fields |         help: a tuple struct with a similar name exists: `S` </ins> error[E0423]: expected value, found struct `S` --> $DIR/privacy-struct-ctor.rs:33:5 | LL |     S; |     ^ constructor is not visible here due to private fields <del> help: possible better candidate is found in another module, you can import it into scope | LL | use m::S; | </del> error[E0423]: expected value, found struct `S2` --> $DIR/privacy-struct-ctor.rs:38:5

Related discussion:
text: For this code: You get the following error message: The suggestion may be excused to be not 100% perfect, but here it suggests to add an use statement despite that same item being imported already. What I want is this exactly: that it removes stuff from the suggestion list that is already being imported. Note that changing the glob import to a non glob one doesn't change anything.
cc
Why is that even an error?
tuple structs have private fields by default, you can't construct instances of B outside of the foo module.
oh ^^ maybe we should simply modify this error message then to say that the "function" is private?
It already says "constructor is not visible here due to private fields". That's okay, but maybe you might have meant another B from another module or something. However, the candidate offered is not any better as its the same one you are attempting to use.
Reopening to track "removal of suggestion" work for pub tuple structs with private fields.
Code change:
<ins> fn main() { // There shall be no suggestions here. In particular not `Ok`. let _ = 读文; //~ ERROR cannot find value `读文` in this scope } </ins>

Related discussion:
text: In I noticed this surprising spelling suggestion: To me and don't seem like they would be similar enough to meet the threshold for showing such a suggestion. Can we calibrate this better for short idents? For comparison, even doesn't assume you mean . rustc 1.45.0-nightly ( 2020-05-23) Mentioning who worked on suggestions most recently in .
I debugged it a bit. is selected as the candidate because the edit distance is just 2 to . The code to fix is likely in or around . I tried some quick tricks but got ICEs and failing tests and gave up. One thing I didn't try that could perhaps work is to consider edit distance between characters of different alphabets/logogram sets as infinite, rather than 1, which is the case right now.
Thank you for investigating! Independent of what we do with different logogram sets (your suggestion sounds plausible), an edit distance of 2 for a string of length 2 should not meet the threshold for showing a suggestion, even within a single logogram set.
I think edit distance of 1 for a string of length 1 is reasonable (a lot of existing UI tests relies on it), but maybe an edit distance of 2 for a string of length 2 is not reasonable indeed. As you point out, with regular chars, the edit distance is still 2 but is not suggested. So maybe there is a simpler fix to be made for than looking at what alphabets/logogram sets characters belong to.
Code change:
/// You can also use `dbg!()` without a value to just print the /// file and line whenever it's reached. /// <ins> /// Finally, if you want to `dbg!(..)` multiple values, it will treat them as /// a tuple (and return it, too): /// /// ``` /// assert_eq!(dbg!(1usize, 2u32), (1, 2)); /// ``` /// /// However, a single argument with a trailing comma will still not be treated /// as a tuple, following the convention of ignoring trailing commas in macro /// invocations. You can use a 1-tuple directly if you need one: /// /// ``` /// assert_eq!(1, dbg!(1u32,)); // trailing comma ignored /// assert_eq!((1,), dbg!((1u32,))); // 1-tuple /// ``` /// </ins> /// [stderr]: https://en.wikipedia.org/wiki/Standard_streams#Standard_error_(stderr) /// [`debug!`]: https://docs.rs/log/*/log/macro.debug.html /// [`log`]: https://crates.io/crates/log

Related discussion:
text: It would be nice if the compiler suggested the intended form: as this seems like a reasonable mistake. This is specific to a particular macro, though, so I'm not sure how flexible we can be with diagnostics here.
Or we could just make the macro accept ...