jiebi/CodeConvo huggingface dataset:
Code change:
#[inline] unsafe fn alloc_zeroed(&self, layout: Layout) -> *mut u8 { <ins> // See the comment above in `alloc` for why this check looks the way it does. </ins> if layout.align() <= MIN_ALIGN && layout.align() <= layout.size() { libc::calloc(layout.size(), 1) as *mut u8 } else {

Related discussion:
text: The man page for says And yet Miri found libstd calling this function with an alignment of 4 on a 64bit-platform. This happens when size=2, align=4. The fact that size<align makes it enter the code path for .
The only reason I can imagine for to exist there is a buggy implementation of . This check is only meaningful if a buggy implementation returns not an allocation suitably aligned for any built-in type (on x86_4 – 16-bytes) but rather an allocation aligned for the particular request?
A lack of comment is disturbing here. If git history does not reveal any such issue, then we should just remove that check entirely.
That extra check was introduced by to fix
I have opened in jemalloc to get clarification from them about their alignment guarantees. It would be nice if someone with more knowledge could chime in, in particular knowledge about where exactly that value of 16 for on x86-64 comes from. Cc
Possibly from here:
C has types with an alignment smaller than are supported in all contexts. AFAICT this includes the memory returned by any memory allocation function - not only , but also . The largest scalar type of C implementations needs to be supported in all contexts. On most platforms, this type is often which the requires it to have an alignment of 16, so on these particular platforms, will have an alignment requirement of 16 bytes. On these platforms, all memory allocation functions need to return memory aligned to a 16 byte boundary when called with a to be able to support the largest scalar type provided by the C implementation. Otherwise would return memory not suitable for storing a scalar type. However, if the memory allocation is smaller than the size of the largest scalar type, then it would be illegal to store it there, so the memory returned needs to only be properly aligned to be able to store the largest scalar type that would fit in that particular size. In practice, this means that for sizes up to , the alignment of the returned memory equals the size of the allocation rounded to the previous power of two (e.g. in a 5 byte allocation, you can at most fit a 32-bit scalar, so the allocation only needs 4 byte of alignment). And for sizes larger than , the alignment is at least (this allows storing, e.g., an array of s).
Code change:
#[inline] unsafe fn alloc_zeroed(&self, layout: Layout) -> *mut u8 { <ins> // See the comment above in `alloc` for why this check looks the way it does. </ins> if layout.align() <= MIN_ALIGN && layout.align() <= layout.size() { libc::calloc(layout.size(), 1) as *mut u8 } else {

Related discussion:
text: In practice, the fastest thing you can do, is calling malloc if , because if malloc will return an alignment of at least rounded to the previous power of two, which is always satisfied (remember that must be a power of two, so if its smaller than size, it is at least the previous one). will do this without having to branch on any user provided alignment argument. That's precisely what that code is doing. The else branch is calling a "generic" which should be able to handle any user-specified alignment. The implementation of based on : appears to have the bug you mention, and should probably call or similar. I suspect that the implementation of provided by jemalloc, which we use here: doesn't have this issue, because it probably just forwards the call to , which supports alignment smaller than .
So basically on the C side, one assumes that is not used with types that use the C equivalent of ? With that assumption, I agree it is enough for to guarantee an alignment of rounded down to the next power of two. (I think your post originally said "up", but now it says "down" so I guess we agree.) That's what I and our implementation indeed handles that case just fine. The bug in the way we call is fixed by Still, it would be nice not to be able to reason about "in practice", but get some commitment from jemalloc -- see And finally, this only concerns on Unixes. Does anyone know what the situation looks like with on Windows? libstd currently assumes even small allocations to be aligned there, and agrees with that (Ctrl-F "on 64-bit platforms").
EDIT: C11 to C, but yes, malloc doesn't know anything about the alignment of a type. It still can be used, but the user needs to check whether the allocation is properly aligned. The docs are quite clear IMO: Anything more concrete than that will be target specific, and those details are outside jemalloc's control - if jemalloc wants to replace the system allocator in a target, it needs to comply with the ABI there. If it were to guarantee more, e.g., all allocations are 16byte aligned, it wouldn't work on platforms using the SysV i386 ABI.
Well, with that statement from the jemalloc docs is wrong, isn't it?
Code change:
#[inline] unsafe fn alloc_zeroed(&self, layout: Layout) -> *mut u8 { <ins> // See the comment above in `alloc` for why this check looks the way it does. </ins> if layout.align() <= MIN_ALIGN && layout.align() <= layout.size() { libc::calloc(layout.size(), 1) as *mut u8 } else {

Related discussion:
text: And for users to manually do the alignment, getting something more concrete would be useful. And also for Rust! Currently you are deducing a whole lot of things from a few words in the spec. I have zero confidence that this is the only way to read the spec. So something like: "for we guarantee an alignment of ; for smaller sizes we guarantee an alignment of the size rounded down to the next power of two." would IMO be prudent to ask from the jemalloc devs. Or else we'll find ourselves with more bugs when someone interprets all this slightly differently.
I don't know how useful would that be: malloc only needs to comply with the C standard. Parts of it are implementation-defined, and what those are defined to is often specified by the system ABI. That's the only thing the global allocator can rely on. On most platforms, the system allocator - which is the default global allocator for Rust programs - is not jemalloc - it is the one from glibc, musl, microsoft, apple, google, mozilla, etc. In some platforms, like FreeBSD, the system allocator is jemalloc, but even there we can't exploit that knowledge because users can just and now the global allocator is a different one. That's an use case we support. So even if jemalloc were to offer extra guarantees here, Rust's system allocator cannot make use of them. The only places were we can can exploit jemalloc's specific guarantees, is when using crates like jemallocator, to explicitly hardcode the allocator to a particular one. As in, if that allocator is not linked, you get a linker error or similar. But even there, it makes sense to stick to what C and the platform ABI guarantees, because jemalloc is free to break anything else in the next version.
Well it would save us this entire discussion. If that doesn't demonstrate its usefulness I don't know what does.^^ I don't know what the "system allocator" is for Linux, but the one in glibc actually guarantees a 16-byte alignment on 64bit systems for all allocations. So by that standard jemalloc would just be incorrect.
The platform ABI guarantees that. What the malloc implementations guarantee is irrelevant.
Code change:
#[inline] unsafe fn alloc_zeroed(&self, layout: Layout) -> *mut u8 { <ins> // See the comment above in `alloc` for why this check looks the way it does. </ins> if layout.align() <= MIN_ALIGN && layout.align() <= layout.size() { libc::calloc(layout.size(), 1) as *mut u8 } else {

Related discussion:
text: If glibc were to guarantee that all addresses are 32-byte aligned, there is no way in which we could exploit that information in the implementation of the system allocator, because the platform only requires 16-byte alignment, and it is valid to pick any allocator at run-time that satisfies that.
So there a document somewhere saying "for x86-64 bit, 16-byte alignment is guaranteed"? But that document contains an exception for small sizes, making s behavior legal?
Yes, there are documents containing the rules of what's legal, at least for Linux x8664. Those document allow an exception for small sizes. One API that uses those is , which requires the alignment to be at least , which is 8 on x86_64, and which allows you to allocate bytes, with a smaller alignment. I still have no idea what jemalloc has to do with any of this - your original question is about , and that has nothing to do with jemalloc. But yes, jemalloc exploits this behavior, to be able to satisfy 1 byte request, and return addresses that are 1 byte aligned. Otherwise each 1 byte request would consume 16 bytes of memory within a memory page.
A document that could be relevant is the C standard. Unfortunately, as mentioned in the commit message for , it is rather tautological on this topic: The standard does not give any numeric value. Like many other aspects of C, it looks like the actual value of is implementation-defined.
When using jemalloc, becomes jemalloc. That's how happened. Do you have a reference for something that concretely calls out an exception for small types? The C standard only does this very indirectly, as you showed.
That was a bug in our implementation of system that applies to pretty much all allocators, not only jemalloc. says (emphasis mine): Since the alignment of an object is a power of two that is always smaller than or equal to the object size, rounding down the alignment of an allocation to the previous power of two always produces an allocation properly aligned for every type that can fit it. That holds for all allocations, so there is no exception for that. That's the rule. Since that would mean that large allocations must be unreasonably aligned, the standard does provide an exception for allocations of size larger than than .
Code change:
#[inline] unsafe fn alloc_zeroed(&self, layout: Layout) -> *mut u8 { <ins> // See the comment above in `alloc` for why this check looks the way it does. </ins> if layout.align() <= MIN_ALIGN && layout.align() <= layout.size() { libc::calloc(layout.size(), 1) as *mut u8 } else {

Related discussion:
text: These only need to be aligned at an boundary. If you believe this is incorrect, please show a counter-example for which this doesn't work.
AFAIK it is a normal way of using to make it override the symbol? Don't we still do that in rustc, or when using "jemallocator"? I don't say it is incorrect, I say it is awfully indirect. It's like reading tea leaves. I am looking for a clear definite statement. That doesn't seem to exist though. :( There clearly is some kind of "non-continuity" where all allocations are aligned MINALIGN except for small ones. Or vice versa, all allocations are aligned "size rounded down to power of 2" except for big ones. You are convincingly deriving that non-continuity from standard wording. I don't say you are wrong, but this feels like interpreting ancient scripture. A clear spec looks different. Also, an object of size 2 with alignment requirement 4 is "fundamental" according to your definition, and yet rounding down the size to the next power of 2 does not give the right alignment. So your rule does have exceptions, namely types marked .
Can you show such an object in C and/or Rust ? It's probably the most common way of switching allocators. What does is it requires to be linked to your binary, allowing (and making use of) jemalloc-specific APIs. If you do this, when using directly (not ), you can obviously rely on assumptions that only hold for . But cannot do that because, then it wouldn't work with other allocators.
The goal is not to rely on assumptions that only hold for . The goal is to make sure that we do not make assumptions that don't hold for . Because that's what we used to do, before got fixed. We were assuming something that was true for system but not for : that all allocations, no matter the size, are aligned. To make sure we don't do that again, I want to be sure that all assumptions we are making hold for . That's why I'd like jemalloc to spell out what we can assume.
Ah I forgot about the stride vs. size thing. So such an object does not exist.
Code change:
#[inline] unsafe fn alloc_zeroed(&self, layout: Layout) -> *mut u8 { <ins> // See the comment above in `alloc` for why this check looks the way it does. </ins> if layout.align() <= MIN_ALIGN && layout.align() <= layout.size() { libc::calloc(layout.size(), 1) as *mut u8 } else {

Related discussion:
text: But such a exists, and it is something we want to support in our allocator API (we even have a test for that). And we do have objects with align size, namely all ZST.
Yeah, I agree. The only cases for which the "round to the previous power of two approach" doesn't work is for ZSTs, and types (or allocations) with align size. Since those just cannot happen in C, the C standard doesn't mention them as exceptions. That is, we can only call when that holds, and if it that doesn't hold, we need to call a different API that supports the align size case.
Code change:
<ins> //@ edition:2021 macro_rules! a { ( ) => { impl<'b> c for d { e::<f'g> //~ ERROR prefix `f` is unknown } }; } fn main() {} </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '--edition=2021 --crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: prefix is unknown', 'error: internal compiler error: prefix is unknown' File: --snippet: 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: --
:thinking: this bisects to cc
very plausible :+1:
Reduced
Code change:
Ok(pat) } <ins> /// Recover from a typoed `...` pattern that was encountered /// Ref: Issue #70388 fn recover_dotdotdot_rest_pat(&mut self, lo: Span) -> PatKind { // A typoed rest pattern `...`. self.bump(); // `...` // The user probably mistook `...` for a rest pattern `..`. self.struct_span_err(lo, "unexpected `...`") .span_label(lo, "not a valid pattern") .span_suggestion_short( lo, "for a rest pattern, use `..` instead of `...`", "..".to_owned(), Applicability::MachineApplicable, ) .emit(); PatKind::Rest } </ins> /// Try to recover the more general form `intersect ::= $pat_lhs @ $pat_rhs`. /// /// Allowed binding patterns generated by `binding ::= ref? mut? $ident @ $pat_rhs`

Related discussion:
text: ` The problem here is that we have instead of The compiler however points towards in the error message instead of the superfluous : Fun fact: when using four dots , it correctly points at the last dot :) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
seems like a simple issue to fix. If I were to take a shot at fixing this, where would I start?
Mentoring instructions: Add a branch after this one... instead of , check that . This should be interpreted as a as in the previous branch, but an error should also be emitted. (Add the code for error emission in a separate method, with an appropriate , where the span of the is replaced with . See for an example on emitting an error with a suggestion.)
Sure thing! Will get to it right after work. Thanks for the pointers.
assign
Code change:
// Change value between simple literals --------------------------------------- <del> #[cfg(cfail1)] const CONST_CHANGE_VALUE_1: i16 = 1; #[cfg(not(cfail1))] </del> #[rustc_clean(cfg="cfail2", except="HirBody")] #[rustc_clean(cfg="cfail3")] #[rustc_metadata_clean(cfg="cfail3")] <del> const CONST_CHANGE_VALUE_1: i16 = 2; </del> <ins> const CONST_CHANGE_VALUE_1: i16 = { #[cfg(cfail1)] { 1 } #[cfg(not(cfail1))] { 2 } }; </ins> <del> // Change value between expressions ------------------------------------------- #[cfg(cfail1)] const CONST_CHANGE_VALUE_2: i16 = 1 + 1; #[cfg(not(cfail1))] </del> <ins> // Change value between expressions ------------------------------------------- </ins> #[rustc_clean(cfg="cfail2", except="HirBody")] #[rustc_clean(cfg="cfail3")] #[rustc_metadata_dirty(cfg="cfail2")] #[rustc_metadata_clean(cfg="cfail3")] <del> const CONST_CHANGE_VALUE_2: i16 = 1 + 2; </del> <ins> const CONST_CHANGE_VALUE_2: i16 = { #[cfg(cfail1)] { 1 + 1 } </ins> <del> #[cfg(cfail1)] const CONST_CHANGE_VALUE_3: i16 = 2 + 3; </del> <ins> #[cfg(not(cfail1))] { 1 + 2 } }; </ins> <del> #[cfg(not(cfail1))] </del> #[rustc_clean(cfg="cfail2", except="HirBody")] #[rustc_clean(cfg="cfail3")] #[rustc_metadata_dirty(cfg="cfail2")] #[rustc_metadata_clean(cfg="cfail3")] <del> const CONST_CHANGE_VALUE_3: i16 = 2 * 3; </del> <ins> const CONST_CHANGE_VALUE_3: i16 = { #[cfg(cfail1)] { 2 + 3 } </ins> <del> #[cfg(cfail1)] const CONST_CHANGE_VALUE_4: i16 = 1 + 2 * 3; </del> <ins> #[cfg(not(cfail1))] { 2 * 3 } }; </ins> <del> #[cfg(not(cfail1))] </del> #[rustc_clean(cfg="cfail2", except="HirBody")] #[rustc_clean(cfg="cfail3")] #[rustc_metadata_dirty(cfg="cfail2")] #[rustc_metadata_clean(cfg="cfail3")] <del> const CONST_CHANGE_VALUE_4: i16 = 1 + 2 * 4; </del> <ins> const CONST_CHANGE_VALUE_4: i16 = { #[cfg(cfail1)] { 1 + 2 * 3 } #[cfg(not(cfail1))] { 1 + 2 * 4 } }; </ins> // Change type indirectly -----------------------------------------------------

Related discussion:
text: Found via rust-icci: https://travis- The commit history of the regex crate contains on changeset that only adds a comment which in turn leads to the body of a function being moved. This results in the update of the source location pointed to by a potential overflow panic message. This message is not updated properly in incremental mode: I have not found out yet why the change is not detected. HIR fingerprinting has special treatment of operations that can trigger overflows: There must be some kind of mismatch between when HIR fingerprinting thinks that an operation can panic and when we actually emit panic messages. This is another span-related papercut cc
Full IR files for reference:
Code change:
<ins> // Copyright 2017 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. // ignore-tidy-linelength // compile-flags: -g  --remap-path-prefix={{cwd}}=/the/aux-cwd --remap-path-prefix={{src-base}}/remap_path_prefix/auxiliary=/the/aux-src #![crate_type = "lib"] pub fn foo<T>() {} </ins>

Related discussion:
text: STR (on Linux): file that has generics usage () code DWARF info Notice that contains such entries as , possibly produced by the fact that "" is a relative path and DWATcompdir is set to "/home/yury". It is expected for core files to have absolute path e.g. ""
cc I wonder what interaction (path rewriting?) causes this result.
FWIW, produces that shows that !DIFile entries has the directory field empty (and the filename is relative)
It is a regression, since +stable has absolute locations, e.g.
could this have to do with
Likely so! I'll try to look into this in the near future
Ok so the change here can be exhibited with this script: If you execute that script you see: but if you remove you see: It appears that if upstream crates (like libstd) use then their filename is listed as the original relative source file instead of the absolute path name that it had previous to when it wasn't compiled with . So somehow using to compile libstd is affecting downstream crates to have relative path names instead of old absolute path names. It makes sense to me that the absolute path name goes away with (that is the whole point after all) but ideally it'd still be an absolute path, just applying the mapping. would you be able to help point me in the direction of where this change in logic might happen? If so I can test out a patch!
This should be what you're looking for: One solution would be to compile libstd with absolute paths and apply proper remapping to those.
Ah that's perfect! I'll see if I can work up a solution to that soon
Code change:
<ins> error[E0531]: cannot find tuple struct or tuple variant `Cons` in this scope --> $DIR/issue-90113.rs:17:9 | LL |         Cons(..) => {} |         ^^^^ not found in this scope | help: consider importing this tuple variant | LL | use list::List::Cons; | error: aborting due to previous error For more information about this error, try `rustc --explain E0531`. </ins>

Related discussion:
text: Bisected to a rollup, but I think it's very likely to be . cc searched nightlies: from nightly-2021-10-01 to nightly-2021-10-19 regressed nightly: nightly-2021-10-02 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
The old suggestion was actually incorrect because it suggested , which is a private import. However, the new error is "more incorrect" IMO since it says something confusing (and incorrect).
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Code change:
/// assert_eq!(*x, 1); /// ``` #[inline] <del> #[unstable(feature = "mutex_unpoison", issue = "96469")] </del> <ins> #[stable(feature = "mutex_unpoison", since = "CURRENT_RUSTC_VERSION")] </ins> pub fn clear_poison(&self) { self.poison.clear(); }

Related discussion:
text: Feature gate: This is a tracking issue for functions to clear the poisoned flag on and . [x] [x] Implementation: [x] Final comment period (FCP) [ ] Stabilization PR <!-- Once the feature has gone through a few release cycles and there are no unresolved questions left, the feature might be ready for stabilization. If this feature didn't go through the RFC process, a final comment period (FCP) is always needed before stabilization. This works as follows: A library API team member can kick off the stabilization process, at which point the rfcbot will ask all the team members to verify they agree with stabilization. Once enough members agree and there are no concerns, the final comment period begins: this issue will be marked as such and will be listed in the next This Week in Rust newsletter. If no blocking concerns are raised in that period of 10 days, a stabilzation PR can be opened by anyone. --<!-- Include any open questions that need to be answered before the feature can be stabilised. If multiple (unrelated) big questions come up, it can be a good idea to open a separate issue for each, to make it easier to keep track of the discussions. It's useful to link any relevant discussions and conclusions (whether on GitHub, Zulip, or the internals forum) here. --- None yet.
Hi, I read (wich got automatically closed by the way) and the PR It seems all good. What is the next step to make it in the stable API ? Can I help somehow ?
Hi, sorry if flooding but are there any updates regarding this issue?
I think the next step is one of the rust developers needs to start the final comment period. IDK what the criteria for doing so are.
fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [ ] [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.
I was wondering whether the idea of had been considered and found that addressed it. SGTM!