jiebi/CodeConvo huggingface dataset:
Change:
= help: consider using a raw pointer instead = note: slices have no C equivalent <ins> error: `extern` fn uses type `Option<&<T as FooTrait>::FooType>`, which is not FFI-safe --> $DIR/lint-ctypes-94223.rs:31:20 | LL | pub type Foo2<T> = extern "C" fn(Option<&<T as FooTrait>::FooType>); |                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not FFI-safe | = help: consider adding a `#[repr(C)]`, `#[repr(transparent)]`, or integer `#[repr(...)]` attribute to this enum = note: enum has no representation hint </ins> error: `extern` fn uses type `FfiUnsafe`, which is not FFI-safe <del> --> $DIR/lint-ctypes-94223.rs:34:17 </del> <ins> --> $DIR/lint-ctypes-94223.rs:41:17 </ins> | LL | pub static BAD: extern "C" fn(FfiUnsafe) = f; |                 ^^^^^^^^^^^^^^^^^^^^^^^^ not FFI-safe

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. -- at <details<summary<strongBacktrace</strong</summary<p</p</detailssearched nightlies: from nightly-2023-01-01 to nightly-2023-08-14 regressed nightly: nightly-2023-07-04 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
As referenced in the other issue this now also happens on stable since = 1.70. The culprint seems to be this type alias: Removing the reference in the Option works around this panic.
Here's a minimal example that reproduces the issue: Interestingly, this only happens while the function is extern "C".
WG-prioritization assigning priority (). cc: for the bisection pointing to label -I-prioritize +P-high
claim
The panic originates in the on this line: It happens because returns which it does because normalization of fails. The reason the normalization fails is because trait resolution fails for the projection due to not being sufficiently bound. If, for example, I change in 's example above to by adding a bound, the panic goes away as trait resolution succeeds now. Since the normalization failure can be legitimate as in this case, I feel this unwrap: should be removed to fix the issue. However, I'm not sure what the enclosing method should do upon receiving a from . I'd presume it should return . Please review and let me know if this analysis makes sense. cc:
Closely related PR: . It fixes an ICE due to similar causes but on a different line. In fact the very next line.
Yeah, I think making not and just bubble up the is the right behavior here.
Change:
dox[code_block.code].to_owned(), ); <del> let has_errors = { let mut has_errors = false; </del> <ins> let validation_status = { let mut has_syntax_errors = false; let mut only_whitespace = true; // even if there is a syntax error, we need to run the lexer over the whole file </ins> let mut lexer = Lexer::new(&sess, source_file, None); loop  { match lexer.next_token().kind { token::Eof => break, <del> token::Unknown(..) => has_errors = true, _ => (), </del> <ins> token::Whitespace => (), token::Unknown(..) => has_syntax_errors = true, _ => only_whitespace = false, </ins> } } <del> has_errors </del> <ins> if has_syntax_errors { Some(CodeBlockInvalid::SyntaxError) } else if only_whitespace { Some(CodeBlockInvalid::Empty) } else { None } </ins> }; <del> if has_errors { </del> <ins> if let Some(code_block_invalid) = validation_status { </ins> let mut diag = if let Some(sp) = super::source_span_for_markdown_range(self.cx, &dox, &code_block.range, &item.attrs) { <del> let mut diag = self .cx .sess() .struct_span_warn(sp, "could not parse code block as Rust code"); </del> <ins> let warning_message = match code_block_invalid { CodeBlockInvalid::SyntaxError => "could not parse code block as Rust code", CodeBlockInvalid::Empty => "Rust code block is empty", }; let mut diag = self.cx.sess().struct_span_warn(sp, warning_message); </ins> if code_block.syntax.is_none() && code_block.is_fenced { let sp = sp.from_inner(InnerSpan::new(0, 3));

Discussion:
Run tests for and you'll get the following diagnostic: But to be as helpful as possible the diagnostic should, if possible, point to the start of the invalid code block.
This error was removed in because I didn't think it could actually be produced. Looks like it was possible to trigger by writing an empty doc test. The error message is misleading, though. It's a valid code block, just empty. On master, this code produces a passing doc test now. IMO, that is the correct behavior. There should probably be a test for it.
I agree completely. Would this mean re-introducing this message but improving the message (replacing invalid with empty or something similar)? I believe that is the best course of action as warning on an empty code block is completely valid and desired IMO.
The original code only caught this incidentally. I think this check would make more sense as a rustdoc lint instead of a hard warning. Could be to or a new pass entirely.
could you edit this issue to reflect the current status? It should be something like "Empty doc tests should be linted".
I'd like to take this issue - should have a PR this week for review.
Change:
<ins> #![feature(type_alias_impl_trait)] // edition:2018 use std::future::Future; pub trait Service<Request> { type Future: Future<Output = ()>; fn call(&mut self, req: Request) -> Self::Future; } // NOTE: the pub(crate) here is critical pub(crate) fn new() -> () {} pub struct A; impl Service<()> for A { type Future = impl Future<Output = ()>; fn call(&mut self, _: ()) -> Self::Future { async { new() } } } </ins>

Discussion:
This is probably a smaller reproduction of .
If anyone has a quick and dirty idea for how to force an type to resolve, I think I could finish minifying the above pretty easily.
Same ICEs without async:
Updated reproducing code to remove need for .
I'm fairly certain this is related to the visibility of types that appear in an type. Specifically, in the code above, if in is changed to , it compiles fine.
ping icebreakers-cleanup-crew
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rust- cc
triage: P-high until we assess severity (the bug written depends on a feature flag) we want to know if that's really needed for the issue to reproduce.
fwiw, my guess is that the feature flag is not necessary, and that the relevant can be replaced by an .
So, for cleanup crew ICE-breakers who might take a look at this: (a) we should try to get a backtrace with line numbers (b) we should see if this is a regression and track down the cause (maybe jump back a few months and see if the corresponding nightly from that time works?) (c) it'd be interesting to see if we can remove the from the impl and thus reproduce on something that builds on stable. As noted, an inherent on could trigger it, or perhaps something like:
Downgrading priority for now until we can reproduce without the gate.
related
Interestingly enough, an inherent method like that does not reproduce the issue, so it appears the existential type in associated type position is also needed.
I just hit the same issue on nightly: Reproduction is huge though: Just it. This happened after I upgraded dependency from to . I don't see feature used in .
That is which was fixed two days ago. Try updating rustc.
Indeed, thanks!
Change:
<del> //@ known-bug: #124348 enum Eek { TheConst, UnusedByTheConst(Sum), } const EEK_ZERO: &[Eek] = &[]; </del>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: interpret const eval failure of Unevaluated(UnevaluatedConst { def: DefId(0:11 ~ ice[ec8e]::EEKZERO), args: [], promoted: Some(promoted[0]) }, &'{erased} [Eek; 0usize]) which is not in requiredconsts', 'error: internal compiler error: interpret const eval failure of Unevaluated(UnevaluatedConst { def: DefId(0:11 ~ ice[ec8e]::EEKZERO), args: [], promoted: Some(promoted[0]) }, &'{erased} [Eek; 0usize]) which is not in requiredconsts' 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: 6 | const EEKZERO: &[Eek] = &[]; [evaltoallocationraw] const-evaluating + checking [evaltoconstvalueraw] simplifying constant for the type system [analysis] running analysis passes on this crate --
cc
Caused by running the interpreter on code that doesn't even pass name resolution. Not sure where to fix this, but probably not in the interpreter.^^ Cc
this is a promoted failing to compile because it gets the layout of this broken type, which gives us back an . I'm certain we can prevent const eval from running by checking such layouts earlier in the MIR pipeline, but the fix isn't clear to me yet.
The issue is that in the sanity check we only know it's an , we don't know whether it was a typeck error on a const-eval error. So we can't really distinguish these cases. If this is a , we could probably fix it by tweaking the error handling . But there probably are similar cases where a promoted fails to evaluate due to a SizeOverflow and then we have to report the error somewhere.

The only option I see right now is to add another variant to (or a flag in ) to track whether this was a failure inside the constant itself or a failure in something the constant referenced. But this distinction isn't always very clear anyway... it would basically have to be "is this an error that can occur even for supposedly infallible operations like ", i.e., match exactly the usecase of the const-eval / promoted sanity check. Which is not great.
We already got the flag that we can reuse for that
Change:
--> $DIR/format-foreign.rs:12:5 | 12 |     println!("%.*3$s %s!/n", "Hello,", "World", 4); <del> |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ </del> <ins> |     ^^^^^^^^^^^^^^^^^^^^^^^^^--------^^-------^^-^^ |                              |         |        | |                              |         |        unused |                              |         unused |                              unused </ins> | <del> note: argument never used --> $DIR/format-foreign.rs:12:30 | 12 |     println!("%.*3$s %s!/n", "Hello,", "World", 4); |                              ^^^^^^^^ note: argument never used --> $DIR/format-foreign.rs:12:40 | 12 |     println!("%.*3$s %s!/n", "Hello,", "World", 4); |                                        ^^^^^^^ note: argument never used --> $DIR/format-foreign.rs:12:49 | 12 |     println!("%.*3$s %s!/n", "Hello,", "World", 4); |                                                 ^ </del> = help: `%.*3$s` should be written as `{:.2$}` = help: `%s` should be written as `{}` = note: printf formatting not supported; see the documentation for `std::fmt`

Discussion:
After , the output for errors looks like: that's a lot of lines dedicated to underlining macro acruments. They should all be output in one multispan. cc
Hum indeed. If no one has taken it in 12 hours, I'll give it a look.
I'm poking at it right now. I think I need to fix 's methods to accept instead of just , and then I can use directly. After all, I created the problem, I should probably fix it. :P
Perfect. Good luck! :)
I believe this should be closed.
Hold on, it seems the PR is still open.
Seeing as there isn’t anyone working on this anymore, I’ll be happy to take over. This is my first issue, (woot), so I’m not exactly sure where to start. I assume I should just fork the repo, change to use , and fix the tests? Pinging and in case you want to work on this still.
I am not working on this anymore.
Those steps may be correct; or someone else may be able to verify for you. You can also look at and which appear to be previous PRs which attempted to do this. Let us know if you'd like any help!
Awesome! I'm super excited. Anyone specific I should ?
bors will select someone automatically if you don't specify anyone, but I think any of me, or would be available for review and or guidance.
For some reason I seem to be getting unrelated to my changes. (ran )
Those tests shouldn't actually be running in ... cc For these changes, I would suggest , I think that should be enough.
Gotcha, it’s possible I copy pasted from the wrong command (on mobile can’t check right now), but I’ll use that command for testing and see if it works. I’m kinda busy for the rest of the week but I’ll keep working on it in my free time. I’ll comment here until I get a PR ready with any updates I have.
Change:
<ins> // Opaque macro can eagerly expand its input without breaking its resolution. // Regression test for issue #63685. // check-pass macro_rules! foo { () => { "foo" }; } macro_rules! bar { () => { foo!() }; } fn main() { format_args!(bar!()); } </ins>

Discussion:
This code ([playpen]) compiles on stable but not on nightly and beta: [playpen]: Standard Error Edit: Removed macro Originally posted by in
modify labels: A-macros A-resolve C-bug T-compiler
I updated the snippet to remove the module.
This is a regression from (cc Slightly more minimized reproduction will look like this: performs eager expansion on its arguments and hygienic context of produced by such expansion looks like it was produced by the opaque for some reason, so it's resolved at ' definition site. It maybe either some issue with hygiene infra interacting with eager expansion, but it also may be caused by incorrect spans produced by .
(I'm currently looking into the details.) UPD: I have a fix locally, will submit tomorrow.
Fixed in

() Errors: If either the recursion () or the is removed (), this compiles exactly as expected. Additionally, if I explicitly name my crate, it works as expected, but would be vulnerable to crate renames in user code (can't reproduce in playground because it doesn't build a library).
If you try and build Rustup, you get a similar failure, but without recursion or . Seems that just using another macro and is enough in some circumstances
cc for the hygiene macro in
This code () compiles on stable but not on nightly and beta:
Please, file a separate issue for the regression, I'll prioritize it over pre-existing issues (which the original issue seems to be).
Thanks, I filed it in
Fixed in
Thanks for your work on this!
Change:
<ins> // check-pass #[macro_export(hello, world)] //~ WARN `#[macro_export]` can only take 1 or 0 arguments macro_rules! a { () => () } #[macro_export(not_local_inner_macros)] //~ WARN `not_local_inner_macros` isn't a valid `#[macro_export]` argument macro_rules! b { () => () } #[macro_export] macro_rules! c { () => () } #[macro_export(local_inner_macros)] macro_rules! d { () => () } #[macro_export()] macro_rules! e { () => () } fn main() {} </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: I expected to see this happen: it shouldn't compile Instead, this happened: it compiles <!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
For anyone who would like to work on this, the following code needs to be adjusted to check if the meta-item list is empty or if it only contains the identifier (i.e. only allowing the attribute to be or : Due to backward compatibility concerns, probably only a future-incompat warning should be issued if the verification fails. label T-compiler A-attributes
claim
First rust-lang/rust contribution I hope this goes well
Change:
"env_logger 0.6.0 (registry+https://github.com/rust-lang/crates.io-index)", "hex 0.3.2 (registry+https://github.com/rust-lang/crates.io-index)", "log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)", <ins> "num-traits 0.2.6 (registry+https://github.com/rust-lang/crates.io-index)", </ins> "rand 0.6.1 (registry+https://github.com/rust-lang/crates.io-index)", "rustc-workspace-hack 1.0.0", "rustc_version 0.2.3 (registry+https://github.com/rust-lang/crates.io-index)",

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and -- nominating for prioritization.
Miri-side fix at which is blocked on
Also blocked on
triage: P-medium
This was fixes a while ago. But now miri broke again and no new issue was opened? Cc
I was about to post the following here(a few minutes before you commented, RalfJung) when my system , so here it is after a re-run(hence it took only a few seconds instead of 34mins):
The fix is in progress at Building Miri takes 34min for you? oO wow.
ah no, that was the output from building rust.
Blocked on and
Change:
debug!("build_impl: impl {:?} for {:?}", trait_.def_id(), for_.def_id()); <del> ret.push(clean::Item::from_def_id_and_parts( </del> <ins> let mut item = clean::Item::from_def_id_and_parts( </ins> did, None, clean::ImplItem(clean::Impl {

Discussion:
I tried this code: I expected to see this happen: both impls being highlighted as needing the feature. Instead, this happened: only the impl got the message: ! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
modify labels: +T-rustdoc
claim
Change:
Basic usage: ``` <del> ", $Feature, "#![feature(saturating_neg)] assert_eq!(100", stringify!($SelfT), ".saturating_neg(), -100); </del> <ins> ", $Feature, "assert_eq!(100", stringify!($SelfT), ".saturating_neg(), -100); </ins> assert_eq!((-100", stringify!($SelfT), ").saturating_neg(), 100); assert_eq!(", stringify!($SelfT), "::MIN.saturating_neg(), ", stringify!($SelfT), "::MAX);

Discussion:
It would be great to have and functions for signed integer types. The current work-around is using a pattern like but having explicit functions would lift the corner-case knowledge "burden" from the user.
What do you expect them to return? Just for the two values that can't be expressed? IMHO you should prefer the instead and explicitly handle that.
The and functions both have a corner case when the negative minimum value is used (e.g. -128 for type i8). The result cannot be represented within the bounds of the output type. The / variants shall return a best-effort value (like 127 in case of -128 i8 input), similar to the existing functions. asserteq!(127i8.saturatingabs(), 127); asserteq!(-127i8.saturatingabs(), 127); asserteq!(-128i8.saturatingabs(), 127); asserteq!(127i8.saturatingneg(), -127); asserteq!(-127i8.saturatingneg(), 127); asserteq!(-128i8.saturating_neg(), 127);
These seems reasonable. I'd suggest just making a PR with them unstable and seeing what libs says. By using they'll automatically get the new saturating implementation, too, which should be better for optimization and codegen than the approach.
Haven't done a PR for Rust yet so will take a look at the contribution guidelines and try to get along.
What's holding up stabilization on this? It seems relatively simple.
In my opinion there is nothing specific holding this up from being stabilized. Initially I wanted to give it some time for others to comment, then forgot about. Added a PR for stabilization now.
Change:
} fn exited(&self) -> bool { <del> // On Linux-like OSes this function is safe, on others it is not. See // libc issue: https://github.com/rust-lang/libc/issues/1888. #[cfg_attr( any(target_os = "linux", target_os = "android", target_os = "emscripten"), allow(unused_unsafe) )] unsafe { libc::WIFEXITED(self.0) } </del> <ins> libc::WIFEXITED(self.0) </ins> } pub fn success(&self) -> bool {

Discussion:
Reasons for: . According to , musl caused a program to run 9x slower. Musl is also known to be slower in certain configurations in C. This varies a lot with the use case and some might even see a performance increase with musl. docker containers using . It is possible to link glibc statically as demonstrated . From what I can tell, on the user facing side, this would be enable using as described in .
The reddit thread mentions libm. And another source of speedups might be the malloc implementation (glibc 2.26 introduced thread-local caches). One can already use custom global allocators, maybe it would make sense to link a custom libm too?
First blocker is the license. Glibc is licensed under LGPL, it has dynamic linking exception so one can freely link dynamically to it. Static linking doesn't fall under this exception. I'm not a lawyer but I think Rust would have to be licensed as (L)GPL to fit it. Another thing is glibc doesn't really support static linking, sure it works well for small software but bites you when you need more of it's features.
(Obviously not a lawyer but), I'm pretty sure that as long as the code it is linked against is (L)GPLed, it should work.
Also as long as the program it is linked against is licensed under a GPL compatible license, it is allowed. The MIT license, is compatible. All this information can be confirmed by looking at the above link. You can even link proprietary code against LGPL if you provide the object files.
because of we need special linking arguments because of the symbols. see also for and glibc uses for the nss modules.
The former should be doable. The latter is a tradeoff that people will need to understand if they statically link glibc, and it's something they already have to deal with if they use .
Implementation instructions: Add an entry for glibc-based targets you want to support to (Same as for musl, but -, because is undesirable ().) Perhaps libm or libpthread will need to be linked in the same way. Set to in target specifications for glibc-based targets you want to support (in ). Test that it actually works, this will require some building of libstd with cargo overridden libc dependency.

I'd be happy to submit the necessary changes, if you can outline what needs doing. () See the comment above.
Thanks!
I have this successfully working; just waiting on a release of the libc crate containing .
Change:
error[E0632]: cannot provide explicit generic arguments when `impl Trait` is used in argument position <del> --> $DIR/synthetic-param.rs:20:5 </del> <ins> --> $DIR/synthetic-param.rs:20:12 </ins> | LL |     func::<u8>(42); <del> |     ^^^^^^^^^^ </del> <ins> |            ^^ explicit generic argument not allowed </ins> error[E0632]: cannot provide explicit generic arguments when `impl Trait` is used in argument position <del> --> $DIR/synthetic-param.rs:23:5 </del> <ins> --> $DIR/synthetic-param.rs:23:17 </ins> | LL |     Foo::func::<u8>(42); <del> |     ^^^^^^^^^^^^^^^ </del> <ins> |                 ^^ explicit generic argument not allowed </ins> error[E0632]: cannot provide explicit generic arguments when `impl Trait` is used in argument position <del> --> $DIR/synthetic-param.rs:26:5 </del> <ins> --> $DIR/synthetic-param.rs:26:23 </ins> | LL |     Bar::<i8>::func::<u8>(42); <del> |     ^^^^^^^^^^^^^^^^^^^^^ </del> <ins> |                       ^^ explicit generic argument not allowed </ins> error: aborting due to 3 previous errors

Discussion:
The spans for this error should point to the generic arguments, not the entire path. See <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim