jiebi/CodeConvo huggingface dataset:
Change:
#[unsafe_destructor] impl<'a> Drop for Finallyalizer<'a> { <ins> #[inline] </ins> fn drop(&mut self) { (self.dtor)(); }

Discussion:
While landed a nice optimization of in , he said that it's still not performing as fast as doing a malloc and a . We should figure out why it is not performing as well as it should be and fix it in order to remove the temptation of using the faster unsafe functions.
It turns out this is substantially slower than I expected. With this test benchmark: I'm getting these results: This is related to and .
mentioned in irc that with the difference is: Which is much better, but still not great.
memset "cheats" with sse. fromelem spends a lot of time in moveval_init without optimizations so there's a bunch of unnecessary function calls. With optimizations, the thing that's killing it is the copies.
LLVM knows how to optimize loops to the same code as memcpy/memmove/memset though, as long as you generate good IR.
I a bench for the literal vec repeat syntax as well: Without optimizations: With optimizations (-O): Looking at the optimized IR, both setmemory and vecrepeat become a memset but setmemory seems to have a lot more overhead. does not become a memset hence the bad results.
this gets a lot better with the optimization passes from , from ~3x as slow to ~2x as slow Before (opt-level=2): After (opt-level=2)
the problem is with the code bloat from the surrounding code, rather than itself - I think we actually produce some IR there with undefined behaviour
greatly speeds up , fixing half of the issue Before: After:
The performance of all 3 has improved, but got slower relative to the others:
It looks like the remaining issue is our pointer arithmetic being slow. The and functions compile to conversions to and from integers, rather than actual pointer arithmetic with the stricter semantics. I think we need to make the and implementations for pointers a compiler feature.
Fixed by .
This since that fix, is attempting a bisect atm. Update: bisect finished, is to blame. isn't optimized. Maybe the needs to be inlined for further optimizations.
Note that set_memory has regressed by ~16ns, cause is ()
Change:
use std::iter; <del> use astconv::{AstConv, Bounds}; </del> <ins> use astconv::AstConv; use bounds::Bounds; </ins> fn require_c_abi_if_c_variadic(tcx: TyCtxt<'_>, decl: &hir::FnDecl<'_>, abi: Abi, span: Span) { if decl.c_variadic && !(abi == Abi::C || abi == Abi::Cdecl) {

Discussion:
That file () has almost 3k LOC and just 3 lines of documentation on the file (methods and types are documented though). I'm entirely unsure how to process that file. I think splitting it up into submodules (e.g. start by extracting out all functions just handling error reporting into a separate module). Some of this work can be just mechanical splitting up, but some parts may require you to start understanding at least some of what's going on in the file in order to find a good module structure. cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I'll do it, although I am not familiar with the . At least the mechanical part is no problem. As to the model structure, I am going to dive into that issue so I can better think of a reasonable structure. If it is a problem that I am not familiar with the topic, I will back down, no worries.
That's awesome. Please wait until is merged though (you can subscribe to it so you see when it does get merged), because otherwise you'll just get loads of conflicts.
If you are unsure about the module structure, you can first post a design suggestion here if you want.
assign
You still working on this?
Not quite, my other PR is not yet through and I thought I wait for it. But if you want to do it, just take it. If not I'll be on it soon.
I would like to claim this, if nobody minds
assign It's all yours!
release-assignment
I'd like to work in this if is not on it anymore
generally it's fine if it's 3 months and there is no pr from the author. you can start working on it
Gotcha, thanks
claim
Change:
<ins> error: unused variable: `x` --> $DIR/let-else-then-diverge.rs:11:13 | LL |         let x = 5; |             ^ help: if this is intentional, prefix it with an underscore: `_x` | note: the lint level is defined here --> $DIR/let-else-then-diverge.rs:6:9 | LL | #![deny(unused_variables)] |         ^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: A helpful error message pointing to the end of the block. Instead, this happened: An error message with a wrong span: <!-- 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. --: cc labels: +T-compiler +F-let-else +requires-nightly +A-diagnostics
Let's try that again... label +T-compiler +F-let-else +requires-nightly +A-diagnostics
FTR this is the error for the equivalent:
I wonder how is affecting this, as this seems to be a bug in the desugaring and that PR changes it. what is the error output with your PR applied? Does it fix the issue? If so, maybe adding a test to your PR would be helpful.
I meant caused by the desugaring, not in the desugaring.
It won't fix it. This needs a bit of work I think, to push the error further inside the if-let-else branch, so the span marked is the implicit return expression or lack thereof, which is (in the source code) further down in the block.
Hmm if you move the println into the , it gives a similar error to the one emitted by : gives
That's because you have only now reproduced the actual desugaring.
Change:
//! assert_eq!(1 + 1, 2); //! ``` <ins> extern crate extern_macros as macros; use macros::attrs_on_struct; </ins> pub mod foo { /// ```

Discussion:
Doctest test names have changed due to . Doc comments that pass through a macro defined in another crate now seem to report a different span. /// assert!(true); /// running with previously looked like this: Now the test names look like this: Frankly, neither are particularly great. It would be nice if the test name used the span from where the macro was invoked, not where it was defined.
I think this also affects normal backtraces :( Just got this rather unuseful backtrace while bootstrapping: full:
cc
What you're describing is entirely in the opposite direction, is the old (and arguably bad) kind of that's impossible to get anymore. I've hidden your comment to focus on the reported issue.
That makes sense, we have a way to get the outermost invocation, that is used by / and : We'd just need to use this in .
cc
cc
Removed label, left nomination for to decide about this issue.
Well, using what suggested seems like the best thing to do.
Change:
<ins> error: constant expression depends on a generic parameter --> $DIR/sneaky-array-repeat-expr.rs:11:20 | LL |     let bar = [(); <()>::Assoc]; |                    ^^^^^^^^^^^ | = note: this may fail depending on what value the parameter takes error: constant expression depends on a generic parameter --> $DIR/sneaky-array-repeat-expr.rs:25:21 | LL |     let bar2 = [(); <()>::Assoc2]; |                     ^^^^^^^^^^^^ | = note: this may fail depending on what value the parameter takes error: aborting due to 2 previous errors </ins>

Discussion:
: <details<summaryerror output</summary</details
Rust playground:
Have you been able to reproduce this ICE with the latest nightly?
Playground link is not failing, I guess it's a good sign.
No longer ICEs since

The code below will trigger an ICE on the latest nightly build This is as small as i could make it while still triggering the error <!-- 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
Also occurs on stable! Regression from 1.50 to 1.51 modify labels: -requires-nightly +regression-from-stable-to-stable
Bisected: searched nightlies: from nightly-2020-01-01 to nightly-2021-04-29 regressed nightly: nightly-2021-01-18 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsRegressed PR is , cc
See and
just because something is gated doesn't mean it can't crash on stable ;) Use the above code and try to build it on the playground or compile it with a stable compiler, it will ICE.
We briefly discussed this on . I'd revert some labels here because we think this is a nightly-only issue due to the unstable feature. The fact that it compiles and reproduces on stable is kind of misleading because it's the that allows that. Makes sense? modify labels: +requires-nightly -regression-from-stable-to-stable +P-medium
sure enough ;) but just to be clear, even without this results in an ICE on stable
Okay so this is a bit complicated. Because while this does has , is still ICEs on stable. That said, not including the feature gate doesn't ICE. Given that, I think the current labels are appropriate, except maybe . It is technically a stable to stable regression, but it requires a feature to ICE, and I'm not sure that's the spirit of what that label is intended to track.
agreed on the labels, I've got the context partially wrong here. modify labels: -requires-nightly
With this also doesn't ICE
No longer ICEs since as far as I could tell with various combinations of the new feature gates
Change:
// error-pattern: evaluation of constant value failed <del> #![feature(const_unreachable_unchecked)] </del> const unsafe fn foo(x: bool) -> bool { match x {

Discussion:
Currently one cannot call in constant functions, so one cannot add hints of the form: These types of hints can heavily influence code generation, which can substantially change the performance of when they are invoked at run-time. It would be a shame to have to write and call and because the code generated for is sub-par. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
One cannot do any sort of conditional control flow, so would currently be less than useless. Any test you can write would be undefined behaviour
the RFC for / in const was merged and is pending an implementation right? When that's implemented, will still be useless?
No it makes sense after we have conditional control flow.
As I understand / in const functions is now implemented. Can be made into a now?
yes. Basically you just need to add the attribute to the intrinsic and wrapper function. This is documented at https://rustc-dev- Let me know if anything is unclear (in which case we should update the guide)
Hi, It looks like previous PR is not being worked on currently. I'm working on this and will create a PR soon. claim
As mentioned in , this issue should be reopened (to track stablization)
cc ^
After a short discussion on Zulip, it was decided that it's best to wait for to stabilize to avoid a potential footgun wherein users use this instead of , leading to UB at runtime. I'm subscribed to the issue and intend to file a PR to stabilize this once the aforementioned happens.
Change:
CFG_GCCISH_PRE_LIB_FLAGS_arm-apple-darwin := CFG_GCCISH_POST_LIB_FLAGS_arm-apple-darwin := CFG_DEF_SUFFIX_arm-apple-darwin := .darwin.def <del> CFG_LLC_FLAGS_arm-apple-darwin := -arm-enable-ehabi -arm-enable-ehabi-descriptors </del> <ins> CFG_LLC_FLAGS_arm-apple-darwin := </ins> CFG_INSTALL_NAME_arm-apple-darwin = -Wl,-install_name,@rpath/$(1) CFG_LIBUV_LINK_FLAGS_arm-apple-darwin = CFG_EXE_SUFFIX_arm-apple-darwin :=

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:
| = note: this error originates in the macro `check_ptr_exist` (in Nightly builds, run with -Z macro-backtrace for more info) <del> error[E0616]: field `name` of struct `CObj` is private --> $DIR/issue-25386.rs:26:43 | LL |     println!("{}", check_ptr_exist!(item, name)); |                                           ^^^^ private field error: aborting due to 2 previous errors </del> <ins> error: aborting due to previous error </ins> For more information about this error, try `rustc --explain E0616`.

Discussion:
The code below yields two errors: field is private error in if expression because type is instead of This means a user can observe the type of a private field of a dependency in their error messages. It doesn't mean they can actually use that information, but it seems weird at least. Is this actually an issue? If you don't consider it one, feel free to close this. - - (originally seen )
I won't close the ticket as this deserves a conversation to be had, but I personally don't consider it to be a big problem. Parsing x.len as when we suggest that would be nice, but in this case it would lead to confusing errors if we don't annotate the compiler state with something along the lines of
Hi Do any of you have opinions on this matter? I lean towards closing as "wontfix" because I feel the current behavior is acceptable.
I agree, like you mentioned , there are some improvements we could make, but I think the current behaviour is fine.
Change:
<ins> // compile-pass use std::num::NonZeroU8; const X: NonZeroU8 = unsafe { NonZeroU8::new_unchecked(5) }; const Y: u8 = X.get(); fn main() { } </ins>

Discussion:
and undo the const -fn changes in This requires changing applicable methods on from to , adding the attribute to all of them and adding some tests ensuring that the methods are not const fn on stable rust.
Ah, no, it requires conditional control-flow.
Ah I thought there were more trivial methods. This issue is only acctionable for at the moment
Hi, I'd like to help out on this. I would appreciate if some one gave me pointers on what needs to be accomplished.
Steps: to the attribute a test in that shows a const usage of the method (needs the feature gate specified in whether the linked commit above can be partially reverted
you may take a look at . These are the steps you have to do in order to add .
I will do that sir. Was busy with my internship.
If you need help, don't hesitate to ping me here, in Discord (Cyres) or on in the rust chat room.
Thank you
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. //! Implementations checker: builtin traits and default impls are allowed just //! for structs and enums. use middle::def; use middle::ty; use syntax::ast::{Item, ItemImpl}; use syntax::ast; use syntax::ast_util; use syntax::visit; use util::ppaux::UserString; pub fn check(tcx: &ty::ctxt) { let mut impls = ImplsChecker { tcx: tcx }; visit::walk_crate(&mut impls, tcx.map.krate()); } struct ImplsChecker<'cx, 'tcx:'cx> { tcx: &'cx ty::ctxt<'tcx> } impl<'cx, 'tcx,'v> visit::Visitor<'v> for ImplsChecker<'cx, 'tcx> { fn visit_item(&mut self, item: &'v ast::Item) { match item.node { ast::ItemImpl(_, _, _, Some(ref opt_trait), _, _) => { let trait_ref = ty::node_id_to_trait_ref(self.tcx, opt_trait.ref_id); if let Some(_) = self.tcx.lang_items.to_builtin_kind(trait_ref.def_id) { match trait_ref.self_ty().sty { ty::ty_struct(..) | ty::ty_enum(..) => {} _ => { self.tcx.sess.span_err( item.span, &format!("builtin traits can only be  implemented on structs or enums")[]); } } } } _ => {} } } } </ins>

Discussion:
Compiling with works fine, definitely does not, though: And, if the bound in is removed, the code compiles fine with or without . So... somehow the test runner is causing a tuple of arity 3 specifically to be inferred to something completely ridiculous.
cc I guess?
points out that specifically having causes the problem.
cc me
FYI: discovered this problem while working on
Slightly more minimized:
contains: This causes the problem.
I'll take a look at it.
Oh, I see you tracked it down -- I thought it might be something like that. This is in fact something I was talking to about as a possible danger of the way we're treating builtin bounds right now, though in a different context.
In fact, I think that the for a tuple ought to be a coherence violation to begin with, actually.
(I think there was language about specifically this in the OIBIT RFC)
I agree with comments here and after a quick chat on IRC with him, we agreed that implementations of built-in traits (and likely default trait impls in the future) should be allowed just on and .
Change:
// such. This helps prevent dependencies of the standard library, for // example, from getting documented as "traits `u32` implements" which // isn't really too helpful. <del> if let Some(stab) = cx.tcx.lookup_stability(did) { if stab.level.is_unstable() { return; </del> <ins> if let Some(trait_did) = associated_trait { if let Some(stab) = cx.tcx.lookup_stability(trait_did.def_id) { if stab.level.is_unstable() { return; } </ins> } } }

Discussion:
e.g., is missing the file/line/column method docs which are present in beta cc
Removing as this is issue.
Why?
A quick test indicates that copying the source of std::panic::Location out into a no_std crate doesn't fix the problem
Oh wait I don't have the latest nightly
As mentioned in , I'm not sure this should be prioritized under t-compiler's wg-prioritization. If this label is useful for the rustdoc team as well, we could tweak triagebot not to notify on Zulip.
Yeah it seems like it would be useful for us
Hmm so I am unable to reproduce this bug on a self contained no-core file that contains the exact code of aside for changes in the body
Regression range .. Auto merge of - Manishearth:rollup-9gxn4od, r=Manishearth Auto merge of - marmeladema:duration-consts-2, r=oli-obk Auto merge of - oli-obk:mir_const, r=RalfJung Auto merge of - Manishearth:rollup-i7iueu8, r=Manishearth Auto merge of - Manishearth:rollup-10vbpdh, r=Manishearth
Works in Regressing PR is
Rustdoc PRs in that rollup Rollup merge of - Manishearth:re-spotlight, r=GuillaumeGomez Rollup merge of - lzutao:rustdoc-tostring, r=GuillaumeGomez Rollup merge of - GuillaumeGomez:focus-source-file-sidebar, r=kinnison Rollup merge of - GuillaumeGomez:doc-alias-check, r=Manishearth Rollup merge of - euclio:rustdoc-highlighting, r=ollie27,GuillaumeGomez Rollup merge of - alexcrichton:ignore-unstable, r=estebank,GuillaumeGomez Rollup merge of - jyn514:name-resolve-first, r=eddyb
Confirmed, (try build from ) is the culprit
What's happening is that that code erroneously checks the stability of the impl, which apparently is "unstable if it contains unstable items". The "foreign item" check applies to libstd reexporting libcore. It shouldn't.

The minimal reproduction is two crates, one using stability attrs such that an impl has at least one unstable item, and the second crate reexporting the type.
I'm going to take a stab at fixing this.
Change:
hir::MatchSource::ForLoopDesugar, None); <del> // `{ let result = ...; result }` let result_ident = lctx.str_to_ident("result"); </del> <ins> // `{ let _result = ...; _result }` // underscore prevents an unused_variables lint if the head diverges let result_ident = lctx.str_to_ident("_result"); </ins> let let_stmt = stmt_let(lctx, e.span, false, result_ident, match_expr, None); let result = expr_ident(lctx, e.span, result_ident, None); let block = block_all(lctx, e.span, vec![let_stmt], Some(result));

Discussion:
Code: Warning: It probably has something to do with for loop desugaring.
I think this should be marked "E-Easy" Relevant code is in . Prefixing the variable name with an should probably be enough to fix this (and a testcase in )
E-easy‽ I'd like to try this one.
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. fn main() { if true { return } match () { () => { static MAGIC: uint = 0; } } } </ins>

Discussion:
Code sample: Backtrace and debug log:
Similar code without the feature does not cause a compiler error:
A smaller test case:
Neither of the test cases are ICEing for me today, I'm seeing the following:
Flagging as needstest

The error message doesn't say that the problem is mismatching mutability.
Looks like this can be closed, this is now: Edit: though now the complaint might be that it doesn't single out 'other'
Flagging as needstest (just in case a test doesn't already exist)
Change:
endif CFG_LIB_NAME_i386-apple-ios = lib$(1).a CFG_LIB_GLOB_i386-apple-ios = lib$(1)-*.dylib <ins> CFG_INSTALL_ONLY_RLIB_i386-apple-ios = 1 </ins> CFG_STATIC_LIB_NAME_i386-apple-ios=lib$(1).a CFG_LIB_DSYM_GLOB_i386-apple-ios = lib$(1)-*.dylib.dSYM CFG_GCCISH_CFLAGS_i386-apple-ios := -Wall -Werror -g -fPIC -m32 $(CFG_IOSSIM_FLAGS_i386-apple-ios)

Discussion:
Full gist:
cc
cc since you've been contributing iOS patches. This same error still repros after with: Are you able to successfully build a cross-compiler?
there are 2 different things: building and installing. What fails is phase and I believe I have kind of dirty hack for it in my fork, but will try to find a correct solution and issue PR soon.
this one ?
yep
cool, would you mind submitting that PR?
since PR is going to be open for a while considering current bors queue, I have to mention that in general when you need up-to-date Rust for iOS you can either built it by yourself from or use a prebuilt version from It may lag a bit (usually <= 1 day) but it is guaranteed to build (as iOS is not on Rust official buildbots and master is broken sometimes).