jiebi/CodeConvo huggingface dataset:
Change:
} let sp = cx.with_def_site_ctxt(sp); <del> let e = match env::var(&*var.as_str()) { Err(_) => { </del> <ins> let value = env::var(&*var.as_str()).ok().as_deref().map(Symbol::intern); cx.parse_sess.env_depinfo.borrow_mut().insert((var, value)); let e = match value { None => { </ins> cx.span_err(sp, &msg.as_str()); return DummyResult::any(sp); } <del> Ok(s) => cx.expr_str(sp, Symbol::intern(&s)), </del> <ins> Some(value) => cx.expr_str(sp, value), </ins> }; MacEager::expr(e) }

Discussion:
This is still in 's build script: But the use site has been moved here: This means that won't be rebuilt when that env var changes. For the record, I haven't seen a bug from this, was just curious where may be used and spotted the mismatch. cc
Found another one: is used in but it's still mentioned by . cc Could we automate ensuring this? e.g. by searching for in tidy.
Yeah, we can try I guess. Not sure :) Maybe the right solution is that Cargo would, other than some whitelist, remove unknown variables from rustc's environment -- and the whitelist can be expanded via the build script env-tracking.
hmm I wonder if abusing the file format (from ) or encoding this extra info in a comment, would be a good idea.
You mean such that if you use we automatically tell Cargo to rebuild on changes? (That's ). But yeah, I think that would be good. Ideally this would be "well-integrated" vs. the current state of everyone having to remember to do it.

(As discussed with on IRC.) Rustc should have an option to obtain a list, as part of building, of every environment variable that was requested via the or macros (tagged accordingly with "required" or "optional"), as well as providing a way to instrument intrinsics like called by scripts. This will make it more feasible to detect (and lint about) the usage of environment variables only set by newer build bits (e.g. Cargo) without an appropriate versioned dependency; for instance, it'd be possible to say "you use the environment variable without a dependency on a version of Cargo that supplies . This would also help people doing reproducible builds to see what environment variables might affect a build. This will never be perfect; it can't capture variables read from native code or from code that goes out of its way to bypass the normal mechanism (e.g. calling .) However, this would still catch many common cases.
Just following up to say that this is an accurate reflection of what we discussed. As said, it's part of a larger goal to detect usage of newer Cargo features on older versions of Cargo and let the user know which version of Cargo they need to upgrade to. For keys in , it's enough to simply keep a list of when a particular key was (since Cargo is the one parsing ). But if Cargo adds an environment variable, we need some compiler help to detect that the environment variable was used from Rust code.
I believe this may be a dupe of
They're related, though I think seems more narrow in scope.
Change:
<ins> error[E0308]: mismatched types --> $DIR/issue-89856.rs:6:20 | LL |     take_str_maybe(option); |                    ^^^^^^ expected `str`, found struct `String` | = note: expected enum `Option<&str>` found enum `Option<&String>` help: try converting the passed type into a `&str` | LL |     take_str_maybe(option.map(|x| &**x)); |                          ++++++++++++++ error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
can easily be converted to , but we give a somewhat opaque E0308 when with the following situation: This results in: Which is not totally clear to people who do not understand the trait and/or do not know that it is implemented for these types. We should suggest that the user use to convert between these types. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
only works for and not for There are a couple of options I thought about, if there is a better one i'd be happy to use it: tell the user to pass a instead of a and use try to find where the parameter comes from and tell the user to remove the & sign and use if this is the last instance where the was used just handle the cases in which a is passed try to find a Copy or Clone impl on the struct and suggest to use it and use (this one seems like the most unsafe for arbitrary types, but in this particular case it would work) sorry for the inconvenience, I am new to rustc and I am currently trying to get started with this issue.
another option that would remain more local than finding where the was constructed is to try and suggest for that case in particular. Having said that, finding where the was constructed would be great because it's a type that is almost always wrong to use, unless it comes from a place where you end up with that because of type params (like a hashmap or another container), so it'd be good to lead people towards better code. What you can do is indeed split your work and focus on making the case work on its own PR, and then follow up with an attempt to handle .
Change:
CFG_GCCISH_PRE_LIB_FLAGS_arm-unknown-linux-gnueabihf := -Wl,-whole-archive CFG_GCCISH_POST_LIB_FLAGS_arm-unknown-linux-gnueabihf := -Wl,-no-whole-archive CFG_DEF_SUFFIX_arm-unknown-linux-gnueabihf := .linux.def <del> CFG_LLC_FLAGS_arm-unknown-linux-gnueabihf := -arm-enable-ehabi -arm-enable-ehabi-descriptors </del> <ins> CFG_LLC_FLAGS_arm-unknown-linux-gnueabihf := </ins> CFG_INSTALL_NAME_ar,-unknown-linux-gnueabihf = CFG_LIBUV_LINK_FLAGS_arm-unknown-linux-gnueabihf = CFG_EXE_SUFFIX_arm-unknown-linux-gnueabihf :=

Discussion:
This code Will generate this IR under Yes, that is a of length 7. I have no idea why this is getting generated, I'm trying to narrow down which pass is generating this, but that is absolutely awful code to generate for such a simple operation. I would expect this function to generate two stores, one of the discriminant and one of the value. Now change the program to have in front of the enum, and we get this code:
cc
I would expect similar code generation with as well as with no annotation. Is this because we're attempting to zero-out the discriminant padding?
Look at the asm. This may actually not be so bad unless the is getting lowered to a true .
Here is the asm. It is not actually generating a call to :
the equivalent to no in this case would be , fwiw.
I agree that the assembly doesn't look that bad, but this is still completely unnecessary, no? I was looking at assembly with huge waterfalls of moving al/ax/eax/rax over and over again. I don't think this is a closed bug because this is a real problem. This may not be a high priority bug, but our assembly is certainly doing things that it doesn't need to do.
Is this ?
Aha, I see the problem: SROA happened, split up our struct into 3 elements, one of which is the padding, and stored the padding. The solution is to add , like . Closing again as a dupe.
It may be, but I don't know enough about LLVM's optimizations to know whether that would help or not.
It would be possible to make the type , and that might make the code seen here less bad, but I don't know if LLVM would be less able to optimize code that accesses the discriminant in that case. It would also be possible to make more complex and have it avoid filling in alignment padding for bytes where none of the variants have fields (so → , → ). We might need this information anyway for .
Patch has been submitted to LLVM upstream.
Change:
<ins> pub trait Array { type Element; } pub trait Visit { fn visit() {} } impl Array for () { type Element = (); } impl<'a> Visit for () where (): Array<Element=&'a ()>, {} fn main() { <() as Visit>::visit(); //~ ERROR: type mismatch resolving } </ins>

Discussion:
Minimal example:
can you reproduce?
I can try, this is from Mar 2nd so not related to my recent changes right?
yes it fails for me with both stable rust 1.25 and the latest nightly rustc 1.27.0-nightly ( 2018-04-11). It's not failing in a part of typeck that I'm familiar with but I'll have a look sometime and see if it makes any sense to me.
Yes this is unrelated to that PR (I think there isn't a nightly including it yet). But since this is related to I thought you might want to take a look.
I started expanding the minimal example so that it didn't depend on nalgebra, it has expanded into quite a lot of code This example is enough to break the compiler but doesn't compile if the ICE is fixed (e.g. if the is commented out). For it to compile it still needs some external dependencies. It appears to be the associated type that is hitting the ICE.
Yeah 's example is huge. Maybe he doesn't know that minimal examples should have no dependencies. if you don't provide minimal examples in bug reports (that is: no dependencies; they should compile in the play ground) they'll take much longer than necessary to fix.
I understand. I'm a relative beginner to rust, so it would take quite a lot of time for me to figure out how to make a more minimal example. I am able to work around this issue in my own code, so it's not that important to me, but I figured it might be easy for someone more experienced to spot what was going wrong. If you don't think it's worth the effort to investigate further, I have no problem with you closing this until a more simple manifestation is discovered.
I've reduced it to the following ():
It's no longer reproduced an ICE on the latest nightly, it seems from 1.38.0. marked as E-needstest
Change:
if (mgens && mgens.has(fnType.id) && mgens.get(fnType.id) !== 0) { return false; } <ins> // Where clauses can represent cyclical data. // `null` prevents it from trying to unbox in an infinite loop const mgensTmp = new Map(mgens); mgensTmp.set(fnType.id, null); </ins> // This is only a potential unbox if the search query appears in the where clause // for example, searching `Read -> usize` should find // `fn read_all<R: Read>(R) -> Result<usize>` // generic `R` is considered "unboxed" <del> return checkIfInList(whereClause[(-fnType.id) - 1], queryElem, whereClause); </del> <ins> return checkIfInList( whereClause[(-fnType.id) - 1], queryElem, whereClause, mgensTmp ); </ins> } else if (fnType.generics.length > 0 || fnType.bindings.size > 0) { const simplifiedGenerics = [ ...fnType.generics, ...Array.from(fnType.bindings.values()).flat(), ]; <del> return checkIfInList(simplifiedGenerics, queryElem, whereClause); </del> <ins> return checkIfInList(simplifiedGenerics, queryElem, whereClause, mgens); </ins> } return false; }

Discussion:
sqlx was updated yesterday. and its search is now broken. compare: with:
Firefox prints those errors: with label -needs-triage +T-rustdoc +A-rustdoc-search +regression-untriaged cc
Change:
<ins> error[E0433]: failed to resolve: use of undeclared crate or module `page_size` --> $DIR/path-to-method-sugg-unresolved-expr.rs:2:21 | LL |     let page_size = page_size::get(); |                     ^^^^^^^^^ use of undeclared crate or module `page_size` error: aborting due to previous error For more information about this error, try `rustc --explain E0433`. </ins>

Discussion:
<!-- 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. --This is new, introduced between (older) and (newer) src/tools/miri/tests/pass- <!-- 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
prioritize
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
[[package]] name = "thiserror-impl" <del> version = "1.0.40" </del> <ins> version = "1.0.47" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "f9456a42c5b0d803c8cd86e73dd7cc9edd429499f37a3550d286d5e86720569f" </del> <ins> checksum = "6bb623b56e39ab7dcd4b1b98bb6c8f8d907ed255b18de254088016b27a8ee19b" </ins> dependencies = [ "proc-macro2", "quote",

Discussion:
Error message says it all: This is probably related to It goes away when I . Looks like the thiserror build script is caching its output too aggressively, so it doesn't notice that it needs to be rerun? Cc
As far as I understand, this is a bootstrap bug, not caching. See 1st paragraph of
Although, sounds like I'm wrong because I wouldn't have expected to help. ¯()/¯ I don't know of anything the thiserror build script is doing wrong with regard to caching.
I think you mean , which I'd say is a cargo limitation. But indeed then clearing my build cache wouldn't have helped... Here we don't have a proc macro dependency I think, so I don't think it is that problem.
I think what happens is that usually, when the rustc version changes, cargo will rerun build scripts automatically. But here the rustc version is always and so even though the output of running on a particular file can change, cargo keeps using the old cache. thiserror would have to say "rerun if the output of running might change", but it doesn't have a way to do that. (The rustc binary didn't even change, the sysroot did.) Maybe bootstrap should delete the cached build script output when the stage0 library artifacts change? Not sure if it even knows that this is the case though. Cc
Will check what we can do on the bootstrap side by the coming weekend. Thanks for the ping.
Hm, we usually rely on Cargo doing the rebuild as a result of depinfo containing references to the sysroot when it uses it (via -Zbinary-dep-depinfo), but in this case that doesn't get passed since we don't control the rustc invocation. I'm not sure we have a good way of recognizing when we need the rebuild and when we don't; we wouldn't want to always clear build scripts because that would cause many more spurious rebuilds...
Hm yeah, maybe the right solution is for cargo to provide a native way of doing "probe builds", that integrates with its caching...
Fixing this on bootstrap will most likely require implementing hacky tricks(like creating/moving some values as files between outputs and comparing them each time on the compilations) and that could make our complex flow even more confusing.

And there's a good chance these things could cause unexpected problems that are hard to detect. +1
FWIW for now thiserror is working around this via
Change:
}) } <ins> fn collect_field(&mut self, field: &'a StructField, index: Option<usize>) { if field.is_placeholder { self.visit_macro_invoc(field.id); } else { let name = field.ident.map(|ident| ident.name) .or_else(|| index.map(sym::integer)) .unwrap_or_else(|| { let node_id = NodeId::placeholder_from_expn_id(self.expansion); sym::integer(self.definitions.placeholder_field_indices[&node_id]) }) .as_interned_str(); let def = self.create_def(field.id, DefPathData::ValueNs(name), field.span); self.with_parent(def, |this| visit::walk_struct_field(this, field)); } } </ins> pub fn visit_macro_invoc(&mut self, id: NodeId) { self.definitions.set_invocation_parent(id.placeholder_to_expn_id(), self.parent_def); }

Discussion:
Stable, and nightly-2019-09-09: nightly-2019-09-10: Mentioning because this is likely from .
Yeah, this is some known shortcut taken in , sorry. Didn't expect people to hit it that fast. Will fix ~this weekend.
Thanks. The realistic usage where this appears is if you forget to import a derive macro, which happens commonly.
Un-nominating since Vadim self-assigned.
triage: P-high.
Fixed in
Change:
<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![feature(rustc_attrs)] #![allow(warnings)] struct Attr { name: String, value: String, } struct Element { attrs: Vec<Box<Attr>>, } impl Element { pub unsafe fn get_attr<'a>(&'a self, name: &str) { self.attrs .iter() .find(|attr| { let attr: &&Box<Attr> = std::mem::transmute(attr); true }); } } #[rustc_error] fn main() { //~ ERROR compilation successful let element = Element { attrs: Vec::new() }; let _ = unsafe { element.get_attr("foo") }; } </ins>

Discussion:
I was trying to compile the following code: And got the following compiler error: Version info:
Still ICEs.
Minimal:
Triage: tracked by glacier
No longer ICEs today. E-needstest. I'm somewhat concerned though because this is the second glacier-tracked ICE that I've seen "fixed."
This was only broken because of the old code.
Change:
@only_on(('linux', 'darwin', 'freebsd', 'openbsd')) def check_rlimit_core(): <ins> import resource </ins> soft, hard = resource.getrlimit(resource.RLIMIT_CORE) if soft > 0: error_unless_permitted('ALLOW_NONZERO_RLIMIT_CORE', """

Discussion:
check- uses Unix-only module , runs and therefore fails on Windows Workaround: use instead of cc
Oof, sorry! Having a look now
What version of python and windows are you on? I was fairly sure that I confirmed this did something reasonable on not-posix, but I do not in fact have a windows box to test on. I'm kinda confused about how the builders are working right now.
msys2 x64 on Windows 7 Python 2.7.9
Change:
use super::{Parser, PathStyle, TokenType}; <ins> use crate::errors::{FnPtrWithGenerics, FnPtrWithGenericsSugg}; </ins> use crate::{maybe_recover_from_interpolated_ty_qpath, maybe_whole}; use rustc_ast::ptr::P;

Discussion:
Newcomers might attempt to write a “generic” function pointer like . In such case, the compiler should provide a better error message. Inspired by a recent Reddit thread I sadly cannot find anymore. Given the following code: The compiler should mention that function pointers may not be generic or […] may not have generic parameters, suggest to move the lifetime(s) to a parameter list (this should be machine-applicable in my judgement) and be able to recover: For later reference, the current output is: Given the following code: The compiler should mention that function pointers may not be generic or […] may not have generic parameters and be able to recover emitting two diagnostics, one for each line. The compiler could also suggest moving the generic parameter list further up to the owning function, struct, etc. if available. Note that this might not be what the user intended (since there is a semantic difference between hypothetical higher-ranked generics and normal ones) and therefore shouldn't be machine-applicable. For later reference, the current output is: label A-parser A-suggestion-diagnostics D-newcomer-roadblock <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
self.parent_def = orig_parent_def; } <del> fn visit_async_fn( &mut self, id: NodeId, name: Name, span: Span, header: &FnHeader, generics: &'a Generics, decl: &'a FnDecl, body: Option<&'a Block>, ) { let (closure_id, return_impl_trait_id) = match header.asyncness { Async::Yes { span: _, closure_id, return_impl_trait_id } => { (closure_id, return_impl_trait_id) } _ => unreachable!(), }; // For async functions, we need to create their inner defs inside of a // closure to match their desugared representation. let fn_def_data = DefPathData::ValueNs(name); let fn_def = self.create_def(id, fn_def_data, span); return self.with_parent(fn_def, |this| { this.create_def(return_impl_trait_id, DefPathData::ImplTrait, span); visit::walk_generics(this, generics); visit::walk_fn_decl(this, decl); let closure_def = this.create_def(closure_id, DefPathData::ClosureExpr, span); this.with_parent(closure_def, |this| { if let Some(body) = body { visit::walk_block(this, body); } }) }); } </del> fn collect_field(&mut self, field: &'a StructField, index: Option<usize>) { let index = |this: &Self| { index.unwrap_or_else(|| {

Discussion:
I was migrating my library (Mammut) to use reqwest and be async, and the compiler ICEd. I don't know how to reduce it further than this. I tried this code: I expected to see this happen: A successful build or another compile error Instead, this happened: I also tried this on the latest nightly and it emits the same error. : Backtrace:
Reproduced with lastest nighlty: ICE from macro resolving I believe. cc
cc
triage: P-high, removing nomination tag. (instead, going to proritize going through the P-high issues that have accumulated over last two weeks.)
Visiting from triage.. the next step is to reduce the reproducer.
Reduced ():
Further reduced:
Fixed in
Change:
let field_ty = candidate_field.ty(self.tcx, subst); if let Some((nested_fields, subst)) = self.get_field_candidates(span, &field_ty) { for field in nested_fields.iter() { <del> let ident = field.ident(self.tcx).normalize_to_macros_2_0(); if ident == target_field { return Some(field_path); } else { </del> <ins> let accessible = field.vis.is_accessible_from(id, self.tcx); if accessible { let ident = field.ident(self.tcx).normalize_to_macros_2_0(); if ident == target_field { return Some(field_path); } </ins> let field_path = field_path.clone(); if let Some(path) = self.check_for_nested_field( span,

Discussion:
Lets consider the following code () : Here, we try to access a property on an object of type . Up to the 1.50 version, the error message was the following : However, since Rust 1.51 and onward, the diagnostic message changed to this: While there is indead a property on the struct, this can't be accessed like that, applying the compiler suggestion implies making the property of public, which is not possible. The compiler should not look at non- properties when searching for properties with a matching name for diagnostic purposes. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
label +A-diagnostics
Related issue:
Change:
let ys = [13, 15, 16, 17, 19, 20, 30]; let mut it = xs.iter().skip(5); let mut i = 0; <del> for &x in it { </del> <ins> while let Some(&x) = it.next() { </ins> assert_eq!(x, ys[i]); i += 1; <ins> assert_eq!(it.len(), xs.len()-5-i); </ins> } assert_eq!(i, ys.len()); <ins> assert_eq!(it.len(), 0); </ins> } #[test] fn test_iterator_take() { <del> let xs = [0u, 1, 2, 3, 5, 13, 15, 16, 17, 19]; let ys = [0u, 1, 2, 3, 5]; </del> <ins> let xs = [0us, 1, 2, 3, 5, 13, 15, 16, 17, 19]; let ys = [0us, 1, 2, 3, 5]; </ins> let mut it = xs.iter().take(5); let mut i = 0; <del> for &x in it { </del> <ins> assert_eq!(it.len(), 5); while let Some(&x) = it.next() { assert_eq!(x, ys[i]); i += 1; assert_eq!(it.len(), 5-i); } assert_eq!(i, ys.len()); assert_eq!(it.len(), 0); } #[test] fn test_iterator_take_short() { let xs = [0us, 1, 2, 3]; let ys = [0us, 1, 2, 3]; let mut it = xs.iter().take(5); let mut i = 0; assert_eq!(it.len(), 4); while let Some(&x) = it.next() { </ins> assert_eq!(x, ys[i]); i += 1; <ins> assert_eq!(it.len(), 4-i); </ins> } assert_eq!(i, ys.len()); <ins> assert_eq!(it.len(), 0); </ins> } #[test]

Discussion:
This should be in : This would require either implementing for (where ), or decoupling and (like in )