jiebi/CodeConvo huggingface dataset:
Change:
|     | |     required by a bound introduced by this call | <del> = note: consider using `Box::pin` </del> <ins> = note: consider using the `pin!` macro consider using `Box::pin` if you need to access the pinned value outside of the current scope </ins> note: required by a bound in `assert_unpin` --> $DIR/static-not-unpin.rs:7:20 |

Discussion:
Consider the following code, taken from the (): Local pin construction was stabilized in . We should update the diagnostics to suggest this instead of the more expensive call. No response cc/ This is probably a "good first issue" as well. If someone can tag it as such? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
In some cases, works but does not (e.g., if you want ownership of the pinned future), so I think it's better to suggest both. Or something like:
claim
Alright, the suggestion has been in . IDK how to link a PR to an issue though, should I just reference the issue in the description of the PR?
if you put " in the PR description, it will automatically close this issue when the PR is merged :)
Change:
"-Wl,-syslibroot".to_string(), get_sdk_root(sdk_name)] } <ins> fn target_cpu(arch: Arch) -> String { match arch { X86_64 => "x86-64", _ => "generic", }.to_string() } </ins> pub fn opts(arch: Arch) -> TargetOptions { TargetOptions { <ins> cpu: target_cpu(arch), </ins> dynamic_linking: false, executables: true, // Although there is an experimental implementation of LLVM which

Discussion:
By default, we use the "generic" target CPU, unfortunately on x8664, this disables various features because "generic" is more like "generic x86". This disable things like some SSE usage and multibyte nops. On x8664 we should use as the minimum target cpu, not sure about other archs. To present some arbitrary numbers: cc
To add some slightly more interesting numbers, these are for : generic: x86-64
Did your PR not resolve this?
It probably did for x84_64, but I'm not sure about x86 (I guess "generic" is like i386, which seems a bit too old a target), ARM, etc. Am 21.01.2015 23:33 schrieb "Alexis Beingessner"
Change:
} static mut MAIN_ALTSTACK: *mut libc::c_void = ptr::null_mut(); <ins> static mut NEED_ALTSTACK: bool = false; </ins> pub unsafe fn init() { let mut action: sigaction = mem::zeroed(); <del> action.sa_flags = SA_SIGINFO | SA_ONSTACK; action.sa_sigaction = signal_handler as sighandler_t; sigaction(SIGSEGV, &action, ptr::null_mut()); sigaction(SIGBUS, &action, ptr::null_mut()); </del> <ins> for &signal in &[SIGSEGV, SIGBUS] { sigaction(signal, ptr::null_mut(), &mut action); // Configure our signal handler if one is not already set. if action.sa_sigaction == SIG_DFL { action.sa_flags = SA_SIGINFO | SA_ONSTACK; action.sa_sigaction = signal_handler as sighandler_t; sigaction(signal, &action, ptr::null_mut()); NEED_ALTSTACK = true; } } </ins> let handler = make_handler(); MAIN_ALTSTACK = handler._data;

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. --I tried this code: and compiled it with: I expected to see asan report a bad pointer use and give a backtrace. Instead I just got a raw sigsegv: Running with verbose output shows that AddressSanitizer is intercepting the signal. It looks like is also installing a signal handler, which is overriding the AddressSanitizer one. <!-- 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. --: </p</details
(set handler and prevent override) is a workaround, but I think the Rust runtime shouldn't stomp SIGSEGV in the sanitizer case.
cc
Change:
pub fn get_gid(&self) -> Option<gid_t> { self.gid } <ins> #[allow(dead_code)] pub fn get_groups(&self) -> Option<&[gid_t]> { self.groups.as_deref() } </ins> pub fn get_closures(&mut self) -> &mut Vec<Box<dyn FnMut() -> io::Result<()> + Send + Sync>> { &mut self.closures

Discussion:
already offers and methods to control the user identity of the child process (calling respectively). For complete control of Unix credentials, there should also be a way to call and the concept of the supplementary group list are; I would expect this not to be a portability concern.) This feature would eliminate a use of and an unsafe block (to call ) from the program I'm currently writing, which is a port to Rust of a setuid C program. For illustration, this function exists in the C version: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I would be prepared to consider a PR to add .
claim
Change:
<del> use rustc_middle::ty::{self, Ty, TyCtxt, TypeSuperVisitable, TypeVisitable, TypeVisitor}; </del> <ins> use rustc_middle::ty::{ self, Ty, TyCtxt, TypeSuperVisitable, TypeVisitable, TypeVisitableExt, TypeVisitor, }; </ins> use std::ops::ControlFlow;

Discussion:
Check out ICU4X (tested on commit ), and build : However this started happening in our nightly CI since (one nightly before this one). The PR must have landed in the recent past. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Working on bisection, so far I have this
regressed commit: <detailsbash cargo bisect-rustc --start 2023-10-28 --end 2023-10-30 </details
Regression is , cc
Change:
while True: try: curs.execute("BEGIN EXCLUSIVE") <ins> break </ins> except sqlite3.OperationalError: pass <ins> sleep(0.25) </ins> return curs except ImportError: print("warning: sqlite3 not available in python, skipping build directory lock")

Discussion:
Since I started using vscode, it is now often the case that the which vscode runs is still not done when I alt-tab back to my terminal to do (for example) . That regularly leads to errors like this: In those cases, just running again solves the problem -- but it would still be better if having vscode run in background would not break what I do in the terminal. Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
So there's several solutions to this: Don't support this, tell people to run x.py check in a different directory so the build directory goes elsewhere. Add a global lock like Cargo's on the build directory Specialize x.py check to use different sysroot for stage0 - i.e. don't fix x.py build and test running simultaneously etc I am interested in hearing which you think would be preferable. Cc
If they could run truly in parallel that would be great. However, a separate build dir also means the bootstrap rustc is downloaded again, right? That would not be great.
Yes, option 1 would duplicate the stage0 rustc downloads. Option 3, though, would not - it's probably the right choice I think since x.py check is somewhat unique in being the most likely to be invoked in parallel.
in an ideal world, would fixing also fix this?
Not really. It might even make things worse. rustbuild uses the same stamps for both check and build steps (and sysroots etc) so when both are running simultaneously we will stomp all over the other, which is going to lead to incorrect behavior.
I was not able to replicate this. On my machine running both in parallel gives
Ok, I figured out when this happens: you need one terminal to be building the compiler while the other is building libstd. If both are building libstd this error doesn't show up.
I think this can also lead to losing the build cache... at least I just had a case where after showing this error, it then (on the next attempt) proceeded to rebuild the crate graph rustc depends on, instead of just the crate that I changed.

FYI option 3 was seen as too big a hammer in ; the proposed fix was to use a build lock on the sysroot instead, the same way cargo has a build lock for .
I think that's not quite accurate, in the specialization was too specific (i.e., the problem is more widespread, any two x.py runs can touch shared files currently). "Insufficiently big hammer" is probably the right description of option 3.
claim
I am afraid this is still not working properly: when I run in the terminal while there is a vscode running in the background, I get but once vscode is done, all that happens is that the in the terminal starts using 100% CPU. It does not actually start running though.
Ah: looks like it missed actually breaking out of that loop -- happy to accept a PR to do so.
is that something you could take a look at?
Change:
(ident, ItemFn(decl, fn_style, abi, generics, body), Some(inner_attrs)) } <ins> /// Parse a method in a trait impl pub fn parse_method_with_outer_attributes(&mut self) -> P<Method> { let attrs = self.parse_outer_attributes(); let visa = self.parse_visibility(); self.parse_method(attrs, visa) } </ins> /// Parse a method in a trait impl, starting with `attrs` attributes. pub fn parse_method(&mut self, attrs: Vec<Attribute>,

Discussion:
As of a few weeks ago was able to parse attributes attached to a quoted method. Recently this fails with a syntax error, See example .
I suspect your commit is the culprit here as it removes a from .
Change:
))], )) } <del> Some(value) => { </del> <ins> Err(VarError::NotUnicode(_)) => { let ExprKind::Lit(token::Lit { kind: LitKind::Str | LitKind::StrRaw(..), symbol, .. }) = &var_expr.kind else { unreachable!("`expr_to_string` ensures this is a string lit") }; let guar = cx.dcx().emit_err(errors::EnvNotUnicode { span: sp, var: *symbol }); return ExpandResult::Ready(DummyResult::any(sp, guar)); } Ok(value) => { </ins> cx.expr_call_global(sp, cx.std_path(&[sym::option, sym::Option, sym::Some]), thin_vec![ cx.expr_str(sp, value) ])

Discussion:
I tried this code: compiler with (using Bash shell syntax, any non-Unicode environment variable value for will work). I expected to see this happen: a value, as the currently states "If the named environment variable is present at compile time, this will expand into an expression of type whose value is of the value of the environment variable". Instead, this happened: The program outputted: Currently, the documentation doesn't consider the possibility of a non-Unicode environment variable value (as only Unicode values can be expressed as a &'static str), and the implementation emits , the same as for a non-existent environment variable. There are three possibilities that I can think of: current behaviour is a bug, and a compilation error should be emitted as it isn't possibly to represent a non-Unicode value as a , and the documentation should also be updated to reflect this. Note that this would be a breaking change to the compiler itself, but would be allowed as it would be a bugfix. current behaviour is not a bug, and the documentation should be updated to reflect the current behaviour. as 2, but the behaviour is unexpected enough to warrant a warn/deny-by-default lint. Personally, I believe 1 to be the case, as the current behaviour is unexpected and leads to code patterns like silently returning incorrect results. There doesn't seem to be a "correct" value to return, as is already taken by "does not exist" and cannot represent a non-Unicode value. It seems unlikely anyone is relying on the current behaviour given Rust's very UTF-8 everywhere design, the fact the same result can be achieved much more easily by just not setting the environment variable, and the platform-specific nature of what non-Unicode values can exist (Windows UTF-16 unpaired surrogates vs. Unix invalid UTF-8 bytes). It therefore seems to be more likely to occur when someone has mistyped something in their shell or due to data corruption, which the current output would make rather confusing to track down (as it would seem to say the variable was missing, rather than set incorrectly). : I believe the decision of what to do is down to libs-api, so label +T-libs-api
I've created a draft implementation of option 1 in .
Change:
<del> error[E0277]: the trait bound `i32: std::convert::From<&str>` is not satisfied --> $DIR/try-block-bad-type.rs:7:9 </del> <ins> error[E0277]: `?` couldn't convert the error to `i32` --> $DIR/try-block-bad-type.rs:7:16 </ins> | LL |         Err("")?; <del> |         ^^^^^^^^ the trait `std::convert::From<&str>` is not implemented for `i32` </del> <ins> |                ^ the trait `std::convert::From<&str>` is not implemented for `i32` </ins> | = help: the following implementations were found: <i32 as std::convert::From<bool>>

Discussion:
Currently E277's message is confusing and seemingly ambiguous when it occurs on a try () expression (this may not be limited to E277, it's just the one I noticed). For example, in : The problem is that 's error type is while 's error type is . In this case the error isn't too confusing, but if the try is in a chained expression () and you're a noob it isn't clear why it wants implemented on . It doesn't necessarily even require a whole fix suggestion, all it would take is making the error only highlight the , as the issue is actually occuring when unwrapping the result. Thanks!
Change:
|         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: outlives requirements can be inferred <ins> --> $DIR/edition-lint-infer-outlives.rs:805:56 | LL |   struct InferredWhereBoundWithInlineBound<'a, T: ?Sized> |  ________________________________________________________^ LL | | LL | |     where T: 'a, | |________________^ help: remove this bound error: outlives requirements can be inferred </ins> --> $DIR/edition-lint-infer-outlives.rs:26:31 | LL |     struct TeeOutlivesAy<'a, T: 'a> {

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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: <!-- Please provide a link to --The current output is: Rustfix will fail to apply this: ` So we need to extend span to include the as well? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The relevant code is in , with . The should be computed using in the loop, instead of crafting a specific computation. Likewise, should use method. If using those 2 methods from is not enough to solve the issue, those methods should perhaps be adapted.
claim
release-assignment Haven't been able to focus on this. Releasing assignment.
claim
Progress report: I'm working on it.
claim
Change:
#![feature(tuple_trait)] #![feature(unicode_internals)] #![feature(unsize)] <ins> #![feature(unwrap_infallible)] </ins> #![feature(vec_pop_if)] // tidy-alphabetical-end //

Discussion:
I tried this code: I expected to see this happen: Both and should get optimized to just return the input unchanged. Instead, this happened: unwrapcopy get's optimized as espected: unwrapclone fails to get optimized and compiles into a loop: Originally I thought that behavior was caused by the underlying type not implementing Copy but Drop seems to be the actual culprit. <!-- 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. --: </p</details
This reminds me of the do-nothing-loop from . That's not quite true, e.g. this also optimizes even though is not : So it's likely due to and the compiler fails to see that the drop can't happen.
Change:
// type Foo<'a, 'b, 'c> = impl Trait<'a> + 'b; // ``` // we may not use `'c` in the hidden type. <del> struct OpaqueTypeLifetimeCollector { </del> <ins> struct OpaqueTypeLifetimeCollector<'tcx> { tcx: TyCtxt<'tcx>, root_def_id: DefId, </ins> variances: Vec<ty::Variance>, } <del> impl<'tcx> ty::TypeVisitor<'tcx> for OpaqueTypeLifetimeCollector { </del> <ins> impl<'tcx> OpaqueTypeLifetimeCollector<'tcx> { #[instrument(level = "trace", skip(self), ret)] fn visit_opaque(&mut self, def_id: DefId, substs: SubstsRef<'tcx>) -> ControlFlow<!> { if def_id != self.root_def_id && self.tcx.is_descendant_of(def_id, self.root_def_id) { let child_variances = self.tcx.variances_of(def_id); for (a, v) in substs.iter().zip(child_variances) { if *v != ty::Bivariant { a.visit_with(self)?; } } ControlFlow::CONTINUE } else { substs.visit_with(self) } } } impl<'tcx> ty::TypeVisitor<'tcx> for OpaqueTypeLifetimeCollector<'tcx> { </ins> #[instrument(level = "trace", skip(self), ret)] fn visit_region(&mut self, r: ty::Region<'tcx>) -> ControlFlow<Self::BreakTy> { if let ty::RegionKind::ReEarlyBound(ebr) = r.kind() {

Discussion:
The following compiles on the current nightly (1.67.0-nightly (2022-12-03 )) although it shouldn't: It is correctly rejected by the current beta: 1.66.0-beta.2 (2022-11-20 ). This is most likely (I haven't bisected though!). Cc label C-bug T-compiler I-unsound regression-from-stable-to-nightly A-impl-trait
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
<ins> // check-pass #![crate_type = "lib"] #![feature(generic_const_exprs)] #![allow(incomplete_features)] pub trait MyIterator { type Output; } pub trait Foo { const ABC: usize; } pub struct IteratorStruct<const N: usize>{ } pub struct Bar<const N: usize> { pub data: [usize; N] } impl<const N: usize> MyIterator for IteratorStruct<N> { type Output = Bar<N>; } pub fn test1<T: Foo>() -> impl MyIterator<Output = Bar<{T::ABC}>> where [(); T::ABC]: Sized { IteratorStruct::<{T::ABC}>{} } pub trait Baz<const N: usize>{} impl<const N: usize> Baz<N> for Bar<N> {} pub fn test2<T: Foo>() -> impl MyIterator<Output = impl Baz<{ T::ABC }>> where [(); T::ABC]: Sized { IteratorStruct::<{T::ABC}>{} } </ins>

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. --I tried this code: This code should compile normally. Instead, this happened: In the function, T was already bounded by the trait which does have an associated item named . However, Rust complains that no associated item named was found for . <!-- 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. --:
I did some digging and this might be related to Mind taking a look?
A fix exists here at but we're waiting on 's pending RPIT refactor work to fix this. In the mean time, developers who need this feature can use the branch in . https://rust-
Change:
extern crate trait_impl_conflict; use trait_impl_conflict::Foo; <del> impl<A> Foo for A { //~ ERROR E0117 </del> <ins> impl<A> Foo for A { //~^ ERROR E0117 //~^^ ERROR E0119 </ins> } fn main() {

Discussion:
Arch Linux, x86_64, Code: I didn't expect this to compile successfully, but when I tried I hit an error which asked me nicely to report it as a compiler bug :smile:
Reduced test case:
Taking a look
It seems that overlap checking is not finding the blanket impl of for at all...
I have a fix, will submit a PR after lunch.
Change:
<ins> warning: function cannot return without recursing --> $DIR/issue-103599.rs:5:1 | LL | fn wrap(x: impl T) -> impl T { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot return without recursing LL | LL |     wrap(wrap(x)) |          ------- recursive call site | = help: a `loop` may express intention better if this is on purpose = note: `#[warn(unconditional_recursion)]` on by default warning: 1 warning emitted </ins>

Discussion:
Valid according to stable (1.64.0), but ICEs beta (1.65.0-beta.4) and : Reduced from a mutation of Two ICEs: <details<summary<strongFull output with both backtraces</strong</summary<p</p</details: Bisected with <a href=''cargo-bisect-rustc</aon x8664-apple-darwin: searched nightlies: from nightly-2022-08-23 to nightly-2022-10-26 regressed nightly: nightly-2022-08-31 searched commit range: regressed commit: (rollup) Among the commits in the rollup, my guess is (CC It the function (frame 19 on the first stack). It with some similarities: an unconditionally recursive function with in return position. label +regression-from-stable-to-beta +A-impl-trait
yup, ez fix incoming
Change:
<ins> 1|       |// Regression test for #93054: Functions using uninhabited types often only have a single, 2|       |// unreachable basic block which doesn't get instrumented. This should not cause llvm-cov to fail. 3|       |// Since these kinds functions can't be invoked anyway, it's ok to not have coverage data for them. 4|       | 5|       |// compile-flags: --edition=2021 6|       | 7|       |enum Never { } 8|       | 9|       |impl Never { 10|       |    fn foo(self) { 11|       |        match self { } 12|       |        make().map(|never| match never { }); 13|       |    } 14|       | 15|       |    fn bar(&self) { 16|       |        match *self { } 17|       |    } 18|       |} 19|       | 20|      0|async fn foo2(never: Never) { 21|       |    match never { } 22|       |} 23|       | 24|      0|fn make() -> Option<Never> { 25|      0|    None 26|      0|} 27|       | 28|      1|fn main() { } </ins>

Discussion:
Between nightly versions 2022-01-14 and 2022-01-15, 0.8.2 lost track of 82% of the coverage of when using the LLVM coverage option (). Other projects of mine continue to have code coverage correctly measured. I'm not where to start narrowing this down, as I'm not getting any errors or warnings printed. Here are the steps to get good code coverage reports out of 2022-01-14: If you look at the report in the coverage folder, the html report will show 80% coverage. Now, test with the next nightly: If you look at the report again, the html report now shows < 1% coverage. The quantity of profraw files are the same, and the sizes of the files are more or less equivalent. I'm not quite sure where to start narrowing this down since it's a unique issue to this project of mine -- but the only unique part I'm aware of is its size :sweat_smile:. For now I'll pin our CI to the last working nightly. Thank you in advance for any suggestions or help!
We noticed the same when upgrading rustc in our project from (December) to . Code coverage measured with and inexplicably dropped . Some crates that are clearly running don't show up at all in the reports. suggests that this is probably caused by
^ says is also affected.
cc label +requires-nightly +A-code-coverage
Thanks for the report! I've tried reproducing locally and I'm able to see the same behavior. Running the LLVM tools directly, I see this when trying to process coverage data for the various binaries: which seems to be the same issue as was reported in a comment on . I'm continuing to investigate ...
The minimal repro seems to be I think I'll have a fix for this within the next few days.
Change:
impl Step for RustAnalyzer { type Output = (); const ONLY_HOSTS: bool = true; <del> const DEFAULT: bool = true; </del> <ins> const DEFAULT: bool = false; </ins> fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.path("src/tools/rust-analyzer")

Discussion:
Sometimes when changing compiler internals, I run to make sure I didn't break tools and codegen backends. This also checks rust-analyzer by default, which is not very useful, I cannot break that. If we want to keep that, it would at least be useful to put it last so I can Ctrl-C out of it. Currently, rustfmt is checked after rust-analyzer. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
mentoring instructions: switch the order of these two lines:
points out that Cargo also isn't checked by default, so for consistency it would be nice for RustAnalyzer not to be either:
claim