jiebi/CodeConvo huggingface dataset:
Change:
if !constant_arguments.contains(&i) { return } <del> if this.qualif.is_empty() { </del> <ins> // Since the argument is required to be constant, // we care about constness, not promotability. // If we checked for promotability, we'd miss out on // the results of function calls (which are never promoted // in runtime code) // This is not a problem, because the argument explicitly // requests constness, in contrast to regular promotion // which happens even without the user requesting it. // We can error out with a hard error if the argument is not // constant here. if (this.qualif - Qualif::NOT_PROMOTABLE).is_empty() { </ins> this.promotion_candidates.push(candidate); } else { this.tcx.sess.span_err(this.span,

Discussion:
: produces cc
Not that this fixes the issue, but and aren't necessarily guaranteed to have the same representation without or on both and .
minified: is this a victim of the backwards algorithm for promotion? Just a hunch, but it might have promoted away the call to and then end up trying to promote the , but it's not in the place where it was expected, because it now lives inside the promoted. So it ends up trying to promote an argument in a basic block that was already promoted away
thanks , I'll update the PR that triggered this - for context
As a workaround until we fix this ICE, you can introduce an intermediate explicit constant for the argument to . Or is this part of a user-exposed API?
This is part of a user-exposed API, but that workaround should allow me to at least get the const tests running.
It won't remove the definition if there's more than one use (unless this is fallout from your changes?)
There's only one use. I don't see how my changes could have caused this, but it seems possible. I'll do a bisection
Oh, I see, is and that's missing a check like:
Fix instructions: Add a which, like the variable, is used to mark blocks whose terminator has been promoted out. skip promoting all such terminators when encountering said block id in a ()
You can use a , although I'm not even sure it's necessary. A promoted call ends up as a , so you could just skip it based on that?
Change:
LL |         return Err(42); |         ++++++        + <del> error: aborting due to previous error </del> <ins> error[E0308]: mismatched types --> $DIR/tail-expr-as-potential-return.rs:20:9 | LL | /     if x { LL | |         Err(42) | |         ^^^^^^^ expected `()`, found enum `Result` LL | |                 //| HELP you might have meant to return this value LL | |     } | |_____- expected this to be `()` | = note: expected unit type `()` found enum `Result<_, {integer}>` help: you might have meant to return this value | LL |         return Err(42); |         ++++++        + error: aborting due to 2 previous errors </ins> For more information about this error, try `rustc --explain E0308`.

Discussion:
Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like it does for the : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-async-await +D-papercut
I'm gonna try and take a shot at this. claim
Thanks for putting up a PR so quickly, label +AsyncAwait-Triaged +AsyncAwait-Polish
Change:
} #[test] <ins> #[cfg(panic = "unwind")] fn test_zip_trusted_random_access_next_back_drop() { use std::panic::catch_unwind; use std::panic::AssertUnwindSafe; let mut counter = 0; let it = [42].iter().map(|e| { let c = counter; counter += 1; if c == 0 { panic!("bomb"); } e }); let it2 = [(); 0].iter(); let mut zip = it.zip(it2); catch_unwind(AssertUnwindSafe(|| { zip.next_back(); })) .unwrap_err(); assert!(zip.next().is_none()); assert_eq!(counter, 1); } #[test] </ins> fn test_double_ended_zip() { let xs = [1, 2, 3, 4, 5, 6]; let ys = [1, 2, 3, 7];

Discussion:
Yet another soundness bug in Zip's TRA specialization. Line 300 is not called when line 298 panics. This leaves outdated, which results in calling with an invalid index in line 242. Here is a that demonstrates creating two mutable references to the same memory location without unsafe code. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
How close is this to ?
The same functions are involved but the aspects that interact to cause unsafety are quite different. claim
I agree, this is much closer to .
Change:
bound_count += bound_spans.len(); let drop_predicate = bound_spans.len() == bounds.len(); <del> if drop_predicate { dropped_predicate_count += 1; </del> <ins> if drop_predicate && in_where_clause { dropped_where_predicate_count += 1; </ins> } if drop_predicate {

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:
= help: add `#![feature(function)]` to the crate attributes to enable error[E0658]: use of unstable library feature 'function' <del> --> $DIR/internal-unstable.rs:39:22 </del> <ins> --> $DIR/internal-unstable.rs:40:22 </ins> | LL |     println!("{:?}", internal_unstable::unstable()); |                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^

Discussion:
Discussed in zulip: https://rust- The problem is that compiler doesn't accept code like this: But it accepts code when merging mutiple annotations into one: : Version 1.48.0-nightly ( 2020-09-22) cc which modified some const stability checks. modify labels: E-mentor
Error: Label P-low can only be set by Rust team members Please let know if you're having trouble with this bot.
just refactored a few individual calls to into a single helper function. only looks for the first attribute it seems. Shouldn't be hard to fix.
assign
Error: Parsing assign command in failed: ...'n bugadani' ''... Please let know if you're having trouble with this bot.
The PR did not actually fix the issue. The test case to the PR also works without the PR. A test case that would fail would actually check whether a second attribute would be honored. Adding a second attribute was silently ignored, and it still is after the PR. Edit: nevermind, all is good:
It doesn't hurt to double check, just takes some time :)
Change:
} impl<T> Default for T { <del> default type Id = T; //~ ERROR: type annotations needed </del> <ins> default type Id = T; </ins> // This will be fixed by #111994 fn intu(&self) -> &Self::Id { //~ ERROR type annotations needed self

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: I expected to see this happen: compiles, or a helpful error message Instead, this happened: Confusing error message, there doesn't seem to be a future that could be awaited?... Interestingly if the default implementation is removed, it compiles. Playground: <!-- 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
The error message on the playground is a bit different, seems to be correlating with the actual problem more, but even more confusing: Expected and found are the same!
Minimal: Something funky going on with the default projection predicate installed for the GAT. I'll look into it
I'm impressed by the speedy handling of this issue! Was hoping this would get a fix in a few weeks . You're awesome!
Once the pr is merged, it will be available the next day on nightly, correct? Btw, the pr failed some tests.
Change:
const PATH: &str = "src/stage0.json"; const COMPILER_COMPONENTS: &[&str] = &["rustc", "rust-std", "cargo"]; <del> const RUSTFMT_COMPONENTS: &[&str] = &["rustfmt"]; </del> <ins> const RUSTFMT_COMPONENTS: &[&str] = &["rustfmt-preview"]; </ins> struct Tool { config: Config,

Discussion:
It should not be possible that clippy component is missing since we are gating on it in CI..? cc
I think this is a rustup bug somehow, it's looking specifically for : I can back this out to give rustup time to fix it in a new release, this wasn't an urgent fix. I want to spend another few minutes investigating first though.
I don't think rustup's rename system is designed to allow changing the name of a component. contains more information about how and why this was done.
says I need at a minimum to keep the key for clippy-preview. I will try to test that out today but I don't have permissions for a dist-static build and it might take me a bit so I'll put up a revert in the meantime.
I'm happy to run dev-static builds as needed, but I agree that a revert is appropriate for the time being. Please feel free to poke on Zulip if you need a quick review, etc. I'm a little surprised our testing in didn't catch this -- let's make sure we understand how to test it in the future.
what went wrong in is that worked before and after, but running before and after did not. I'll make sure to test that in any future PR.
Change:
unsafe fn also_allowed() {} unsafe trait AllowedUnsafe { } unsafe impl AllowedUnsafe for super::Bar {} <ins> #[no_mangle] fn allowed2() {} #[export_name = "foo"] fn allowed3() {} </ins> } macro_rules! unsafe_in_macro { <del> () => { </del> <ins> () => {{ #[no_mangle] fn foo() {} //~ ERROR: declaration of a `no_mangle` function #[no_mangle] static FOO: u32 = 5; //~ ERROR: declaration of a `no_mangle` static #[export_name = "bar"] fn bar() {} //~^ ERROR: declaration of a function with `export_name` #[export_name = "BAR"] static BAR: u32 = 5; //~^ ERROR: declaration of a static with `export_name` </ins> unsafe {} //~ ERROR: usage of an `unsafe` block <del> } </del> <ins> }} </ins> } <ins> #[no_mangle] fn foo() {} //~ ERROR: declaration of a `no_mangle` function #[no_mangle] static FOO: u32 = 5; //~ ERROR: declaration of a `no_mangle` static #[export_name = "bar"] fn bar() {} //~ ERROR: declaration of a function with `export_name` #[export_name = "BAR"] static BAR: u32 = 5; //~ ERROR: declaration of a static with `export_name` </ins> unsafe fn baz() {} //~ ERROR: declaration of an `unsafe` function unsafe trait Foo {} //~ ERROR: declaration of an `unsafe` trait unsafe impl Foo for Bar {} //~ ERROR: implementation of an `unsafe` trait

Discussion:
Given that there should be a lint that is capable of detecting it (there was a suggestion that should also detect it, but it might make sense to be able to lint it individually too).
So maybe should be a lint group, and include this new lint? I am suggesting that because I think should suffice to trigger the new lint.
I've got the basic lint working now. do you think it's worth adding it as a separate lint, renaming to something else (which I can't think of a name for), and adding them both as lints in an group; or better to just integrate it into the current lint?
I'll defer to for that :D
I am partial towards having a hard error when encountering multiple functions with the same name in a given workspace, . Adding this to might be problematic in the wild. Let's make a PR that rolls it into and see the behavior in the wild with a crater run, but if it causes too much fallout, lets make it an independent lint.
There's other ways of using which create UB than just overriding within a workspace, e.g. the example in While adding a hard error for cases that can be detected would be nice, I don't think it's possible in general.
Removing I-prioritize since this is already tracked at
Is there a tracking issue for additional lints like this to similar "unsafe attributes"? I think that'd be great!
not that I know of but you could open one :)
Done
Change:
<ins> // Regression test for #84455 and #115052. </ins> // run-pass // aux-build:static_init_aux.rs extern crate static_init_aux as aux; static V: &u32 = aux::V; static F: fn() = aux::F; <ins> static G: fn() = aux::G; </ins> fn v() -> *const u32 { V

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. --Sorry, haven't tried to minimise this yet. The repro steps are here: <!-- 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. --: Also reproduces in <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Hoisting the inline structure initialisation into s makes the ICE go away. That... doesn't make a lot of sense to me. <details<summary<strongDiff</strong</summary<p</p</details
Also reproduces in which is our current MSRV
The implementation here should probably also recurse into :
I can confirm that the ICE goes away with the suggested patch.
Possibly related -- while this made the ICE go away, the code when compiled in mode seems to not link. <details<summary<strongmysterious link error</strong</summary<p</p</detailsNaively -- with no understanding of rustc internals -- it feels like a reachability pass that doesn't find these values won't emit them into the library? Slapping some extra attributes around the place is a workaround.
Change:
pub(crate) no_emit_shared: bool, /// If `true`, HTML source code pages won't be generated. pub(crate) html_no_source: bool, <ins> /// Whether `-Zforce-unstable-if-unmarked` unstable option is set pub(crate) force_unstable_if_unmarked: bool, </ins> } #[derive(Copy, Clone, Debug, PartialEq, Eq)]

Discussion:
This is a regression from stable to beta, although this issue will be P-low. The problem is ignored documenting unstable traits for non-local types, fixes some regressions caused by it but the regression in nightly-rustc / compiler docs still opens. For example: Compare and . The doc in 1.46.0 has impl, while on nightly it doesn't have. A way to fix this issue is ignoring this check when the compiling-crates are being passed flag or the crate/module has feature: : Version 1.48.0-nightly ( 2020-09-14)
Hey! I would like to check this out if that is okay
Is this actually a regression?
Dropping regression label. nightly-rustc docs are, well, not really important on non-nightly channels, as they cannot be used by normal consumers.
if you're still interested in working on this we'd love to have the help! If you have trouble, feel free to ask for help in or :)
Thanks! Yes, I am still interested, I have been busy that past few weeks. I will give it a shot this weekend and will reach out if I can't figure it out!
Since zulip is lag in my region at night, I post a respond here. You could use to check for flag passed during compilation.
I think I'll hop onto this if that's OK. I've always wanted to contribute :)
Go for it!
It doesn't seem to be fixed by I'll check the cause
Change:
<ins> error[E0004]: non-exhaustive patterns: `_` not covered --> $DIR/non-exhaustive-pattern-pointer-size-int.rs:4:11 | LL |     match 0usize { |           ^^^^^^ pattern `_` not covered | = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms = note: the matched value is of type `usize` = note: `usize` does not have a fixed maximum value, so a wildcard `_` is necessary to match exhaustively = help: add `#![feature(precise_pointer_size_matching)]` to the crate attributes to enable precise `usize` matching error[E0004]: non-exhaustive patterns: `_` not covered --> $DIR/non-exhaustive-pattern-pointer-size-int.rs:12:11 | LL |     match 0isize { |           ^^^^^^ pattern `_` not covered | = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms = note: the matched value is of type `isize` = note: `isize` does not have a fixed maximum value, so a wildcard `_` is necessary to match exhaustively = help: add `#![feature(precise_pointer_size_matching)]` to the crate attributes to enable precise `isize` matching error[E0004]: non-exhaustive patterns: type `usize` is non-empty --> $DIR/non-exhaustive-pattern-pointer-size-int.rs:20:11 | LL |     match 7usize {} |           ^^^^^^ | = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms = note: the matched value is of type `usize` error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0004`. </ins>

Discussion:
Gives:
Fairly sure this is intentional for
From the pull I've seen a part that I didn't see/remember: An unstable feature precisepointersizematching will be to permit matching exactly on pointer-size integer types. So you're right, this isn't a new bug, it's a known unfinished part. I hope to see that precisepointersizematching implemented.
It already exists.
I see, then what do I have to hope to see? :-)
I'm not sure the feature is ever going to be stabilised, because there are concerns that this isn't a desirable feature. But hopefully the diagnostics will at least be improved in
Do you have a link to such concerns? (Or are you willing to summarize them?) (I value your work on the compiler a lot varkor :-) )
I think the relevant concerns arose in the (from this comment up). The overview is that we ought not to make assumptions about pointer sizes on the target platform, because they're not guaranteed to be fixed, so this could cause compatibility issues.
Change:
evaluation_cache: self.evaluation_cache.clone(), reported_trait_errors: self.reported_trait_errors.clone(), reported_closure_mismatch: self.reported_closure_mismatch.clone(), <del> tainted_by_errors_flag: self.tainted_by_errors_flag.clone(), </del> <ins> tainted_by_errors: self.tainted_by_errors.clone(), </ins> err_count_on_creation: self.err_count_on_creation, in_snapshot: self.in_snapshot.clone(), universe: self.universe.clone(),

Discussion:
should be to guarantee that we emit an error when that flag is set. This is already done for of other types in rustc. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
renamed to to keep consistent.
Change:
pub mod term; pub mod time; pub mod arena; <del> pub mod par; </del> pub mod base64; pub mod rl; pub mod workcache;

Discussion:
Just a few parallel algorithms. This is unused and probably not efficient enough for real use. If we're going to do this it will need to be rethought from scratch.
Is it possible to add an API that would spawn a task assigned to an exclusive OS thread?
There is already a way to do that by creating a task with the scheduler mode. The mechanism may change with the new scheduler, but it's an important use case so there will continue to be a way to dedicate an entire thread to a single task.
assign=me
did this land? if not do you want to rebase your patch?
Change:
/// couldn't complete due to errors elsewhere - this is distinct /// from `Ok(None)` to avoid misleading diagnostics when an error /// has already been/will be emitted, for the original cause <del> #[instrument(level = "debug", skip(tcx))] </del> <ins> #[instrument(level = "debug", skip(tcx), ret)] </ins> pub fn resolve( tcx: TyCtxt<'tcx>, param_env: ty::ParamEnv<'tcx>,

Discussion:
In , I a combinator that always returns . However, the corresponding test in crashes with a segfault, instead of hanging indefinitely (the expected behavior for this incomplete implementation). According to GDB, the test function is miscompiled quite badly, and just unconditionally dereferences a NULL pointer when run: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Is this like... the futures version of
I'll minimize this a bit claim
Uhh this is as much as I could minimize it -- not sure if it's segfaulting because I minimized it poorly or because it actually repro's this issue, but it's a start!! :laughing: <details</details
Thanks I was able to use your test case to look into it a bit further. The issue looks related to the Future trait, I wasn't able to reproduce it using other traits. In the example below I changed the trait definition to this: And the call to fails to compile with this LLVM error: Compile in debug mode to see the error, release mode doesn't complain and outputs code that segfaults. <details</details
In , the call to is incorrectly resolved to , i.e., .
Thanks I can look into why we're resolving this method to the wrong instance...
Ah. This isn't a user-facing bug, but a bug in that expects the trait to have one method. :facepalm: So it turns out that this really isn't that high-prio of a bug. It still needs fixing, and that method could use some major robustness checks, at least when debug assertions are enabled. I'll take a stab at it. claim
I'm going to remove the unsoundness tag and I think this probably doesn't need to be prioritized (or at least doesn't need to be anything higher than like... P-high) because this really has to do with an incongruency between and the compiler's assumption about the contents of the trait. That being said, this bug still sucks and I'm sorry that had to deal with it, but nothing like this is possible to trigger without and a trait definition for that diverges from the one in libstd currently. (that being said, I will still fix this bug and make it harder to trigger in the future)
Change:
// compiler statically verifies that it is not currently borrowed. // Therefore the following assertion is just a `debug_assert!`. debug_assert!(self.borrow.get() == UNUSED); <del> unsafe { self.value.into_inner() } </del> <ins> self.value.into_inner() </ins> } /// Replaces the wrapped value with a new one, returning the old value,

Discussion:
It's been unsafe since 2014 when it was called . Nobody thought about it, I guess, but it shouldn't be unsafe.
For reference the PR which it is
Someone thought about it enough to : Has something changed to make this consideration unnecessary or do you have an explanation of why the reasoning is faulty?
Because the function takes so by definition it must be the owner of the value so there can be no other viewers, either from this thread or another thread.
Although this isn't backwards-compatible there is some prior art of going unsafe -safe: (although, that was pre-1.0)
That's weird, it seems like you ought to be able to assign a safe fn to an unsafe fn pointer. , Nicole Mazzuca wrote:
We removed the subtyping relation at some point; it does seem like a coercion would be (probably) ok, but that would still not be (strictly) backwards compatible.
(I tend to agree that could be safe, though, and I highly doubt any existing crates would actually break due to this change.)
We could always do a crater run just to be absolutely sure nobody is turning into a function pointer.
HI ! Any news on this one ?
No change that I know of.
FWIW the relevant coercion was in
This change is breaking my crate. If I add the then it will work for older compilers. If I remove the then it will work for newer compilers. Is there a conditional compilation attribute for compiler version? I can't find one.
Use
Yeah, that's what I'm doing for now. It seems kind of lame, though. But it does work.