jiebi/CodeConvo huggingface dataset:
Change:
pub use self::machine::Machine; pub use self::memory::{write_target_uint, write_target_int, read_target_uint}; <ins> use rustc::mir::interpret::{EvalResult, EvalErrorKind}; use rustc::ty::{Ty, TyCtxt, ParamEnv}; pub fn sign_extend<'a, 'tcx>(tcx: TyCtxt<'a, 'tcx, 'tcx>, value: u128, ty: Ty<'tcx>) -> EvalResult<'tcx, u128> { let param_env = ParamEnv::empty(); let layout = tcx.layout_of(param_env.and(ty)).map_err(|layout| EvalErrorKind::Layout(layout))?; let size = layout.size.bits(); assert!(layout.abi.is_signed()); // sign extend let amt = 128 - size; // shift the unsigned value to the left // and back to the right as signed (essentially fills with FF on the left) Ok((((value << amt) as i128) >> amt) as u128) } pub fn truncate<'a, 'tcx>(tcx: TyCtxt<'a, 'tcx, 'tcx>, value: u128, ty: Ty<'tcx>) -> EvalResult<'tcx, u128> { let param_env = ParamEnv::empty(); let layout = tcx.layout_of(param_env.and(ty)).map_err(|layout| EvalErrorKind::Layout(layout))?; let size = layout.size.bits(); let amt = 128 - size; // truncate (shift left to drop out leftover values, shift right to fill with zeroes) Ok((value << amt) >> amt) } </ins>

Discussion:
The previous version of the crate fails to compile with the error (see the build log). No error nor warning was present in the 1.25 release. Since is actually , the error is wrong and should be fixed. regressed from stable to beta () cc
cc -- initial git log dive notes that this could be related to miri transition? Not sure.
Jup it's a regression. :
Not yet fixed on beta, this needs a backport.
Backported to beta! Thanks!
Change:
} impl Key for DefId { <del> type CacheSelector = DefaultCacheSelector<Self>; </del> <ins> type CacheSelector = DefIdCacheSelector; </ins> fn default_span(&self, tcx: TyCtxt<'_>) -> Span { tcx.def_span(*self)

Discussion:
Per-crate cache maps keyed on may be more efficient and/or allow us to use for queries keyed on instead of . We can use specialization (e.g. for splitting into and ), I think. cc
Sounds like a good idea if the lookup array ends up being densely populated enough. In general, we should provide a way to implement customized in-memory caching for specific queries.
Change:
}); } <ins> function escape(content) { return $('<h1/>').text(content).html(); } </ins> function showResults(results) { var output, shown, query = getQuery(); currentResults = query.id; <del> output = '<h1>Results for ' + query.query + (query.type ? ' (type: ' + query.type + ')' : '') + '</h1>'; </del> <ins> output = '<h1>Results for ' + escape(query.query) + (query.type ? ' (type: ' + escape(query.type) + ')' : '') + '</h1>'; </ins> output += '<table class="search-results">'; if (results.length > 0) {

Discussion:
The input for doc searches isn't sanitized, allowing for arbitrary HTML input.
Is this problematic? Afaik everything is done client-side.
Yes. For example, if rustdoc documentation is served on a site that uses a cookie for authentication, an attacker could perform XHRs on the victim's behalf by injecting a tag. It's not particularly problematic on the site, though.
But the search is done with client-side javascript on a client-side resources index; how can you secure that?
I'm not sure what you mean by the search being unsecurable because the index is searched on the client. The problem is that the Javascript responsible for rendering the search query does not properly escape it, so an attacker can insert arbitrary HTML and therefore execute arbitrary Javascript in another user's browser merely by tricking the user into following a link. This is easily fixed by escaping and here: If you're not convinced of the danger, see for an example. If I were more nefarious, and I knew of a site that served rustdoc HTML documentation on the same domain as another site that uses cookie authentication, I could impersonate a user of this site just by convincing them to follow a link I've sent them.
I see thanks for the explanations, opened up a PR for it.
I think this is the part that makes me go from "meh" to "OH!." There's not a lot of damage on rust-, but we shouldn't open up others to these issues.
Change:
<ins> // check-pass trait Foo { type Bar<T> where dyn Send + 'static: Send; } impl Foo for () { type Bar<T> = i32; // We take `<() as Foo>::Bar<T>: Sized` and normalize it under the where clause // of `for<S> <() as Foo>::Bar<S> = i32`. This gives us back `i32: Send` with // the nested obligation `(dyn Send + 'static): Send`. However, during candidate // assembly for object types, we disqualify any obligations that has non-region // late-bound vars in the param env(!), rather than just the predicate. This causes // the where clause to not hold even though it trivially should. } fn main() {} </ins>

Discussion:
The type is not inferred to be by the above mentioned nightly release, c.f. Using the stable, the code compiles with out issue. EDIT: It seems to be related to GAT, i.e. a more minimal reproducer is: which similarly fails on nightly and builds on stable. <details<summaryMore details</summaryon the above-mentioned nightly version whereas stable is happy Simply asserting that is via e.g. works on stable and nightly. </details
The reproducer wouldn't compile on stable though?
Sorry, I must have messed something up when trying to whittle it down as the reproducer I started with definitely did compile on stable. Will try to trace my steps backwards.
And indeed using instead of makes it compile on stable. (I wanted to avoid to avoid the standard library but indeed is closer to the original code in question.) I updated the reproducer in the OP accordingly.
Great, thank you. So I believe this to be a different manifestation of from cc -- and therefore also to be fixed by
Stumbled on this separately in my own code. The simplest reproduction I was able to come up with is Removing makes it compile on nightly as well. Putting a bound on does not help.
Change:
#![feature(cfg_target_thread_local)] #![feature(cfg_target_vendor)] #![feature(char_escape_debug)] <ins> #![feature(char_error_internals)] </ins> #![feature(char_internals)] #![feature(collections)] #![feature(collections_range)]

Discussion:
I'm not sure if this is an oversight. But the implementation should be trivial. I'll add tests and implement it, if it is fine.
Strings aren't indexable and .len() doesn't count the number of chars. :smile: What comes to mind first is an iterator inspecting the two first chars:
xD I didn't test my code, but you get the gist. I had a impl at first, but then edited it
cc
Triage: this has not been .
PRs welcome!
I can take this. I was also thinking of adding a impl for , but unsure if it would be better to wait for to get closer to stabilization and use that instead of adding another empty enum to std
wait, that wouldn't work bc of lifetime issues regardless, right? :(
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. // aux-build:issue-15562.rs extern crate i = "issue-15562"; pub fn main() { extern { fn transmute(); } unsafe { transmute(); i::transmute(); } } // We declare this so we don't run into unresolved symbol errors // The above extern is NOT `extern "rust-intrinsic"` and thus // means it'll try to find a corresponding symbol to link to. #[no_mangle] pub extern fn transmute() {} </ins>

Discussion:
The transmute intrinsic has some special restrictions. The check that implements these does not actually check that the function is a lang item, just looking at the name 'transmute': For defs in the local crate it appears this only happens with foreign functions called 'transmute'. From looking at the code, it looks like the cross-crate case isn't so restricted and will try to check every function called 'transmute'.
(I guess this would be an easy fix after .)
Change:
// unpack and write all other args let layout = self.layout_of(args[1].ty)?; <del> if let ty::TyTuple(..) = args[1].ty.sty { </del> <ins> if let ty::TyTuple(_) = args[1].ty.sty { if layout.is_zst() { // Nothing to do, no need to unpack zsts return Ok(()); } </ins> if self.frame().mir.args_iter().count() == layout.fields.count() + 1 { <del> match args[1].value { Value::ByRef(ptr, align) => { for (i, arg_local) in arg_locals.enumerate() { let field = layout.field(&self, i)?; let offset = layout.fields.offset(i); let arg = Value::ByRef(ptr.ptr_offset(offset, &self)?, align.min(field.align)); let dest = self.eval_place(&mir::Place::Local(arg_local))?; trace!( "writing arg {:?} to {:?} (type: {})", arg, dest, field.ty ); let valty = ValTy { value: arg, ty: field.ty, }; self.write_value(valty, dest)?; } } Value::Scalar(Scalar::Bits { defined: 0, .. }) => {} other => { trace!("{:#?}, {:#?}", other, layout); let mut layout = layout; 'outer: loop { for i in 0..layout.fields.count() { let field = layout.field(&self, i)?; if layout.fields.offset(i).bytes() == 0 && layout.size == field.size { layout = field; continue 'outer; } } break; } { let mut write_next = |value| { let dest = self.eval_place(&mir::Place::Local( arg_locals.next().unwrap(), ))?; let valty = ValTy { value: Value::Scalar(value), ty: layout.ty, }; self.write_value(valty, dest) }; match other { Value::Scalar(value) | Value::ScalarPair(value, _) => write_next(value)?, _ => unreachable!(), } if let Value::ScalarPair(_, value) = other { write_next(value)?; } } assert!(arg_locals.next().is_none()); } </del> <ins> for (i, arg_local) in arg_locals.enumerate() { let field = mir::Field::new(i); let valty = self.read_field(args[1].value, None, field, args[1].ty)?; let dest = self.eval_place(&mir::Place::Local(arg_local))?; self.write_value(valty, dest)?; </ins> } } else { trace!("manual impl of rust-call ABI");

Discussion:
I saw that was closed when was merged so I thought it would fix the same error on my own code as well however as of nightly: it still happens. Code: Playground: From what I can tell its an alignment issue because changing id from a to a fixes the issue.
Change:
<ins> #![feature(postfix_match)] use std::ops::Add; //@ pretty-mode:expanded //@ pp-exact:precedence.pp macro_rules! repro { ($e:expr) => { $e.match { _ => {} } }; } struct Struct {} impl Add<Struct> for usize { type Output = (); fn add(self, _: Struct) -> () { () } } pub fn main() { let a; repro!({ 1 } + 1); repro!(4 as usize); repro!(return); repro!(a = 42); repro!(|| {}); repro!(42..101); repro!(1 + Struct {}); } </ins>

Discussion:
As of current nightly, produces this: which is not valid Rust syntax. The correct output would contain . tracking issue:
Change:
} else if self.check(&token::BinOp(token::Or)) || self.check(&token::OrOr) { self.parse_closure_expr(attrs) } else if self.check(&token::OpenDelim(token::Bracket)) { <del> self.parse_array_or_repeat_expr(attrs) </del> <ins> self.parse_array_or_repeat_expr(attrs, token::Bracket) </ins> } else if self.check_path() { self.parse_path_start_expr(attrs) } else if self.check_keyword(kw::Move) || self.check_keyword(kw::Static) {

Discussion:
I ended up spending way too much time debugging the following error, since I was trying to port some C code to rust. Give the error: The error message is very vague and hard to determine the actual error here. Seeing as though some programming languages like Java and C use for arrays, I think it'd make sense for the compiler to suggest using if the user is trying to create an array. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I suppose adding manual diagnostic somewhere around will get the job done. claim
Change:
match snapshot.parse_array_or_repeat_expr(attrs, token::Brace) { Ok(arr) => { let hi = snapshot.prev_token.span; <del> self.struct_span_err( arr.span, "this code is interpreted as a block expression, not an array", ) .multipart_suggestion( "try using [] instead of {}", vec![(lo, "[".to_owned()), (hi, "]".to_owned())], Applicability::MaybeIncorrect, ) .note("to define an array, one would use square brackets instead of curly braces") .emit(); </del> <ins> self.struct_span_err(arr.span, "this is a block expression, not an array") .multipart_suggestion( "to make an array, use square brackets instead of curly braces", vec![(lo, "[".to_owned()), (hi, "]".to_owned())], Applicability::MaybeIncorrect, ) .emit(); </ins> self.restore_snapshot(snapshot); Some(self.mk_expr_err(arr.span))

Discussion:
, we should provide a structured suggestion as we already do when . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
seems easy enough, claim
Change:
.as_deref() .map(|value| RustcLto::from_str(value).unwrap()) .unwrap_or_default(); <ins> config.rust_validate_mir_opts = rust.validate_mir_opts; </ins> } else { config.rust_profile_use = flags.rust_profile_use; config.rust_profile_generate = flags.rust_profile_generate;

Discussion:
Because currently it doesn't. has a handful of problems which are reported elsewhere, but discovering problems with MIR optimizations is often as simple as building the compiler with the optimization enabled and . So we should do that in CI. Note that all MIR opt levels are supposed to be sound, and known unsoundness is supposed to be gated behind , which I am not suggesting we test with. Currently attempting to build the standard library with these flags results in pages of this error: Which looks to me like <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
also mentioned to me that some opts are using as a minimum threshold, it may be helpful to test that as well (maybe in a separate builder). does not change the output of the compiler and should be ok to turn on unconditionally for libstd; we might want to be more selective about where we enable it for the compiler itself, though, since it's a lot slower. We should also have at least one builder where we enable for UI tests.
Mentoring instructions: new option to and This option should pass unconditionally for libstd. Test it works locally with , you should see the ICE posted above. that new option on all builders around here: You can test that works by opening a PR (please put in the description) and making sure it shows the same ICE. that works, we can figure out whether we want to enable this for rustc as well on some builders; maybe we should have separate and configs? And for turning it on in compiletest?
claim
Reproduced it on the PR.
Change:
<ins> // compile-pass // aux-build:promotable_const_fn_lib.rs #![feature(nll)] extern crate promotable_const_fn_lib; use promotable_const_fn_lib::{foo, Foo}; fn main() { let x: &'static usize = &foo(); let x: &'static usize = &Foo::foo(); } </ins>

Discussion:
apint fails to compile (https://crater-) on beta. Note that the crate must be compiled in test mode.
cc -- I believe this is your crate, though it seems plausible this is a bug in the compiler
cc -- beta/stable regression, would be good to proactively triage before meeting if possible
Could this be promotion-related?
Yea. The call to on arrays does not actually do what it advertises, it derefs to a slice and then does . We stopped allowing const fns in promoteds is still marked as promotable, so that shouldn't be the issue. I'll investigate later today when I get back to a PC
yeah that's my crate thanks for linking! I have already stumbled upon this CI error but couldn't yet find time to wrap my head around it. Though I thought it was a bug in a former version of the borrow checker that now got fixed. So if I understood correctly simply using a instead of plain would solve that issue? Maybe we should reiterate on this design for on arrays if that's the case. :D
minimal repro Nope, it's a new bug that I was sure we had regression tests against.
This was injected between rustc 1.31.0-nightly ( 2018-10-03) and rustc 1.31.0-nightly ( 2018-10-04) Log of bors commits in that time in the details block <details% git log .. --author bors --format=oneline Auto merge of - nikomatsakis:universes-refactor-1, r=scalexm Auto merge of - matthewjasper:mir-function-spans, r=pnkfelix Auto merge of - Manishearth:clippyup, r=oli-obk Auto merge of - pietroalbini:rollup, r=pietroalbini Auto merge of - christianpoveda:master, r=kennytm Auto merge of - oli-obk:local_promotion, r=eddyb Auto merge of - arielb1:evaluate-outlives, r=nikomatsakis Auto merge of - KiChjang:issue-, r=nikomatsakis Auto merge of - davidtwco:issue-, r=petrochenkov </details
Hmm I wonder if this could somehow be a consequence fo ...?

update: probably not, since this afflicts both AST-borrowck and MIR-borrowck.
Full diff: (limiting promotability of const fns) also fell in there.
I even unit tests, but never any for promoting functions from the libstd. will only work if a function call is promoted in the same crate where the function is declared. I think the solution is to make the const qualifier eagerly call while a function is qualified to cache the result (in the query engine), so that the query is never evaluated in the perspective of another crate (and add an ) to to safeguard against messing this up
Discussed a bit with and investigated independently. Some details of note: The implementation of relies on . If you don't have the latter, the former will essentially be silently ignored, AFAICT. It seems like there are some holes in 's analysis above. In particular, I attempted to make a unit test with multiple crates, and it seemed like promotion was still happening. See here:
reassigning to for followup investigation and hopefully fixing.
Change:
error: `#[target_feature(..)]` cannot be applied to safe trait method <ins> --> $DIR/trait-impl.rs:22:5 | LL |     #[target_feature(enable = "sse2")] |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot be applied to safe trait method LL | LL |     fn foo(&self) {} |     ------------- not an `unsafe` function error: `#[target_feature(..)]` cannot be applied to safe trait method </ins> --> $DIR/trait-impl.rs:13:5 | LL |     #[target_feature(enable = "sse2")]

Discussion:
The compiler currently allows safe default method implementations to be marked with : which I don't think is allowed in . For reference, is not allowed on trait implementations: From my limited testing, this doesn't seem to be unsound however, as the compiler seems to consider all implementations of as having . cc label T-lang T-compiler C-bug F-targetfeature11 <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
A good resolution to this would be to move it into a separate feature gate I guess?
claim
Change:
// except according to those terms. // xfail-test <del> #[feature(quote_expr, quote_tokens, quote_item, quote_pat, quote_stmt)]; </del> <ins> #[feature(quote)]; </ins> #[feature(managed_boxes)]; extern mod syntax;

Discussion:
These all are only useful in the compiler, aren't hygienic, etc. Nominating.
What hygiene issues do they still have? The hygiene issue I'm aware of was fixed by . They'll be very useful for externally defined syntax extensions. I'm okay with feature gating it though.
The only thing I recall is that they require an to be in scope. Perhaps that's not technically a hygiene problem.
Accepted for 1.0, P-backcompat-lang.
I would like to look at this, but I am not familiar to quasi-quoting. Can you list some quasi-quoting macros, or point out the directory of the source tree to look up? What I have found related to quasi-quoting lies on .
All of the quasi-quoting macros live there.
Their .
Change:
it to [Crates.io](http://crates.io). Easier said than done, but very, very valuable! <del> [pound-rust]: http://chat.mibbit.com/?server=irc.mozilla.org&channel=%23rust </del> <ins> [rust-discord]: https://discord.gg/rust-lang </ins> [users]: https://users.rust-lang.org/ [so]: http://stackoverflow.com/questions/tagged/rust [community-library]: https://github.com/rust-lang/rfcs/labels/A-community-library

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:
} } <ins> // If we're inside the vendor directory then we need to preserve // everything as Cargo's vendoring support tracks all checksums and we // want to be sure we don't accidentally leave out a file. if spath.contains("vendor") { return true } </ins> let excludes = [ "CVS", "RCS", "SCCS", ".git", ".gitignore", ".gitmodules", ".gitattributes", ".cvsignore", ".svn", ".arch-ids", "{arch}",

Discussion:
The process of creating the tarballs doesn't include .gitignore files from src/vendor. This results in a missmatched hash failure when building with vendoring enabled. Hoping to switch to rustbuild with the next rust release! FYI: I'd be happy with the vendoring happening during the create tarball process, having enormous vendoring commits in the git history is ugly... !
Needs to be fixed for 1.15.
cc
Seems like the vendoring process should include a sanity check that the vendored sources hash correctly.
Fixed in
Things move fast around here. Awesome thanks!
Change:
}) } <del> fn recover_local_after_let(&mut self, lo: Span, attrs: AttrWrapper) -> PResult<'a, Stmt> { self.collect_tokens_trailing_token(attrs, ForceCollect::No, |this, attrs| { let local = this.parse_local(attrs)?; // FIXME - maybe capture semicolon in recovery? Ok(( this.mk_stmt(lo.to(this.prev_token.span), StmtKind::Local(local)), TrailingToken::None, )) }) } </del> /// Parses a local variable declaration. fn parse_local(&mut self, attrs: AttrVec) -> PResult<'a, P<Local>> { let lo = self.prev_token.span;

Discussion:
<!-- 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. --: <details<summary<strongBacktrace</strong</summary<p</p</details label A-parser A-macros <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
cc this should probably be gated with your "may eagerly recover" work as well
This code is actually already mentioned in ;)
claim
Yeah, gating this recovery behind a is the correct fix here.
Also very fun that these things can ICE sometimes.
Found these also panic: Since these are highly related to the case, one pull request can fix all of these (maybe).
Change:
RUN sh /scripts/sccache.sh ENV RUST_CONFIGURE_ARGS --qemu-riscv64-rootfs=/tmp/rootfs <del> ENV SCRIPT python3 ../x.py --stage 2 test --target riscv64gc-unknown-linux-gnu </del> <ins> ENV SCRIPT python3 ../x.py --stage 2 test --host='' --target riscv64gc-unknown-linux-gnu </ins> ENV NO_CHANGE_USER=1

Discussion:
Some run-make tests require an directive as a workaround for link failures that occur during CI. and or modified tests to include this directive in order to avoid at least this error: . I assume that this shouldn't be necessary, and that there is actually some deficiency in our CI build system that we can fix.
Never mind, it may not be related. Sorry for the noise.