jiebi/CodeConvo huggingface dataset:
Change:
if is_extern && !std_internal { let target = &tcx.sess.target.target.llvm_target; // WebAssembly cannot export data symbols, so reduce their export level <del> if target.contains("wasm32") || target.contains("emscripten") { </del> <ins> if target.contains("emscripten") { </ins> if let Some(Node::Item(&hir::Item { kind: hir::ItemKind::Static(..), .. })) = tcx.hir().get_if_local(sym_def_id) {

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:
if ident.name == lookup_name && ns == namespace { if filter_fn(name_binding.def()) { // create the path <del> let mut segms = path_segments.clone(); </del> <ins> let mut segms = if self.session.rust_2018() && !in_module_is_extern { // crate-local absolute paths start with `crate::` in edition 2018 // FIXME: may also be stabilized for Rust 2015 (Issues #45477, #44660) let mut full_segms = vec![ ast::PathSegment::from_ident(keywords::Crate.ident()) ]; full_segms.extend(path_segments.clone()); full_segms } else { path_segments.clone() }; </ins> segms.push(ast::PathSegment::from_ident(ident)); let path = Path { span: name_binding.span,

Discussion:
Consider the following program. When compiled with with the 6 July nightly, we get this error message: But if we take the suggestion literally (and continue using the 2018 edition), is : A pull request is forthcoming.
Change:
/// ``` pub fn invalid() {} //~^^^^ WARNING could not parse code block as Rust code <ins> /// ``` /// fn wook_at_my_beautifuw_bwaces_plz() {); /// ``` pub fn uwu() {} //~^^^^ WARNING could not parse code block as Rust code </ins>

Discussion:
I have created which reliably reproduces the internal compiler error on my system. The readme in that crate includes version as well as from inside and outside the repo which has a . This is recreated with: with the dependencies from my original crate into : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Note, changing to enables to succeed with version: -and:
claim
I'm also getting a similar error but mine doesn't resolve by changing in . More info:
This issue here is caused by nom as well. The fix is pretty simple, I should be able to open up the PR today.
Change:
<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. use std::num::Num; trait BrokenAdd: Num { fn broken_add<T>(&self, rhs: T) -> Self { *self + rhs //~ ERROR mismatched types } } impl<T: Num> BrokenAdd for T {} pub fn main() { let foo: u8 = 0u8; let x: u8 = foo.broken_add("hello darkness my old friend".to_string()); println!("{}", x); } </ins>

Discussion:
(sorry about the bad title but I really have no clue what's going on here!) Compiles and prints . I think it's getting at the of the inside a . edit: As one might expect, does not compile.
Seems rather bad. cc
Nominating.
This is a fun bug, it's by far not limited to the operator. I tried to reduce the test case a bit, starting with a new non-operator trait, changed it to a static method that just returns for inference, and...
cc me
Assigning 1.0, P-backcompat-lang.
Even smaller:
Change:
} pub use accepted::ACCEPTED_FEATURES; <del> pub use active::{Features, ACTIVE_FEATURES, INCOMPLETE_FEATURES}; </del> <ins> pub use active::{Features, ACTIVE_FEATURES, INCOMPATIBLE_FEATURES, INCOMPLETE_FEATURES}; </ins> pub use builtin_attrs::{ deprecated_attributes, find_gated_cfg, is_builtin_attr_name, AttributeGate, AttributeTemplate, AttributeType, BuiltinAttribute, GatedCfg, BUILTIN_ATTRIBUTES, BUILTIN_ATTRIBUTE_MAP,

Discussion:
I expect the code below code to compile, but it fails. should allow more than just the types whitelisted in , but it seems rustc only looks at the flag in this case. The error message is:
You are right But why would you want to use the two of them?
I imagine this to happen whenever at first you only decide to use , but then later also switch to . You might just follow rustc, which tells you to add to your project, so you do, but then you get the behaviour as described in this issue. This could also perhaps get triggered in a more subtle way where you write a library that uses to enable or disable features.
what do you think ?
It probably makes sense to instead check if we are not using here, but there are a quite a few places were we check for , we maybe want to instead emit an error/warning when using both and in the same crate.
Created a way to produce an error in case of incompatible features, like this one
I have one question, how does using 'incompatible feature' cause maybe undefined behavior? Are there other incompatible features? In this case, wouldn't it be better to produce an error message like "feature(constgenerics) is a superset of feature(minconst_generics)"?
Note that: results in a : So currently is not a superset of .
You are missing a in your feature. I still think constgenerics are a superset of minconstgenerics, but rustc just suggest using the smaller one in this case becouse that's the subset aiming to be stabilized for now
Ah of course, my bad I was confused looking at some ui tests for const generics, and missed that those now have support differentiating between expected behavior under and , and thought a particular error was always being thrown, instead of only under .
Change:
ar: HashMap::new(), ranlib: HashMap::new(), crates: HashMap::new(), <ins> crate_paths: HashMap::new(), </ins> is_sudo, ci_env: CiEnv::current(), delayed_failures: RefCell::new(Vec::new()),

Discussion:
I tried this code: I expected to see this happen: bootstrap documents the whole compiler, like it does for . Instead, this happened: The problem is that is too naive and expects the name of each crate to match its file path on disk: It needs to map from the path to the name somehow. There's already a way to go from the name to the path: but I don't think there's a way to do the reverse. HEAD is . label +A-bootstrap
label: +A-bootstrap
label: +E-mentor +A-rustbuild
Change:
// Don't leak types into signatures unless they're nameable! // For example, if a function returns itself, we don't want that // recursive function definition to leak out into the fn sig. <del> let mut should_recover = false; </del> <ins> let mut recovered_ret_ty = None; </ins> <del> if let Some(ret_ty) = ret_ty.make_suggestable(tcx, false, None) { </del> <ins> if let Some(suggestable_ret_ty) = ret_ty.make_suggestable(tcx, false, None) { </ins> diag.span_suggestion( ty.span, "replace with the correct return type", <del> ret_ty, </del> <ins> suggestable_ret_ty, </ins> Applicability::MachineApplicable, ); <del> should_recover = true; </del> <ins> recovered_ret_ty = Some(suggestable_ret_ty); </ins> } else if let Some(sugg) = suggest_impl_trait(&tcx.infer_ctxt().build(), tcx.param_env(def_id), ret_ty) {

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: Unexpected coroutine/closure type in variance computation', 'error: internal compiler error: Unexpected coroutine/closure type in variance computation' File: --auto-reduced (treereduce-rust): original: 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: [cratevariances] computing the variances for items in this crate [variancesof] computing the variances of [mirborrowck] borrow-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
smaller
ice since it seems
i can look into this claim
Change:
} ty::AliasTy<'tcx> { <del> p!(print_def_path(self.def_id, self.substs)); </del> <ins> if let DefKind::Impl { of_trait: false } = cx.tcx().def_kind(cx.tcx().parent(self.def_id)) { p!(pretty_print_inherent_projection(self)) } else { p!(print_def_path(self.def_id, self.substs)); } </ins> } ty::ClosureKind {

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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
regression in cc
claim
another one `

<!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regression in cc
Thanks :) claim
Change:
pub const LOG10_E: f32 = 0.434294481903251827651128918916605082_f32; /// 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: f32 = 0.301029995663981195213738894724493027_f32; /// ln(2)

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:
} } <del> fn update_macro_reachable_mod( &mut self, reachable_mod: hir::HirId, defining_mod: DefId, ) { </del> <ins> fn update_macro_reachable_mod(&mut self, reachable_mod: hir::HirId, defining_mod: DefId) { </ins> let module_def_id = self.tcx.hir().local_def_id(reachable_mod); let module = self.tcx.hir().get_module(module_def_id).0; for item_id in &module.item_ids {

Discussion:
Seems to be something to do with Rocket. Having a on the internal function is causing the compiler to blow up. Version: Stack trace:
I think this issue might be better-suited for the Rocket repository.
Ah OK. The output told me to file an issue here so I thought it might be a compiler problem rather than something specific to Rocket. Can we leave it open for a bit just until it's confirmed as Rocket-specific?
Hm, this bug probably originates with interesting codegen in Rocket, but is likely a bug in rustc in the end. I would keep it here, though letting Rocket know about it might not be a bad idea.
I'm going to label this as P-high for now since it affects Rocket. cc re. macros & privacy.
Without looking too deeply I would wager that we're getting a here, although it could be any other which would be worrisome:
Would be great to have a reproducer that did not depend on Rocket and codegen, if it is possible.
Trying to get a simple reproducible example and am unable to :( It got a little time-consuming and I really need to get work done so have worked around it for now. I could possibly publish everything in a repo, but it would still be rocket + codegen and not a very simple example!
Latest nightly (2019-08-11) still panics, but with different error message:
Also as a sidenote: Rocket master does not ICE anymore. The ICE "was fixed" by so it may be a problem with decl_macro ?
I would still wan't not to ICE on the face of malformed input.
For future reference, when panicking or using for not finding what you expect it is a good idea to include in the message what the found value was. :)
I think you got me wrong. I haven't said, that this should be closed because upstream code has changed, but I said, that upstream does not ICE anymore, so I looked into it, what caused it to not ICE anymore.

I try to go that ;) Confirmed, that it is related to decl maros modify labels: +A-macros-2.0
I need your help with the tags here please ^^
<details<summaryBacktraces</summary<details<summary60960a260</summary</details<details<summarydddb7fca0</summary</details</details modify labels: -E-needs-mcve
What is the appropriate visibility scope for ? is failing because we get the following instead: In my mind the expected semantics of this could would be to scope to inside , but currently with a macro by example it would be scoped to the current module. I can implement either semantic. Edit: I'm talking out of my ass, matches my intuition. Don't know why I thought otherwise.
Change:
"overloaded augmented assignments are not stable"); fileline_help!( tcx.sess, e.span, <del> "add #![feature(augmented_assignments)] to the crate features  </del> <ins> "add #![feature(augmented_assignments)] to the crate root  </ins> to enable"); } }

Discussion:
I the augmented_assignments feature to the , but when testing, the compiler complained: I thought I had already done that, but it turns out it isn't enough to be in the source file using the feature. In retrospect (now that I know from help on IRC what the issue is), I'd expect the error to say: or something to that effect.
Change:
use super::Iterator; /// Compare `a` and `b` for equality using `TotalEq` <del> pub fn equals<A: TotalEq, T: Iterator<A>>(mut a: T, mut b: T) -> bool { </del> <ins> pub fn equals<A: TotalEq, T: Iterator<A>, S: Iterator<A>>(mut a: T, mut b: S) -> bool { </ins> loop { match (a.next(), b.next()) { (None, None) => return true,

Discussion:
They're currently very restricted as they only work with a single iterator type for both arguments, so, e.g. doesn't work. It should be easy to just add another parameter for the second argument.
Change:
<del> #![feature(type_privacy_lints)] </del> #![deny(unnameable_types)] mod m {

Discussion:
This is a tracking issue for the RFC "Type privacy and private-in-public lints " (rust-lang/rfcs). Steps: [ ] Implement the RFC (cc ) [ ] Adjust documentation ([see instructions on forge][doc-guide]) [ ] Stabilization PR ([see instructions on forge][stabilization-guide]) [stabilization-guide]: [doc-guide]: Unresolved questions: [ ] It's not fully clear if the restriction for associated type definitions required for type privacy soundness, or it's just a workaround for a technical difficulty. [ ] Interactions between macros 2.0 and the notions of reachability / effective visibility used for the lints are unclear. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Oops - I didn't mean for that to un-assign you. Is there a way to prevent these lints from becoming insta-stable? Would it make sense to put them behind a feature gate?
Perhaps we could only fire the lints if an unstable compiler flag (maybe ) is passed? This would still make the lint names insta-stable, though.
in core ffi There is a fixme about , how to fixes that?
By implementing this RFC, I guess. Until that workarounds like this sealed trait will need to be used.
Where is the impl, the RFC is already accepted...
An RFC being accepted just means the feature can be implemented, not that it has been implemented. It doesn't even mean that implementing it is a priority. I believe there has been more discussion of this RFC over at as well as other issues that I can't seem to track down right now.
Hello! I know y'all are busy, but I'm curious if there's an update, particularly on for Voldemort Types - which I'd love to see. I was actually a bit surprised to find that it wasn't included in the existing lint. Appreciate the work that y'all are doing, especially who seems to have put in a lot of legwork.
The tentative plan is that will work on this in March-May.
Cool! Good luck! I'm happy to be a guinea pig to try it out or do code review if that would be helpful.
This issue should be closed by Two follow up issues about improving the effective visibility tables
Change:
//          use proc_macro::bridge::client::ProcMacro; // //          #[rustc_proc_macro_decls] <ins> //          #[allow(deprecated)] </ins> //          static DECLS: &[ProcMacro] = &[ //              ProcMacro::custom_derive($name_trait1, &[], ::$name1); //              ProcMacro::custom_derive($name_trait2, &["attribute_name"], ::$name2);

Discussion:
Use attribute on a procedural macro function doesn't work like expected: it triggers a warning message also when library is building and not just in call place. I know that the attribute support is not landed in stable but this warning is present in all channels (stable, beta and nightly). Compiling lib simple by raise follow warning: Sadly this issue make attribute not usable at all for procedural macro. Follow the code to reproduce this issue: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The most likely reason is that and friends are used from the proc macro harness automatically generated for proc macro crates. So either the harness should generate (there are precedents for this, e.g. test harness generates ), or should not be reported from "externally generated code", which usually includes macros from other crates, but also code generated by the compiler.
Adding should be a very simple fix - the item referring to the proc macro definition functions is generated in in .
claim
Change:
if (!next) { return; } <del> if (next.getElementsByClassName("method").length > 0 && hasClass(e, "impl")) { </del> <ins> if (hasClass(e, "impl") && (next.getElementsByClassName("method").length > 0 || next.getElementsByClassName("associatedconstant").length > 0)) { </ins> insertAfter(toggle.cloneNode(true), e.childNodes[e.childNodes.length - 1]); } };

Discussion:
The first impl block with a constant is not collapsible like the second impl block with a function. !
As far as I can tell, this is the desired behaviour (not to hide associated impl constant). So unless I'm missing something, there is nothing to fix here? cc
Why are they not hidden? It felt surprising to me, as they are part of the impl block. Also because if an impl block contains both constants and methods, both the constants and the methods are hidden when the impl block is collapsed (and this I expected).
For example  contains constants, and it is collapsible, with both the constants and the methods hidden on collapse.
It seems weird to me as well but I wasn't the one enforcing it and I don't remember the reason. Let's wait to hear from first.
It seems odd to me that they're not treated equivalently.
Change:
fn description() -> &'static str { "failure-forwarder" } <ins> fn set_expected_token(&mut self, tok: &'matcher Token) { self.expected_token = Some(tok); } fn get_expected_token(&self) -> Option<&'matcher Token> { self.expected_token } </ins> } pub(super) fn emit_frag_parse_err(

Discussion:
one of the desired output should be much help, rather than: No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim