jiebi/CodeConvo huggingface dataset:
Change:
/// in the given deque. The collection may reserve more space to speculatively avoid /// frequent reallocations. After calling `try_reserve`, capacity will be /// greater than or equal to `self.len() + additional` if it returns <del> /// `Ok(())`. Does nothing if capacity is already sufficient. </del> <ins> /// `Ok(())`. Does nothing if capacity is already sufficient. This method /// preserves the contents even if an error occurs. </ins> /// /// # Errors ///

Discussion:
Any methods of container types (12 in Rust 1,62.1, including duplicated ones in ), and maybe corresponding methods. - - - - ... and corresponding methods in . Documentations for describes "If the capacity overflows, or the allocator reports a failure, then an error is returned.". However, it does not give any guarantees about whether the content is preserved or not on that error. This guarantee (or absence of the guarantee) should be explicitly described.
At least for (and -based things like ) it's obvious to guarantee that, so we might as well. (Thank you, Rust, for insisting on move-is- so we don't have the "what if the move constructor panics" problems like C++.) I think it'll need to be to hashbrown before we can consider promising it for /, through -- there's no guarantee in <https://rust-
Modulo needing to add it in hashbrown, shall we see if we have consensus to say that failures preserve the current contents? merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [x] [ ] [x] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon.
Please feel free to post a PR for this.
Created a PR for this.
Change:
//~| WARNING this was previously accepted by the compiler //~| invalid vtable: size is bigger than largest supported object <ins> #[repr(transparent)] struct W<T>(T); // The drop fn is checked before size/align are, so get ourselves a "sufficiently valid" drop fn fn drop_me(_: *mut usize) {} const INVALID_VTABLE_ALIGNMENT_UB: W<&dyn Trait> = unsafe { std::mem::transmute((&92u8, &(drop_me as fn(*mut usize), 1usize, 1000usize))) }; //~^^ ERROR it is undefined behavior to use this value //~| invalid vtable: alignment `1000` is not a power of 2 const INVALID_VTABLE_SIZE_UB: W<&dyn Trait> = unsafe { std::mem::transmute((&92u8, &(drop_me as fn(*mut usize), usize::MAX, 1usize))) }; //~^^ ERROR it is undefined behavior to use this value //~| invalid vtable: size is bigger than largest supported object </ins> fn main() {}

Discussion:
The following code ICEs: To fix this, this code here needs to properly catch the "invalid size/align" error and turn it into a validation failure: But for this we first need to make these errors catchable by introducing separate variants into this enum: You can use the existing variant as a model; it does the same job for invalid drop function pointers in the vtable. Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'll take care of this claim
Change:
<ins> error[E0277]: `PhantomPinned` cannot be unpinned --> $DIR/suggest-pin-macro.rs:22:17 | LL |     dummy(test1.get_mut()); |                 ^^^^^^^ within `Test`, the trait `Unpin` is not implemented for `PhantomPinned` | = note: consider using the `pin!` macro consider using `Box::pin` if you need to access the pinned value outside of the current scope note: required because it appears within the type `Test` --> $DIR/suggest-pin-macro.rs:5:8 | LL | struct Test { |        ^^^^ note: required by a bound in `Pin::<&'a mut T>::get_mut` --> $SRC_DIR/core/src/pin.rs:LL:COL error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
Consider the following code, taken from the (): Local pin construction was stabilized in . We should update the diagnostics to suggest this instead of the more expensive call. No response cc/ This is probably a "good first issue" as well. If someone can tag it as such? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
In some cases, works but does not (e.g., if you want ownership of the pinned future), so I think it's better to suggest both. Or something like:
claim
Alright, the suggestion has been in . IDK how to link a PR to an issue though, should I just reference the issue in the description of the PR?
if you put " in the PR description, it will automatically close this issue when the PR is merged :)
Change:
pub struct MyString; /// See also [char] <del> // @has intra_link_prim_precedence/struct.MyString2.html '//a/@href' 'intra_link_prim_precedence/char/index.html' </del> <ins> // @has intra_link_prim_precedence/struct.MyString2.html '//a/@href' 'https://doc.rust-lang.org/nightly/std/primitive.char.html' </ins> pub struct MyString2; <ins> /// See also [crate::char] and [mod@char] // @has intra_link_prim_precedence/struct.MyString3.html '//*[@href="../intra_link_prim_precedence/char/index.html"]' 'crate::char' // @has - '//*[@href="../intra_link_prim_precedence/char/index.html"]' 'mod@char' pub struct MyString3; </ins>

Discussion:
For example in the doc for : The in the doc links to instead of . Outside of the standard library, links to the primitive, unless there is a statement in which case it links to the module.
Therefore we should try to link to types before modules I assume? I'll see how it comes out.
Yes I think types should go before modules. After all it's always possible to use charstd::charstd::charchar` as the link text.
Oh btw, you can force the resolution by adding the type before hand like . I wonder if this is documented somewhere... Just like you can say it's a macro by at the end or a function by adding at the end.
It comes from the compiler directly. We need to re-order how the items are resolved. cc
an alternative is to resolve in an empty module first and only then resolve in the current scope. This ambiguity is only possible for primitives, any other types will give a multiple definition error: Since primitives are always in scope they will be the only thing in scope in the empty module (assuming there's no , , or keyword).
Originally posted by in is this still your opinion? That would mean closing this issue as wontfix, but I'm not convinced that's the most clear behavior.
Well, I would close this as fixed, but yes. I think this is a pretty rare situation to be in and the current behavior is not incorrect, it's just surprising, but "fixing" it would also make it surprising to another group.
and I discussed this again and decided it would be less surprising than the current behavior ( himself made the same mistake in !) So I plan to implement this sometime soon.
Change:
<ins> error[E0425]: cannot find function `consume` in this scope --> $DIR/suggest-method-on-call-for-ambig-receiver.rs:10:13 | LL |             consume(right); |             ^^^^^^^ not found in this scope error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0425`. </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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
Maybe but probably easier to debug from scratch.
Change:
self.check_def_id(item, data.principal_def_id()); } ty::TyBox(..) => { <del> self.check_def_id(item, self.tcx.lang_items.owned_box().unwrap()); </del> <ins> match self.tcx.lang_items.require_owned_box() { Ok(trait_id) => self.check_def_id(item, trait_id), Err(msg) => self.tcx.sess.span_fatal(item.span, &msg), } </ins> } ty::TyChar => { self.check_primitive_impl(def_id,

Discussion:
Hi, first time contributor here. This might be a bug. I think every factor mentioned in the title is required to trigger this. (I'm trying to do horrible things to the runtime, but I don't think this is significant here.) Source: Backtrace (rustc 0.13.0-nightly ( 2015-01-04 00:50:59 +0000) installed via rustup on Ubuntu LTS):
This happened to me as well, with an almost identical program. More info:
Following the backtrace, it looks like assumes that the 'ownedbox' lang item is always defined and calls unwrap(), triggering the panic.
Triage: still ICEs:
Change:
<ins> // Regression test for #80779. pub struct T<'a>(&'a str); pub fn f<'a>(val: T<'a>) -> _ { //~^ ERROR: the type placeholder `_` is not allowed within types on item signatures g(val) } pub fn g(_: T<'static>) -> _ {} //~^ ERROR: the type placeholder `_` is not allowed within types on item signatures fn main() {} </ins>

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. --: Note: Same error on stable and beta. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
this works for me on latest nightly. If you update your version of the compiler, does it work for you?
Oh oops, I was missing , sorry:
Slightly smaller: If you change to , it works, so I think this is while trying to infer .
glacier ""
This issue has been fixed by , marking as .

<!-- 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. --Hi, it appears that I've stumbled upon an internal compiler error. I'm sorry that I can't provide a minimal example, but I'm not on a level to understand what is going on (at least for now, heh :P). I'm just here, because the compiler told me to go here. I have, however, pushed a commit of my project in the state that yields the error: The error occurs when running or , for that matter. <!-- 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. --: Also happens on nightly: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsI hope this helps. Please tell me, if there's more you need me to do.
reduced: `
modify labels: -E-needs-mcve
Assigning as and removing .
This ICEs since modify labels: +regression-from-stable-to-stable
This issue has been fixed by , marking as .
Change:
/// /// [module]: ../../std/fmt/index.html /// <del> /// This trait can be used with `#[derive]`. </del> <ins> /// This trait can be used with `#[derive]` if all fields implement `Debug`. When /// `derive`d for structs, it will use the name of the `struct`, then `{`, then a /// comma-separated list of each field's name and `Debug` value, then `}`. For /// `enum`s, it will use the name of the variant and, if applicable, `(`, then the /// `Debug` values of the fields, then `)`. </ins> /// /// # Examples ///

Discussion:
I'm using s as keys in a BtreeMap. I have to look up the map ~15 million times per second (10G ethernet line rate). Ipv4Addr cmp() compiles to this on my system (linux x86-64, rustc 1.10.0-nightly ( 2016-05-21)) Which seems kinda inefficient for a thing which is basically u32. I guess part of the reason is the which converts it to an array(!) first. I copied the definition and implemented Ord like this: It's about 10 times faster on my .
Nice find! Want to send a PR for this? Looks like something that'd be more than welcome :)
Change:
use rustc_middle::query::plumbing::CyclePlaceholder; use rustc_middle::ty::print::with_forced_trimmed_paths; use rustc_middle::ty::util::IntTypeExt; <del> use rustc_middle::ty::{self, ImplTraitInTraitData, IsSuggestable, Ty, TyCtxt, TypeVisitableExt}; </del> <ins> use rustc_middle::ty::{self, IsSuggestable, Ty, TyCtxt, TypeVisitableExt}; </ins> use rustc_span::symbol::Ident; use rustc_span::{Span, DUMMY_SP};

Discussion:
Minimal example (): outputs In the example, the implementation is irrelevant. The definition itself is the cause for error. Removing either the lifetime or the results in successful compilation as expected. I don't understand why it's causing a cycle error, but intuitively I don't see why it should be. Introducing an trait with a blanket implementation is a possible workaround and what I'll be doing while the issue exists.
Change:
// These targets statically link libc by default base.crt_static_default = true; <del> // These targets allow the user to choose between static and dynamic linking. base.crt_static_respected = true; </del> base }

Discussion:
Reasons for: . According to , musl caused a program to run 9x slower. Musl is also known to be slower in certain configurations in C. This varies a lot with the use case and some might even see a performance increase with musl. docker containers using . It is possible to link glibc statically as demonstrated . From what I can tell, on the user facing side, this would be enable using as described in .
The reddit thread mentions libm. And another source of speedups might be the malloc implementation (glibc 2.26 introduced thread-local caches). One can already use custom global allocators, maybe it would make sense to link a custom libm too?
First blocker is the license. Glibc is licensed under LGPL, it has dynamic linking exception so one can freely link dynamically to it. Static linking doesn't fall under this exception. I'm not a lawyer but I think Rust would have to be licensed as (L)GPL to fit it. Another thing is glibc doesn't really support static linking, sure it works well for small software but bites you when you need more of it's features.
(Obviously not a lawyer but), I'm pretty sure that as long as the code it is linked against is (L)GPLed, it should work.
Also as long as the program it is linked against is licensed under a GPL compatible license, it is allowed. The MIT license, is compatible. All this information can be confirmed by looking at the above link. You can even link proprietary code against LGPL if you provide the object files.
because of we need special linking arguments because of the symbols. see also for and glibc uses for the nss modules.
The former should be doable. The latter is a tradeoff that people will need to understand if they statically link glibc, and it's something they already have to deal with if they use .
Implementation instructions: Add an entry for glibc-based targets you want to support to (Same as for musl, but -, because is undesirable ().) Perhaps libm or libpthread will need to be linked in the same way. Set to in target specifications for glibc-based targets you want to support (in ). Test that it actually works, this will require some building of libstd with cargo overridden libc dependency.

I'd be happy to submit the necessary changes, if you can outline what needs doing. () See the comment above.
Thanks!
I have this successfully working; just waiting on a release of the libc crate containing .
Change:
<ins> error: this operation will panic at runtime --> $DIR/unconditional_panic_promoted.rs:7:13 | LL |     let _ = slice[2]; |             ^^^^^^^^ index out of bounds: the length is 2 but the index is 2 | = note: `#[deny(unconditional_panic)]` on by default error: aborting due to 1 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: Instead, this happened: Apparently, taking a shared reference of will suppress the lint. This seems like a false negative. While false negatives can't be avoided entirely, this case seems to be avoidable as taking a shared reference shouldn't change the type of (which is ) or modify any data in this example. Note that will trigger the lint properly. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
See also .
claim
Note this is a problem because which is supposed to fail to compile but this bug makes it fail at runtime instead
In case no one has dug into it yet, the error is suppressed in but not in and before:
label +regression-from-stable-to-stable
WG-prioritization assigning priority (). label -I-prioritize +P-medium
This is caused by . It only ever worked because the lint ran after optimizations. I made a fix . It specializes the length of arrays as constant, even if the array isn't. I'm going to open a PR when I have time, probably tomorrow. In the long term, I'd like to implement some more extensive tracking of "what parts of a value are constant". For example, the compiler currently assumes that anything that had its reference taken can change, but actually, this can only happen inside (as I understand it).
Labels from the closed duplicate , label A-diagnostics, A-lint, A-mir-opt, T-compiler.
Fixed on stable label E-needs-test
I claim the add test part
This lint only appears on full builds (not check), but this will be fixed once lands.
Reopening because I feel this is not yet solved, see on . As per the , should nail down this issue?
MRE: Also, duplicate of
Another variant of this same issue:
Change:
let field_ty = layout.field(bx, i).ty; let (unsized_size, mut unsized_align) = size_and_align_of_dst(bx, field_ty, info); <del> // FIXME (#26403, #27023): We should be adding padding // to `sized_size` (to accommodate the `unsized_align` // required of the unsized field that follows) before // summing it with `sized_size`. (Note that since #26403 // is unfixed, we do not yet add the necessary padding // here. But this is where the add would go.) // Return the sum of sizes and max of aligns. let size = bx.add(sized_size, unsized_size); // Packed types ignore the alignment of their fields. if let ty::Adt(def, _) = t.kind() { if def.repr().packed() { unsized_align = sized_align; </del> <ins> // # First compute the dynamic alignment // For packed types, we need to cap the alignment. if let ty::Adt(def, _) = t.kind() && let Some(packed) = def.repr().pack { if packed.bytes() == 1 { // We know this will be capped to 1. unsized_align = bx.const_usize(1); } else { // We have to dynamically compute `min(unsized_align, packed)`. let packed = bx.const_usize(packed.bytes()); let cmp = bx.icmp(IntPredicate::IntULT, unsized_align, packed); unsized_align = bx.select(cmp, unsized_align, packed); </ins> } } // Choose max of two known alignments (combined value must // be aligned according to more restrictive of the two). <del> let align = match ( </del> <ins> let full_align = match ( </ins> bx.const_to_opt_u128(sized_align, false), bx.const_to_opt_u128(unsized_align, false), ) {

Discussion:
Execute with Miri: The problem is that and do not take the reduced field alignment into account and calculate the offset as-if the standard alignment was in place.
The labels are incorrect. Neither does this require nightly, nor is it related to const-eval. This is I-unsound on stable.
label I-prioritize (Looks like can't set .)
Error: Label can only be set by Rust team members Please let know if you're having trouble with this bot.
Error: Parsing relabel command in failed: ...'const-eval' ' "I-unsoun'... Please let know if you're having trouble with this bot.
Assigning as discussed as part of the and removing .
label -I-prioritize +P-medium
labels -T-types Discussed in types team on-site -- we think this is a MIR building bug, in any case, not part of T-types. Throwing hot back to compiler team.
It was actually a bug in the codegen backend, introduced when support for was -- the existing code has logic that assumed "if it is packed then alignment is 1", and that was never re-visited.
Ah, scratch that -- there was a different related bug (the sizeofval / alignofval computation for packed structs with tail was wrong), caused by what I said above. This here was caused by the codegen backend just never considering packed types when computing the offset of the unsized field. Almost always this happened to work since the unsized field is a slice/str and so its alignment (and therefore its offset) is dynamically known, but when dyn trait tails are involved this starts to go wrong. This got fixed by ; will add a test.
Change:
"cargo_metadata 0.9.0", "clippy-mini-macro-test", "clippy_lints", <del> "compiletest_rs 0.4.0", </del> <ins> "compiletest_rs", </ins> "derive-new", "lazy_static 1.3.0", "regex",

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! cc the PR reviewer, and nominating for compiler team prioritization.
triage: P-medium, removing nomination label.
Change:
async fn foo() {} fn make_generator() { <del> let _gen = || foo.await; //~ ERROR `await` is only allowed inside `async` functions and blocks </del> <ins> let _gen = || foo().await; //~^ ERROR `await` is only allowed inside `async` functions and blocks </ins> } fn main() {}

Discussion:
Hi I'm pretty new to rust and programming in general. I was trying (failing) to write some toy async code and I got this internal compiler error, the theme seems to be always report ICEs so here we go This was from cargo: ~ The code I was trying was this code: ~ <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Minimized:
ICEs with any statement between while inside a function that isn't async ICE Error without and without the ICE statement inside async function
claim
This is actually the same as . I think I've got a fix for both.
do you have a PR for this open?
Closing as a duplicate of , both of which are fixed by

<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Not had a lot of time to look at this unfortunately and it appears has come up with a fix in in the meantime. release-assignment
claim
assign (Sorry for the noise, testing a new GH feature)