jiebi/CodeConvo huggingface dataset:
Code change:
} // Don't report FFI errors for unit return types. This check exists here, and not in <del> // `check_foreign_fn` (where it would make more sense) so that normalization has definitely </del> <ins> // the caller (where it would make more sense) so that normalization has definitely </ins> // happened. if is_return_type && ty.is_unit() { return;

Related discussion:
text: The function itself is considered FFI-safe and does not trigger the warning (). Its function pointer should also be allowed, to be consistent. Discovered on CI The original code has several more levels of indirection, but is also considered FFI-safe before. <details<summaryExtracted original code</summary</detailsAccording to CI logs, the warning occurs since rust 1.72.0-nightly ( 2023-07-03). Probably caused by . cc
Okay, so, I had a fix for this that just got rid of the regression, but I'm not sure that's the correct solution here - I think this is correct to be linting in the fn-ptr case and should be linting for the function case. is FFI-unsafe, but we allow a function to return because that's the default, but that doesn't mean that a within a type is okay (with the exception of a wrapper around the - because that's just returning , which we've already decided is okay). In the function case that works right now, that's being allowed because of this code.. ..which is there to support the case. However, it's not quite the right check. It doesn't actually check for ! It checks that the type - however nested - which was deemed FFI-unsafe is and that type is part of a return type. So any FFI-unsafe in a return type makes the entire return type FFI-safe - which is clearly incorrect. That's making the example below compile, which absolutely shouldn't. I've submitted , which makes this even more of a regression by making the function case fail too. We already had a simple "is it a unit" check, so I extended that to check for transparent newtype wrappers too, and removed the incorrect check.
This is unfortunate since I'm trying to return a where is likely to be . What should I do instead if I want to be FFI-safe with layout ?
I'm not so sure anymore after reading comment (). It's clear that some changes are required regardless - our current implementation wrong as demonstrated in the final example from my previous comment, but it's also inconsistent, in that this example... lint for the argument use of , but not the return use of , when really it should be both or neither. After my pull request, it's both.
Code change:
} // Don't report FFI errors for unit return types. This check exists here, and not in <del> // `check_foreign_fn` (where it would make more sense) so that normalization has definitely </del> <ins> // the caller (where it would make more sense) so that normalization has definitely </ins> // happened. if is_return_type && ty.is_unit() { return;

Related discussion:
text: With and without my pull request, when you change this to , it doesn't lint.
I'll nominate this issue so that it sees some discussion - see also and .
I posted some more info on zulip but it may also worth mentioning here. ZST is still zero-sized under repr(C), rather than FFI-unsafe.
The issue now also exists in beta. I also found uitests which seems to expect ZST to be FFI-safe, but ends in to suppress the warning and tests nothing.
We discussed this in today's meeting. We didn't have consensus that this should warn; at least some people thought the code in the top comment should continue to compile without warnings. We did have consensus that changing that (to warn) would need an FCP. So, we felt that we'd like to see a fix removing the warning applied to beta and nightly, and then separately if someone wants to propose that we change this to warn, we could evaluate that and do an FCP on it. But at the moment the temperature of the team seems to be that we don't have consensus for such an FCP.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
labels -I-lang-nominated We rendered our opinion
Code change:
// Computing common supertype in an if expression IfExpression(Span), <ins> // Computing common supertype of an if expression with no else counter-part IfExpressionWithNoElse(Span) </ins> } /// See `error_reporting.rs` for more details

Related discussion:
text: I apologize in advance if this is a separate issue. With the map() generic function from the tutorial: That code gives a nice error message: However, remove the assignment and what should be the same error message becomes:
Yes, that is unrelated to this issue. You're seeing an expected type mismatch error since the return type of main() is () and your samples result in two different non-() results.
Thanks I was one hour into learning Rust when I came across this. I understand what is going on now. I still think the error message could be improved to mention that "expected " is referring to the return type of main(). That simple clue could help people not as familiar with Rust to remember the semicolon rule to turn a statement into an expression.
Not critical for 0.7, but improving error messages is always good. Nominating for milestone 5.
declined. this is bad but it's not a blocker.
Confirmed that the situation is unchanged.
This is still an issue.
Bug triage. Still an issue.
Very, very small change:
Code change:
<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // Test that wrapping an unsized struct in an enum which gets optimised does // not ICE. struct Str { f: [u8] } fn main() { let str: Option<&Str> = None; str.is_some(); } </ins>

Related discussion:
text: I was playing with DST by reimplementing the primitive as a , but hit an ICE while testing. The code is in this cc This seems similar to cc
Minimal test case:
Code change:
} } } <ins> // just tests by whether or not this compiles fn _pending_impl_all_auto_traits<T>() { use std::panic::{RefUnwindSafe, UnwindSafe}; fn all_auto_traits<T: Send + Sync + Unpin + UnwindSafe + RefUnwindSafe>() {} all_auto_traits::<std::future::Pending<T>>(); } </ins>

Related discussion:
text: Right.. is my own PR; I'm noting this as an issue, mainly so I won't forget this, because I won't do this myself right now / today. Or someone else can do this if they want. I'm not 100% certain where the best place for such a test to go is, and/or whether it makes sense to have them in one place or separated and more close to the respective type's definition. A test to prevent any future regression removing the new auto trait implementations introduced by can look about as follows <s` </sEdit: This code is needlessly complicated, see my comment below. label C-enhancement, A-testsuite, E-easy, E-needs-test, T-libs <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
FYI, somehow I missed the more straightforward way of writing these.
Code change:
() => ((file!(), line!())) } <del> #[cfg(all(unix, not(target_os = "macos"), not(target_os = "ios"), not(target_os = "android"), not(all(target_os = "linux", target_arch = "arm"))))] </del> macro_rules! dump_and_die { ($($pos:expr),*) => ({ // FIXME(#18285): we cannot include the current position because // the macro span takes over the last frame's file/line. <del> dump_filelines(&[$($pos),*]); panic!(); </del> <ins> if cfg!(target_os = "macos") || cfg!(target_os = "ios") || cfg!(target_os = "android") || cfg!(all(target_os = "linux", target_arch = "arm")) || cfg!(all(windows, target_env = "gnu")) { // skip these platforms as this support isn't implemented yet. } else { dump_filelines(&[$($pos),*]); panic!(); } </ins> }) } <del> // this does not work on Windows, Android, OSX or iOS #[cfg(not(all(unix, not(target_os = "macos"), not(target_os = "ios"), not(target_os = "android"), not(all(target_os = "linux", target_arch = "arm")))))] macro_rules! dump_and_die { ($($pos:expr),*) => ({ let _ = [$($pos),*]; }) } </del> // we can't use a function as it will alter the backtrace macro_rules! check { ($counter:expr; $($pos:expr),*) => ({

Related discussion:
text: Symbol names are not properly supported yet on msvc, so backtraces are generally unhelpful. As a result, is currently disabled. This issue can be closed when it's been reenabled.
Code change:
// MACRO_RULES ITEM self.parse_item_macro_rules(vis, has_bang)? } else if self.isnt_macro_invocation() <del> && (self.token.is_ident_named(sym::import) || self.token.is_ident_named(sym::using)) </del> <ins> && (self.token.is_ident_named(sym::import) || self.token.is_ident_named(sym::using) || self.token.is_ident_named(sym::include) || self.token.is_ident_named(sym::require)) </ins> { return self.recover_import_as_use(); } else if self.isnt_macro_invocation() && vis.kind.is_pub() {

Related discussion:
text: I was looking at namely issue when I thought about this. If work is being put into improving error messages when somebody uses a keyword that defines a function in another language, there should also be improved error messages if someone uses the incorrect directive to bring something into the scope of their module or namespace/ Given the following code: The current output is: The error message should preferably suggest the user to use the directive to bring something into scope of their module. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
For the record, on nightly, both and suggest using . I'm sure it's not that difficult to add .
ah. I was not aware of this. Less work to do then!
[Ignore this, just notes]
And also add ? Rust may go tooooo friendly in diagnostic message . Do you mind that I make a PR for it? I'm a newbie in hacking Rust compiler.
Sure! The earlier message should clarify where the edits are needed to be made. Ain't nothing as a diagnostic too friendly. =)
Remember to assign yourself using rustbot. Just a note for the future, usually if someone has already claimed an issue, it's not exactly common for someone else to fix it [aside from if the issue is abandoned by the claimee]. Since you're a newcomer here, I removed my assignment (and because I was working on another). However, you can find loads of easy issues with the E-Easy and/or E-Mentor tag for gaining experience. A few resources that might be helpful - Have fun hacking on Rust!
claim
Totally forgot about ! Good catch!
Code change:
)?; write_minify("search.js", static_files::SEARCH_JS)?; write_minify("settings.js", static_files::SETTINGS_JS)?; <ins> write_minify("sidebar-items.js", static_files::sidebar::ITEMS)?; </ins> if cx.shared.include_sources { write_minify("source-script.js", static_files::sidebar::SOURCE_SCRIPT)?; }

Related discussion:
text: <!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --Since i don't know which version, when running on a project, the left sidebar of the docs no longer has a nav for all crates in the dependency graph. However, the documentation for all dependencies is still compiled. a Rust project with a few dependencies. : Left sidebar has a list of all dependencies, linking to each crate's local docs. : No such thing. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: I honestly don't remember. I update my nightly before every dev session. Allegedly that bug is 27 days old. <!-- Provide the version you are using that has the regression. --: <!-- 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 --
Appears to be a regression from , the call to was moved into , but this function is not called on the crate-root doc page. I tested locally that it fails on and works on .
Checking looks like this has made it onto the 1.53 beta.
cc
I think the ideal fix is around We should emit a sidebar- for the top page that just calls . And remove that comment, since we now have dynamic crate loading. A quicker fix is to just move the call to addSidebarCrates so it gets called independently from initSidebarItems. I like that less since the crates really are a sidebar item and should be treated as such.
I can do that if no one else wants to do it!
Go for it! I'm happy to review.
Assigning .
It's actually something I fixed in (still waiting for approval/review).
I propose we plan on landing and backporting to fix the regression: it's much smaller and limited to the specific fix. Then we can work on landing in nightly.
No, the approach taken in is problematic. The information is already there and we don't need this new file.
Code change:
)?; write_minify("search.js", static_files::SEARCH_JS)?; write_minify("settings.js", static_files::SETTINGS_JS)?; <ins> write_minify("sidebar-items.js", static_files::sidebar::ITEMS)?; </ins> if cx.shared.include_sources { write_minify("source-script.js", static_files::sidebar::SOURCE_SCRIPT)?; }

Related discussion:
text: EDIT: also, is ready, there is a debate for the other part of the PR (the change on module's sidebar) which I can move to another PR.
See - after some discussion, and concluded to merge as our quick fix. To explain why I proposed to add a tiny sidebar- We have one that's loaded by a variety of different pages. It also potentially has many different entry points. For instance, the primary entry point is that when itself is loaded, it runs various functions, adding event handlers and so on. Another entry point is that when sidebar- loads, it calls . That's the root cause of this bug - code in expected would get called, and for a subset of pages it wasn't. It's a bit inelegant to have a small file whose purpose is only to call a known function. But I think that inelegance is balanced against the improved maintainability of having most doc pages follow closer to the same code path through The more code paths, the more chances for bugs and the more complexity in testing. Another way to address this longer-term would be to eliminate the entrypoint entirely. Instead, when runs, it would trigger the load of sidebar-items and run any callbacks based on that load. Yet another way to address this would be to separate out from , so that is called unconditionally for all pages.
Code change:
<ins> error[E0106]: missing lifetime specifier --> $DIR/opaque-and-lifetime-mismatch.rs:5:24 | LL |     fn bar() -> Wrapper<impl Sized>; |                        ^ expected named lifetime parameter | = help: this function's return type contains a borrowed value, but there is no value for it to be borrowed from help: consider using the `'static` lifetime, but this is uncommon unless you're returning a borrowed value from a `const` or a `static`, or if you will only have owned values | LL |     fn bar() -> Wrapper<'static, impl Sized>; |                         ++++++++ error[E0412]: cannot find type `T` in this scope --> $DIR/opaque-and-lifetime-mismatch.rs:1:22 | LL | struct Wrapper<'rom>(T); |                      ^ not found in this scope | help: you might be missing a type parameter | LL | struct Wrapper<'rom, T>(T); |                    +++ error[E0107]: struct takes 0 generic arguments but 1 generic argument was supplied --> $DIR/opaque-and-lifetime-mismatch.rs:5:17 | LL |     fn bar() -> Wrapper<impl Sized>; |                 ^^^^^^^ ---------- help: remove this generic argument |                 | |                 expected 0 generic arguments | note: struct defined here, with 0 generic parameters --> $DIR/opaque-and-lifetime-mismatch.rs:1:8 | LL | struct Wrapper<'rom>(T); |        ^^^^^^^ error[E0053]: method `bar` has an incompatible return type for trait --> $DIR/opaque-and-lifetime-mismatch.rs:11:17 | LL |     fn bar() -> i32 { |                 ^^^ |                 | |                 expected `Wrapper<'static>`, found `i32` |                 return type in trait error[E0053]: method `bar` has an incompatible type for trait --> $DIR/opaque-and-lifetime-mismatch.rs:11:17 | LL |     fn bar() -> i32 { |                 ^^^ |                 | |                 expected `Wrapper<'static>`, found `i32` |                 help: change the output type to match the trait: `Wrapper<'static>` | note: type in trait --> $DIR/opaque-and-lifetime-mismatch.rs:5:17 | LL |     fn bar() -> Wrapper<impl Sized>; |                 ^^^^^^^^^^^^^^^^^^^ = note: expected signature `fn() -> Wrapper<'static>` found signature `fn() -> i32` error: aborting due to 5 previous errors Some errors have detailed explanations: E0053, E0106, E0107, E0412. For more information about an error, try `rustc --explain E0053`. </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: expect 1 RPITITs in call to '', 'thread 'rustc' panicked at 'assertion failed: expect 1 RPITITs in call to '' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- query stack: [collectreturnpositionimpltraitintraittys] comparing an impl and trait method signature, inferring any hidden types in the process [typeof] computing type of [checkmodimplwf] checking that impls are well-formed in top-level module [analysis] running analysis passes on this crate --
<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
fyi
Code change:
<ins> error[E0596]: cannot borrow `*inner` as mutable, as it is behind a `&` reference --> $DIR/issue-91206.rs:13:5 | LL |     let inner = client.get_inner_ref(); |         ----- help: consider changing this to be a mutable reference: `&mut Vec<usize>` LL | LL |     inner.clear(); |     ^^^^^^^^^^^^^ `inner` is a `&` reference, so the data it refers to cannot be borrowed as mutable error: aborting due to previous error For more information about this error, try `rustc --explain E0596`. </ins>

Related discussion:
text: <!-- 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. --: In case it helps, when using the stable toolchain, the compiler does not panic but instead emits this error: <!-- 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 --
Bisected to . CC searched nightlies: from nightly-2021-10-01 to nightly-2021-11-25 regressed nightly: nightly-2021-11-23 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: aarch64-apple-darwin Reproduce with: </details label regression-from-stable-to-nightly
I can fix this quickly -- seems like just changing an to a since the can be out of bounds. claim
(only tangentially related) I also noticed a regression in error spans between stable and beta... stable: beta:
That was an intentional change, meant to highlight the fact that the attempted mutable borrow is occurring because of the method call. However, it seems to be confusing for a lot of people, so I'll look into improving it.
Ah thanks for letting me know. Maybe we can split the span up into the receiver and the method, and add a note on the latter like "due to this method which takes &mut self". Not sure if that much info bubbles down into borrowck. I'd be interested in making that change if you've got a lot on your plate and it's (relatively) easy to do.
See for discussion about this exact idea. It'd be nice, but likely hard to implement.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
Code change:
use libc::types::os::arch::c95::{c_int, size_t}; pub static SIGTRAP : c_int = 5; <ins> pub static SIGPIPE: c_int = 13; pub static SIG_IGN: size_t = 1; </ins> pub static GLOB_ERR      : c_int = 1 << 0; pub static GLOB_MARK     : c_int = 1 << 1;

Related discussion:
text: Scripts to reproduce Steps to reproduce: Output:  Backtrace: None Exit code: 141 Version:
What are you expecting to happen? When you send a TERM signal to a process without a registered handler, it terminates promptly. The runtime currently doesn't register any TERM/INT handlers, that's up to you.
I was expecting the runtime to return some upon requesting an action from a defunct process. I also tried polling the state of the defunct process using (as mentioned in the ), but this returned as well. Even if the runtime dosn't "catch" the SIG{TERM,INT}, is it not possible at all to or return in any of the two cases mentioned above?
Oh whoops, sorry! I had my understanding backwards, and apparently this isn't a bug on OSX which caused more confusion for me. Anyway, closing as a dupe of , it's the same cause.
Oh wow, I've done it again. I'm sorry, again! I apologize for not investigating more thoroughly. This is indeed separate from
Code change:
<ins> // edition:2021 #![feature(async_closure)] // Don't ICE in ByMove shim builder when MIR body is tainted by writeback errors fn main() { let _ = async || { used_fn(); //~^ ERROR cannot find function `used_fn` in this scope 0 }; } </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '-Zvalidate-mir -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: unexpected body ty: {type error} phase Runtime(PostCleanup)', 'error: internal compiler error: unexpected body ty: {type error} phase Runtime(PostCleanup)' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [mirdropselaboratedandconstchecked] elaborating drops for [analysis] running analysis passes on this crate --
cc :D (note you'll need which was merged 10 minutes ago ^^ )
Code change:
<ins> // edition:2021 #![feature(async_closure)] // Don't ICE in ByMove shim builder when MIR body is tainted by writeback errors fn main() { let _ = async || { used_fn(); //~^ ERROR cannot find function `used_fn` in this scope 0 }; } </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '--edition=2021 -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: impossible case reached', 'error: internal compiler error: impossible case reached' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [mirconst] preparing for borrow checking [mirpromoted] promoting constants in MIR for [mir_borrowck] borrow-checking [analysis] running analysis passes on this crate --
cc