jiebi/CodeConvo huggingface dataset:
Change:
&declared_ret_ty, decl.output.span(), ); <ins> debug!("check_fn: declared_ret_ty: {}, revealed_ret_ty: {}", declared_ret_ty, revealed_ret_ty); </ins> fcx.ret_coercion = Some(RefCell::new(CoerceMany::new(revealed_ret_ty))); fn_sig = fcx.tcx.mk_fn_sig( fn_sig.inputs().iter().cloned(),

Discussion:
With the following code: comes the following error: However, this function compiles correctly without the keyword.
cc
You can trigger this without async/await using : cc
Some more reduction in genericity and clearing up a few things: The problem is that is not know in impl trait items. It's also not related to the return position, but refers to any impl trait in the function. Outside of impl trait can be resolved without a problem, so it must be something related to the way impl trait reuses the generics of its parent.
It seems to be a missing normalization, most likely.
I have a local fix for reduction above, but is making this rather difficult as it makes output not work properly.
This also happens for definitions: My fix only seems to turn this into a cycle error for some reason. EDIT: Nevermind I just broke existential types in general lol
Marking as blocking, although I think there's minimal future compat risk. If push came to shove I personally would be ok with removing this from the blocking list. But then it looks like already fixed it =)
I think the problem is on this line of code: in particular, we "instantiate" the predicates -- meaning, substitute in the values for their type parameters -- but we never normalize them. We should be able to invoke the methods. Note that in this code we do have an available, as well, in . I think we should be able to invoke: this returns an  value, which contains obligations that must be pushed into .
Hmm, that code is only invoked if is true, which I think wouldn't be the case here since there are no region bounds at all (right?). I also noticed that does not exist in this context ( is an ), and there's no nearby either. However, another place where is called without normalizing the result is here, further down in the same file: there does exist (as does ). Quick testing shows that normalizing there fixes this issue as well, and as a bonus also fixes the issue with without ICEs!
good catch -- actually I think the lines you found are the ones I meant to direct you to in the first place. I see you have some other problems on the PR, looking now.
Change:
<ins> error[E0061]: this function takes 6 arguments but 2 arguments were supplied --> $DIR/issue-97197.rs:2:5 | LL |     g((), ()); |     ^-------- multiple arguments are missing | note: function defined here --> $DIR/issue-97197.rs:6:8 | LL | pub fn g(a1: (), a2: bool, a3: bool, a4: bool, a5: bool, a6: ()) -> () {} |        ^ ------  --------  --------  --------  --------  ------ help: provide the arguments | LL |     g((), {bool}, {bool}, {bool}, {bool}, ()); |     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error: aborting due to previous error For more information about this error, try `rustc --explain E0061`. </ins>

Discussion:
: <!-- 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 --
Also ICEs on beta. Output on stable: label regression-from-stable-to-beta
searched nightlies: from nightly-2022-04-16 to nightly-2022-04-17 regressed nightly: nightly-2022-04-17 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailscc
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Change:
<ins> error: expected one of `!` or `::`, found keyword `let` --> $DIR/public-instead-of-pub-2.rs:4:8 | LL | public let x = 1; |        ^^^ expected one of `!` or `::` error: aborting due to previous error </ins>

Discussion:
When writing it will suggest and I think nothing should be suggested before it is validated. The statement to be suggested must be checked if it is true or not, if true it is suggested and if not it is not. The issue from: : The current output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Oh dear, I didn't think of that while making the PR. A possible solution could be checking if the current token is for initializing an item? Like, struct/enum/macro, etc.
I wrote this solution, but I don't know if I can use it in rustc, it's currently building
I can't work on the problem unfortunately, whoever will assign it to him you can solve it this way The block
release-assignment
claim
Trying to add a method in token: And add a check: Any other better idea?
could be the keyword, as well. looks alright, ideally the repeated block could be prevented using a macro? I'm afraid that might slightly overengineer it, though.
Change:
target CPU may be selected with the `-C target-cpu=val` flag. - `target-features` — List of available target features for the current target. Target features may be enabled with the `-C target-feature=val` <del> flag. </del> <ins> flag. This flag is unsafe. See [known issues](targets/known-issues.md) for more details. </ins> - `relocation-models` — List of relocation models. Relocation models may be selected with the `-C relocation-model=val` flag. - `code-models` — List of code models. Code models may be selected with the

Discussion:
When discussing in the compiler team triage meeting, it became clear that target-features ought to be considered generally unsafe. We should document this fact in the and in the . Ideally, we'd also start listing out known gotchas. For example, in noted that: and had a . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Compiler triage meeting: Marking as P-medium
claim
The reference section about mentions this: The link to the section of the reference mentions this as well: So maybe the could point people to the reference?
That is one way in which targetfeature is unsafe, but it's not the one which was the subject of so just pointing at the reference as it is is insufficient. Plus, it's also more about than (where the compiler will hit you in the face with ). So the rustc book is a better place for it than the reference IMO.
I think that for users to better properly understand the UB involved, it might be more educational to say that stamps on all functions, but with the subtle difference that it doesn't make them , so no unsafe-check happens when this triggers UB. The reference does not document all current perils of using . In particular, it does not document that these can change the function call ABI, and that rustc neither checks that nor handles it correctly - we just currently assume people don't do that. Independently of whether we document that in the rustc book as well or not, that bit should also probably be documented in the reference, because it is easy to trigger this. On stable Rust, I think one can indeed only trigger this via and the reference should say so, but on nightly one can definitely trigger this with bare within a single Rust crate.
Change:
<ins> error[E0706]: functions in traits cannot be declared `async` --> $DIR/issue-95307.rs:7:5 | LL |     async fn new() -> [u8; _]; |     -----^^^^^^^^^^^^^^^^^^^^^ |     | |     `async` because of this | = note: `async` trait functions are not currently supported = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait error[E0658]: using `_` for array lengths is unstable --> $DIR/issue-95307.rs:7:28 | LL |     async fn new() -> [u8; _]; |                            ^ | = note: see issue #85077 <https://github.com/rust-lang/rust/issues/85077> for more information = help: add `#![feature(generic_arg_infer)]` to the crate attributes to enable error: in expressions, `_` can only be used on the left-hand side of an assignment --> $DIR/issue-95307.rs:7:28 | LL |     async fn new() -> [u8; _]; |                            ^ `_` not allowed here error: aborting due to 3 previous errors Some errors have detailed explanations: E0658, E0706. For more information about an error, try `rustc --explain E0658`. </ins>

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 --
minimized: claim
I am not sure if I am able to solve this ICE -- it has to do with the way that in traits are treated as async fn in some places, but not lowered as async fn in other places. That means there's a DefId that is not associated with a HIR Id, but I can't exactly track it down. release-assignment
I'm working on a return position impl traits change that is going to make it easier to lowering return position impl traits in traits and that would make async fns in traits easy. All this is in my todo list. I should be able to accomplish some of these things soon. not sure if you were going to work on this, but we can talk about this in Zulip if you want.
Triage: The ICE doesn't occur on the latest nightly, bisecting shows fixed it but I'm not 100% sure what PR did, perhaps ? Marking .
Change:
fn size_hint(&self) -> (uint, Option<uint>) { (0, None) } } <ins> // FIXME(#21363) remove `old_impl_check` when bug is fixed #[old_impl_check] impl<'a, T> Iterator for &'a mut (Iterator<Item=T> + 'a) { type Item = T; fn next(&mut self) -> Option<T> { (**self).next() } fn size_hint(&self) -> (usize, Option<usize>) { (**self).size_hint() } } </ins> /// Conversion from an `Iterator` #[stable] #[rustc_on_unimplemented="a collection of type `{Self}` cannot be 

Discussion:
This code fails to compile: error message: A similar error occurs if is used instead of . However, if you comment out the for loop, the call to works just fine. I thought maybe it had something to do with auto-deref, so I tried dereferencing the iterator: but dumps core: I'm not sure, but this may be related to ? dumps core when I try too. version:
CC
I think the problem is worse than this; trait objects in general don’t seem to be being recognised as implementing their traits: All three fail:
I'm not sure this is a bug at all. You're pretty much asking for an automatic - I did come up with a & -based model that would kinda work for this and IIRC pointed out that object-safe traits would eventually qualify for this. We do have object safety now, so it might be doable, but I wouldn't bet on it making into 1.0. In the meanwhile, does work? If it doesn't, is it just the case of missing in a couple places?
This a particular case of . See comments over there. is leaning towards an opt-in syntax extension that handles the boiler plate code, instead of automatic s by the compiler.
ByRef for trait objects seems to hit the same llvm assertion: output:
Interesting. So if I have a value with type where is a trait, then we can't say that implements in the general case? (Assuming object safety.) So my guess is that can still call because of auto deref? Shouldn't that mean it can work with ? Maybe that is what is about... You have to explicitly deref a to use it in ? (Sorry for all the questions. I'm just confused!)
doing autoderef on the iterator in seems like something reasonable to have. looks like the compiler is mistakenly treating an unsized lvalue as an rvalue, in trans.
On Mon, Jan 12, 2015 at 01:33:08PM -0800, Andrew Gallant wrote: Actually, I believe it works with , but not with the other types.
Just thank you for this issue. It resolves all my problems perfectly!
Change:
# struct Point { x: f64, y: f64 } # enum Shape { Rectangle(Point, Point) } # impl Shape { fn area(&self) -> int { 0 } } <del> let start = @Point { x: 10.0, y: 20.0 }; </del> <ins> let start = ~Point { x: 10.0, y: 20.0 }; </ins> let end = ~Point { x: start.x + 100.0, y: start.y + 100.0 }; let rect = &Rectangle(*start, *end); let area = rect.area();

Discussion:
Their continued existence in the tutorial is causing confusion over what the status of this feature is. Let all the world know that managed pointers are relegated to the dustbin of history!
It's unclear to me if the tutorial is being rewritten from scratch by Mozilla. There's not much motivation for anyone to work on it if it's just going to be thrown out.
That may be true, but if a good samaritan wanted to do just enough work to delete mentions of them from the current tutorial, it would not be unappreciated.
Hi, I am the one who asked about this initially. I have started to work on it now.
At this point I do think it's worthwhile to keep maintaining the tutorial. Even if it doesn't survive as the tutorial, it does contain a lot of information that will end up disseminated elsewhere.
Not maintaining the tutorial leads to a growing collection of inaccurate or wrong information. Removing it could give newcomers a better first-time experience of Rust.
Change:
#![feature(nll)] #![feature(generator_trait)] #![feature(generators)] <ins> #![feature(once_cell)] </ins> #![recursion_limit = "256"] mod callbacks;

Discussion:
After is merged, usage of in this module: should be replaced by . The dependency from corresponding can be removed afterwards. It might make sense to request a perf run, as version uses parkinglot, while the standard one uses std mutex, but I expect the difference to not matter -- fast path is equivalent for both.
claim
is done! Though, I am not unsure if we maybe should wait until it tickles down to beta? Not sure how bootstraping works with libstd, I guess, we can just try and see if the build fails.
The compiler always builds with the in-tree standard library, so cfg(bootstrap) should never be necessary (beyond lints, and other compiler-implemented rather than library-implemented) details.
ping this is ready to be implemented.
I'll start soon! Sorry I got a bit overwhelmed with work. If in the next couple of days I haven't replied feel free to re-assign.
On it!
once this is merged, should other sub-crates that depend on also be updated? Like for example. Also, what about ? Some usage can probably be replaced by .
We definitely should actively remove oncecell crate from all rustc’s crates, because having two difference sources of the same data structure feels bad. Replacing lazystatic with std::lazy would also be good!
I'll try to take of it once this issue is fixed :+1:
Change:
} else { let mut ret = false; do csearch::get_item_attrs(tcx.cstore, did) |meta_items| { <del> ret = attr::contains_name(meta_items, attr); </del> <ins> ret = ret || attr::contains_name(meta_items, attr); </ins> } ret }

Discussion:
It seems the decoding of [mutable] and [nonowned] is broken: specifically it seems they are ignored when applied on a struct in an external module, when another attribute follows. In particular, it seems that when more than one attribute is present, only the last_ attribute survives encode+decode, and the others are somehow lost.
Nominating for the production ready milestone.
Should be fixable with the following patch:
Fixed by .
Change:
cmd.arg("--docck-python").arg(builder.python()); <del> if builder.config.build.ends_with("apple-darwin") { // Force /usr/bin/python3 on macOS for LLDB tests because we're loading the // LLDB plugin's compiled module which only works with the system python // (namely not Homebrew-installed python) cmd.arg("--lldb-python").arg("/usr/bin/python3"); } else { cmd.arg("--lldb-python").arg(builder.python()); } </del> <ins> cmd.arg("--lldb-python").arg(builder.python()); </ins> if let Some(ref gdb) = builder.config.gdb { cmd.arg("--gdb").arg(gdb);

Discussion:
python: python3: It sounds like python3 is strictly required for LLDB, so we should move this check from to , which will only require instead of both commands. cc label: +E-easy +E-mentor +E-help-wanted +A-rustbuild +A-contributor-roadblock <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
But not everyone will want to run lldb, right? We only mention /usr/bin/python3 there, we don't actually run it unless lldb tests are run, which is pretty rare. This may still be an OK change, of course.
Sure - but in that case, we hardly need python at all, only for rustdoc tests, and it seems ok to use the system python.
I would actually support requiring Python 3 in any case.
let's please keep discussion about 2 vs 3 in and not relitigate it on each issue that mentions python.
claim
If I understand the issue here correctly, just moving the check from to the doesn't entirely remove the issue of needing the name defined on MacOS given the call to in To resolve this should the check in include a MacOS specific check for or an additional check for ?
The former - it should just use any time it needs python on MacOS, and remove the existing check for on that platform.
About to raise a PR, but is it even necessary to perform any check in if we are always forcing in Are there instances where won't be called before ? Also first time using , what would be the correct test to run here?
I don't think it's necessary to check in both places, no, you can return /usr/bin/python3 unconditionally in (). Whether you can remove the check in is a question for - I think probably yes, since you can still run the build without python, but it doesn't necessarily need to go in the same change switching to /bin/python3 consistently. Basically everything runs the check in , but I think it's only relevant when BOOTSTRAP_PYTHON is unset, so probably you'll need to make sure the check executes. If you want to check the version of python used works, you can run .

If we can rely on /usr/bin/python3 always existing on macOS there's no need to check for it, but I would expect that the code in isn't platform-specific and so should continue to look for python in a variety of ways (likely the same ways across all platforms). It looks like python is currently used for two separate things: lldb tests, and docck. The latter likely works with python 2 and python 3, or at least, so it's likely that we need to leave the discovery and configuration in place. Certainly on e.g. Windows /usr/bin/python3 is not expected to exist, I believe.
Change:
// The primary bundle was present and translation succeeded Some(Ok(t)) => t, <ins> // If `translate_with_bundle` returns `Err` with the primary bundle, this is likely // just that the primary bundle doesn't contain the message being translated, so // proceed to the fallback bundle. Some(Err( primary @ TranslateError::One { kind: TranslateErrorKind::MessageMissing, .. }, )) => translate_with_bundle(self.fallback_fluent_bundle()) .map_err(|fallback| primary.and(fallback))?, </ins> // Always yeet out for errors on debug (unless // `RUSTC_TRANSLATION_NO_DEBUG_ASSERT` is set in the environment - this allows // local runs of the test suites, of builds with debug assertions, to test the

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. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
claim
After doing some more investigation, this also happens on a crate with only the empty crate: and like the original error, and are all used in manual implementations.
There are a bunch of these triggering in various lints it seems, so I wonder if the assert might actually not be thaaat justified?
changed that when a message is not in the primary bundle and debugassertions are on, it ices. So, for example, if you are using a half translated French bundle with messages missing, and have debugassertions on, you'll probably ice a lot. I agree that that in hindsight might have been a bad idea, and we should back that out ...however we don't actually have any other bundles, so I have no idea how this can trigger. I did some more debugging today, and it looks like the primary bundle never has any messages, so it should only trigger if the message requires formatting. I have no idea why that is or why it only happens if you have a rustc built with debug_assertions, rather than during tests for example. The only thing I can come up with is that between invoking rustc and running tests the bundle is created differently.
Change:
for &i in &inverse_memory_index { let field = fields[i as usize]; if !sized { <del> bug!("univariant: field #{} of `{}` comes after unsized field", offsets.len(), ty); </del> <ins> self.tcx.sess.delay_span_bug( DUMMY_SP, &format!( "univariant: field #{} of `{}` comes after unsized field", offsets.len(), ty ), ); </ins> } if field.is_unsized() {

Discussion:
The bug should be different from , as the stack traces are different. <!-- 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
Bisected:
Weirdly, the ICE only happens when you don't import . I.e., this ICEs: but this gives an appropriate unsized field error:
The error happens when a is involved, which makes the sizedness check for not to be evaluated. A way to side-step the issue is to change to be
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium
A potential duplicate. <!-- 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