jiebi/CodeConvo huggingface dataset:
Code change:
LL |     arg.map(|v| &**v) |        ++++++++++++++ <del> error: aborting due to 1 previous error </del> <ins> error[E0308]: mismatched types --> $DIR/transforming-option-ref-issue-127545.rs:9:19 | LL |     arg.unwrap_or(&[]) |         --------- ^^^ expected `&Vec<i32>`, found `&[_; 0]` |         | |         arguments to this method are incorrect | = note: expected reference `&Vec<i32>` found reference `&[_; 0]` help: the return type of this call is `&[_; 0]` due to the type of the argument passed --> $DIR/transforming-option-ref-issue-127545.rs:9:5 | LL |     arg.unwrap_or(&[]) |     ^^^^^^^^^^^^^^---^ |                   | |                   this argument influences the return type of `unwrap_or` note: method defined here --> $SRC_DIR/core/src/option.rs:LL:COL help: use `Option::map_or` to deref inner value of `Option` | LL |     arg.map_or(&[], |v| v) |         ~~~~~~    +++++++ error[E0308]: mismatched types --> $DIR/transforming-option-ref-issue-127545.rs:13:19 | LL |     arg.unwrap_or(v) |         --------- ^ expected `&Vec<i32>`, found `&[i32]` |         | |         arguments to this method are incorrect | = note: expected reference `&Vec<i32>` found reference `&'a [i32]` help: the return type of this call is `&'a [i32]` due to the type of the argument passed --> $DIR/transforming-option-ref-issue-127545.rs:13:5 | LL |     arg.unwrap_or(v) |     ^^^^^^^^^^^^^^-^ |                   | |                   this argument influences the return type of `unwrap_or` note: method defined here --> $SRC_DIR/core/src/option.rs:LL:COL help: use `Option::map_or` to deref inner value of `Option` | LL |     arg.map_or(v, |v| v) |         ~~~~~~  +++++++ error[E0308]: mismatched types --> $DIR/transforming-option-ref-issue-127545.rs:17:19 | LL |     arg.unwrap_or(&[]) |         --------- ^^^ expected `&Vec<i32>`, found `&[_; 0]` |         | |         arguments to this method are incorrect | = note: expected reference `&Vec<i32>` found reference `&[_; 0]` help: the return type of this call is `&[_; 0]` due to the type of the argument passed --> $DIR/transforming-option-ref-issue-127545.rs:17:5 | LL |     arg.unwrap_or(&[]) |     ^^^^^^^^^^^^^^---^ |                   | |                   this argument influences the return type of `unwrap_or` note: method defined here --> $SRC_DIR/core/src/result.rs:LL:COL help: use `Result::map_or` to deref inner value of `Result` | LL |     arg.map_or(&[], |v| v) |         ~~~~~~    +++++++ error: aborting due to 4 previous errors </ins> For more information about this error, try `rustc --explain E0308`.

Related discussion:
text: Given : Current error, for the motivating use case above: It should be possible for rustc to suggest replacing this specific instantiation of with . Maybe similarly for some other common cases: . Originally posted by in label -T-rustdoc T-compiler
Code change:
<ins> // check-pass // compile-flags: -Z validate-mir #![feature(let_chains)] fn let_chains(entry: std::io::Result<std::fs::DirEntry>) { if let Ok(entry) = entry && let Some(s) = entry.file_name().to_str() && s.contains("") {} } fn main() {} </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: both compiles successfully Instead, this happened: fails to compile <!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
This may have something to do with , as there is something about let_chain drops here as well, but I don't for sure.
The same behaviour happens with an older compiler version. Here goes an example that compiles with . It is not up to me to decide if this behaviour is a blocker that will revert stabilization but in case of such event, I won't have enough free time to investigate and fix stuff in the near future.
Personally and despite the differences, I think that the version is "correct" and the nested version is surprisingly holding a reference of an owned structure () without an explicit bind.
drops the scrutinee after the statement.
cc who have been dealing with dropping stuff related to
Some things that might be helpful to know: The drop order changes for in also had borrow checker impact and made an example compile (see the PR's thread). I'm not a borrow checker expert, so I might be wrong, but this too might be fixed by drop order changes alone. In I'm studying drop order impacts of conditional statements, motivated by let else, but the test that PR adds also includes let chains. There I observed that let chains generally behave drop order wise like when there is a involved, and when it's a bool. I have only studied them regarding the body contained inside though. This table provides a summary of drop orders (disclaimer: it's outdated for let else):
I've locally amended of to add if let chains: And this is the output: Which actually runs counter to what I wrote above, because it predrops.
Code change:
<ins> // check-pass // compile-flags: -Z validate-mir #![feature(let_chains)] fn let_chains(entry: std::io::Result<std::fs::DirEntry>) { if let Ok(entry) = entry && let Some(s) = entry.file_name().to_str() && s.contains("") {} } fn main() {} </ins>

Related discussion:
text: It seems that it depends on whether the in the chain is preceded by a or not: if you change the line with to , removing the , you get this: So that rule that I wrote above is not correct, but the underlying behaviour is more complicated. Hmmm...
Thanks
claim
pointed this out to me. It may be motivation to revert the stablization of let-chains on beta. Lets try to ensure we talk about this at Thursday triage label I-compiler-nominated
False alarm; pointed out to me that let-chains is already been marked unstable (on beta and nightly). label: -I-compiler-nominated
Code change:
= help: add `#![feature(derive_smart_pointer)]` to the crate attributes to enable = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date <del> error: aborting due to 3 previous errors </del> <ins> error: aborting due to 2 previous errors </ins> For more information about this error, try `rustc --explain E0658`.

Related discussion:
text: https://crater- https://crater- cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
label F-derivesmartpointer
Thread on zulip: https://rust-
claim
WG-prioritization assigning priority (). label -I-prioritize +P-high
Code change:
[[package]] name = "git2" <del> version = "0.11.0" </del> <ins> version = "0.12.0" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "77519ef7c5beee314d0804d4534f01e0f9e8d9acdee2b7a48627e590b27e0ec4" </del> <ins> checksum = "26e07ef27260a78f7e8d218ebac2c72f2c4db50493741b190b6e8eade1da7c68" </ins> dependencies = [ "bitflags", "libc",

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:
declare_lint!(OVERFLOWING_LITERALS, Warn, "literal out of range for its type") <ins> declare_lint!(EXCEEDING_BITSHIFTS, Deny, "shift exceeds the type's number of bits") </ins> pub struct TypeLimits { /// Id of the last visited negated expression negated_expr_id: ast::NodeId,

Related discussion:
text: Currently overlong bit shifts are undefined behavior because that's how llvm rolls--. But even when they aren't, we should warn on something like where happens to be , since it's a useless operation that couldn't possibly return anything interesting. There's a and I imagine it'd be a common gotcha since other languages tend to read unadorned integral literals as 32bit s and then promote the in before doing the actual shift.
I think this can be closed, resolved in
Hooray!
Code change:
<ins> error: `enum` and `struct` are mutually exclusive --> $DIR/issue-99625-enum-struct-mutually-exclusive.rs:3:5 | LL | pub enum struct Range { |     ^^^^^^^^^^^ help: replace `enum struct` with: `enum` error: aborting due to previous error </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. 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: <!-- Please provide a link to --The current output is: <!-- The following is not always necessary. --Ideally the output should look like: Highlight to the user that the keywords and are mutually exclusive. Replace with . <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Code change:
} /// Returns the set of parameters constrained by the impl header. <del> pub fn parameters_for_impl<'tcx>(impl_self_ty: Ty<'tcx>, impl_trait_ref: Option<ty::TraitRef<'tcx>>) -> FxHashSet<Parameter> { </del> <ins> pub fn parameters_for_impl<'tcx>( impl_self_ty: Ty<'tcx>, impl_trait_ref: Option<ty::TraitRef<'tcx>>, ) -> FxHashSet<Parameter> { </ins> let vec = match impl_trait_ref { Some(tr) => parameters_for(&tr, false), None => parameters_for(&impl_self_ty, false),

Related discussion:
text: The second error in this snippet is "nonsense" because it says the type parameter is not constrained, while the real error was already reported — the actual type could not be imported. Found in: rustc 1.13.0-nightly ( 2016-09-26)
.
Code change:
<ins> error: unexpected closing delimiter: `)` --> $DIR/issue-98601-delimiter-error-unexpected-close.rs:5:17 | LL | fn main() { |           - this opening brace... LL |     todo!(); LL | } | - ...matches this closing brace LL | LL | fn other(_: i32)) {} |                 ^ unexpected closing delimiter error: aborting due to previous error </ins>

Related discussion:
text: See: This code: produces on latest stable (1.61.0).
Maybe we could form a heuristic around tokens that we know should eventually be followed by -- , , , etc. If we see one of those, (then some random other tokens), then we see , then that would be a suspicious rbrace which we could point out later.. e.g. if we see that triggers the heuristic, but not
The problem is that the error happens in the lexer, not the parser. Ideally we'd rework the lexer to have a token stream mode of operation instead of a token tree mode of operation, only for code that is being passed to the parser (i.e., not coming from a macro).
This is particularly confusing when the points to a macro: gives on 1.65.0-nightly (2022-08-31 )
the output now changed to: Do you think the should be removed?
This is changed to: it seems more helpful now.
Let's close this ticket after adding these two cases to the test suite then. I'm sure there are outstanding issues in this area, but we can hope that we'll get tickets for those more specific cases, while the tests keep us from regressing silently (hopefully, lets make sure the tests are fully annotated so its harder to do that by accident).
Code change:
// Float => does not implement iterator. for i in 0f32..42f32 {} <del> //~^ ERROR `core::iter::Iterator` is not implemented for the type `core::ops::Range<f32>` //~^^ ERROR //~^^^ ERROR // FIXME(#21528) not fulfilled obligation error should be reported once, not thrice </del> <ins> //~^ ERROR the trait `core::num::Int` is not implemented for the type `f32` </ins> // Unsized type. let arr: &[_] = &[1us, 2, 3];

Related discussion:
text: cc
I think you have a PR that improves type inference in some cases where closures are involved (?), do you know if by chance that fixes this as well?
This is not closure specific:
This must be duo to . It seems to enforce the numeric fallback rule a bit too eagerly.
Another example from IRC is that type checked while didn't. Rather interesting.
edwardw, not just that, type inference regressed slightly at the time of the range stabilization PR.
also related
Have a partial fix by deferring numeric fallback, but it seems to hit now.
OK, so I spent some time digging into this. I don't think that deferring numeric fallback is necessarily the solution. sorry if I kept disappearing on IRC, I had to put my head down and study the log to see what was happening. So what seems to happen is that we correctly come up with the constraint: However, we are unable to make the connection between and . The reason is that the new has separate impls for each of the numeric types, whereas the old had only impl for a type . When we process the projections, we first try to resolve (without considering the output type ), and we get ambiguity, because there are many impls that could apply. Unfortunately this all seems a bit right to me. Basically we're trying to infer the type of the range from the output type, which is the reverse direction inference is supposed to go. When we used a blanket impl, we were able to resolve this because there was only one impl for . Probably the best fix is to go back to that, actually, but this is an interesting quandry. I'll have to think about it a bit.
To be clear, the example I was digging into was
Also, to put it another way: having a single blanket impl allows us to draw the connection that when you iterate over , you get . With the current setup of many distinct impls, that is not known to be true.
After some discussion with on RFC, I just wanted to clarify a few things (I myself was a touch confused too). the impl is probably the easiest way to fix this in the short term. , to some extent, this limitation is an artifact of how trait matching is implemented. That is, we intentionally do not take output bindings into account when selecting traits.
Code change:
// Float => does not implement iterator. for i in 0f32..42f32 {} <del> //~^ ERROR `core::iter::Iterator` is not implemented for the type `core::ops::Range<f32>` //~^^ ERROR //~^^^ ERROR // FIXME(#21528) not fulfilled obligation error should be reported once, not thrice </del> <ins> //~^ ERROR the trait `core::num::Int` is not implemented for the type `f32` </ins> // Unsized type. let arr: &[_] = &[1us, 2, 3];

Related discussion:
text: However, it doesn't have to be this way, but it'd take some work to massage the trait matching infrastructure, since impl selection doesn't presently have access to output binding information, that'd have to be propagated inward. It might be interesting to try and address this in a more wholistic way (i.e., something that accounts for the full set of facts that are registered). particular, the important constraint that we MUST maintain is that, during trans, given the input types, we can derive the output type. But it's permissible for us to use the output type to derive the input type during type checking, since once inference is done, we then have the input types to supply during trans so that we can rederive the output.
The fix is very simple then. Thanks for helping diagnose the problem and pointing to the right direction.
Code change:
// Float => does not implement iterator. for i in 0f32..42f32 {} <del> //~^ ERROR `core::iter::Iterator` is not implemented for the type `core::ops::Range<f32>` //~^^ ERROR //~^^^ ERROR // FIXME(#21528) not fulfilled obligation error should be reported once, not thrice </del> <ins> //~^ ERROR the trait `core::num::Int` is not implemented for the type `f32` </ins> // Unsized type. let arr: &[_] = &[1us, 2, 3];

Related discussion:
text: This code compiled fine before 1.0.0-nightly ( 2015-01-23 16:08:14 +0000): But with that version, it now gives this error:
changing to should work, I stumbled upon the same thing and the doc seems to be updated: (see at the very bottom) EDIT: Maybe worth noting that these work:
That's just a workaround to a bug (not sure if that was implied). should fall back to being as per the existence of the integer fallback.
I don't necessarily expect this to work. Fallback comes late in the process, once all constraints are known, but (like method dispatch) requires the type being cast to be known immediately.
It's plausible we could make it work since we know that the type is integral (I imagine that's how it ever worked, not sure what would have changed that, though it might have been something I did). It occurs to me though that this is somewhat forward-hostile to the idea of integer literals ever being used for anything other than plain ints (but enabling such a feature may well wind up requiring opt-in anyway).
(Though really it's sort of silly that requires the type to be known immediately, so I guess fixing that would be another way to ease the forward compat fears.)
I thought this was a feature because it's saying that it doesn't know if it's or for example. Would it assume it's signed only if it contains negative numbers in the range? EDIT3: what said makes sense: EDIT2: ignore the following, my bad But I might be missing something because this doesn't output anything from : EDIT: just realized -1u32 is too big so the following makes sense: There's no output from , unless using
Code change:
/// [`Metadata`]: struct.Metadata.html /// [`fs::metadata`]: fn.metadata.html /// [`fs::symlink_metadata`]: fn.symlink_metadata.html <ins> /// [`is_dir`]: struct.FileType.html#method.is_dir /// [`is_file`]: struct.FileType.html#method.is_file </ins> /// [`is_symlink`]: struct.FileType.html#method.is_symlink /// /// # Examples

Related discussion:
text: should document that , , and are all mutually exclusive. (and that it may also be the case that none of them are true) Why? Because returns true for both files and symlinks to files, and this tends to make me paranoid that a will share similar characteristics and perhaps claim that both and . The only way to convince myself that FileType's behavior is indeed sane is to write a little test program---again. Surely I can't be alone in this.
is calling not (and equivalent on Windows), so if the path is a symlink, then it returns the results based on what the symlink points to, not the symlink itself. So respects the same mutual exclusivity rules as . But yes, this ought to be documented, especially given that the mutually exclusive behavior may be surprising to Windows developers.
Similar goes for , which should document that these are always false for a obtained by calling on a symlink.
Well you can always call on something that is not a symlink, in which case or could be true.
Code change:
let addr = builder.config.dist_upload_addr.as_ref().unwrap_or_else(|| { panic!("nnfailed to specify `dist.upload-addr` in `config.toml`nn") }); <del> let pass = if env::var("BUILD_MANIFEST_DISABLE_SIGNING").is_err() { let file = builder.config.dist_gpg_password_file.as_ref().unwrap_or_else(|| { panic!("nnfailed to specify `dist.gpg-password-file` in `config.toml`nn") }); t!(fs::read_to_string(&file)) } else { String::new() }; </del> <ins> let file = builder.config.dist_gpg_password_file.as_ref().unwrap_or_else(|| { panic!("nnfailed to specify `dist.gpg-password-file` in `config.toml`nn") }); let pass = t!(fs::read_to_string(&file)); </ins> let today = output(Command::new("date").arg("+%Y-%m-%d"));

Related discussion:
text: Seems like no nightly was released today. That might be related to Unfortunately I don't think I have access to the logs. Cc
Logs are missing on the server, let me start a manual release...
Well that is odd. You wouldn't know what commit is is using? ( file in the tarball, if I recall correctly.)
Is there a way for me to download the "dist" artifacts for better testing? Right now I am manually grabbing a bunch of files from https://s3-us-west- (and we only get dir listing for alt builds there it seems so I am using those). That's not very convenient at all.
Apparently not all commits are pushed to toolstate ( vs ), for example the latest one () is missing in toolstate .
Reverting the cause in the meantime --
Alternatively we could land which will just skip of the toolstate is not found. That installs a toolchain based on these artifacts, but I don't think it gives me access to the tarballs. FTR, for now I did So we are only committing when the toolstate changed? Ouch. That kills my entire approach :(
It should print the URLs it's downloading though, and you can use to avoid it actually downloading stuff.
Code change:
} else { match self.try_coercion_cast(fcx) { Ok(()) => { <del> self.trivial_cast_lint(fcx); debug!(" -> CoercionCast"); fcx.typeck_results.borrow_mut().set_coercion_cast(self.expr.hir_id.local_id); </del> <ins> if self.expr_ty.is_unsafe_ptr() && self.cast_ty.is_unsafe_ptr() { // When casting a raw pointer to another raw pointer, we cannot convert the cast into // a coercion because the pointee types might only differ in regions, which HIR typeck // cannot distinguish. This would cause us to erroneously discard a cast which will // lead to a borrowck error like #113257. // We still did a coercion above to unify inference variables for `ptr as _` casts. // This does cause us to miss some trivial casts in the trival cast lint. debug!(" -> PointerCast"); } else { self.trivial_cast_lint(fcx); debug!(" -> CoercionCast"); fcx.typeck_results .borrow_mut() .set_coercion_cast(self.expr.hir_id.local_id); } </ins> } Err(_) => { match self.do_check(fcx) {

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: it compiles, since raw pointer casts should be allowed even for completely different types. Instead, this happened: it fails with: It looks like for some reason the compiler creates a lifetime obligation here. Strangely, it works with : .
I've looked into this. The issue is that typeck considers this cast to be a "coercion cast", because typeck thinks that you could replace the function body with just since the types are the same (it also triggers the lint (allow-by-default)). HIR typeck isn't aware of lifetimes. So then THIR building and MIR building build MIR that doesn't contain a cast but instead just assigns one to the other. The borrow checker is rightfully not pleased. The bug here is that the THIR does not contain an explicit cast anymore. I'm not sure how to best fix this, as the current logic for "is this a no-op cast (called coercion cast in the code)" is just "try to coerce the types in the same way that happens on coercion sites and if it works it has to be useless". Which is wrong in the presence of lifetimes. It seems like the current strategy works this way because it reuses some code in THIR building. Thinking about it a little more, this is very special to pointer casts, because only pointer casts are allowed to change the type like this. Maybe THIR building should just special case pointer casts to always be emitted?
Unfortunately due to this bug there is that should be turned into a raw pointer cast, but we cannot.
I think that's a different case, these are boxes and not raw pointers, and box-box casts are not allowed to do arbitrary changes (and are in fact coercion casts, so the doesn't actually do anything). The error there is correct and this needs a transmute.
I'd like to replace the transmutes by raw pointer casts, which IMO is much preferable, similar to But this bug is in the way of that.