jiebi/CodeConvo huggingface dataset:
Change:
<ins> // Copyright 2016 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. // compile-flags: -C overflow-checks use std::panic; fn main() { let r = panic::catch_unwind(|| { [1, i32::max_value()].iter().sum::<i32>(); }); assert!(r.is_err()); let r = panic::catch_unwind(|| { [2, i32::max_value()].iter().product::<i32>(); }); assert!(r.is_err()); let r = panic::catch_unwind(|| { [1, i32::max_value()].iter().cloned().sum::<i32>(); }); assert!(r.is_err()); let r = panic::catch_unwind(|| { [2, i32::max_value()].iter().cloned().product::<i32>(); }); assert!(r.is_err()); } </ins>

Discussion:
Tracking issue for
FWIW this should be a relatively easy bug to knock out! The option is and we'd just want to add a new flag to the (we'll delete the flag once everyone's migrated). There's a few uses throughout the codebase which I believe will need an update:    After that we'd just need to add a test which validates this behavior, likely a addition with a annotation at the top. Likewise the Cargo support should be relatively easy:
I'd like to tackle this!
OK, so this is pretty straightforward. Couple questions after actually implementing this: The RFC says the option is , but comments on the RFC suggest that people expect this to be , so one could have (I guess) . Which variant should be supported? It seems better to make the value in the single source of truth to be used throughout the compiler by setting it based on the value of or ; this makes the uses easier to read and also makes any future removal of straightforward. How should interact with ? Should we just consider any explicit setting of to "win" and only consult if the option was not explicitly provided? I guess that would mean that we'd almost have to implement the variant above?
I think it's fine to just reuse the existing  which accepts a "standard variety" of boolean options. Makes sense to me to have a single source of truth! Right now I don't think we have a lot of precedent for modifying after creation so this may not be easy. Perhaps a helper method on though? That's what a . Yeah let's just have trump . The precise semantics likely don't matter too much anyway as we'll quickly phase out the version anyway.
Change:
assert!(reference.dep_tracking_hash() != opts.dep_tracking_hash()); opts = reference.clone(); <ins> opts.cg.overflow_checks = Some(true); assert!(reference.dep_tracking_hash() != opts.dep_tracking_hash()); opts = reference.clone(); </ins> opts.cg.no_prepopulate_passes = true; assert!(reference.dep_tracking_hash() != opts.dep_tracking_hash());

Discussion:
Tracking issue for
FWIW this should be a relatively easy bug to knock out! The option is and we'd just want to add a new flag to the (we'll delete the flag once everyone's migrated). There's a few uses throughout the codebase which I believe will need an update:    After that we'd just need to add a test which validates this behavior, likely a addition with a annotation at the top. Likewise the Cargo support should be relatively easy:
I'd like to tackle this!
OK, so this is pretty straightforward. Couple questions after actually implementing this: The RFC says the option is , but comments on the RFC suggest that people expect this to be , so one could have (I guess) . Which variant should be supported? It seems better to make the value in the single source of truth to be used throughout the compiler by setting it based on the value of or ; this makes the uses easier to read and also makes any future removal of straightforward. How should interact with ? Should we just consider any explicit setting of to "win" and only consult if the option was not explicitly provided? I guess that would mean that we'd almost have to implement the variant above?
I think it's fine to just reuse the existing  which accepts a "standard variety" of boolean options. Makes sense to me to have a single source of truth! Right now I don't think we have a lot of precedent for modifying after creation so this may not be easy. Perhaps a helper method on though? That's what a . Yeah let's just have trump . The precise semantics likely don't matter too much anyway as we'll quickly phase out the version anyway.
Change:
trace!("encoding {:?} with {:#?}", alloc_id, alloc); ALLOC_DISCRIMINANT.encode(encoder)?; alloc.encode(encoder)?; <ins> // encode whether this allocation is the root allocation of a static </ins> tcx.interpret_interner .get_corresponding_static_def_id(alloc_id) .encode(encoder)?;

Discussion:
fresh clone of using local Rust and Cargo latest nightly (also occurs in beta-1.25.0), MSVC x64 with Visual Studio 2017 In : set and to Rustup's proxies set (happens only in debug mode) set (specific value doesn't appear to affect the issue) run It gets to this point and ICEs: I grepped the error message () and it points to which appears to be associated with incremental compilation, which makes sense because this only triggers when building in debug mode and setting avoids the ICE. cc rust-lang/cargo
There's a very high chance that this is fixed by
I'll try to build the latest master and see what happens.
Nope, just changed the file the error is emitted from. I have the backtrace here if you like but it's more than 100 frames deep so I don't know how much context you need.
Thanks. I'll have a look. No need for a backtrace
Repro: The problem is that statics don't have allocations (because it makes no sense for them to have usable memory during const evaluation). This is easy to fix :)
Change:
error[E0106]: missing lifetime specifier <del> --> $DIR/opaque-and-lifetime-mismatch.rs:5:24 </del> <ins> --> $DIR/opaque-and-lifetime-mismatch.rs:4:24 </ins> | LL |     fn bar() -> Wrapper<impl Sized>; |                        ^ expected named lifetime parameter

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'expect 0 RPITITs in call to '', 'thread 'rustc' panicked at 'expect 0 RPITITs in call to '' 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: [collectreturnpositionimpltraitintraittys] comparing an impl and trait method signature, inferring any hidden types in the process [typeof] computing type of [checkwellformed] checking that is well-formed [checkmodtype_wf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
Okay, lol, here the types obviously do unify and therefore isn't effective in this situation.
More fundamentally, the thing that goes “wrong” in these kinds of situations is the fact that we call if we have which is the case because generated one because the HIR (!) type visitor inside found an opaque type in the HIR type (here ) while the lowered type (here ) no longer contains any opaque types ultimately leading to the assert triggering. In short: visit the HIR ty , see an opaque type and take note of that synthesize an assoc ty for the RPITIT (I think) because of (1) lower the ty to due to the argument kind mismatch try to collect RPITITs on the lowered type & fail to find the opaque type I don't know if this is actually useful in general :thinking: What kinds of bugs is it supposed to catch?
cc
So either we delay the detection of RPITITs and the synthesis of RPITIT assoc tys until after HIR ty lowering / AstConv (but I don't know if that's an option) or we modify the assert (either remove it outright or check the corresp. HIR ty, I don't know if that makes sense; furthermore oli is/was on a roll to remove HIR operations from this part of the code base iirc).

Yeah, this assertion was simply there to make sure we weren't incorrectly calling for methods that had no RPITITs themselves (b/c it's expensive, and it actually is a bit stronger in what it enforces in the method signatures since it uses rather than in the signature relation for lifetime reasons), but now that this code isn't being changed much, I doubt that will ever happen. Feel free to remove it, or else I can do.
We could also delay a bug on mismatch
Change:
LL | #![deny(unreachable_code)] |         ^^^^^^^^^^^^^^^^ <del> error: unreachable expression </del> <ins> error: unreachable call </ins> --> $DIR/unreachable-in-call.rs:17:5 | <del> LL | /     call( LL | |         get_u8(), LL | |         diverge()); | |__________________^ </del> <ins> LL |     call( |     ^^^^ </ins> error: aborting due to 2 previous errors

Discussion:
rustc warns that the entire line is an unreachable expression however the code is clearly executed as can be see If the line was truly unreachable, there would be no panic... This bug appears on stable, beta and nightly
The is the unreachable part, so perhaps the error should be rephrased and pointed at that function call only
Hmm, so the span is wrong?
the order of execution is panic! and then everything else, so in some sense everything but the panic is unreachable. I'm not sure what a good span for that would be.
The method receiver is evaluated first, so the and calls still happen. The span can point just at the .
Ah, hm, I didn't expect that to be the case, but it makes sense. Then this seems relatively straightforward as to what the expected output is at least.
I feel like this should also add a note that the panic is called before everything else. It could also suggest but that seems more like a clippy lint.
Similar case: Maybe we can simply add a note that won't be called because evaluation of its arguments leaves the current code path. I agree that suggestion is indeed too specific and may be better suited to clippy. If this is acceptable, I would like to pick it up! As long as it's fine for me to progress more slowly than normal
GitHub wasn't clever enough to read that the PR said "might close" instead of "close." The PR seems to imply more work can be done on this.
Change:
`Config` struct. * Adding a sanity check? Take a look at `bootstrap/sanity.rs`. <del> If you have any questions feel free to reach out on `#rust-infra` on IRC or ask on internals.rust-lang.org. When you encounter bugs, please file issues on the rust-lang/rust issue tracker. </del> <ins> If you have any questions feel free to reach out on `#infra` channel in the [Rust Discord server][rust-discord] or ask on internals.rust-lang.org. When you encounter bugs, please file issues on the rust-lang/rust issue tracker. [rust-discord]: https://discord.gg/rust-lang </ins>

Discussion:
There are still of IRC in the repo. Removing them is not a priority but it will avoid confusion for newcomers.
Should these places be replaced with references to the rust discord server, or just be removed outright?
Probably replaced. Gonna update title.
Opened to address this.
This is horrible. Replacing IRC with Discord.. :/
If you haven't read about it yet, is the post from April.
Yeah I read already. I'd remove the mention of any particular discussion channel, instead of putting Discord in. I can't wait for Matrix to become more mature so the Rust project can use it. Falling back to Discord is quite bad for a FOSS project.
IMO we should just mirror subreddit solution and point to Discord.
Change:
let main = P(ast::Item { ident: main_id, <del> attrs: thin_vec![main_attr, coverage_attr, missing_docs_attr], </del> <ins> attrs: thin_vec![main_attr, coverage_attr, doc_hidden_attr], </ins> id: ast::DUMMY_NODE_ID, kind: main, vis: ast::Visibility { span: sp, kind: ast::VisibilityKind::Public, tokens: None },

Discussion:
I tried this code: I expected to see this happen: no errors Instead, this happened: : Very likely to be related
Looks like allowed missing docs on the generated function, but didn't test having any actual s. cc
Attempt fix in
Change:
} } <del> #[derive(Clone)] </del> <ins> enum ReallyDefault<'a> { Bool(bool), Lazy(Lazy<bool, Box<dyn Fn() -> bool + 'a>>), } </ins> pub struct ShouldRun<'a> { pub builder: &'a Builder<'a>, // use a BTreeSet to maintain sort order

Discussion:
introduced some checks which execute 4 times. They run unconditionally when executing , even if it is just to run tidy. On my system the wall time exceeds that of running tidy itself. I'll look into whether the checks themselves can be made be less wasteful. But if there are suggestions how to completely eliminate them or defer them while preserving their original purpose that would be great too. ! CC can you explain the purpose of running this in rather than erroring in ?
To know beforehand if the test should unconditionally be run or not. If the test is run and the npm package isn't installed, we panic. To be noted that we could make it go down to 2 by switching the order of : currently we check both "local" and "global". Switching the two of them will divide the number of calls by two. cc
I don't have installed, so it'll fail and no short-circuiting will happen regardless of order.
In case you don't have it it'll check 4 times indeed.
Hm, this does seem annoying. It's possible we could add some lazily-evaluated default condition so that this never runs if we're not considering default-on steps (if defaults are on, then these npm lists are likely quite fast in comparison to the rest of the logic).
Change:
<ins> // Copyright 2014 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. // Checks that regions which appear in a trait object type are // observed by the variance inference algorithm (and hence // `TOption` is contavariant w/r/t `'a` and not bivariant). // // Issue #18262. use std::mem; trait T { fn foo(); } #[rustc_variance] struct TOption<'a> { //~ ERROR regions=[[-];[];[]] v: Option<Box<T + 'a>>, } fn main() { } </ins>

Discussion:
If you pass an immutable reference through two structs, one of which is a trait, you can take an immutable reference to a variable that will be mutated later, and the compiler will compile. For a proof of concept, see , and if you want to see it in an actual use case, see (look in the main file). I don't know if this is an issue or not, it didn't cause any safety issues when I used it. Is there a rust-ier way of doing the type of thing I did in the second example (allow an immutable reference to a value that will be mutated, in order to see the new value).
The whole thing in one piece: Thanks for filing, these memory safety bugs are very important to catch, however, I think this may be a duplicate of another bug which I cannot find right now (iirc was interacting with those other bugs). I believe the underlying problem here is the function is invalid, the boxing/returning that happens should be disallowed without the having the lifetime too.
FWIW, I’ve reduced the issue a little more ():
Nominating
As I posted on IRC, this is a variance problem - is unsoundly bivariant:
Thanks for cutting it down. I still am not a good Rust programmer, so I was just copying, as close as I could, the original, accidental, version.
cc
P-backcompat-lang, 1.0.
seems to be dup of
I tested and this is indeed fixed by PR . Too bad I didn't look into this bug first rather than , since I see that other people already worked out the variance connection already.
Change:
/// Returns the path to the C++ compiler for the target specified, may panic /// if no C++ compiler was configured for the target. fn cxx(&self, target: &str) -> &Path { <del> self.cxx[target].path() </del> <ins> match self.cxx.get(target) { Some(p) => p.path(), None => panic!("nntarget `{}` is not configured as a host, only as a targetnn", target), } </ins> } /// Returns flags to pass to the compiler to generate code for `target`.

Discussion:
Can you provide more assistance in debugging as well? For example what was at line 896 of What configuration did you provide? etc.
Relevant line is a part of At that point anything pertaining i686 in my were Replacing with does still result in the same error. For now, I just specified for 32 bit version of LLVM I have, which works.
Ah ok, thanks for the info! Right now this should be a better error (of course) but the cause is how rustbuild treats the and arrays in the configuration. No C++ compilers are found for the array, so you can't request any host-related targets (e.g. LLVM) when a triple is only mentioned in the array. You can fix this by moving the target to the array.
Change:
match ASCII_ARRAY.iter().find(|&&(c, _)| c == ascii_char) { Some(&(ascii_char, ascii_name)) => { let msg = <del> format!("unicode character '{}' ({}) looks like '{}' ({}), but it's not", </del> <ins> format!("Unicode character '{}' ({}) looks like '{}' ({}), but it is not", </ins> ch, u_name, ascii_char, ascii_name); <del> err.span_help(span, &msg); </del> <ins> err.span_suggestion(span, &msg, ascii_char.to_string()); true </ins> }, None => { let msg = format!("substitution character not found for '{}'", ch); reader.sess.span_diagnostic.span_bug_no_panic(span, &msg); <ins> false </ins> } } <del> }); </del> <ins> }).unwrap_or(false) </ins> }

Discussion:
This code: () Looks pretty identical to this code: But the first one doesn't compile because I accidentally used a unicode minus sign (−) instead of a dash (-). This happened to me when I pasted a constant from Wikipedia. We already produce an error about things like this in other cases. For example with an en space: We produce the following: Maybe we could do the same for the minus sign since it is a pretty confusing error to receive?
The unicode minus sign is already on the list of similar characters: However it looks like it doesn't work in this context.
Change:
build::construct_const(cx, body_id, return_ty, return_ty_span) }; <del> lints::check(tcx, &body, def_id); </del> let mut body = BodyAndCache::new(body); body.ensure_predecessors(); <ins> lints::check(tcx, &body.unwrap_read_only(), def_id); </ins> // The borrow checker will replace all the regions here with its own // inference variables. There's no point having non-erased regions here. // The exception is `body.user_type_annotations`, which is used unmodified

Discussion:
noticed these cases: thinks the way to resolve this is to reimplement the lint on top of the analysis stuff.
Isn't the first one kind of correct, if misleading? The second one is indeed problematic.
Technically correct, because it can't return at all ;)
It's wrong because the function can diverge without recursively calling itself. They're both literally the same example, I just replaced one form of divergence with another.
mmmm.... In my mind I read this as while the latter, being it is also , but can terminate (while the has no side-effects). You're correct, but I'd love it if we could somehow differentiate when evaluating divergence between "can't return" and "can't return but can panic".
Both "stuck in an infinite loop" and "panics" are different from "infinitely self-recurses". What we want to detect is unguarded self-recursion, that is, when you forgot to check some condition that would give you a convergent or divergent "base case", that would stop the infinite recursion. The message of the lint doesn't help my point, it should be more clearly about "infinite recursion". While usually you're missing a condition, or you're calling the wrong function, it's also possible that you're using infinite recursion to infinitely repeat something - but we don't have guaranteed tail calls, so what you really want to do is rewrite the infinite recursion into an infinite loop.
Triage: no change
Since we currently lint this: Wouldn't this need a backwards dataflow analysis to catch this case? It doesn't looks like the bit would ever be propagated to a return block like this. A backwards analysis would instead propagate it to the entry block, if I understand correctly.
You're right, there's no merge for either the or the examples, that could collect the information. Presumably we want to tell these apart: vs So I guess the property you'd propagate backwards is "always reaches self-call", which means every block starts at (except those that contain a self-call) and the merge operator is . The funny thing about this being a 1-bit-per-block analysis is that instead of a you can use a simple and fixpoint is also easier to achieve. Rough sketch:
Change:
<ins> // run-pass // compile-flags: -C overflow_checks=true #![feature(cfg_overflow_checks)] fn main() { assert!(cfg!(overflow_checks)); assert!(compiles_differently()); } #[cfg(overflow_checks)] fn compiles_differently()->bool { true } #[cfg(not(overflow_checks))] fn compiles_differently()->bool { false } </ins>

Discussion:
An enhancement request discussed here: (That thread also contains a hacky solution by Yandros). I propose to add a config like this: #[cfg(overflow_checks)] I would like to use it to enable/disable lines of code that perform safe unsafe "as" casts replacing them with casts when I compile with debug builds or with release builds compiled with "-C overflow-checks".
modify labels: C-enhancement
label A-attributes T-compiler
I’d also be interested in this.
Tracking issue:
Change:
// Clone-on-write //////////////////////////////////////////////////////////////////////////////// <ins> #[stable(feature = "cow_from_vec", since = "1.7.0")] impl<'a, T: Clone> From<&'a [T]> for Cow<'a, [T]> { fn from(s: &'a [T]) -> Cow<'a, [T]> { Cow::Borrowed(s) } } #[stable(feature = "cow_from_vec", since = "1.7.0")] impl<'a, T: Clone> From<Vec<T>> for Cow<'a, [T]> { fn from(v: Vec<T>) -> Cow<'a, [T]> { Cow::Owned(v) } } </ins> #[stable(feature = "rust1", since = "1.0.0")] impl<'a, T> FromIterator<T> for Cow<'a, [T]> where T: Clone { fn from_iter<I: IntoIterator<Item = T>>(it: I) -> Cow<'a, [T]> {

Discussion:
Both Vec<Tand &[T] are missing From impls for Cow, unlike String/&str and PathBuf/&Path. Coherence is not (afaict) an issue, since the impl would be in the same crate as Cow. Is there some reason these don't exist (do they cause coherence issues in downstream crates or something)?
Whoa, I have no idea why these aren't implemented... Should be good to go ahead and add them! Want to send a PR?