jiebi/CodeConvo huggingface dataset:
Change:
``` This reveals two interesting things about Rust: it is an expression-based <del> language, and semicolons are different than in other 'curly brace and semicolon'-based languages. These two things are related. </del> <ins> language, and semicolons are different from semicolons in other 'curly brace and semicolon'-based languages. These two things are related. </ins> ## Expressions vs. Statements

Discussion:
There are a number of small typos in the guide, and some of the prose could be tightened up or clarified. In general the tone of the guide comes across as trying too hard to be chatty. Keeping things casual is probably a good idea for Rust's introductory document, but we can probably remove most (all?) of the chatty prose without becoming stodgy or boring.
The guide is inconsistent with its use of certain conventions. These don't really have a correct form, but a single style should be enforced. Single-quotes () versus double-quotes () in prose. Example: Periods and commas within quotes versus without. Example: "different from" versus "different than". Example: "filename" versus "file name"
If you find any obvious errors, or think you can write a section in a better way, please don't hesitate to submit a PR with a fix. You don't need to compile a compiler or download the source to edit the guide. You can do it all in github's ui, for the most part.
thanks for being specific. And for your earlier pull request. As for these... They should be double quotes. Ideally, they'd even be actual curlies rather than . Periods and commas go within in almost all cases. In both of the cases you show, they should go inside. "Different from" vs. "Different than" isn't something that's generally settled. Some styles choose it in different situations, others say "from" is the only correct way to say this. "file name" is my preferred way, though there's no specific actual guidance.
Change:
#[link(name = "gcc_s", cfg(not(target_feature = "crt-static")))] extern "C" {} <ins> // When building with crt-static, we get `gcc_eh` from the `libc` crate, since // glibc needs it, and needs it listed later on the linker command line. We // don't want to duplicate it here. #[cfg(all(target_os = "linux", target_env = "gnu", not(feature = "llvm-libunwind")))] #[link(name = "gcc_s", cfg(not(target_feature = "crt-static")))] extern "C" {} </ins> #[cfg(target_os = "redox")] #[link(name = "gcc_eh", kind = "static-nobundle", cfg(target_feature = "crt-static"))] #[link(name = "gcc_s", cfg(not(target_feature = "crt-static")))]

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:
#[stable(feature = "rust1", since = "1.0.0")] impl<T> fmt::Display for PoisonError<T> { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { <del> self.description().fmt(f) </del> <ins> "poisoned lock: another task failed inside".fmt(f) </ins> } } <del> impl<T> Error for PoisonError<T> { </del> <ins> impl<T: Send> Error for PoisonError<T> { </ins> fn description(&self) -> &str { "poisoned lock: another task failed inside" }

Discussion:
currently requires , while requires . I'm unsure of what each should require, but I think they should agree so that it is possible to have code which returns (which is useful to allow try! across functions returning different types of error codes), and be able to the results.
There was a lengthy discussion about this towards the bottom of the RFC:
/cc , I vaguely remember this might change? If not, then this should be in the RFCs repo.
Nominating for 1.0-beta P-backcompat-libs. (The trait isn't yet, but it probably will be for 1.0).
0 beta, P-backcompat-libs, I-needs-decision.
Change:
<ins> #[main]  //~ ERROR cannot find attribute `main` in this scope fn main() {} </ins>

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected an error, because the main attribute has never been available on stable, and had apparently been removed in . Instead, the program ran without error, although the attribute has no apparent effect. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked as expected (emitting an error) on Rust 1.52.1: <!-- Provide the version you are using that has the regression. --This stopped being an error in 1.53.0 (in which a warning was still emitted), and continues to be accepted in stable through the current 1.58.1 version (in which the warning has also disappeared).
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high +T-compiler
Change:
fn may_contain_mutable_ref(self) -> bool { match self { CtfeValidationMode::Static { mutbl } => mutbl == Mutability::Mut, <ins> CtfeValidationMode::Promoted { .. } => false, </ins> CtfeValidationMode::Const { .. } => false, } }

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: compile fine, with the static containing a slice that references . Instead, this happened: <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: <!-- Provide the version you are using that has the regression. --:
searched nightlies: from nightly-2024-02-10 to nightly-2024-02-11 regressed nightly: nightly-2024-02-11 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.8</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: cc
Context for how I found this: I use this technique in in code generation for benchmarks of generic functions. The simple example I gave is just a minimal reproduction of the issue.
Hm, that is very strange. Not sure if there is a good way to get the backtrace of where in the code the cyclic queries are made? My first guess is that it is the new call to here: But... surely we can ask for the type of a static while evaluating that very static, that can't be cyclic?
Ah no, probably it is related to the fact that we now recursively validate when a constant points to a static. Previously we stopped there. I guess we should not do that for promoteds.
WG-prioritization assigning priority (). label -I-prioritize +P-high -E-needs-bisection +T-compiler
Change:
"src/libstd/path.rs", "src/libstd/f32.rs", "src/libstd/f64.rs", <ins> "src/libstd/lib.rs", // Until next stage0 snapshot bump </ins> "src/libstd/sys_common/mod.rs", "src/libstd/sys_common/net.rs", "src/libterm", // Not sure how to make this crate portable, but test needs it

Discussion:
Since bumped the bootstrap compiler, stage0 libstd fails to build when jemalloc is disabled: I believe it needs to restore the logic removed here: I tried to add this to : Then stage0 passed, but stage1 std failed like:
cc
We should probably add a builder for this...
or just get on with evicting jemalloc...
is not the right way to fix this - I that so I could build rust with a local rust that does not have jemalloc i.e. unless the following two conditions are true: you're using a local rust (as opposed to the automatic stage0 download) and your local rust does not have jemalloc (you compiled the whole thing yourself with ) it's irrelevant. Edit: to be clear, by "not the right way to fix this" I mean "it worked fine before I that flag, so its removal is probably not the root cause". That's doesn't exclude the possibility that we could perform some incantations with this flag and fix the issue. Edit2: sorry, I thought you were exclusively referring to rather than all the logic. I read and thought this issue was about the same thing.
Generally, the two conditions you list are actually true for me. I build Fedora's rustc without jemalloc, and I use that as the local stage0 to build the next release. And i think the force flag does come into play too, because if we need to rebuild the current release then the local rust gets treated as a stage1. But right now it's more direct. I am using the downloaded stage0, which wants to default to jemalloc. Since I'm disabling that for my build, stage0 can't find it.
Interesting, I kinda figured I was the only one! Rereading , I see I'm wrong about my two conditions above - it actually applies when trying to build something without jemalloc, from something that defaults to it. Anyway, it should all be fixed soonish...
Change:
pub const ALLOC_DISCRIMINANT: usize = 0; pub const FN_DISCRIMINANT: usize = 1; <ins> pub const EXTERN_STATIC_DISCRIMINANT: usize = 2; pub const SHORTHAND_START: usize = 3; </ins> pub fn specialized_encode_alloc_id< 'a, 'tcx,

Discussion:
fresh clone of using local Rust and Cargo latest nightly (also occurs in beta-1.25.0), MSVC x64 with Visual Studio 2017 In : set and to Rustup's proxies set (happens only in debug mode) set (specific value doesn't appear to affect the issue) run It gets to this point and ICEs: I grepped the error message () and it points to which appears to be associated with incremental compilation, which makes sense because this only triggers when building in debug mode and setting avoids the ICE. cc rust-lang/cargo
There's a very high chance that this is fixed by
I'll try to build the latest master and see what happens.
Nope, just changed the file the error is emitted from. I have the backtrace here if you like but it's more than 100 frames deep so I don't know how much context you need.
Thanks. I'll have a look. No need for a backtrace
Repro: The problem is that statics don't have allocations (because it makes no sense for them to have usable memory during const evaluation). This is easy to fix :)
Change:
() } <del> impl<T, V> Trait for (T, V, V, u32) {} impl<U, V> Trait for (Opaque<U>, V, i32, V) {} </del> <ins> impl<T, U, V> Trait for (T, U, V, V, u32) {} impl<U, V> Trait for (Opaque<U>, U, V, i32, V) {} </ins> fn main() {}

Discussion:
The following UB compiles: The impl is invalid because the lifetime parameter appears unconstrained in the impl header. It should be rejected for the same reason that projection types doesn't constraint impl generics: label C-bug T-types I-unsound requires-nightly F-typealiasimpl_trait
Change:
<ins> // build-pass // compile-flags: -Copt-level=1 --crate-type=lib #![feature(specialization)] //~^ WARN the feature `specialization` is incomplete pub unsafe trait Storage { type Handle; } pub unsafe trait MultipleStorage: Storage {} default unsafe impl<S> Storage for S where S: MultipleStorage {} // Make sure that we call is_freeze on `(S::Handle,)` in the param-env of `ice`, // instead of in an empty, reveal-all param-env. pub fn ice<S: Storage>(boxed: (S::Handle,)) -> (S::Handle,) { boxed } </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. -- (requires release mode) <!-- 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. --: 1.70.0-nightly (2023-04-02 ) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details labels modify +F-specialization +requires-nightly +requires-incomplete-features
I understand how this ICE can come about, but I frankly cannot reproduce this. can you help out?
Ah, I apparently forgot to list that the ICE requires ; building without optimizations doesn't ICE.
label +F-specialization +requires-nightly +requires-incomplete-features
Change:
use crate::simd::{SimdPartialEq, ToBitMask}; let first_probe = needle[0]; <ins> let last_byte_offset = needle.len() - 1; </ins> // the offset used for the 2nd vector let second_probe_offset = if needle.len() == 2 {

Discussion:
PR a x8664 SIMD-based implementation of to optimize searching into strings when the needle is at most 32 bytes long. Unfortunately, that implementation doesn't seem to be sound. When compiling the standard library with debug assertions on, running UI tests excluding results in compiletest itself panicking before executing any test due to a in libcore: To reproduce the issue, use the following configuration file: run: cc
Tentatively opened a revert PR in
Ugh. I ran it under miri with quite a combinatorial test that I thought should cover all the edge-cases. It's not immediately obvious what's wrong, so it's fine to land the revert for now.
Last I checked (and a lot has happened since then so I could be working on outdated info -- might be able to confirm), miri can't catch failure in many cases I believe, since it's "just" library UB.
the memory will be accessed after the get_unchecked so it should still be an invalid memory access when it's out of bounds. Unless I'm just doing some shortening slicing and then extending it again so that it's valid within the same allocation but not correct slicing.
What says is correct. The error here is in a situation like Miri (without Stacked Borrows) will not complain about that since the index is in-bounds of the allocation. But the debug assertion will complain since you are causing library UB by going out-of-bounds of the slice. I don't quite understand your last comment,
It seems like the test is just insufficient. Even with debug asserts and overflow checks enabled it doesn't catch it. I'll have to reproduce it first to figure out what's missing.
Ooh, I was getting absolutely unexplainable compiler errors when building stage 1 libstd with a stage 0 rustc which was built with however, could this be the cause for this? :sweat_smile:
Possible, but it would also do incorrect things on x86-64 baseline
has a proper fix
Change:
// We won't diverge unless both branches do (or the condition does). self.diverges.set(cond_diverges | then_diverges & else_diverges); } else { <del> self.if_fallback_coercion(sp, then_expr, &mut coerce); </del> <ins> self.if_fallback_coercion(sp, cond_expr, then_expr, &mut coerce); </ins> // If the condition is false we can't diverge. self.diverges.set(cond_diverges);

Discussion:
The following code () gives the following error: which is weird, since the clause would never be visited even if it was present. The equivalent one-arm match compiles just fine (expectedly). Adding an branch to the is, of course, possible, but unelegant, and really shouldn't be needed, as it can be inferred at compile time.
You can match irrefutably without in this case: though maybe we should give this special diagnostics.
I think this is too niche to deserve a special diagnostics (and I don't think we should substantially work on diagnostics for until let_chains is implemented). is defined by a desugaring: becomes: so what you really wrote is: The block is typed at which does not unify with unless it is also typed at .
I didn't know was a valid syntax. If I did, I probably wouldn't have filed the issue, because of course, in hindsight, that's how you write an infallible . (With that knowledge in mind) I agree that it's only a diagnostics issue and no language change is needed here. And I fully agree that it's a niche low-priority quirk that should maybe be fixed "someday". (I don't know what but even then I'd guess that this one is lower priority than that).
I think the appropriate thing to do here would be to lint on , which would have clarified things.
We already do.
But we do only after typechecking, and we don't if there are any errors before then. Quite a few lints have similar issues related to not happening early enough.
How do you know that the pattern is irrefutable before match checking in HAIR?
You can't, but you can write the lint in such a way that it triggers regardless. We're getting to typechecking, we should be able to detect irrefutability by then. It just can't use the standard linting machinery (like a few other lints already do to avoid being silenced by accident).
Change:
<ins> // build-pass trait AssociatedConstant { const DATA: (); } impl<F, T> AssociatedConstant for F where F: FnOnce() -> T, T: AssociatedConstant, { const DATA: () = T::DATA; } impl AssociatedConstant for () { const DATA: () = (); } fn foo() -> impl AssociatedConstant { () } fn get_data<T: AssociatedConstant>(_: T) -> &'static () { &T::DATA } fn main() { get_data(foo); } </ins>

Discussion:
I'm seeing an internal compiler error on the following input (found by ): Note that a similar issue () was recently closed. The fix for that ( it seems) apparently does not prevent this crash. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
It seems the ICE has been fixed in latest nightly.
Bisected, I think it has been fixed by . Adding regression test is reasonable so marked as E-needstest.

When the associated constant of an impl trait is referenced it creates an ICE: This panics on stable and nightly. Tested on , macOS and in Docker: : rustc 1.38.0 ( 2019-09-23) binary: rustc commit-hash: commit-date: 2019-09-23 host: x86_64-unknown-linux-gnu release: 1.38.0 LLVM version: 9.0 The panic originates from the same assertion as in : <details<summaryBacktrace:</summary</details
cc
triage: P-medium. Removing nomination label.
The ICE seems to disappear on latest nightly, could someone confirm it?
Fixed by , but I believe it could do with a compile test
Change:
// Note, however, that we run on lots older linuxes, as well as cross // compiling from a newer linux to an older linux, so we also have a // fallback implementation to use as well. <del> // // Due to rust-lang/rust#18804, make sure this is not generic! </del> #[cfg(any( target_os = "linux", target_os = "fuchsia",

Discussion:
The corresponding issue has been closed by PR , so is that passage still relevant or can it be removed? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Seems likely it can be removed. Marking as E-help-wanted; I don't expect we'll do this ourselves but if someone files a PR removing the comment I think it's likely we can accept that pretty easily.
Hi:) I would like to work on this.
claim
Change:
INC="$INC:/usr/include" hide_output  <del> cmake ../llvm-$LLVM.src  </del> <ins> cmake ..  </ins> -DCMAKE_C_COMPILER=/rustroot/bin/gcc  -DCMAKE_CXX_COMPILER=/rustroot/bin/g++  -DCMAKE_BUILD_TYPE=Release 

Discussion:
This can be reproduced in a centos 5 docker container, such as the one provided by python's pypa: The last command produces the following error: Versions: : : : : crashes with the same output as above
Some bisection reveals that this is a regression from actually, and I suspect the most likely candidate of that rollup is cc As to why these symbols are just now showing up, I'm not sure...
Ok I've confirmed is the cause of this bug. I don't really know how this is showing up though as none of the symbols which use are even referenced from the file: None of those symbols are even used from or LLVM or... anywhere it seems. I have no idea what's putting that into some symbol table that needs to be resolved. This may be some LLD change though because if I disable ThinLTO for LLVM itself then these symbol references seem to go away...
Ok I've bisected this to , which makes sense sort of because that's injecting references to all builtins, even if we're not actually using them. I'll follow up with LLVM later tomorrow
Or actually, I've gone ahead and opened an to get the ball rolling there. This is also a beta regression as well, so I'm retagging as such. I believe the only solution we have for now on this is to turn off ThinLTO, so I'm going to send a PR to do that.
Er turns out this is likely already fixed at , so I can try out building that locally
This seems to have regressed again: https://travis- with this Dockerfile: Relevant excerpt:
Indeed! This should be fixed in
Change:
static BAR: _ = "test"; //~ ERROR E0121 <del> fn main() { } </del> <ins> fn main() {} </ins>

Discussion:
I'll jump straight into the minimum verifiable example: Try it out . Here is the standard error output: Being a complete beginner I don't really know what I can add to this report, and I have a workaround which I can use to avoid this problem. (I know what I can put in the place of ) Edit: () gives which seems not ideal.
Assigning as and removing .
There is a partial fix in , though it regresses diagnostics. I think it ought not to be too much work to address this, but I do not have time at the moment.
This ICEs since . modify labels: +regression-from-stable-to-stable