jiebi/CodeConvo huggingface dataset:
Code change:
MergeFunctions::Disabled | MergeFunctions::Trampolines => {} MergeFunctions::Aliases => { <del> add("-mergefunc-use-aliases"); </del> <ins> add("-mergefunc-use-aliases", false); </ins> } } } if sess.target.target.target_os == "emscripten" && sess.panic_strategy() == PanicStrategy::Unwind { <del> add("-enable-emscripten-cxx-exceptions"); </del> <ins> add("-enable-emscripten-cxx-exceptions", false); </ins> } // HACK(eddyb) LLVM inserts `llvm.assume` calls to preserve align attributes // during inlining. Unfortunately these may block other optimizations. <del> add("-preserve-alignment-assumptions-during-inlining=false"); </del> <ins> add("-preserve-alignment-assumptions-during-inlining=false", false); </ins> for arg in &sess.opts.cg.llvm_args { <del> add(&(*arg)); </del> <ins> add(&(*arg), true); </ins> } }

Related discussion:
text: LLVM's MergeFunctions introduces aliases which can trigger a bug in macOS's linker when compiling with ThinLTO: For this reason Firefox has to be built with a patched version of when compiling with xLTO. Since the bug in question is pretty nasty (the above example shows a program just returning a different value with no indication that anything is wrong), we should probably try to not trigger it. Right now, however, it seems that one cannot even turn the MergeFunctions pass off in stable Rust. (I wonder if the pass should even be disabled by default on macOS?) cc & (this seems related to )
Is it a mergefunc bug or a ThinLTO bug? Can it be triggered without ThinLTO? If not, I would rather not blindly disable it on macOS, at least not when ThinLTO isn't enabled.
It's not a bug in mergefunc. It might not even be a bug in ThinLTO. It's just that mergefunc is the only thing in that generates symbol aliases in LLVM IR, and these are what can lead to "miscompilations" when using the macOS linker.
Has the ld64 bug been reported somewhere?
We could use to prevent the pass from emitting aliases on macOS, AFAIK.
This is already supported via either or in the target spec.
Do you mean that the test case also fails with enabled, or that we already have a knob to disable them?
Answering my own question, we already have a knob for that.
Which was because .
As and point to there is the unstable option which I've only tested on nightly. I guess there could be a stabilized option, but maybe what you really want to do is to patch the x8664 macos target definition (I believe this is the correct one: ).
Yes, I've been told that it has been reported to Apple. On nightly, one can already control the mergefunc pass. On stable, however, one is stuck with the default behavior. That's what this issue is mostly about.
just want to double-check my understanding: I would have thought one could use the options and to override the set of passes, even on the stable channel. Am I incorrect about this? (If I am correct, I nonetheless will admit that this is an ugly (and very fragile) method to opt out of the MergeFunctions pass)
I think that is correct, yes.
Code change:
MergeFunctions::Disabled | MergeFunctions::Trampolines => {} MergeFunctions::Aliases => { <del> add("-mergefunc-use-aliases"); </del> <ins> add("-mergefunc-use-aliases", false); </ins> } } } if sess.target.target.target_os == "emscripten" && sess.panic_strategy() == PanicStrategy::Unwind { <del> add("-enable-emscripten-cxx-exceptions"); </del> <ins> add("-enable-emscripten-cxx-exceptions", false); </ins> } // HACK(eddyb) LLVM inserts `llvm.assume` calls to preserve align attributes // during inlining. Unfortunately these may block other optimizations. <del> add("-preserve-alignment-assumptions-during-inlining=false"); </del> <ins> add("-preserve-alignment-assumptions-during-inlining=false", false); </ins> for arg in &sess.opts.cg.llvm_args { <del> add(&(*arg)); </del> <ins> add(&(*arg), true); </ins> } }

Related discussion:
text: It would be rather hard, however, to re-create the set of passes meaningfully, I suspect. Even the compiler delegates this to methods within LLVM, iirc.
I think using might work on stable.
So did that help,
Unfortunately not. Specifying this gives me:
Code change:
<ins> use rustc_middle::ty::TyCtxt; use rustc_middle::ty::Visibility; use crate::clean; use crate::clean::Item; use crate::core::DocContext; use crate::fold::{strip_item, DocFolder}; use crate::passes::Pass; pub(crate) const STRIP_ALIASED_NON_LOCAL: Pass = Pass { name: "strip-aliased-non-local", run: strip_aliased_non_local, description: "strips all non-local private aliased items from the output", }; fn strip_aliased_non_local(krate: clean::Crate, cx: &mut DocContext<'_>) -> clean::Crate { let mut stripper = AliasedNonLocalStripper { tcx: cx.tcx }; stripper.fold_crate(krate) } struct AliasedNonLocalStripper<'tcx> { tcx: TyCtxt<'tcx>, } impl<'tcx> DocFolder for AliasedNonLocalStripper<'tcx> { fn fold_item(&mut self, i: Item) -> Option<Item> { Some(match *i.kind { clean::TypeAliasItem(..) => { let mut stripper = NonLocalStripper { tcx: self.tcx }; // don't call `fold_item` as that could strip the type-alias it-self // which we don't want to strip out stripper.fold_item_recur(i) } _ => self.fold_item_recur(i), }) } } struct NonLocalStripper<'tcx> { tcx: TyCtxt<'tcx>, } impl<'tcx> DocFolder for NonLocalStripper<'tcx> { fn fold_item(&mut self, i: Item) -> Option<Item> { // If not local, we want to respect the original visibility of // the field and not the one given by the user for the currrent crate. // // FIXME(#125009): Not-local should probably consider same Cargo workspace if !i.def_id().map_or(true, |did| did.is_local()) { if i.visibility(self.tcx) != Some(Visibility::Public) || i.is_doc_hidden() { return Some(strip_item(i)); } } Some(self.fold_item_recur(i)) } } </ins>

Related discussion:
text: I tried this code: with and . I expected to see this happen: No internal fields of the should be displayed as users won't be able to use the fields, making their appearance confusing and useless. Instead, this happened: The internal fields of the are displayed ! Real impact as can be seen . : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
labels +T-rustdoc +A-rustdoc-ui -needs-triage claim
Dupe of and more discussion there
Code change:
<ins> use rustc_middle::ty::TyCtxt; use rustc_middle::ty::Visibility; use crate::clean; use crate::clean::Item; use crate::core::DocContext; use crate::fold::{strip_item, DocFolder}; use crate::passes::Pass; pub(crate) const STRIP_ALIASED_NON_LOCAL: Pass = Pass { name: "strip-aliased-non-local", run: strip_aliased_non_local, description: "strips all non-local private aliased items from the output", }; fn strip_aliased_non_local(krate: clean::Crate, cx: &mut DocContext<'_>) -> clean::Crate { let mut stripper = AliasedNonLocalStripper { tcx: cx.tcx }; stripper.fold_crate(krate) } struct AliasedNonLocalStripper<'tcx> { tcx: TyCtxt<'tcx>, } impl<'tcx> DocFolder for AliasedNonLocalStripper<'tcx> { fn fold_item(&mut self, i: Item) -> Option<Item> { Some(match *i.kind { clean::TypeAliasItem(..) => { let mut stripper = NonLocalStripper { tcx: self.tcx }; // don't call `fold_item` as that could strip the type-alias it-self // which we don't want to strip out stripper.fold_item_recur(i) } _ => self.fold_item_recur(i), }) } } struct NonLocalStripper<'tcx> { tcx: TyCtxt<'tcx>, } impl<'tcx> DocFolder for NonLocalStripper<'tcx> { fn fold_item(&mut self, i: Item) -> Option<Item> { // If not local, we want to respect the original visibility of // the field and not the one given by the user for the currrent crate. // // FIXME(#125009): Not-local should probably consider same Cargo workspace if !i.def_id().map_or(true, |did| did.is_local()) { if i.visibility(self.tcx) != Some(Visibility::Public) || i.is_doc_hidden() { return Some(strip_item(i)); } } Some(self.fold_item_recur(i)) } } </ins>

Related discussion:
text: Using to document private types of the current workspace exposes external types private implementation details (in this case private fields). I would expect the expansion to limit itself to public fields. e.g. gives ! <details<summary<coderustc --version --verbose</code</summary<p</p</detailsr?
I suppose it's "ok" since you used the option. I'll add it to the next rustdoc team meeting agenda to be confirmed by the team.
Rendered output for anyone wondering: !
I'll summarize the exchange I had with Guillaume on matrix. First, the flag I'm talking about is the one you provide to . does not blindly pass the flag to but only for crates you own in your current workspace. That means that when documenting your workspace with . Private items, fields of your crates are shown contrary to your dependencies. Regarding design, it seems weird to me that aliased type expansion shows private implementation details of dependencies (e.g. for the given example). I would personally expect something like:
Code change:
pub fn install_ctrlc_handler() { #[cfg(not(target_family = "wasm"))] ctrlc::set_handler(move || { <del> // Indicate that we have been signaled to stop. If we were already signaled, exit // immediately. In our interpreter loop we try to consult this value often, but if for // whatever reason we don't get to that check or the cleanup we do upon finding that // this bool has become true takes a long time, the exit here will promptly exit the // process on the second Ctrl-C. if CTRL_C_RECEIVED.swap(true, Ordering::Relaxed) { std::process::exit(1); } </del> <ins> // Indicate that we have been signaled to stop, then give the rest of the compiler a bit of // time to check CTRL_C_RECEIVED and run its own shutdown logic, but after a short amount // of time exit the process. This sleep+exit ensures that even if nobody is checking // CTRL_C_RECEIVED, the compiler exits reasonably promptly. CTRL_C_RECEIVED.store(true, Ordering::Relaxed); std::thread::sleep(Duration::from_millis(100)); std::process::exit(1); </ins> }) .expect("Unable to install ctrlc handler"); }

Related discussion:
text: Sometimes when things go really wrong the compiler emits a ton of error messages. This can actually take a while to render them all. And since somewhat recently, hitting Ctrl-C no longer interrupts that, I get a thousand error messages displayed after Ctrl-C. I suspect this may have to do with The Ctrl-C handler does nothing at all on the first Ctrl-C unless the compiler is in the middle of const-eval. Cc
Do you have a reproducer? I have not run into this myself. The implementation should also ensure that the compiler exits promptly if you hit ctrl+c again. Does it?
if stuff keeps going on ctrl+c, sometimes suspending the process (ctrl+z) and then killing the terminal does the trick somehow :sweat_smile:
Unfortunately no, I encountered this during some rustc hacking where I ended up getting well over 1k error messages in the standard library build and that turned out to be hard to cancel. I thought I had tried that, but I am not entirely sure.
Is it possible the shell is part of the problem? If, by the time you hit ctrl-c, it's working through a large amount of output it still has buffered then it might be awhile before you see a response.
It's possible, sure -- but usually it reacts to Ctrl-C immediately even when there's tons of output.
Have you tried reverting to check if that fixes it?
No. At the time I was busy getting a PR done and now I don't have a reproducing example any more.
only checks for ctrl-c during const eval, so if no const eval runs for an extended period of time, the ctrl-c will be silently ignored. This is not the only problem with that PR. It also caused , and shows the "compilation was interrupted" error after the prompt is already drawn by bash.
is there a good way to make rustc loop endlessly without ever touching const eval? maybe via the trait solver? :thinking: it would help for debugging this.
Yeah, just take any issue (none are anyway). I can reproduce this issue with for example: nightly-2024-03-26 (before ): Exits after a single ^C nightly-2024-03-27 (after ): Requires ^C^C to exit bjorn3's analysis checks out.
cool!
Code change:
pub fn install_ctrlc_handler() { #[cfg(not(target_family = "wasm"))] ctrlc::set_handler(move || { <del> // Indicate that we have been signaled to stop. If we were already signaled, exit // immediately. In our interpreter loop we try to consult this value often, but if for // whatever reason we don't get to that check or the cleanup we do upon finding that // this bool has become true takes a long time, the exit here will promptly exit the // process on the second Ctrl-C. if CTRL_C_RECEIVED.swap(true, Ordering::Relaxed) { std::process::exit(1); } </del> <ins> // Indicate that we have been signaled to stop, then give the rest of the compiler a bit of // time to check CTRL_C_RECEIVED and run its own shutdown logic, but after a short amount // of time exit the process. This sleep+exit ensures that even if nobody is checking // CTRL_C_RECEIVED, the compiler exits reasonably promptly. CTRL_C_RECEIVED.store(true, Ordering::Relaxed); std::thread::sleep(Duration::from_millis(100)); std::process::exit(1); </ins> }) .expect("Unable to install ctrlc handler"); }

Related discussion:
text: I wasn't sure how much of the compiler's code flowed through const-eval, is why I asked.
Another case where this is observed: IMO we should revert or at least make the signal handler run after a short timeout.
I'll post a PR that adds a timeout later today, but by all means if you feel strongly just put up a PR. The initial handler here was just through the normal PR process, there's no reason to be more cautious on reverting or modifying it.
Code change:
use std::c_str::ToCStr; use std::cast; <ins> use std::hashmap::{HashMap, HashSet}; </ins> use std::cmp; use std::io; use std::os::consts::{macos, freebsd, linux, android, win32};

Related discussion:
text: Built glfw-rs using rust 0.10-pre. When referencing this crate in another source file and building, I get error: internal compiler error: unexpected failure This message reflects a bug in the Rust compiler. We would appreciate a bug report: note: the compiler hit an unexpected failure path. this is a bug Ok(task 'rustc' failed at 'assertion failed: ()', ) This is on OSX 10.9: rustc 0.10-pre ( 2014-02-18 10:16:48 -0800) host: x8664-apple-darwin
This means that you've got two versions of the same lying around, and doesn't like having two versions. This will be fixed by , I just need to land it :(
I have just build the library for the first time, and I can only find one dylib for it on my system (next to the rlib, but I gues that shouldn't cause any problems). Is there another possibility for this error? Gesendet: Mittwoch, 19. Februar 2014 um 01:09 UhrVon: "Alex Crichton" : mozilla/rust hhildebr : Re: [rust] Compiler error when referencing crate "glfw-rs" () This means that you've got two versions of the same libglfw- lying around, and rustc doesn't like having two versions. This will be fixed by , I just need to land it :( — Reply to this email directly or view it on GitHub.
my reading of is that having a dylib and an rlib simultaneously is a problem.
Having a dylib and an rlib simultaneously should not be a problem, it is in fact quite common. Having 2 dylibs and 1 rlib or 2 rlibs and 1 dylib however is a problem.
sorry, my mistake in parsing the title of .
Yes, indeed, I had several identical dylibs, but it wasn't the glfw-rs.. there were rust libs in /usr/local/lib and /usr/local/lib/rustlib/... Thanks! Gesendet: Mittwoch, 19.
Code change:
use std::c_str::ToCStr; use std::cast; <ins> use std::hashmap::{HashMap, HashSet}; </ins> use std::cmp; use std::io; use std::os::consts::{macos, freebsd, linux, android, win32};

Related discussion:
text: Februar 2014 um 17:15 UhrVon: "Alex Crichton" : mozilla/rust hhildebr : Re: [rust] Compiler error when referencing crate "glfw-rs" () Having a dylib and an rlib simultaneously should not be a problem, it is in fact quite common. Having 2 dylibs and 1 rlib or 2 rlibs and 1 dylib however is a problem. — Reply to this email directly or view it on GitHub.
so can we close this ticket now, in that case? Or do you want to wait for alexcrichton's patches to land, and see what things look like for you then?
Nono, the ticket can be closed for now. Thanks for your help! Gesendet: Mittwoch, 19. Februar 2014 um 21:30 UhrVon: "Felix S Klock II" : mozilla/rust hhildebr : Re: [rust] Compiler error when referencing crate "glfw-rs" () so can we close this ticket now, in that case? Or do you want to wait for alexcrichton's patches to land, and see what things look like for you then? — Reply to this email directly or view it on GitHub.
Code change:
<ins> error: macro-expanded `extern crate` items cannot shadow names passed with `--extern` --> $DIR/issue-109148.rs:6:9 | LL |         extern crate core as std; |         ^^^^^^^^^^^^^^^^^^^^^^^^^ ... LL | m!(); | ---- in this macro invocation | = note: this error originates in the macro `m` (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to previous error </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. --: <!-- 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 --
claim
label +S-bug-has-mcve
I'm having trouble understanding this ICE. Could someone point me in the right direction? Thanks for your help!
release-assignment I'm finding this quite hard. For anyone else: I suspect is responsible.
Code change:
use syntax::source_map::Span; use super::{ <del> FnVal, GlobalId, ImmTy, InterpCx, InterpResult, MPlaceTy, Machine, OpTy, PlaceTy, StackPopCleanup, </del> <ins> FnVal, ImmTy, InterpCx, InterpResult, MPlaceTy, Machine, OpTy, PlaceTy, StackPopCleanup, </ins> }; impl<'mir, 'tcx, M: Machine<'mir, 'tcx>> InterpCx<'mir, 'tcx, M> {

Related discussion:
text: Follow-up to agreed to move to . Generally I propose that should not contain code that is only needed by CTFE. We have and in there are they need some very deep access to Miri engine internals, but at least those are separate modules. Also, has grown pretty messy, and it does not seem like the order of definitions in that file follows any principle. We could split the file into two similar to what I did with Miri: for implementing the machine trait and defining everything that is needed during CTFE execution, and for defining the setup functions and all the glue that connects CTFE with the rest of the compiler.
Code change:
self_ty: Ty<'tcx>, sig: ty::PolyGenSig<'tcx>, ) -> ty::Binder<'tcx, (ty::TraitRef<'tcx>, Ty<'tcx>)> { <del> debug_assert!(!self_ty.has_escaping_bound_vars()); </del> <ins> assert!(!self_ty.has_escaping_bound_vars()); </ins> let trait_ref = tcx.mk_trait_ref(fn_trait_def_id, [self_ty]); sig.map_bound(|sig| (trait_ref, sig.return_ty)) }

Related discussion:
text: An there actually does panic for the test. I only moved this code between the files, the same comment and code pattern exists as well for normal closures: Originally posted by in
I couldn't repro this failure, maybe was doing instead of ? The ordering is important here.
I believe I did, yes.
Code change:
} <del> #[cfg(test)] mod bench; </del> <ins> #[cfg(test)] #[macro_use] mod bench; </ins> // FIXME(#14344) this shouldn't be necessary #[doc(hidden)]

Related discussion:
text: the closure being passed into in BTreeMap and VecMap's benches has a trailing semi-colon making the return value , and thus making the entire operation a no-op. Removing the semi-colon causes lifetime conflict issues. CC
I have a branch that just gives up and replaces these with macros. This results in clearer and more concise code like . Confirmed produces sane results in benchmark output. Hope to submit something tomorrow.
Code change:
<ins> // Regression test for https://github.com/rust-lang/rust/issues/43134 // check-pass // compile-flags: --cap-lints allow type Foo<T: Clone> = Option<T>; fn main() {} </ins>

Related discussion:
text: Test case: With rustc 1.20.0-nightly ( 2017-07-06), output when compiling with : correctly stops the dead code / unused type alias warning from being shown, but the trait bounds not enforced warning is shown anyway. Per and , this might be on purpose. I think this is the wrong decision. The point of is to allow Cargo to inhibit warnings in external dependencies. When building Servo it is not useful to spam the console with many warnings, future-proofing or not, about code that Servo has not direct control over. CC
Nominating for discussion. Not sure if compiler team or lang team is best, though, so tagging both...
From the lang team's point of view: definitely a bug.
Couple of bugs here: First off, we should not be ignoring the bounds in types. And sometimes they are needed. I'd like to fix this by not ignoring them, but I worry about the backcompat issues. Unknown risk there. Second, if we must warn, we should be emitting a regular lint that can be silenced. Plausibly, we should just remove the warning (eliminating the immediate problem), and prioritize trying to do a proper fix here.
Somewhat related to not ignoring bounds (but in the other direction): .
After some discussion in compiler team, decided to move this to a "future compatibility" lint, one that we will hopefully make more precise over time. Right now the check is not very good. At least this means you won't have to see it. We need some mentoring instructions though!
Some tips here:
triage: P-medium
I've hit this recently. It seems like it is possible to write code that requires exactly this bound. So it is quite bad that we cannot suppress this warning. Example code:
Agreed, this is poor. There just hasn't been a lot of energy to try and improve the situation.
Fixed in , probably by We should add a regression test for this particular case before we close this issue however, since I don't think the test in the PR detects a regression for the problem described in this issue. The problem in this issue is output on stderr, not that compilation fails ( exit code is 0 both with and without the fix in the PR). label E-needs-test
Code change:
fn parse_crate_mod(&mut self) -> Result<ast::Crate, ParserError> { let mut parser = AssertUnwindSafe(&mut self.parser); <del> match catch_unwind(move || parser.parse_crate_mod()) { Ok(Ok(k)) => Ok(k), Ok(Err(db)) => { </del> <ins> // rustfmt doesn't use `run_compiler` like other tools, so it must emit // any stashed diagnostics itself, otherwise the `DiagCtxt` will assert // when dropped. The final result here combines the parsing result and // the `emit_stashed_diagnostics` result. let parse_res = catch_unwind(move || parser.parse_crate_mod()); let stashed_res = self.parser.dcx().emit_stashed_diagnostics(); let err = Err(ParserError::ParsePanicError); match (parse_res, stashed_res) { (Ok(Ok(k)), None) => Ok(k), (Ok(Ok(_)), Some(_guar)) => err, (Ok(Err(db)), _) => { </ins> db.emit(); <del> Err(ParserError::ParseError) </del> <ins> err </ins> } <del> Err(_) => Err(ParserError::ParsePanicError), </del> <ins> (Err(_), _) => err, </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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I suspect this is related to cc
tests/ui/suggestions/unnamable-
Very likely. I'll take a look soon.
For the record: it was that caused this.