jiebi/CodeConvo huggingface dataset:
Change:
<ins> // aux-build:param-attrs.rs // check-pass #![feature(param_attrs)] #![feature(c_variadic)] extern crate param_attrs; use param_attrs::*; struct W(u8); #[attr_extern] extern "C" { fn ffi(#[a1] arg1: i32, #[a2] ...); } #[attr_extern_cvar] unsafe extern "C" fn cvar(arg1: i32, #[a1] mut args: ...) {} #[attr_alias] type Alias = fn(#[a1] u8, #[a2] ...); #[attr_free] fn free(#[a1] arg1: u8) { let lam = |#[a2] W(x), #[a3] y| (); } impl W { #[attr_inherent_1] fn inherent1(#[a1] self, #[a2] arg1: u8) {} #[attr_inherent_2] fn inherent2(#[a1] &self, #[a2] arg1: u8) {} #[attr_inherent_3] fn inherent3<'a>(#[a1] &'a mut self, #[a2] arg1: u8) {} #[attr_inherent_4] fn inherent4<'a>(#[a1] self: Box<Self>, #[a2] arg1: u8) {} } trait A { #[attr_trait_1] fn trait1(#[a1] self, #[a2] arg1: u8); #[attr_trait_2] fn trait2(#[a1] &self, #[a2] arg1: u8); #[attr_trait_3] fn trait3<'a>(#[a1] &'a mut self, #[a2] arg1: u8); #[attr_trait_4] fn trait4<'a>(#[a1] self: Box<Self>, #[a2] arg1: u8, #[a3] Vec<u8>); } fn main() {} </ins>

Discussion:
As this This is the example proc-macro: This is the test: Run both of result and result are: Formal parameter attributes disappear in proc-macro. Toolchain:
cc
I have a fix in
Change:
UV_UDP_SEND, UV_FS, UV_WORK, <ins> UV_GETNAMEINFO, </ins> UV_GETADDRINFO, UV_ACCEPT, UV_FS_EVENT_REQ,

Discussion:
For example, this program prints on unix, and on windows:
The appears to be different on windows for both libgreen and libnative.
I believe this happens because the arguments end up being quoted for Windows. Simplest fix would be to drop empty arguments. Thoughts?
(Alternatively, we could quote empty arguments on Unix.)
I would expect the empty arguments to be passed through as significant argument position. I ran into this in cargo because passed on unix but on windows it would try to consume the next argument for the test args. It looks like to fix this we just need to alter to see if the argument is 0-length, and if so we quote it. Libuv already does . I'm investigating a fix for libgreen, it looks like it should be working...
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. macro_rules! m { () => { 1 } } macro_rules! n { () => { 1 + m!() } } fn main() { let _: [u32; n!()] = [0, 0]; } </ins>

Discussion:
This crate compiles fine with beta (0.13.0-beta.1) and stable (0.12.0).
Last nightly that worked: nightly-2016-09-27
Could be a duplicate of , cc
I have a fresh build from master, fixed this as well.
Yay!

Version: rustc 1.13.0-nightly ( 2016-09-27) thinks you may have some insight into this...
This was probably caused by -- I'll investigate.
Fixed in -- thanks for the report!
Change:
impl<'self> fmt::Default for Item<'self> { fn fmt(it: &Item<'self>, fmt: &mut fmt::Formatter) { <ins> match attr::find_stability(it.item.attrs.iter()) { Some(stability) => { write!(fmt.buf, "<a class='stability {lvl}' title='{reason}'>{lvl}</a>", lvl = stability.level.to_str(), reason = match stability.text { Some(s) => s, None => @"", }); } None => {} } </ins> // Write the breadcrumb trail header for the top write!(fmt.buf, "<h1 class='fqn'>"); match it.item.inner {

Discussion:
Nominating for milestone 5, production-ready
Can't be done without running resolve.
should be optional at most, as sometimes you want to see them
just a bug, removing milestone/nomination.
Still relevant though parenting to metabug on rustdoc_ng
/cc This would involve looking at the visibility of the associated trait and excluding the impl from the list if it's not public.
Didn't find a trait to test it with but it should be done now.
Change:
<ins> // Copyright 2015 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. // exec-env:RUST_LOG=rustc::middle=debug fn main() { let b = 1isize; println!("{}", b); } </ins>

Discussion:
Per theme in , here's a minimized example exhibiting the same ICE:
This also triggers an ICE. The error and backtrace: output of rustc --version --verbose Note that removing the where clause eliminates the error. (although it isn't used anywhere)
Yet another variant:
Slight variant:
I'm currently getting the following ICE on the latest version of : The relevant code fragments: Changing the method call to use function notation, i.e. , as indicated in did not work here.
Change:
fn is_shadow(cx: &LateContext<'_>, owner: LocalDefId, first: ItemLocalId, second: ItemLocalId) -> bool { let scope_tree = cx.tcx.region_scope_tree(owner.to_def_id()); <del> let first_scope = scope_tree.var_scope(first); let second_scope = scope_tree.var_scope(second); </del> <ins> let first_scope = scope_tree.var_scope(first).unwrap(); let second_scope = scope_tree.var_scope(second).unwrap(); </ins> scope_tree.is_subscope_of(second_scope, first_scope) }

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. --<!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I was just looking at the parsing code for const generic exprs.. claim
actually, so this isn't related to incorrectly parsing , since we're parsing in expr position to allow if-let chains.. -- this is due to const eval lowering to MIR and the fact that const generic parameters have no enclosing scope. Adding around the generic args works, but I don't know where exactly to hack in a scope for these params. release-assignment label A-const-eval A-mir
Maybe fixing this also fixes :slightlysmilingface:
This gives an error without ICE in 1.55
It was unclear to me - I think meant that changing to gives a compile error instead of an ICE. So the proper fix here is probably to add somewhere instead of panicking.
Then this should be easy. claim
Change:
// `val` dropped here while still borrowed // borrow might be used here, when `val` is dropped and runs the `Drop` code for type `std::rc::Weak` } <del> #[test] fn rc_from_vec_opt() { let mut v = Vec::with_capacity(64); v.push(0usize); let addr = v.as_ptr().cast::<u8>(); let rc: Rc<[_]> = v.into(); unsafe { assert_eq!( rc.as_ptr().cast::<u8>().offset_from(addr), (std::mem::size_of::<usize>() * 2) as isize, "Vector allocation not reused" ); } } </del>

Discussion:
Miri reports UB in the new test: On first sight, the error seems legitimate. That test got in Cc
Probably what happens is that in Miri, will always move the data to a new location, and then the way the test checks whether that happened causes UB. You should not call unless you are already 100% sure that both pointer point to the same allocation -- and in this case, you cannot be sure of that, since allocators do not promise that keeps the same allocation. In fact, it might be the case that even if keeps the data in-place, the allocation has a new provenance -- it is considered a new allocation at the same location, but all old pointers are invalid now and must be 'refreshed'. So this code probably has UB even if keeps the allocation in-place. I recall this was discussed somewhere at some point, and I think the C standard contains wording along these lines, but I forgot the details... Cc The fix is easy -- just do and later compare that with . The test will still fail in Miri though, and in other allocators that do not shrink in-place.
Yeah, the C standard is quite explicit about this, so for now we should follow suit. Opened
Might it be a good idea to the pointer comparison itself, so that Miri can check the actual implementation, even if it can't check the final assertion. I did suspect that other platforms might not have this behaviour - seems to show this. It might be best to feature gate the test and opt to only platforms with allocators that work like this.
Yes, but to be clear there are two bugs here: the test can fail in some platforms, such as Miri, when realloc doesn't shrink in-place the test has UB on all platforms because the two pointers are into different allocations (realloc conceptually creates a new allocation, even if it remains in-place), but is explicitly documented to only work on pointers within the same allocation
Is the comparison still UB? I'm currently working on a patch that Uses the cast for comparison Turns off this feature for non-GNU targets (since that's the only one I know for sure has the shrink-in-place behaviour) Disables the test on non GNU, and the comparison itself on Miri With that in mnd though, I'm wondering if this opt should just be removed entirely.

The perf wins I got in testing were pretty small for the amount of maintenance headache this seems likely to cause
returns regular integers, you can compare them in whatever way you want.
Change:
<del> Subproject commit 453affaaa1762a065d2857970b8333017211208c </del> <ins> Subproject commit 5dde0fe6de2941c9ef16bc1e9d91ecf20ac5ee8b </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri 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!
Change:
} else { // Defer other checks until we're done type checking. let mut deferred_cast_checks = self.deferred_cast_checks.borrow_mut(); <del> match cast::CastCheck::new(self, e, t_expr, t_cast, t.span, expr.span) { </del> <ins> match cast::CastCheck::new( self, e, t_expr, t_cast, t.span, expr.span, self.param_env.constness(), ) { </ins> Ok(cast_check) => { debug!( "check_expr_cast: deferring cast from {:?} to {:?}: {:?}",

Discussion:
Compiles in stable rust (1.64) as well as in beta. But in nightly, we get this compilation error: playground link: 64, and beta current nightly
searched nightlies: from nightly-2022-08-01 to nightly-2022-10-24 regressed nightly: nightly-2022-09-23 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Seems like closures pick the constness of their parent when they should always be notconst
Change:
<ins> error[E0277]: the trait bound `<T as A>::AssocA: TransmuteFrom<(), Assume { alignment: false, lifetimes: false, safety: false, validity: false }>` is not satisfied --> $DIR/assoc-bound.rs:16:19 | LL |     type AssocB = T::AssocA; |                   ^^^^^^^^^ the trait `TransmuteFrom<(), Assume { alignment: false, lifetimes: false, safety: false, validity: false }>` is not implemented for `<T as A>::AssocA` | note: required by a bound in `B::AssocB` --> $DIR/assoc-bound.rs:9:18 | LL |     type AssocB: std::mem::TransmuteFrom<()>; |                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^ required by this bound in `B::AssocB` help: consider further restricting the associated type | LL |     T: A, <T as A>::AssocA: TransmuteFrom<(), Assume { alignment: false, lifetimes: false, safety: false, validity: false }> |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error[E0277]: `()` cannot be safely transmuted into `<&i32 as A>::AssocA` --> $DIR/assoc-bound.rs:24:19 | LL |     type AssocB = <&'static i32 as A>::AssocA; |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^ `<&i32 as A>::AssocA` has an unknown layout | note: required by a bound in `B::AssocB` --> $DIR/assoc-bound.rs:9:18 | LL |     type AssocB: std::mem::TransmuteFrom<()>; |                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^ required by this bound in `B::AssocB` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'not implemented: NormalizationFailure(Alias(Projection, AliasTy { args: [T/], defid: DefId(0:12 ~ a[cc78]::Aaa::Y), .. }), Type(Alias(Projection, AliasTy { args: [T/], defid: DefId(0:12 ~ a[cc78]::Aaa::Y), .. })))'', 'thread 'rustc' panicked at 'not implemented: NormalizationFailure(Alias(Projection, AliasTy { args: [T/], defid: DefId(0:12 ~ a[cc78]::Aaa::Y), .. }), Type(Alias(Projection, AliasTy { args: [T/], defid: DefId(0:12 ~ a[cc78]::Aaa::Y), .. })))'' 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: [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regression in nightly-2024-08-22 seems to bisect to
Slightly more reduction:
(Note that this reduction should drop the feature gate, as this ICEs without the feature gate)
claim
Change:
} else { self.valid_promotion_candidates() }; debug!("qualify_const: promotion_candidates={:?}", promotion_candidates); for candidate in promotion_candidates { match candidate { <del> Candidate::Repeat(Location { block: bb, statement_index: stmt_idx }) => { if let StatementKind::Assign(box(_, Rvalue::Repeat( Operand::Move(place), _ ))) = &self.body[bb].statements[stmt_idx].kind { if let Some(index) = place.as_local() { promoted_temps.insert(index); } } } </del> Candidate::Ref(Location { block: bb, statement_index: stmt_idx }) => { <del> if let StatementKind::Assign( box( _, Rvalue::Ref(_, _, place) ) ) = &self.body[bb].statements[stmt_idx].kind { if let Some(index) = place.as_local() { promoted_temps.insert(index); </del> <ins> if let StatementKind::Assign(box( _, Rvalue::Ref(_, _, place))) = &self.body[bb].statements[stmt_idx].kind { if let PlaceBase::Local(local) = place.base { promoted_temps.insert(local); </ins> } } } <del> Candidate::Argument { .. } => {} </del> <ins> // Only rvalue-static promotion requires extending the lifetime of the promoted // local. Candidate::Argument { .. } | Candidate::Repeat(_) => {} </ins> } }

Discussion:
Consider the following code: The borrow of the tuple field in is promoted out along with the tuple itself in accordance with the rules for rvalue static promotion. However, in the , the mechanism for promotion does not remove / for the tuple, causing to dangle. On stable, this is only caught during const-evaluation and results in a warning. If this warning is supressed, an ICE occurs. On nightly, the MIR borrow checker prevents this from happening, and this code is rejected instead. It should be accepted in all contexts.
Change:
means that they're a 'view' into an already-allocated string, such as a string literal or a `String`. <del> # String </del> <ins> ## `str` You may occasionally see references to a `str` type, without the `&`. While this type does exist, it’s not something you want to use yourself. Sometimes, people confuse `str` for `String`, and write this: ```rust struct S { s: str, } ``` This leads to ugly errors: ```text error: the trait `core::marker::Sized` is not implemented for the type `str` [E0277] note: `str` does not have a constant size known at compile-time ``` Instead, this `struct` should be ```rust struct S { s: String, } ``` So let’s talk about `String`s. # `String` </ins> A `String` is a heap-allocated string. This string is growable, and is also guaranteed to be UTF-8. `String`s are commonly created by

Discussion:
The distinguishes between and but makes no mention of a third type people will come across: . is defined as the type which you refer to? Perhaps define as the type and mention that in most cases it must be borrowed... This honestly threw me the first time I saw it. I thought, "what is 's only and ...". : Error:
Note: is an unsized type, and is simply a pointer to the unsized type (like or ). But I agree that the docs could be clearer.
The error messages can be quite unfriendly for new users. I recently saw someone attempt: The error: Doesn't mean much to a new user. What does that mean to users? Is there a valid reason to ever use in code? The doc says So it's not a valid type? But the error message you gave me said "for the type " ... If it's not valid why doesn't the compiler say so in the error message above, instead of complaining that it's unsized?
Today, this is the string chapter of the book.
Change:
<ins> #![crate_type = "lib"] use std::alloc::System; #[global_allocator] static ALLOCATOR: System = System; pub fn do_something() { format!("allocating a string!"); } </ins>

Discussion:
I have a project that overrides the global allocator in , and recently noticed that I can no longer link the test binary for my project with recent beta/nightly compilers. points to which certainly looks relevant. I reproduced the error using a slightly modified example from the global allocator documentation: If I move the allocator definition from to , I no longer have a problem. Is that the right thing to do? If so, do I need to do anything else to make sure my tests use the desired allocator? I tried this code: I expected to see this happen: Instead, this happened: searched nightlies: from nightly-2023-05-25 to nightly-2023-06-16 regressed nightly: nightly-2023-05-26 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details modify labels: +regression-from-stable-to-beta -regression-untriaged
Adding the full linker error output here in case it's of interest.
I tried adding based on a brief look at the change that pointed to. It doesn't seem to make any difference, but that's why it's in my repro above.
I can reproduce this. and such are properly defined in the library rlib. It seems to be caused by the library order. Traditional linkers require symbols to have their uses in object files before their definition. So for circular dependencies and has to be used or libraries have to be mentioned multiple times. And indeed which doesn't have this restriction is entirely fine with this. I think registering a circular dependency between the defining crate of and liballoc (and every crate that depends on it) at would work. Edit: Reading the code it references closer, I think adding to would be enough to fix this. I can't work on this tomorrow, but unless someone else picks it up, I will work on this.
Finished some work early. fixes the issue.
thank you for the quick fix!
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
TestDescAndFn, TestOpts, run_test, MetricMap, StaticTestName, DynTestName, DynTestFn, ShouldPanic}; use std::sync::mpsc::channel; <ins> use bench; use Bencher; </ins> #[test] pub fn do_not_run_ignored_tests() {

Discussion:
functions are run multiple times. Some benchmark functions might depend on some runtime initialisation which may fail. For example: Will print “Benchmarks on even hours are forbidden!” a lot of times. If one opts to not report set-up failure, the benchmark function just keeps processor hot for a while without actually benchmarking anything (and reporting 0ns/iter anyway). Would it be sensible to (one of possible solutions): Not run the same function multiple times, since iteration is done by ; Not run the same again if is not called at least once; Provide a method on to cancel all subsequent runs of the function? Or maybe my approach is incorrect?
If one tries to keep benchmarks in separate files and opts for to cancel further runs of the function, the panic will abort the whole benchmark process (i.e. including the benchmarks in other executables).
For , we want to run on the CI infrastructure to ensure all the tests build. However, we don't want to actually benchmark on the CI infrastructure, because the CI infrastructure isn't reliable enough for benchmarking. Thus, doing more than one iteration on the CI infrastructure just wastes time. And, that time, in particular the wall time, negatively affects my other repos, because generally CI services like Travis CI and Appveyor only allow one project to build at a time, for their free open source tiers. Further, even out side of CI infrastructure, we want contributors to run the benchmarks before sending PRs. But, it's not reasonable to expect them to wait through many minutes of perf tests before asking for a PR. Here are two ideas: a that overrides the default targeted benchmark execution time so that we can write to run tests once. a so we can write . I prefer because that also might help with
Never mind. I just learned that will do exactly what I want: run the benchmarks once each.
This was bugging me, so I implemented the first proposed option: As this is my first real rust code, I imagine its pretty bad quality. A fist attempt is here: I'll clean it up a bit, give it some more testing, then send in a pull request unless anyone offers any opinions before I get that far.
Does anyone have an example on how to use this feature ? I'd like to run a benchmark only once.
:frowning_face: