Change:
<!-- 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.

Discussion:
let fallback_locale = langid!("en-US"); let requested_fallback_locale = requested_locale.as_ref() == Some(&fallback_locale); <ins> trace!(?requested_fallback_locale); if requested_fallback_locale && additional_ftl_path.is_none() { return Ok(None); } </ins> // If there is only `-Z additional-ftl-path`, assume locale is "en-US", otherwise use user // provided locale. let locale = requested_locale.clone().unwrap_or(fallback_locale);

bundle.set_use_isolating(with_directionality_markers); // If the user requests the default locale then don't try to load anything. <del> if !requested_fallback_locale && let Some(requested_locale) = requested_locale { </del> <ins> if let Some(requested_locale) = requested_locale { </ins> let mut found_resources = false; for sysroot in user_provided_sysroot.iter_mut().chain(sysroot_candidates.iter_mut()) { sysroot.push("share");

<del> use crate::error::TranslateError; </del> <ins> use crate::error::{TranslateError, TranslateErrorKind}; </ins> use crate::snippet::Style; use crate::{DiagnosticArg, DiagnosticMessage, FluentBundle}; use rustc_data_structures::sync::Lrc;

// 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

do yeet primary } <del> // 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 or // something else went wrong) so proceed to the fallback bundle. </del> <ins> // ..otherwise, for end users, an error about this wouldn't be useful or actionable, so // just hide it and try with the fallback bundle. </ins> Some(Err(primary)) => translate_with_bundle(self.fallback_fluent_bundle()) .map_err(|fallback| primary.and(fallback))?,

<ins> // compile-flags:-Ztranslate-lang=en_US #![feature(negative_impls)] #![feature(marker_trait_attr)] #[marker] trait MyTrait {} struct TestType<T>(::std::marker::PhantomData<T>); unsafe impl<T: MyTrait + 'static> Send for TestType<T> {} impl<T: MyTrait> !Send for TestType<T> {} //~ ERROR found both positive and negative implementation unsafe impl<T: 'static> Send for TestType<T> {} //~ ERROR conflicting implementations impl !Send for TestType<i32> {} fn main() {} </ins>

<ins> error[E0751]: found both positive and negative implementation of trait `Send` for type `TestType<_>`: --> $DIR/issue-106755.rs:13:1 | LL | unsafe impl<T: MyTrait + 'static> Send for TestType<T> {} | ------------------------------------------------------ positive implementation here LL | LL | impl<T: MyTrait> !Send for TestType<T> {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ negative implementation here error[E0119]: conflicting implementations of trait `Send` for type `TestType<_>` --> $DIR/issue-106755.rs:15:1 | LL | unsafe impl<T: MyTrait + 'static> Send for TestType<T> {} | ------------------------------------------------------ first implementation here ... LL | unsafe impl<T: 'static> Send for TestType<T> {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `TestType<_>` error: aborting due to 2 previous errors Some errors have detailed explanations: E0119, E0751. For more information about an error, try `rustc --explain E0119`. </ins>