jiebi/CodeConvo huggingface dataset:
Change:
use crate::back::write::create_informational_target_machine; use crate::errors::{ <del> InvalidTargetFeaturePrefix, PossibleFeature, TargetFeatureDisableOrEnable, </del> <ins> FixedX18InvalidArch, InvalidTargetFeaturePrefix, PossibleFeature, TargetFeatureDisableOrEnable, </ins> UnknownCTargetFeature, UnknownCTargetFeaturePrefix, UnstableCTargetFeature, }; use crate::llvm;

Discussion:
On the target, specifying the target feature using the flag results in the following warning: The desired effect of this flag is to reserve the x18 register so that LLVM does not use it during codegen. Note that despite the warning, the flag still works fine today since it is passed on to LLVM. This feature is necessary for Rust to work when using the Linux Kernel's dynamic shadow call stack feature on aarch64 (). The shadow call stack feature requires that the x18 register is reserved, since it is used to store the shadow stack. In C code, the dynamic version of shadow call stack requires you to pass but not (which is only used for non-dynamic SCS). Clang has a collection of flags for reserving other registers than x18 as well. I think it would make sense to add those as well, even if they are less useful than x18. Related to . Related to .
This affects the ABI, right? I think adding a target spec option makes the most sense (or actually you can already set it as target feature in the target spec without giving a warning). That way you can't enable or disable it for individual functions or crates, which would break the ABI.
Yeah, it would be nice to have a flag for this (or having something like "global target features", i.e. like , but that it ensures it is set the same way for all compilation units).
There could be ABI concerns with this in general. AAPCS64 defines x18 as a platform register if required, or temporary if a platform register isn't needed. For x18 it's probably unlikely for it to have ABI concerns as it's already reserved for use on some platforms, the ones where it's not already reserved, it's only supposed to be a temporary register so not using it should be OK as it is not used for any fixed purpose. That's obviously assuming a platform defines its ABI based on the Arm standards. LLVM does support reserve on other registers, most notably for ABI reasons, x1 through x7 which would have ABI problems. LLVM does have test cases to ensure that a function call doesn't occur if any of the argument registers have been reserved. I'm not sure what other codegen backends do in that case though, or if they even support reserving those registers.

The analysis that LLVM does, doesn't seem to care if it would need to use that register for ABI reasons, even a function such as can't be called in a quick test. Using target features for this feels strange to me though, I'm wondering if a codegen option to reserve certain registers would be a better approach here. While this issue is specifically about reserving a register on AArch64, LLVM does support this for multiple other architectures and multiple registers, which we should maybe consider for the future.
Change:
#[rustc_const_stable(feature = "rust1", since = "1.0.0")] pub const unsafe fn bar2_gated() -> u32 { 42 } <del> // @has 'foo/fn.bar_not_gated.html' '//pre' 'pub unsafe fn bar_not_gated() -> u32' </del> <ins> // @has 'foo/fn.bar_not_gated.html' '//pre' 'pub const unsafe fn bar_not_gated() -> u32' </ins> pub const unsafe fn bar_not_gated() -> u32 { 42 } pub struct Foo;

Discussion:
This is a follow-up on I opened earlier, with the requested minimal reproduction in the form of a simple .
Looks like this is either or cc - do you know what those are doing/why they exist?
It's because of the feature. As long as it's not stable, they don't want the keyword to be displayed, even if the function description is describing a const fn. This is a bit strange.
Yeah, that makes no sense to me at all. I have a crate that is very much nightly-only containing a rather large number of s, and at the moment literally none of them are displayed as such in my documentation because of this, despite the fact that they've never not been and will never not be in the future. I of course cannot disable the flag either as then the crate won't compile, as much of what I'm doing does not fit into the stabilized set of functionality. At the very least, surely there must be some way to make it possible to specifically tell rustdoc to "please always document s as exactly what they are no matter what" without changing this default behaviour if that's not desired?
I think the metric should be 'does this have , not 'is this a function'.
I wonder if this isn't an artifact of the switch when adding support... But in any case, it should be a check over , you're absolutely right.
I wonder if this ever worked ... do you mind trying this with an old version of rustdoc? Preferably before was implemented: cc
I'll try that on my crate later today.
After testing both the example I gave here and my own crate with various nightlies from before was implemented, I can confirm that this problem definitely pre-dates it. There's no difference in how rustdoc behaved.
(apologies to lcnr for the ping)
If this helps at all, whichever version of rustdoc was using on August 1st did document my crate properly, it seems. Only the very latest version, uploaded on September 5th, was documented with the keyword missing. So it's a fairly recent bug, overall.
Ok, so I think I was reading the dates on the PRs a bit wrong when I tested yesterday as far as the timeframe for when was merged.

I just did a whole bunch more one-by-one testing of nightlies from August, and in fact the problem doesn't quite predate which was merged on August 7th. Specifically, the very last nightly to have a rustdoc that documents correctly is . Switching directly from that to from the next day makes the problem appear.
consider using instead which will do it automatically
Well, I already know it's a commit from between the 10th and 11th of August now, at least. Also, doesn't really seem to be designed for scenarios where identifying the problem specifically requires running on a crate and then visually inspecting the generated HTML files...
Change:
<ins> // check-pass pub trait Archive { type Archived; } impl<T> Archive for Option<T> { type Archived = (); } pub type Archived<T> = <T as Archive>::Archived; pub trait Deserialize<D> {} const ARRAY_SIZE: usize = 32; impl<__D> Deserialize<__D> for () where Option<[u8; ARRAY_SIZE]>: Archive, Option<[u8; ARRAY_SIZE]>: Archive, Archived<Option<[u8; ARRAY_SIZE]>>: Deserialize<__D>, { } fn main() {} </ins>

Discussion:
Prior to Rust 1.56, I could use values when defining rkyv structs. However, in Rust 1.56, this is no longer allowed. I tried this code: I expected to see this happen: Prior to Rust 1.56, this compiled. Instead, this happened: The following error appears: It most recently worked on: Rust 1.55 : <!-- 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 --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Further information: This is using the crate. We use an older , however this still occurs with the latest version.
Bisected to . label +E-needs-mcve
Reproducer without macros, but still dependent on rkyv:
Reduced: Also, if you remove one of the lines, the code still compiles on 1.55 but the error on 1.56 changes to: label regression-from-stable-to-stable (not sure what happened with rustbot and the labels above)
label -E-needs-mcve
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high +T-compiler
Ok, I know what is the problem and have a fix. Apparently when looking for implementation for compiler considers candidates: one for top-level impl and two s. Before was using that was enough to discard the two s. But changed it to use instead, which is pessimistic, so now the compiler drops the global impl instead (because is not sure) and then can't decide between the two s.
Funny thing is it seems like it's fixed already in the master branch... Trying to bisect what fixed it to better understand if my change is needed after all.
also fixes it.
Change:
<ins> // Copyright 2015 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. trait Tup { type T0; type T1; } impl Tup for isize { type T0 = f32; type T1 = (); } fn main() {} </ins>

Discussion:
This was the smallest I could make it. Commenting out the lines for either or or making and the same type allows compilation to finish successfully. Error: What I don't understand is: why in the world is it even complaining about implementations when no one is using ? Is this some sort of weird interaction with trait object types? (rustc at commit , Linux)
I've been seeing this too, any time I have a trait with two associated types that are different. Still happens as of the current nightly. Strangely, if you make them the same (i.e. "type T0 = f32; type T1 = f32;" in the impl), the error goes away.
This seems to be fixed. The example compiles on
Change:
Canonical, CanonicalVarValues, CanonicalizedQueryResponse, Certainty, OriginalQueryValues, QueryOutlivesConstraint, QueryRegionConstraints, QueryResponse, }; <ins> use crate::infer::nll_relate::{NormalizationStrategy, TypeRelating, TypeRelatingDelegate}; </ins> use crate::infer::region_constraints::{Constraint, RegionConstraintData}; <del> use crate::infer::InferCtxtBuilder; use crate::infer::{InferCtxt, InferOk, InferResult}; </del> <ins> use crate::infer::{InferCtxt, InferCtxtBuilder, InferOk, InferResult, NLLRegionVariableOrigin}; </ins> use crate::traits::query::{Fallible, NoSolution}; <del> use crate::traits::TraitEngine; </del> <ins> use crate::traits::{DomainGoal, TraitEngine}; </ins> use crate::traits::{Obligation, ObligationCause, PredicateObligation}; use rustc::arena::ArenaAllocatable; use rustc::ty::fold::TypeFoldable; <ins> use rustc::ty::relate::TypeRelation; </ins> use rustc::ty::subst::{GenericArg, GenericArgKind}; use rustc::ty::{self, BoundVar, Ty, TyCtxt}; use rustc_data_structures::captures::Captures;

Discussion:
mullvad-vpn build fails after jnix crate upgrade to v0.2.0 I tried this code: sudo pacman -Russnc mullvad-vpn sudo rm -rf /var/cache/mullvad-vpn/ sudo rm -rf /var/log/mullvad-vpn/ git clone cd mullvad-vpn makepkg -si I expected to see this happen: build completes without errors Instead, this happened: rustc panicks at 'assertion failed: data.isempty()', :
cc
ping icebreakers-cleanup-crew
Currently running
prints: searched nightlies: from nightly-2020-02-11 to nightly-2020-02-18 regressed nightly: nightly-2020-02-16 searched commits: from to regressed commit: source code: modify labels: -E-needs-bisection
modify labels: -E-needs-mcve
triage: P-high. Removing nomination.
I'm also getting this error. : Backtrace:
Change:
| sym::cfi_encoding // FIXME(cfi_encoding) | sym::may_dangle // FIXME(dropck_eyepatch) | sym::pointee // FIXME(derive_smart_pointer) <del> | sym::linkage // FIXME(linkage) </del> | sym::omit_gdb_pretty_printer_section // FIXME(omit_gdb_pretty_printer_section) | sym::used // handled elsewhere to restrict to static items | sym::repr // handled elsewhere to restrict to type decls items

Discussion:
I tried this code: I expected to see this happen: compilation failure because of attribute on an item where it makes no sense Instead, this happened: compiled successfully : cc see for where to fix this issue <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
var fullNewTheme = newTheme + resourcesSuffix + ".css"; var newHref = mainStyleElem.href.replace(fullBasicCss, fullNewTheme); <ins> // If this new value comes from a system setting or from the previously // saved theme, no need to save it. if (saveTheme === true) { updateLocalStorage("rustdoc-theme", newTheme); } </ins> if (styleElem.href === newHref) { return; }

Discussion:
Repro: Clear local-storage for Set system theme to light Visit change theme to Visit note that the theme has been set to following the system Visit see that the theme changes back to because the stored theme was never updated Visit then change the system theme to dark, updating the displayed theme to , and then change the system theme back to light, updating the displayed theme to Visit see that the theme is now because the stored theme was updated This affects the plan we have for to follow rustdoc's theme setting, , I assumed that rustdoc would update the stored theme whenever it changes so we could synchronize off that. Missing the initial setting based on the fact that is the "default" theme loaded before the JS runs seems like a bug. cc
Error: Label rustdoc-ui can only be set by Rust team members Please let know if you're having trouble with this bot.
I'll implement this
Change:
href = href, name = name, generics = g.print(cx), <del> decl = d.full_print(header_len, indent, header.asyncness, cx), </del> <ins> decl = d.full_print(header_len, indent, cx), </ins> notable_traits = notable_traits_decl(d, cx), where_clause = print_where_clause(g, cx, indent, end_newline), )

Discussion:
produces: But I think it should be. For the HTML backend, rustdoc "resugars" the return type to get the from I think we should move this to a pass. cc does this change seem like a good idea. modify labels: +T-rustdoc +A-rustdoc-json
I'm not sure if it's worth adding a pass for this... Maybe handling this into a specific function shared between both formats could be a better idea?
We could call in . Or we could move this to when constructing . I'm not sure which makes most sense.
In directly seems like a good approach.
Change:
); } } <del> let msg = "an `as` expression can only be used to convert between primitive  types or to coerce to a specific trait object"; </del> <ins> let (msg, note) = if let ty::Adt(adt, _) = self.expr_ty.kind() && adt.is_enum() && self.cast_ty.is_numeric() { ( "an `as` expression can be used to convert enum types to numeric  types only if the enum type is unit-only or field-less", Some( "see https://doc.rust-lang.org/reference/items/enumerations.html#casting for more information", ), ) } else { ( "an `as` expression can only be used to convert between primitive  types or to coerce to a specific trait object", None, ) }; </ins> if label { err.span_label(self.span, msg); } else { err.note(msg); } <ins> if let Some(note) = note { err.note(note); } </ins> } else { err.span_label(self.span, "invalid cast"); }

Discussion:
Possibly link to the Rust Reference where this is explained in detail. Casting an enum to an int is common for C developers. When I searched the internet for guides on how to do this in Rust, they all essentially said it just works like . E.g. , . These guides don't explicitly say that this only works if all of the enum variants are unit-like. The compiler message in this situation did not help me to understand what had gone wrong, and googling for it and "enum" returned the same sort of results as mentioned above. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label D-newcomer-roadblock D-confusing
claim
Change:
fn main() { e::foo(); f::foo(); //~ ERROR `foo` is ambiguous <del> g::foo(); //~ ERROR `foo` is ambiguous </del> <ins> g::foo(); </ins> } mod ambiguous_module_errors {

Discussion:
the code i tried: noticed there was a typo, fixed it, still getting an ICE i expected: cargo-generate/pull/135, to not compile and give an error about typo cargo-generate/pull/136, to compile (and no longer display 2018 warnings about path clarity) instead, what happened: system info:
i also get this on stable and earlier nightlies, if that is at all useful.
(also please feel free to let me know if i can provide any more info- this is my first time filing a compiler bug! thanks for all your hardwork and help <3)
Nominating -- we should keep focus on Rust 2018-related bugs like this, I think.
Did you? I mean, there is a typo, right? Do you mean, you expected a controller error? Specifically I see this in the diff: and I think it should be ?
I guess you are saying you get the same ICE from , which has a fix... did you try a cargo clean? (I'm wondering if it is related to incremental compilation.)
yeah, so i noticed the typo, and then fixed it (hence the 2 PRs- i included both on the offchance that there were 2 issues.) i expected the 2nd one to compile, and the first one (after i noticed the typo, to not compile but give an error re: the typo). i will run a cargo clean and see if it helps!
OK, thanks for the clarification.
just ran and then and have the same error message.
Fixed in
Change:
GEPi(bcx, fat_ptr, &[0, abi::FAT_PTR_ADDR]) } <ins> pub fn copy_fat_ptr(bcx: Block, src_ptr: ValueRef, dst_ptr: ValueRef) { Store(bcx, Load(bcx, get_dataptr(bcx, src_ptr)), get_dataptr(bcx, dst_ptr)); Store(bcx, Load(bcx, get_len(bcx, src_ptr)), get_len(bcx, dst_ptr)); } </ins> // Retrieve the information we are losing (making dynamic) in an unsizing // adjustment. // When making a dtor, we need to do different things depending on the

Discussion:
I've tried to write: The line above gives LLVM assertion. I think this must show some syntax error.
Change:
// except according to those terms. struct Foo { <del> x: &bool, //~ ERROR E0106 </del> <ins> x: &bool, //~^ ERROR E0106 //~| NOTE expected lifetime parameter </ins> } enum Bar { A(u8), <del> B(&bool), //~ ERROR E0106 </del> <ins> B(&bool), //~^ ERROR E0106 //~| NOTE expected lifetime parameter </ins> } <del> type MyStr = &str; //~ ERROR E0106 </del> <ins> type MyStr = &str; //~^ ERROR E0106 //~| NOTE expected lifetime parameter </ins> fn main() { }

Discussion:
From: src/test/compile- Error E0106 needs a span_label, updating it from: To:
I'll try this one.
I think "expected lifetime parameter" is a better label. bonus: have the label on the ampersand only.
to suggestions
Do you mean like this? Or like this, with the primary span changed?
I think he means the second one:
Change:
on: branch: auto DEPLOY_ALT: 1 <ins> max_error_retry: 5 </ins> # init: #   - ps: iex ((new-object net.webclient).DownloadString('https://raw.githubusercontent.com/appveyor/ci/master/scripts/enable-rdp.ps1'))

Discussion:
Seen twice now with the failure message: Logs: I'll probably email them about retries and such come next week, wanted to start collecting logs in the meantime.
sigh
We've got enough examples now I've about this.
An has been created for this.
Change:
resolve_consider_marking_as_pub = consider marking `{$ident}` as `pub` in the imported module <ins> resolve_consider_move_macro_position = consider moving the definition of `{$ident}` before this call </ins> resolve_const_not_member_of_trait = const `{$const_}` is not a member of trait `{$trait_}` .label = not a member of trait `{$trait_}`

Discussion:
Often times, the actual error of the attempted call and the warning of the unused macro can be apart and/or soaked in other errors. Due to this, it might be desirable to couple a help message addressing this specific situation of a later definition. This might also be useful advice for beginners who are just starting out with Rust and might not be aware of the horrors of declarative macros using , and as such could appreciate a helping hand by the compiler here. No response_ I tried to keep the suggested output close to the one for similarly named macros/variables, but that might not be applicable here and instead deserve its own section under the code excerpt. Open for bikeshedding. Like all of this, actually. Hmm. (The message is the same on nightly 2024-02-12.)
label +D-terse +D-newcomer-roadblock
Thank you!!
Change:
<ins> // compile-flags: -O #![crate_type = "lib"] #[no_mangle] // CHECK-LABEL: @noop( pub fn noop(v: &mut Vec<u8>) { // CHECK-NOT: reserve_for_push // CHECK-NOT: call // CHECK: tail call void @llvm.assume // CHECK-NOT: reserve_for_push // CHECK-NOT: call // CHECK: ret if let Some(x) = v.pop() { v.push(x) } } #[no_mangle] // CHECK-LABEL: @push_byte( pub fn push_byte(v: &mut Vec<u8>) { // CHECK: call {{.*}}reserve_for_push v.push(3); } </ins>

Discussion:
The following code should be optimized to a no-op afaict, but instead gives: (this is true on stable, beta and nightly). I think a blocking point here is that rustc/LLVM do not manage to infer the invariant: Note that the version with asserts for this invariant removes the useless conditional call to but instead gets useless calls to assert failure code.
I think there are two issues here: the invariant isn't encoded anywhere inside the push and pop methods llvm's constraint elimination pass (in llvm 16) isn't smart enough to figure these things out (even with the s) The first issue can be fixed by adding s to push and pop. The second one is somewhat tricky, however we are fortunate that this has been improved somewhat already in upstream llvm: (c++ reproducer, so it's not directly visible that the constraint elimination pass got improved) (llvm-ir)
Thanks for investigating! Unfortunately your code is equivalent to this Rust code which gets correctly optimized (): I'm not proficient in C++ but I'll try to find an example closer to Rust.
This gets correctly optimized, I'll try a PR to add the assume to and see how it does on benchmarks.
Just ran into which seems similar
Also
Change:
endef <ins> ifneq ($(CFG_ENABLE_DIST_HOST_ONLY),) </ins> $(foreach host,$(CFG_HOST), <del> $(eval $(call DEF_INSTALLER,$(host)))) </del> <ins> $(eval $(call DEF_INSTALLER,$(host),$(host)))) else $(foreach host,$(CFG_HOST), $(eval $(call DEF_INSTALLER,$(host),$(CFG_TARGET)))) endif </ins> dist-install-dirs: $(foreach host,$(CFG_HOST),dist-install-dir-$(host))

Discussion:
Currently, Servo uses snapshots generated from . This works great for self-targeting builds, but there's no support today for generating cross-compilation snapshots. This feature is required to support Servo Android test machines on Travis CI. I see that handles cross-compilation: It would be great if there were a different (?), too, to support this scenario.
If I went ahead and created such a target, is that something you would be open to?
Sounds reasonable to me!
I've started the patch to do this. There is some existing cruft from somebody making a similar half-fix previously that needs to be deleted. Doing it right I will involve switching the default behavior to package all targets, leaving the current behavior as a special case for our bots, which means we need to update the bots. It looks pretty easy though and I hope to have it done tomorrow.
Thanks! That explains the confusion I had - I kept getting halfway through it and then getting very confused because it looked like it should be doing what I wanted already.