jiebi/CodeConvo huggingface dataset:
Change:
g } else { // FIXME(nagisa): perhaps the map of externs could be offloaded to llvm somehow? <del> // FIXME(nagisa): investigate whether it can be changed into define_global let g = declare::declare_global(cx, &sym, cx.layout_of(ty).llvm_type(cx)); </del> <ins> debug!("get_static: sym={} item_attr={:?}", sym, cx.tcx.item_attrs(def_id)); let attrs = cx.tcx.codegen_fn_attrs(def_id); let g = check_and_apply_linkage(cx, &attrs, ty, sym, None); </ins> // Thread-local statics in some other crate need to *always* be linked // against in a thread-local fashion, so we need to be sure to apply the // thread-local attribute locally if it was present remotely. If we // don't do this then linker errors can be generated where the linker // complains that one object files has a thread local version of the // symbol and another one doesn't. <del> for attr in cx.tcx.get_attrs(def_id).iter() { if attr.check_name("thread_local") { llvm::set_thread_local_mode(g, cx.tls_model); } </del> <ins> if attrs.flags.contains(CodegenFnAttrFlags::THREAD_LOCAL) { llvm::set_thread_local_mode(g, cx.tls_model); </ins> } if cx.use_dll_storage_attrs && !cx.tcx.is_foreign_item(def_id) { // This item is external but not foreign, i.e. it originates from an external Rust // crate. Since we don't know whether this crate will be linked dynamically or

Discussion:
For example: This can be a little more clearly seen with the IR generated for main: Note the lack of anywhere on .
Triage: this is still true today, though needs to be updated to , and there's now a warning about not being a valid foreign type, which is irrelevant to this particular issue.
claims it repros still.
Updated test code: Still fails to compile with the same errors mentioned in the top post along with the irrelevant invalid foreign type warning mentioned by
Change:
//! More documentation can be found in each respective module below, and you can //! also check out the `src/bootstrap/README.md` file for more information. <del> // NO-RUSTC-WRAPPER #![deny(warnings, rust_2018_idioms, unused_lifetimes)] </del> #![feature(core_intrinsics)] #![feature(drain_filter)]

Discussion:
When using 1.38 beta to bootstrap itself, I get:
This is expected and not a supported bootstrapping configuration; if you want to not see these errors you'll want to either bootstrap with N-1 compiler (so, in this case, 1.37) or I believe remove from bootstrap and some other libraries, as well as set deny-warnings in to false. Note that only the 1.37 bootstrap method is officially supported as "guaranteed to work", the deny warnings fix is more of a hack. Closing as won't fix.
Huh? In the past this was always fixed as it's a very common practice for distribution packaging (I don't know of a single packager not doing that). See e.g. or (in which you sort of acknowledged that yourself) deny-warnings is already set to false in , so I guess it somehow doesn't apply to building bootstrap itself.
I hope is an acceptable compromise wrt this. Thanks for pointing out the deny-warnings option which I forgot (since it has been set to false forever for us and never had any effect on the build of bootstrap itself)
Yeah is great; in this case the unsafe block is needed for 1.37 but not on 1.38; if there was an easy way to support both use cases then I'd be happy to accept a PR targeting beta but I'm not personally aware of one -- it looks like we don't seem to have an or similar? We try to support distros and such where possible in this configuration, it's just that this specific case I'm not sure how much we can do. deny-warnings=false is always my recommendation when using a different bootstrap compiler, or manual patches to the code.
Change:
); if !is_simple_error || terr.must_include_note() { diag.note_expected_found(&expected_label, expected, &found_label, found); <ins> if let Some(ty::Closure(_, args)) = exp_found.map(|expected_type_found| expected_type_found.found.kind()) { diag.highlighted_note(vec![ StringPart::normal("closure has signature: `"), StringPart::highlighted( self.tcx .signature_unclosure( args.as_closure().sig(), rustc_hir::Unsafety::Normal, ) .to_string(), ), StringPart::normal("`"), ]); } </ins> } } }

Discussion:
Here it's obvious, but when the error says that it is mismatched with and that "types differ in mutability" then I have zero chance of figuring what's going on. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim Sounds like a feature I would like to use as well.
Change:
fn drop(&mut self) { unsafe { match &self.flavor { <del> SenderFlavor::Array(chan) => chan.release(|c| c.disconnect()), </del> <ins> SenderFlavor::Array(chan) => chan.release(|c| c.disconnect_senders()), </ins> SenderFlavor::List(chan) => chan.release(|c| c.disconnect_senders()), SenderFlavor::Zero(chan) => chan.release(|c| c.disconnect()), }

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: I expected to see the struct in the Sender buffer get dropped after the Receiver is dropped during the unwind of the panicking thread. Instead, this happened: The data in the Sender buffer is not dropped until the whole process ends. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.66.1 <!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --</p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
bisection seems to point to cc searched nightlies: from nightly-2022-11-01 to nightly-2023-02-01 regressed nightly: nightly-2022-11-14 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with:
In crossbeam, the unbounded channel does this (), but the bounded channel does not. There is no particular intent, it just hasn't been implemented. cc
Change:
rustc_driver::in_named_rustc_thread(name, move || with_globals(move || { io::set_panic(panic); io::set_print(print); <del> hygiene::set_default_edition(edition); </del> run_test(&test, &cratename, &filename,

Discussion:
Rustdoc seems to fail on async syntax in some situations. With in , the following is a sample of some apparent issues. This should build fine, but fails when running rustdoc: Tested with a few different nightlies (rustc 1.30.0-nightly ( 2018-08-05)) and latest master ().
This is a bug between rustdoc and , where the only place that is handed to libsyntax is this specific all-in-one entry point to the compiler: However, since rustdoc manages the phases of compilation itself, this line is never hit, and thus the global state telling libsyntax what edition to use is not set. We use this call manually for building doctests (see ), but not anywhere else. I propose moving the call from to , right before it sets up the parse session. That way, rustdoc can continue to set the edition in the session options, and other consumers of aren't caught by this gotcha.
Change:
rustc_serialize = { path = "../libserialize", package = "serialize" } syntax = { path = "../libsyntax" } syntax_pos = { path = "../libsyntax_pos" } <del> byteorder = { version = "1.1", features = ["i128"] } </del> <ins> byteorder = { version = "1.3" } </ins> rustc_apfloat = { path = "../librustc_apfloat" } smallvec = { version = "0.6.7", features = ["union", "may_dangle"] }

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. 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 prioritization.
triage: P-medium. Unnominating.
Change:
pub const LOG2_E: f64 = 1.44269504088896340735992468100189214_f64; /// log<sub>10</sub>(2) <del> #[unstable(feature = "extra_log_consts", issue = "50540")] </del> <ins> #[stable(feature = "extra_log_consts", since = "1.43.0")] </ins> pub const LOG10_2: f64 = 0.301029995663981195213738894724493027_f64; /// log<sub>10</sub>(e)

Discussion:
Specifically, and . PR:
Has anyone used these constants at all and want to pitch in for stabilisation of these? These have landed for a while and I'm curious how many people are using them.
+1 for stabilization. (Tried to see if log<sub2</sub(10) exists and found that it is unstable .)
(Mind providing the specific use case? Curious to see if people are using this for anything other than scientific computing.)
to estimate the "&minus;log<sub2</sub(probability)" of collision of two values chosen randomly from a set, which will be used to derive the probability of collision of N values (≈ 1 &minus; e<sup-pN<sup2</sup/2</sup, p &ll; 1, N &gg; 1). log<sub2</subis chosen instead of natural log because the set size is often 2<supn</sup(e.g. u32), but sometimes it is drawn from a set of n decimal digits which would then involve n·log<sub2</sub(10).
One ) is = shannons (bits). Currently the constant is duplicated in .
I can't @ anyone from the libs team but do you think we'd be able to start an FCP for this?
cc .
fcp merge I believe the stabilization includes .
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. The RFC will be merged soon.
Does this need a stabilization report/PR?
It needs a PR.

Not sure if we should include in that though; would you be willing to open a separate tracking issue for that, considering how that wasn't included in the FCP for this one?
There is already .
Oh, my bad. I for some reason noticed that this issue got linked in the PR and thought that there wasn't a separate tracking issue.
Change:
<ins> error[E0308]: mismatched types --> $DIR/issue-105494.rs:2:19 | LL |     let _v: i32 = (1 as i32).to_string(); |             ---   ^^^^^^^^^^^^^^^^^^^^^^ expected `i32`, found struct `String` |             | |             expected due to this | help: try removing the method call | LL -     let _v: i32 = (1 as i32).to_string(); LL +     let _v: i32 = (1 as i32); | error[E0308]: mismatched types --> $DIR/issue-105494.rs:5:19 | LL |     let _v: i32 = (1 as i128).to_string(); |             ---   ^^^^^^^^^^^^^^^^^^^^^^^ expected `i32`, found struct `String` |             | |             expected due to this error[E0308]: mismatched types --> $DIR/issue-105494.rs:7:20 | LL |     let _v: &str = "foo".to_string(); |             ----   ^^^^^^^^^^^^^^^^^ expected `&str`, found struct `String` |             | |             expected due to this | help: try removing the method call | LL -     let _v: &str = "foo".to_string(); LL +     let _v: &str = "foo"; | error[E0308]: mismatched types --> $DIR/issue-105494.rs:14:12 | LL |     let mut path: String = "/usr".to_string(); |                   ------ expected due to this type ... LL |     path = format!("{}/{}", path, folder).as_str(); |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `String`, found `&str` | help: try removing the method call | LL -     path = format!("{}/{}", path, folder).as_str(); LL +     path = format!("{}/{}", path, folder); | error: aborting due to 4 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
I tried this code (): I expected to see this happen: Instead, this happened: This is just a very specific instance where the suggestion to add some code, while "technically correct", is less useful than the better suggestion to remove some code. <!-- 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<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
label +A-diagnostics
it seems that given an expression, you can generically check if removing the last method call if present would give you the right type, so this could be implemented in a very generic way instead of special casing &str/String.
This looks awesome, thank you so much!
This is how it looks now . Very cool.
Change:
<ins> #![crate_name = "foo"] //! Reference to footnotes A[^1], B[^2] and C[^3]. //! //! [^1]: Footnote A. //! [^2]: Footnote B. //! [^3]: Footnote C. // @has 'foo/index.html' // @has - '//*[@class="docblock"]/*[@class="footnotes"]/ol/li[@id="fn1"]/p' 'Footnote A' // @has - '//li[@id="fn1"]/p/a/@href' '#fnref1' // @has - '//*[@class="docblock"]/*[@class="footnotes"]/ol/li[@id="fn2"]/p' 'Footnote B' // @has - '//li[@id="fn2"]/p/a/@href' '#fnref2' // @has - '//*[@class="docblock"]/*[@class="footnotes"]/ol/li[@id="fn3"]/p' 'Footnote C' // @has - '//li[@id="fn3"]/p/a/@href' '#fnref3' </ins>

Discussion:
Footnote lines, when written on adjacent lines, squish into a single footnote: ! -paste the following snippet at the top of a new module: . that the footnotes have been incorrectly rendered as a single footnote. No response One workaround is to separate the footnotes with empty lines: It's not pretty, though.
Transferring to Rust as it is an issue with doc generation.
I think this is somewhat working as intended. Footnote definitions need to be separated by blank lines. That is not ideal, and I think is the closest thing tracking this issue.
This is the expected behaviour from commonmark as you can see . Closing then.
Hi CommonMark does not support footnotes at all. RustDoc is very explicit that it does, so the behaviour of RustDoc's footnotes should probably be based on whatever library it uses for Markdown parsing rather than actual CommonMark. You can see from this simple example that : But :
Oh I see, my apologies. Reopening the issue then.
Triage: Still an issue.
Taking a look.
Change:
"save all temporary output files during compilation"), rpath: bool = (false, parse_bool, [UNTRACKED], "set rpath values in libs/exes"), <ins> overflow_checks: Option<bool> = (None, parse_opt_bool, [TRACKED], "use overflow checks for integer arithmetic"), </ins> no_prepopulate_passes: bool = (false, parse_bool, [TRACKED], "don't pre-populate the pass manager with a list of passes"), no_vectorize_loops: bool = (false, parse_bool, [TRACKED],

Discussion:
Tracking issue for
FWIW this should be a relatively easy bug to knock out! The option is and we'd just want to add a new flag to the (we'll delete the flag once everyone's migrated). There's a few uses throughout the codebase which I believe will need an update:    After that we'd just need to add a test which validates this behavior, likely a addition with a annotation at the top. Likewise the Cargo support should be relatively easy:
I'd like to tackle this!
OK, so this is pretty straightforward. Couple questions after actually implementing this: The RFC says the option is , but comments on the RFC suggest that people expect this to be , so one could have (I guess) . Which variant should be supported? It seems better to make the value in the single source of truth to be used throughout the compiler by setting it based on the value of or ; this makes the uses easier to read and also makes any future removal of straightforward. How should interact with ? Should we just consider any explicit setting of to "win" and only consult if the option was not explicitly provided? I guess that would mean that we'd almost have to implement the variant above?
I think it's fine to just reuse the existing  which accepts a "standard variety" of boolean options. Makes sense to me to have a single source of truth! Right now I don't think we have a lot of precedent for modifying after creation so this may not be easy. Perhaps a helper method on though? That's what a . Yeah let's just have trump . The precise semantics likely don't matter too much anyway as we'll quickly phase out the version anyway.
Change:
$(S)configure $(S)Makefile.in               $(S)man                                     $(addprefix $(S)src/,                       <ins> bootstrap                                 build_helper                              </ins> compiletest                               doc                                       driver                                   

Discussion:
Download and unpack: It should contain the same files as but it's missing the following directories: src/bootstrap, src/build_helper, src/rustc, src/grammar, etc. The files that are present in both cases are equal, so the tarball is only missing files. Perhaps a "whitelist" needs to be updated. cc
Change:
<del> // check-pass </del> #![feature(type_alias_impl_trait)] <del> mod foo { </del> <ins> mod lifetime_params { </ins> type Ty<'a> = impl Sized; fn defining(s: &str) -> Ty<'_> { s } fn execute(ty: Ty<'_>) -> &str { todo!() } <ins> //~^ ERROR return type references an anonymous lifetime, which is not constrained by the fn input types type BadFnSig = fn(Ty<'_>) -> &str; //~^ ERROR return type references an anonymous lifetime, which is not constrained by the fn input types type BadTraitRef = dyn Fn(Ty<'_>) -> &str; //~^ ERROR binding for associated type `Output` references an anonymous lifetime </ins> } <del> mod bar { </del> <ins> mod lifetime_params_2 { </ins> type Ty<'a> = impl FnOnce() -> &'a str; fn defining(s: &str) -> Ty<'_> { move || s } fn execute(ty: Ty<'_>) -> &str { ty() } <ins> //~^ ERROR return type references an anonymous lifetime, which is not constrained by the fn input types } // regression test for https://github.com/rust-lang/rust/issues/97104 mod type_params { type Ty<T> = impl Sized; fn define<T>(s: T) -> Ty<T> { s } type BadFnSig = fn(Ty<&str>) -> &str; //~^ ERROR return type references an anonymous lifetime, which is not constrained by the fn input types type BadTraitRef = dyn Fn(Ty<&str>) -> &str; //~^ ERROR binding for associated type `Output` references an anonymous lifetime </ins> } fn main() {}

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. --. Prior to , these types were rejected with this error: Currently, they're accepted. Based on the assumption that generic parameters on opaque type are not constrained (see Niko's comment ), I believe the previous behavior is correct. CC: label F-typealiasimpl_trait A-impl-trait T-compiler A-lifetimes
Out of curiosity, here's an exploit derived from . It type-checks but fails at monomorphization.
The above exploit is and should be easier to do with , where indirection through would not be necessary, so label I-unsound requires-nightly T-types
if the same code were written without lifetime params and used arguments instead, we'd see the same problem before , right?
Sorry, I've clearly missed the notification :sweat_smile:. I think you already know the answer given that you've just pushed a fix :).
Change:
#[no_mangle] pub extern fn foo() {} <ins> #[no_mangle] pub static FOO: u64 = 42; </ins>

Discussion:
Repro rustc 1.40.0 ( 2019-12-16) , the resulting wasm file doesn't have the symbol . But if we compile with , the symbol is correctly exported in the wasm file. Expected behavior: Public static variables should get exported by default. We believe this is a regression from 1.39.0. Does correctly export static variables.
cc
Symbols for wasm are and it looks like no flag is passed for , which is the bug. It looks like this may trace back to not including statics, but that's just a guess. I don't personally have time to deeply investigate this right now.
After a some investigation: disables , which means all the symbols are exported. This is why appears. If is set, symbols have to be exported , which is not the case for as has stated above The reason for this is is false. is a rust symbol and we export to a c lib. Statics are explicitly marked as . It is unclear to me how this should be handled. Maybe statics should be exported with if the static is a number? I'll make a PR for it, that might be a better place to talk about implementation details.
Oh good find! I'm not sure about emscripten, but wasm has changed in the meantime so that it can export statics, so the wasm case there I believe can be removed.
Change:
match base_cmt.ty.builtin_index() { Some(ty) => (ty, ElementKind::VecElement), None => { <ins> debug!("Explicit index of non-indexable type {:?}", base_cmt); </ins> return Err(()); } }

Discussion:
hi, my code used to compile last week. I updated the compiler today and now it crashes note that you can get my code here ()
note: going back to nightly-2017-04-01; everything work again. 'nightly-2017-04-17 is not ok. so troubles started somewhere in between.
cc
not too sure what to do with this message. can I help you with something ? I can do a small dichotomy to figure out the last working nightly if this can help.
Minified:
there is a pending fix (), no action needed on your part
triage: P-high
Change:
<ins> // check-pass trait TraitA { const VALUE: usize; } struct A; impl TraitA for A { const VALUE: usize = 1; } trait TraitB { type MyA: TraitA; const VALUE: usize = Self::MyA::VALUE; } struct B; impl TraitB for B { type MyA = A; } fn main() { let _ = [0; A::VALUE]; let _ = [0; B::VALUE]; // Indirectly refers to `A::VALUE` } </ins>

Discussion:
Hiya, on , compilation fails when defining an array whose length is from a constant from a trait from an associated type. The code compiles fine on . The error message: It seems similar to , but in this case, isn't being used. It may also be a duplicate of It also compiles fine on playpen nightly: .
Ouput from searched nightlies: from nightly-2019-12-29 to nightly-2019-12-31 regressed nightly: nightly-2019-12-31 searched commits: from to regressed commit:
cc
triage P-high, removing nomination.
A user reports that this is blocking the Rust Playground from updating its nightly. (See ) Nominating for discussion at today's meeting.
Sorry everyone, I totally forgot about this. A fix PR is up now.
Change:
struct C; <del> struct D<const X: C>; //~ ERROR the types of const generic parameters must derive </del> <ins> struct D<const X: C>; //~ ERROR `C` must be annotated with `#[derive(PartialEq, Eq)]` </ins> fn main() {}

Discussion:
I tried this code: This produces the following error on rustc 1.44.0-nightly: I guess that const generics with a generic type isn't supported/allowed. If that's the case, this should be mentioned in the error message. :
The type needs to derive , not just implement them. This is because only types can be used for const generics at the moment, but we don't expose that to the user. Maybe we could improve the diagnostic here by actually mentioning .
thanks for fixing this so quickly! Is there a chance that this restriction will be lifted, so the above code compiles?
We would like to lift the restriction, but probably not in the first stabilised version of const generics, as it's not easy to get right: we need to be very careful in making sure that we don't accidentally allow unsoundness to sneak in, and there are many subtleties.