Question: panic_unwind = { path = "../panic_unwind", optional = true } panic_abort = { path = "../panic_abort" } core = { path = "../core", public = true } <del> compiler_builtins = { version = "0.1.114" } </del> <ins> compiler_builtins = { version = "0.1.117" } </ins> profiler_builtins = { path = "../profiler_builtins", optional = true } unwind = { path = "../unwind" } hashbrown = { version = "0.14", default-features = false, features = [

I do not have minimised code. This was a sudden CI build failure on nightly for aarch64-unknown-linux-musl () Note that this is a cross compile using cross-rs. It fails on rust version 1.82.0-nightly ( 2024-07-29) but works on 1.82.0-nightly ( 2024-07-28). Needless to say it also works perfectly fine on stable. The error is reproducible on rebuild and locally with cross-rs. It is not reproducible with cargo-zigbuild interestingly enough. I also checked that the version of cross-rs didn't change between the successful and failing builds (no new releases of that project since february). The only change between the successful and failing CI runs were a typo fix to an unrelated CI pipeline (the release one, so it didn't even run yet). As such I'm forced to conclude that the blame lies with Rustc. Steps to reproduce: I expected to see this happen: Compilation successful (as it is with stable for same target, or with -gnu and nightly) Instead, this happened () It most recently worked on: 1.82.0-nightly ( 2024-07-28) (or stable 1.80.0 or beta 1.81.0, take your pick for triaging) :
cc (of cross-rs fame) in case he has any insight on this regression
I have hit the same issue in a similar situation. Cross compiling to aarch64-unknown-linux-musl from x86_64 linux in a Github CI pipeline using cross-rs. Link to pipeline failing logs:
Seems rune isn't needed based on the comment by Updated the title.
This is probably
WG-prioritization assigning priority (). label -I-prioritize +P-high
Yeah that's probably it. We used to build the C version of those symbols but switched to Rust versions with the compiler builtins update. Unfortunately we can't enable them on all platforms because LLVM has crashes, and the logic that would allow optional configuration is apparently not working.


Question: panic_unwind = { path = "../panic_unwind", optional = true } panic_abort = { path = "../panic_abort" } core = { path = "../core", public = true } <del> compiler_builtins = { version = "0.1.114" } </del> <ins> compiler_builtins = { version = "0.1.117" } </ins> profiler_builtins = { path = "../profiler_builtins", optional = true } unwind = { path = "../unwind" } hashbrown = { version = "0.14", default-features = false, features = [

After that part is fixed, we will need to enable the symbols on all platforms where is f128 (which includes aarch64), since these errors probably come from here I think anyone who needs a quick workaround can add to their dependencies to get the symbols directly, as described near the top of Note that this requires nightly.
Is it possible to add a dependency conditionally based on if it is nightly? (In a specific range of dates even?) I cannot and will not depend on nightly, but I do test my code on nightly in CI (in order to find breakages like this early). For now I just disabled that nightly build on aarch64 musl.
Same for me. Not using cross-rs though. Logs are here:
Same for me, both using as host toolchain and cross compiling.
Looks like it is happening now too for x86_64.
Not for my projects, so you should probably provide a reproducer on x86-64 GNU if possible, since that is a tier 1 platform (unlike Aarch64 on Musl). Or is this about some other x8664 variation that is also tier 2?
Woops, sorry, the x86_64 build failed too, but then i looked at the aarch64 build logs :) which still fail.


Question: <ins> #![feature(auto_traits)] auto trait AutoTrait {} // You cannot impl your own `dyn AutoTrait`. impl dyn AutoTrait {} //~ERROR E0785 // You cannot impl someone else's `dyn AutoTrait` impl dyn Unpin {} //~ERROR E0785 fn main() {} </ins>

Given the following code (): The current output is: This is rather confusing. It's not immediately clear what the difference between and this working code is (): Since is accepted, the user might be confused why would be considered a nominal type when isn't. The real reason why is an error is because it is an block for . Ideally the output should look like:
It seems like this only happens with auto traits. Regular traits already emit E0116 in this case (): Note that this still happens with auto traits in the same crate, but in this case wouldn't be applicable (): The diagnostic is still confusing in this case and could be rewritten to explicitly point out that is not allowed. modify labels: +D-confusing +F-auto_traits


Question: .push(PathSegment { name: last_segment.name, args: new_params }); bounds.insert(GenericBound::TraitBound( <del> PolyTrait { trait_: new_path, generic_params: poly_trait.generic_params }, </del> <ins> PolyTrait { trait_: new_path, generic_params: poly_trait.generic_params.clone(), }, </ins> hir::TraitBoundModifier::None, )); }

No crash in stable 1.62.1, crashes with nightly 2022-07-24 and 2022-08-03 : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
label -E-needs-mcve
Was this at least on a project you can share the source to, or was it closed source? If it's a big project that you can't minimise, then it would be good to share/link to that, so someone else can do the minimisation. an example is better than no example, even if it's not minimal.
Managed to find something. The bound seems crucially important.
searched nightlies: from nightly-2022-01-01 to nightly-2022-08-02 regressed nightly: nightly-2022-06-23 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsLooks like


Question: .map(|i| from_item_id_with_name(i.item_id, tcx, i.name)) .collect() } <ins> fn ids_keeping_stripped( items: impl IntoIterator<Item = clean::Item>, tcx: TyCtxt<'_>, ) -> Vec<Option<Id>> { items .into_iter() .map(|i| { if !i.is_stripped() && !i.is_keyword() { Some(from_item_id_with_name(i.item_id, tcx, i.name)) } else { None } }) .collect() } </ins>

At some point their should also be a for , and probably a way to tell what position each of the non stripped items are, as currently each of these 3 variants are documented with the same inner. but HTML gets a good representation:  The solution is probably to do what we do for structs, and store the , and a , such that each field of a varient gets an to hold the . We also should have a numfields, as even in that schema, you can't tell the difference between This also effects struct AFAIKT. I don't think this needs to be done now. I'll file an issue for it. Originally posted by in modify labels: +A-rustdoc-json +T-rustdoc
Related:


Question: #[derive(SmartPointer)] //~ ERROR use of unstable library feature 'derive_smart_pointer' #[repr(transparent)] struct MyPointer<'a, #[pointee] T: ?Sized> { <del> //~^ ERROR the `#[pointee]` attribute is an experimental feature </del> ptr: &'a T, }

https://crater- https://crater- cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
label F-derivesmartpointer
Thread on zulip: https://rust-
claim
WG-prioritization assigning priority (). label -I-prioritize +P-high


Question: ... LL |     arg.wait(); |         ^^^^ <del> | help: another candidate was found in the following trait, perhaps add a `use` for it: | LL | use private::Future; | </del> error: aborting due to previous error

Issues with this diagnostic: method is not being invoked on a trait object; it's invoked on the concrete value . note suggests importing the same trait that is already being reported about.
/cc also looks relevant based on the title, but appears to have a different enough error message.
Is the following output from enough?
I don't feel like it's at the usual amazing quality . My points still appear to exist: In some magical world, I might hope for something like this (and I'm very flexible in that): I tried to address my points via the s.


Question: <ins> // check-pass // aux-build:test-macros.rs // compile-flags: -Z span-debug #![no_std] // Don't load unnecessary hygiene information from std extern crate std; extern crate test_macros; #[test_macros::print_attr] fn foo<T>() where T: Copy + { } fn main() {} </ins>

The following code: is currently pretty-printed as: If this occurs in a macro invocation, it leads to an instance of
Extra info (but it boils down to what said): Using I get the following log: Rendered diff:
This applies to all trailing separators in theory (except that the separator is leading rather than trailing in this case), but in other cases the difference is fixed up by fuzzy comparison in .


Question: } alloc0 (static: FOO, size: 4, align: 4) { <del> ╾─alloc3──╼                                     │ ╾──╼ </del> <ins> ╾─alloc9──╼                                     │ ╾──╼ </ins> } <del> alloc3 (size: 168, align: 1) { </del> <ins> alloc9 (size: 168, align: 1) { </ins> 0x00 │ ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab │ ................ 0x10 │ ab ab ab ab ab ab ab ab ab ab ab ab ╾─alloc4──╼ │ ............╾──╼ 0x20 │ 01 ef cd ab 00 00 00 00 00 00 00 00 00 00 00 00 │ ................

This little matrix processing code shows miscompilation if compiled with: But it compiles correctly with: With:
Hmm, on first glance the replacement it performs looks correct: It replaces local () with the return place . Previously the return place was only used in the block by a copy statement, so this transformation should be correct. Maybe this part of the diff causes a problem? We're using our return place as the return destination for the inner call. It's possible that there's an undocumented (and maybe unintended) assumption that the return place is not reused like this, either in other MIR optimizations or in codegen. Haven't looked too deeply yet though.
Ah, there's this bad call in LLVM IR: It passes a reference to as both the return pointer, and the second (immutable) argument.
we have this corresponding MIR, where we already incorrectly pass a reference to as an argument, while also assigning the call result to it: The destination propagation pass already has code that prevents merging a call destination with one of the arguments, but here we pass a reference instead. Curiously, the was produced by merging with , which is not really something the pass should be doing since a reference is taken to , and we avoid touching any local that has its address taken.
The propagation is disabled only if both locals have their address taken. Changing that to be more conservative does fix this issue. Minimized:
Oof, this should have been an , not an
Thanks
Opened with a fix


Question: for _ in 0..sz_a - self.len { self.a.next_back(); } <ins> self.a_len = self.len; </ins> } let sz_b = self.b.size(); if B::MAY_HAVE_SIDE_EFFECT && sz_b > self.len {

Here is called for potential side effects until , ignoring however that it could have already been called in with those indexes. that demonstrates how this can be exploited to get two mutable references to the same data and cause an use-after-free bug.
Assigning as part of the .
The gift that keeps on giving Maybe it is time to get rid of as it exists today and replace it with a ? One that imposes the additional requirement on the caller that it must bring the iterator back into a safe state after it is done iterating. The upside would be eliminating a lot of code in and enabling the same optimization for and similar sources. While the downside would be that external iteration (i.e. loops and manual calls to ) would cease to benefit from optimizations and only internal iteration methods (including ) would continue to do so.
I don't know, I feel like that would just make more complex to upheld the invariants. IMO a good improvement over the current would be separating forward and backward iteration, this way it becomes easier to keep track of the state and I think would also make it possible to implement them for
I don't see how separating the forward and backward state would help with a drop implementation. The issue is that the source () currently does not have access to that state, instead the consumer drives the iteration by direct access through and never informs the source about it.
It would help because it allows the source iterator to keep track of its state by updating it when the method is called. Anyway, looks like someone already and it resulted in worse optimizations, but maybe LLVM got better in the meantime, or maybe that implementation could have been better. Anyway I don't think this is the right place to discuss this, a topic on zulip would probably be better.
https://rust-


Question: /// /// This is required because we may still want to run MIR passes on an item /// with type errors, but normal MIR construction can't handle that in general. <del> fn construct_error(tcx: TyCtxt<'_>, def: LocalDefId, err: ErrorGuaranteed) -> Body<'_> { let span = tcx.def_span(def); let hir_id = tcx.hir().local_def_id_to_hir_id(def); let coroutine_kind = tcx.coroutine_kind(def); let body_owner_kind = tcx.hir().body_owner_kind(def); let ty = Ty::new_error(tcx, err); let num_params = match body_owner_kind { hir::BodyOwnerKind::Fn => tcx.fn_sig(def).skip_binder().inputs().skip_binder().len(), hir::BodyOwnerKind::Closure => { let ty = tcx.type_of(def).instantiate_identity(); match ty.kind() { ty::Closure(_, args) => 1 + args.as_closure().sig().inputs().skip_binder().len(), ty::Coroutine(..) => 2, _ => bug!("expected closure or coroutine, found {ty:?}"), } </del> <ins> fn construct_error(tcx: TyCtxt<'_>, def_id: LocalDefId, guar: ErrorGuaranteed) -> Body<'_> { let span = tcx.def_span(def_id); let hir_id = tcx.hir().local_def_id_to_hir_id(def_id); let coroutine_kind = tcx.coroutine_kind(def_id); let (inputs, output, yield_ty) = match tcx.def_kind(def_id) { DefKind::Const | DefKind::AssocConst | DefKind::AnonConst | DefKind::InlineConst | DefKind::Static(_) => (vec![], tcx.type_of(def_id).instantiate_identity(), None), DefKind::Ctor(..) | DefKind::Fn | DefKind::AssocFn => { let sig = tcx.liberate_late_bound_regions( def_id.to_def_id(), tcx.fn_sig(def_id).instantiate_identity(), ); (sig.inputs().to_vec(), sig.output(), None) } DefKind::Closure => { let closure_ty = tcx.type_of(def_id).instantiate_identity(); let ty::Closure(_, args) = closure_ty.kind() else { bug!() }; let args = args.as_closure(); let sig = tcx.liberate_late_bound_regions(def_id.to_def_id(), args.sig()); let self_ty = match args.kind() { ty::ClosureKind::Fn => Ty::new_imm_ref(tcx, tcx.lifetimes.re_erased, closure_ty), ty::ClosureKind::FnMut => Ty::new_mut_ref(tcx, tcx.lifetimes.re_erased, closure_ty), ty::ClosureKind::FnOnce => closure_ty, }; ([self_ty].into_iter().chain(sig.inputs().to_vec()).collect(), sig.output(), None) } DefKind::Coroutine => { let coroutine_ty = tcx.type_of(def_id).instantiate_identity(); let ty::Coroutine(_, args, _) = coroutine_ty.kind() else { bug!() }; let args = args.as_coroutine(); let yield_ty = args.yield_ty(); let return_ty = args.return_ty(); let self_ty = Ty::new_adt( tcx, tcx.adt_def(tcx.lang_items().pin_type().unwrap()), tcx.mk_args(&[Ty::new_mut_ref(tcx, tcx.lifetimes.re_erased, coroutine_ty).into()]), ); let coroutine_state = Ty::new_adt( tcx, tcx.adt_def(tcx.lang_items().coroutine_state().unwrap()), tcx.mk_args(&[yield_ty.into(), return_ty.into()]), ); (vec![self_ty, args.resume_ty()], coroutine_state, Some(yield_ty)) </ins> } <del> hir::BodyOwnerKind::Const { .. } => 0, hir::BodyOwnerKind::Static(_) => 0, </del> <ins> dk => bug!("{:?} is not a body: {:?}", def_id, dk), </ins> }; <ins> let source_info = SourceInfo { span, scope: OUTERMOST_SOURCE_SCOPE }; let local_decls = IndexVec::from_iter( [output].iter().chain(&inputs).map(|ty| LocalDecl::with_source_info(*ty, source_info)), ); </ins> let mut cfg = CFG { basic_blocks: IndexVec::new() }; let mut source_scopes = IndexVec::new(); <del> let mut local_decls = IndexVec::from_elem_n(LocalDecl::new(ty, span), 1); </del> cfg.start_new_block(); source_scopes.push(SourceScopeData {

<!-- 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 (): Somehow in the second case we think that is unconstrained even though it doesn't seem to contain more or less type information than the first case. Note also that this does not error if I use RPIT instead.
I think in the second example mir building doesn't generate code for the trailing expression because it's statically known as dead code. But I thought we were keeping around the typeck types nowadays, and typeck should be the same for both functions
I don't think that's it, same error if I put the match in a branch ():
In fact this doesn't need an empty type at all:
I think we're generating bogus MIR or THIR because of that empty match -- Are you sure the bug doesn't exist on the THIR/MIR building side, (hacked to dump the instead of )
Oh I'm sure of nothing I just assumed an unreachable in a branch would not affect anything else
So: If there's a match error, we end up constructing a failure MIR body. This will prevent us from inferring the opaque later on. edit: that last sentence was a lie Let me see if I can cook up a quick fix.


Question: if !fail { return None; } <del> bug!("unexpected const parent path def {:?}", x); </del> <ins> tcx.sess.delay_span_bug( DUMMY_SP, &format!( "unexpected const parent path def {:?}", x ), ); tcx.types.err </ins> } } }

Following code sample causes a compiler panic. should be .
Also happens on nightly. Likely due to const generics changes (cc
Minimal reproduction:
Another case:


Question: &mut self, radix: u32, max_digits: Option<usize>, <ins> allow_zero_prefix: bool, </ins> ) -> Option<T> { self.read_atomically(move |p| { let mut result = T::ZERO; let mut digit_count = 0; <ins> let has_leading_zero = p.peek_char() == Some('0'); </ins> while let Some(digit) = p.read_atomically(|p| p.read_char()?.to_digit(radix)) { result = result.checked_mul(radix)?;

According to the , "The four octets are in decimal notation, divided by . (this is called 'dot-decimal notation'). Notably, octal numbers and hexadecimal numbers are not allowed per IETF RFC 6943"; however the parsing of the violates the "strict" form mentioned in —this form is what prohibits octal and hexadecimal numbers—meanwhile the conforms to it. IETF RFC 6943 Section 3.1.1. states: If the af argument of inetpton() is AFINET, the src string shall be in the standard IPv4 dotted-decimal form: where "ddd" is a one to three digit decimal number between 0 and The inetpton() function does not accept other formats (such as the octal numbers, hexadecimal numbers, and fewer than four numbers that inetaddr() accepts). As shown above, inetpton() uses what we will refer to as the "strict" form of an IPv4 address literal. Some platforms also use the strict form with getaddrinfo() when the AINUMERICHOST flag is passed to it. I tried this code: I expected to see this happen: both s not causing a panic since the first has an octet represented by more than three base-10 numbers despite the requirement per RFC 6943 stating each octet be a "one to three digit decimal number". The second is valid per RFC 6943 since it is a string of exactly 4 octets separated by where each octet is a "one to three digit decimal number". Instead, this happened: Both lines cause a panic. : : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
I believe that the second input () is not valid, since the spec explicitly says that octal numbers are disallowed, and is an octal number in the loose form. The example in the RFC for an octal number is , which parses to if you use octal, but if you use decimal. If you instead have it parse it always as , that means that bad things can happen, such as different tools interpreting as different things.


Question: &mut self, radix: u32, max_digits: Option<usize>, <ins> allow_zero_prefix: bool, </ins> ) -> Option<T> { self.read_atomically(move |p| { let mut result = T::ZERO; let mut digit_count = 0; <ins> let has_leading_zero = p.peek_char() == Some('0'); </ins> while let Some(digit) = p.read_atomically(|p| p.read_char()?.to_digit(radix)) { result = result.checked_mul(radix)?;

If you read the source code where the ipv4 address is parsed, it specifically disallows that: Regarding , the documentation only says that the disallowing of hexadecimal and octal numbers are according to IETF RFC 6943, and does not say anything about only allowing three digits. Also, four or more zeroes are an edge case, and thus the only numbers that can be parsed there with more than three digits, due to the disallowing of octal numbers apart from .
From the :
I'm confused by these comments. Padded zeros is not unique to the base-8 numeral system. Base-2, Base-3, etc. all have the property of having an infinite number of padded zeros with the convention being to truncate them all. After all is also valid in base-8, base-9, etc. The documentation is quite clear that the octets are to be interpreted in base-10 though, so this problem of how to interpret the octets is solved. Consequently the last octet in is interpreted as 1 in base-10 for the same reason the first octet in is interpreted as 127 in base-10 and not some other value (e.g., 87 in base-10) namely because the documentation says so. After all objecting to on the grounds that the last octet could be in base-8—again, all of the octets there could be in base-8—doesn't apply to the fact that is also rejected by the parsing algorithm since clearly each of those octets are not in base-8 since is not a symbol in the base-8 numeral system. This is of course nothing more than a consequence of incorrectly assuming padded 0s means base-8. The inconsistent treatment of 0 (in base-10) is also a consequence of this incorrect assumption. Why is 0 (in base-10) allowed to be represented by one or more s, but 1 (in base-10) cannot have padded s? There is nothing special about the syntactic representation of 0 (in base-10) that warrants this inconsistent treatment. To me the solution is clear: more strictly follow IETF RFC 6943 and enforce that each octet be one-to-three digits in length.


Question: &mut self, radix: u32, max_digits: Option<usize>, <ins> allow_zero_prefix: bool, </ins> ) -> Option<T> { self.read_atomically(move |p| { let mut result = T::ZERO; let mut digit_count = 0; <ins> let has_leading_zero = p.peek_char() == Some('0'); </ins> while let Some(digit) = p.read_atomically(|p| p.read_char()?.to_digit(radix)) { result = result.checked_mul(radix)?;

One could even follow a stricter format and require that there be no padded s at all—since the RFC doesn't actually specify that. This would then lead to consistent behavior (that's also more easily predictable since it follows a well-established convention) in that both and will either be accepted (since they both follow RFC 6943) or rejected (if a stricter form is required that requires the minimal number of digits necessary to represent each octet).
This is not an incorrect assumption, as octal numbers in the loose format are specified by the number having a leading zero. (See for the PR that banned octal numbers) This is an implementation detail in the way that it checks for leading zeroes: it checks if the number starts with a zero and rejects it if the resultant parsed number is not zero.
So we are re-defining how mathematics defines numeral systems? Saying that is in base-8 (i.e., octal) because of the leading makes no sense since none of those symbols except exist in that system. Rust certainly doesn't treat the in base-8 here: . Also the documentation clearly states that each octet is in "decimal notation". Suddenly treating the octet as base-8 is a clear contradiction to the documentation.
Using leading zeros to designate octal literals is a fairly common convention. In other languages like JS and C, . Rust doesn't have that as an octal prefix because it is confusing. When using leading zeros to indicate octal numbers, isn't a valid number at all (in the same way that isn't a valid base-10 number).
So it sounds like the documentation needs to be modified. It is confusing (because it is contradictory to reality) to say that each octet is in decimal notation when the actual implementation requires each octet to be either base-10 or base-8 where the latter is assumed when there are leading s and the value is not 0—at which point any positive-integer amount of s are allowed—and furthermore error when any octet is interpreted as base-8. Seems much easier to both document and comprehend to simply require at most 3 decimal digits for each octet and either forbid leading s (including for the integer 0) or allow leading s (including ).
"The actual implementation" is relevant only insofar as its behavior is externally observable.


Question: &mut self, radix: u32, max_digits: Option<usize>, <ins> allow_zero_prefix: bool, </ins> ) -> Option<T> { self.read_atomically(move |p| { let mut result = T::ZERO; let mut digit_count = 0; <ins> let has_leading_zero = p.peek_char() == Some('0'); </ins> while let Some(digit) = p.read_atomically(|p| p.read_char()?.to_digit(radix)) { result = result.checked_mul(radix)?;

And -- correct me if I'm wrong -- in every case where the function succeeds, it (behaves as if it) interprets all digits in decimal, right? So I'd say it is correct to say that everything is "in decimal notation". The only weird bit is that is accepted, but is not. This is strange, but not in contradiction with saying things are "in decimal notation".
When the documentation says the "four octets are in decimal notation", that is effectively a definition which in turn can be phrased as a logical biconditional. In this case, the logical biconditional I formed in my head was something like: "a will be parsed into an iff it is a sequence of exactly 4 base-10 numbers delimited by a ". Only one of those directions is true: if an is produced from parsing a , then the was a sequence of exactly 4 base-10 numbers delimited by a . The other direction, which is observable via a parsing failure, is not true as can be seen with something like . That is a sequence of exactly 4 base-10 numbers delimited by a , but it leads to a parsing failure. As was discovered in the discussion , it sounds like "decimal notation" as used in the documentation is not what it has meant my entire life nor what it means in a lot of areas in Rust. Specifically, any number that has leading s is not a base-10 number but in fact a base-8 number. With this modified definition of "decimal"; then my counterexample, , is in fact not a counterexample since each of those octets are not in "decimal" notation but in fact base-8. Even more perplexing as stated by is that "a lone 0 is technically octal as well in C, not that it matters" which means the definition of "decimal" used in the documentation is neither the mathematical definition nor the C definition—since something like is successfully parsed despite each of those octets being in base-8 per the C definition.
That's true in C. (Specifically, it is how C converts series of digits to numbers. "Numbers" don't have leading 0s, numbers are elements of the set of integers. The representation of a number as a string of digits can have leading 0s.


Question: &mut self, radix: u32, max_digits: Option<usize>, <ins> allow_zero_prefix: bool, </ins> ) -> Option<T> { self.read_atomically(move |p| { let mut result = T::ZERO; let mut digit_count = 0; <ins> let has_leading_zero = p.peek_char() == Some('0'); </ins> while let Some(digit) = p.read_atomically(|p| p.read_char()?.to_digit(radix)) { result = result.checked_mul(radix)?;

At least that's how I think the term is usually used when one needs to be precise about series of digits vs. the thing they represent.) However, it's not true for this function. Any number that has leading 0s is rejected by this function. This fact about C was brought up only to explain why leading 0s are rejected. No base-8 occurs anywhere in the behavior of this function. If you disagree, please show an input-output pair for this function which demonstrates that base 8 is used. (The code inside the function doesn't matter, of course. Only its observable behavior does.) I really don't understand why you keep insisting that this function has anything to do with base 8. I think it might be because of some quirk in how it is implemented, but unobservable implementation details are irrelevant. As a mathematician you should be even more used to this than most programmers, since the usual way of defining mathematical functions consists entirely of input-output pairs, there is not even such a thing as an "implementation"... but I am digressing. ;) Even mathematically speaking, the sequence of digits "0" represents the same number in any base system. So, in a very precise formal sense, "not that it matters" is accurate. A base is just a way to convert a series of digits into a number, and for series of digits consisting only of 0s, the result is always the same. The definition of "decimal" used in the documentation exactly matches the mathematical definition. The documentation just fails to mention that there is an additional restriction, namely that no leading 0s are accepted (except if all digits of an octet are 0). However, it remains the case that if an input is accepted by this function, then all octets are interpreted as decimal -- and moreover, all decimal representations without leading 0s are accepted by this function.
Saying a definition matches exactly with another definition before subsequently changing the definition by adding other restrictions does not make sense to me. Does the definition of an even integer "match exactly" with the definition of an integer? No. Adding or removing restrictions to a definition changes the definition. So the fact that leading s is not allowed means we are not talking about mathematical base-10.


Question: &mut self, radix: u32, max_digits: Option<usize>, <ins> allow_zero_prefix: bool, </ins> ) -> Option<T> { self.read_atomically(move |p| { let mut result = T::ZERO; let mut digit_count = 0; <ins> let has_leading_zero = p.peek_char() == Some('0'); </ins> while let Some(digit) = p.read_atomically(|p| p.read_char()?.to_digit(radix)) { result = result.checked_mul(radix)?;

If I define a function that takes an integer and it errors any time the integer is not even; however the documentation of that function makes no mention of that seems very problematic. I would not defend such documentation by saying "my definition of integer matches exactly with the definition of the mathematical definition of an integer except I also require the integer to be divisible by 2". My documentation should very clearly define what I mean by "integer", or better, simply state "even integer".
Okay, I guess I should have said that it is strictly a restriction of the mathematical definition (a subset, if you take the graph view of a function). But it doesn't disagree on any inputs where it is defined. Your talking about base 8 makes it sound like sometimes it is not matching the base 10 function even when it does produce a result (but matches the base 8 function instead), and it took a quite a lot of time to realize that is not what happens. Moreover, the subset still contains the full graph of the inverse of the full "base 10" function where you always pick the shortest representation (i.e., the most common "serialization" function of numbers into base 10 representation). So unlike your "even" example it is a pretty reasonable parsing function still. There are only some "non-canonical" representations being rejected.
Well, I think we are talking in circles at this point honestly, lol. While I would agree my example is a more extreme example of documentation failure since conflating the definition of "even integer" with "integer" is more absurd than conflating the definition of "base-10 in the shortest representation (with the exception of 0 which is allowed any non-negative integer amount of leading 0s)" with "base-10", both examples suffer from the fact that additional failures occur than otherwise would occur based on the exact definition of the term that is used (in my example "integer" and in this example "decimal"). For me, as I mentioned in the other discussion, this really is not me being "pedantic". I wrote code based on the documentation that ended being invalid since I (mis-)interpreted "decimal" to be more general than what it actually means in this context.


Question: &mut self, radix: u32, max_digits: Option<usize>, <ins> allow_zero_prefix: bool, </ins> ) -> Option<T> { self.read_atomically(move |p| { let mut result = T::ZERO; let mut digit_count = 0; <ins> let has_leading_zero = p.peek_char() == Some('0'); </ins> while let Some(digit) = p.read_atomically(|p| p.read_char()?.to_digit(radix)) { result = result.checked_mul(radix)?;

Ideally, in my opinion at least, that should not happen especially since it is not that much additional effort to more properly document what certain terms mean even if that means just adding one or two more examples highlighting parsing failures (or successes) that one (like myself) would not expect.
We already agree that the docs need to be improved. :) The rest of this discussion is then mostly philosophical and not going to lead to a productive outcome, so maybe we better stop it. ;)


Question: <ins> // build-pass // force-host // no-prefer-dynamic // aux-build:exports_no_mangle.rs #![crate_type = "proc-macro"] // Issue #111888: this proc-macro crate imports another crate that itself // exports a no_mangle function. // // That combination was broken for a period of time, because: // // In PR #99944 we *stopped* exporting no_mangle symbols from // proc-macro crates. The constructed linker version script still referred // to them, but resolving that discrepancy was left as a FIXME in the code. // // In PR #108017 we started telling the linker to check (via the // `--no-undefined-version` linker invocation flag) that every symbol referenced // in the "linker version script" is actually present in the linker input. So // the unresolved discrepancy from #99944 started surfacing as a compile-time // error. extern crate exports_no_mangle; </ins>

<!-- 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. ---rs has been updated with a workaround, so the reproduction described below will need adapting (e.g. check out that repo from around or earlier, since that will not include the workaround in ) problem exhibits itself only with certain numbers of codegen-units. The default setting for codegen-units is host dependent (the default is chosen, in part, as a function of the number of cores the host has available, in order to parallelize the code-generation performed by LLVM). In my own experiments, the problem is masked (does not arise) for codegen-units={1,2,4,8}, and the problem does arise for codegen-units={16,32,64,128,256}. You are best off passing explicit when investigating this, just to ward against that being an invisible factor in the experiments. (bug report follows below) I tried this code: I expected to see this happen: succeeds in debug mode. Instead, this happened: fails in debug mode. *isn't immediately obvious why would cause the problem searched nightlies: from nightly-2023-03-27 to nightly-2023-04-02 regressed nightly: nightly-2023-04-01 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<!-- 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-nightly-to-nightly -regression-untriaged --
I forked and minimized the reproducible example down to simply having a type (but not a value) with in a crate (and then adding that proc macro crate as a dependency of another crate). You can find it here: (just run in ) Here is a workaround for the crate:
WG-prioritization assigning priority ().


Question: <ins> // build-pass // force-host // no-prefer-dynamic // aux-build:exports_no_mangle.rs #![crate_type = "proc-macro"] // Issue #111888: this proc-macro crate imports another crate that itself // exports a no_mangle function. // // That combination was broken for a period of time, because: // // In PR #99944 we *stopped* exporting no_mangle symbols from // proc-macro crates. The constructed linker version script still referred // to them, but resolving that discrepancy was left as a FIXME in the code. // // In PR #108017 we started telling the linker to check (via the // `--no-undefined-version` linker invocation flag) that every symbol referenced // in the "linker version script" is actually present in the linker input. So // the unresolved discrepancy from #99944 started surfacing as a compile-time // error. extern crate exports_no_mangle; </ins>

label -I-prioritize +P-high +T-compiler
TBH it's not clear to me how alignment checks would end up causing linker errors, but since this seems bisected to , let's at the very least notify the PR's author
I already looked over this and was also mystified. I suppose I could take another look? I know almost completely nothing about wasm so I'm not hopeful.
Builds fine: Same linker error: As a mitigation for the linker error, users may put this in their (for the workspace!) That only helps with the alignment checks, is still not going to work.
I can build the reproducer, unmodified, if I use LLD. Or suggests this might be a link order issue. That would explain why LLD is fine with the link, but GNU's linker isn't. Actually, that doesn't make much sense because our standard library is already at the end of the link. I'm out of ideas :shrug: I think this is somehow dependent on linker details that I don't know and I'm struggling to educate myself on.
reported this same linker error from . It can be reproduced by creating an empty Cargo project, then running then . I have not managed to minimize this reproducer. The errant symbol is which is defined as: This has the same sort of shape as the non-unwinding panics from the alignment checks and from the standard library UB-detecting assertions. searched nightlies: from nightly-2023-01-01 to nightly-2023-06-09 regressed nightly: nightly-2023-03-12 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </detailsSo this bisects to a rollup then can't find the unrolled perf builds. Manual trials identifies as the source of the regression.
A tiny update: it seems like this problem goes away if you use  (and for me, it also didn't reproduce for many other values for number-of-codegen-units; I won't bother enumerating those here). This was somewhat of a surprise. I need to investigate more to figure out what relevance the codegen unit partitioning has to do with this issue.


Question: <ins> // build-pass // force-host // no-prefer-dynamic // aux-build:exports_no_mangle.rs #![crate_type = "proc-macro"] // Issue #111888: this proc-macro crate imports another crate that itself // exports a no_mangle function. // // That combination was broken for a period of time, because: // // In PR #99944 we *stopped* exporting no_mangle symbols from // proc-macro crates. The constructed linker version script still referred // to them, but resolving that discrepancy was left as a FIXME in the code. // // In PR #108017 we started telling the linker to check (via the // `--no-undefined-version` linker invocation flag) that every symbol referenced // in the "linker version script" is actually present in the linker input. So // the unresolved discrepancy from #99944 started surfacing as a compile-time // error. extern crate exports_no_mangle; </ins>

If nothing else, it is a halfway decent fallback measure while we continue to investigate the problem.
Wanted to add, that I also ran into this issue. For me, it also occurred while compiling a macro crate. I originally thought it was an issue with , as it happened after I ran a , and the issue was fixed by pinning to a slightly older version: There was a bunch of weird behavior I encountered when trying to uncover the issue. The issue was one. When I made other library upgrade changes, it would cause or fix the breakage. I didn't dive too deeply, but it seems like I was still encountering this issue even when I set the compiler to 1.67. (See this Github Actions build and associated commit: ) So it's possible that going to an old version simply hid the issue, but didn't actually pinpoint where the issue was introduced. Let me know if there's any other information I can provide to help isolate the issue. I've seemingly been able to work around the issue by using , as described earlier: I didn't try the other solution about codegen-units.
One MCVE for the stylist-macros build issue looks like this: Just a stylist-macros crate, with this and : So now I'm switching gears to see if I reduce wasm_bindgen to something smaller, so that we can have a small set of crates to talk about on their own here.
Okay got a pretty impressively tiny MCVE for wasm-bindgen too: In case its not clear, this seems like a pretty simple example that should easily work out of the box. (The use of from the mcve-stylist part of the story seems like an important part of the reproduction.) Still looking. Update: Wow, is it somehow of all things that is causing the problem here? That is ... bizarre, to say the least.
may be relevant. That issue is about not mentioning symbols in the version script such that they don't get exported. Also when applying to the rlib containing the symbols the linker error is fixed, so it seems like the linker doesn't pull in archive members even when the version script mentions it. Edit: For regular dylibs we mention all these symbols in , but for proc macros we only list a couple of internal symbols.


Question: <ins> // build-pass // force-host // no-prefer-dynamic // aux-build:exports_no_mangle.rs #![crate_type = "proc-macro"] // Issue #111888: this proc-macro crate imports another crate that itself // exports a no_mangle function. // // That combination was broken for a period of time, because: // // In PR #99944 we *stopped* exporting no_mangle symbols from // proc-macro crates. The constructed linker version script still referred // to them, but resolving that discrepancy was left as a FIXME in the code. // // In PR #108017 we started telling the linker to check (via the // `--no-undefined-version` linker invocation flag) that every symbol referenced // in the "linker version script" is actually present in the linker input. So // the unresolved discrepancy from #99944 started surfacing as a compile-time // error. extern crate exports_no_mangle; </ins>

Edit2: There is a special case for proc macros with the handling to not mention any symbols beyond those required to handle circular dependencies. Fixing should fix this issue too by making the version script a subset of again (apart from a couple of symbols defined outside of archives).
: As an addendum to this: (which was in a rollup, as mentioned) the future-proofing safe-guard of adding to the linker invocation. We can add that same link-arg ourselves as part of further bisection that acts prior to PR . In my own MCVE, when I add that link-arg, I find that the code did compile circa 1.63 even with that flag. The flag stopped working sometime between nightly-2022-08-01 and nightly-2022-08-02. (I have not yet tracked down further than that, since its too old to have per-commit prebuilds archived.) Update: oh, of course, it is almost certainly PR that injected the change in behavior mentioned in the previous paragraph.
See related discussion in https://rust- (I have a branch with a commit that seems to fix this here: ; I hope to have a PR up today, once I get a regression test into place.)


Question: "checksum arrayvec 0.4.7 (registry+https://github.com/rust-lang/crates.io-index)" = "a1e964f9e24d588183fcb43503abda40d288c8657dfc27311516ce2f05675aef" "checksum atty 0.2.11 (registry+https://github.com/rust-lang/crates.io-index)" = "9a7d5b8723950951411ee34d271d99dddcc2035a16ab25310ea2c8cfd4369652" "checksum autocfg 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)" = "0e49efa51329a5fd37e7c79db4621af617cd4e3e5bc224939808d076077077bf" <del> "checksum backtrace 0.3.25 (registry+https://github.com/rust-lang/crates.io-index)" = "1c50b4cb6d852a8567d98bb11c03f91ccec4dfbd88778bc1b92789c624081283" </del> <ins> "checksum backtrace 0.3.29 (registry+https://github.com/rust-lang/crates.io-index)" = "2d631cd7af21b7ff796293f1990104e3cdb606852863bac32f000c193aa35dfb" </ins> "checksum backtrace-sys 0.1.27 (registry+https://github.com/rust-lang/crates.io-index)" = "6ea90dd7b012b3d1a2cb6bec16670a0db2c95d4e931e84f4047e0460c1b34c8d" "checksum bit-set 0.5.0 (registry+https://github.com/rust-lang/crates.io-index)" = "6f1efcc46c18245a69c38fcc5cc650f16d3a59d034f3106e9ed63748f695730a" "checksum bit-vec 0.5.0 (registry+https://github.com/rust-lang/crates.io-index)" = "4440d5cb623bb7390ae27fec0bb6c61111969860f8e3ae198bfa0663645e67cf"

Every since a recent nightly update, both distributed nightlies and locally built produce backtraces where every level of the stack is represented only by their memory address and the label : Sadly I don't have a more specific repro case, but I can consistently reproduce locally. Older distributed nightlies do not present this behavior.
This happens consistently for me as well (also macOS).
I've been seeing this on Linux too, though it's been at least a week. (It also may have been fixed in a rustc newer than the one servo uses)
We should have tests for backtraces, so they don't regress again in the future.
this is certainly happening on master, and it's been happening for a while, but I assumed it was my env.
It just occurred to me that this might be related to the new symbol mangling (although I doubt it).
I've been experiencing this for about a week now (also on macOS). It definitely started prior to being merged. I also have the following in my :
has absolutely no changes if you don't use the flag, so it's not from there.
It's definitely , I tried before and after. It works if you enable the "coresymbolication" feature, though that's obviously not an option for distribution. I tried the latest master of , but it didn't help.
To confirm, is everyone only experiencing problems on OSX for rustc itself? Are there problems with other projects on OSX? can you please confirm or deny your experience from Linux? Throwing in a new platform here changes this quite a lot
Ok I believe I've found the issue for OSX, but if other platforms are still an issue that would be good to know
I've only experienced this with rustc itself on OSX. Things it builds seem ok, and linux/windows seem to be ok.
No, it's still happening on Linux as of yesterday (I can try again today). I also assumed it was my env.
I think the Linux issue is separate since it's been happening much longer than the OSX one
Hey, this seems to an issue on nightly for Windows (msvc) as well: This uses backtrace via :
if that's only using the crate and not using libstd, can you open an issue on the repository? The OSX issue should be fixed in , which I'd like to finish testing and then I'll send an update to libstd.


Question: "checksum arrayvec 0.4.7 (registry+https://github.com/rust-lang/crates.io-index)" = "a1e964f9e24d588183fcb43503abda40d288c8657dfc27311516ce2f05675aef" "checksum atty 0.2.11 (registry+https://github.com/rust-lang/crates.io-index)" = "9a7d5b8723950951411ee34d271d99dddcc2035a16ab25310ea2c8cfd4369652" "checksum autocfg 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)" = "0e49efa51329a5fd37e7c79db4621af617cd4e3e5bc224939808d076077077bf" <del> "checksum backtrace 0.3.25 (registry+https://github.com/rust-lang/crates.io-index)" = "1c50b4cb6d852a8567d98bb11c03f91ccec4dfbd88778bc1b92789c624081283" </del> <ins> "checksum backtrace 0.3.29 (registry+https://github.com/rust-lang/crates.io-index)" = "2d631cd7af21b7ff796293f1990104e3cdb606852863bac32f000c193aa35dfb" </ins> "checksum backtrace-sys 0.1.27 (registry+https://github.com/rust-lang/crates.io-index)" = "6ea90dd7b012b3d1a2cb6bec16670a0db2c95d4e931e84f4047e0460c1b34c8d" "checksum bit-set 0.5.0 (registry+https://github.com/rust-lang/crates.io-index)" = "6f1efcc46c18245a69c38fcc5cc650f16d3a59d034f3106e9ed63748f695730a" "checksum bit-vec 0.5.0 (registry+https://github.com/rust-lang/crates.io-index)" = "4440d5cb623bb7390ae27fec0bb6c61111969860f8e3ae198bfa0663645e67cf"

That could affect Linux as well but I doubt it, so if there are persisting Linux/Windows issues please feel free to let me know. If you can create an isolated problem which uses the crate rather than libstd that's even better!
Done: rust-lang/backtrace-rs


Question: debug!(?cache_projection, ?obligation_projection); match infcx.at(cause, param_env).eq( <del> DefineOpaqueTypes::No, </del> <ins> DefineOpaqueTypes::Yes, </ins> cache_projection, obligation_projection, ) {

<!-- 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. --Hey! I was trying to make it work somehow with , when the function depends on the other generic parameters. I came to this approach and encountered an ICE. <!-- 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. --: <details<summary<strongOutput</strong</summary<p</p</details
label requires-nightly F-typealiasimpl_trait
Regression in nightly-2023-02-22 Regression in cc
still crashing, rustc 1.77.0-nightly ( 2024-01-08)


Question: use rustc_middle::ty::{self, Ty, TyCtxt}; use rustc_middle::ty::{fast_reject, TypeFoldable}; use rustc_middle::ty::{ToPredicate, TypeVisitableExt}; <del> use rustc_span::ErrorGuaranteed; </del> <ins> use rustc_span::{ErrorGuaranteed, DUMMY_SP}; </ins> use std::fmt::Debug; pub(super) mod structural_traits;

<!-- ICE: Rustc '-Znext-solver=coherence -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'internal error: entered unreachable code: Weak and Inherent aliases should have been normalized away already'', 'thread 'rustc' panicked at 'internal error: entered unreachable code: Weak and Inherent aliases should have been normalized away already'' 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: [specializationgraphof] building specialization graph of trait [coherent_trait] coherence checking all impls of trait [analysis] running analysis passes on this crate --
cc


Question: <ins> #![feature(associated_const_equality)] trait T { type A: S<C<X = 0i32> = 34>; //~^ ERROR associated type bindings are not allowed here } trait S { const C: i32; } fn main() {} </ins>

I expect the following code to be rejected by the compiler but it is actually accepted and compiles successfully: The associated constant does not have any generic parameters / associated items (constants cannot have those anyways in the current version of Rust) and thus the argument list should be flagged as erroneous. Interestingly, if you remove the , the compiler correctly identifies this as an error: . I think is to be interpreted as a nested equality constraint (and not as a “defaulted” parameter, i.e. a parameter with a default value). : label T-compiler requires-nightly (it now does) Hence, I am just going to mention its tracking issue: . CC <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Doesn't need assoc const equality: Let me take a quick stab at this. claim
On a related note, a slightly modified version of the code above leads to an ICE (I was about to create a separate issue for this, should I still do that?): <details<summarystderr (diagnostics & backtrace)</summary</detailsThis only leads to an ICE on the current nightly (2022-09-27) (e.g. on the playground) but not on older ones like (2022-09-21).
If you want to bisect it feel free, but I think fixing the original issue in this report will also fix this one.
Yeah, I think so, too. I guess I won't bisect this.
This regressed in the last day
Oh wait, I caused it: searched nightlies: from nightly-2022-08-01 to nightly-2022-09-26 regressed nightly: nightly-2022-09-26 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: </details


Question: <del> Subproject commit 648e5b90b49af483d07caa8e413473a4517853d6 </del> <ins> Subproject commit 5cb983338e924ec85898880d60e65f2a1291b7be </ins>

Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver 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.
Caused by
I'm working on this.


Question: <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. trait Foo { } impl<T:Copy> Foo for T { } fn take_param<T:Foo>(foo: &T) { } fn main() { let x = box 3i; take_param(&x); //~^ ERROR instantiating a type parameter with an incompatible type } </ins>

Example: This should be fixed by code in .
Nominating for 1.0, P-backcompat-lang.
Assigning 1.0, P-backcompat-lang


Question: <ins> warning: the feature `inherent_associated_types` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/variance-computation-requires-equality.rs:3:12 | LL | #![feature(inherent_associated_types)] |            ^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: see issue #8995 <https://github.com/rust-lang/rust/issues/8995> for more information = note: `#[warn(incomplete_features)]` on by default warning: 1 warning emitted </ins>

<!-- 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
related. label F-inherentassociatedtypes
It caused by a cycle query:
There's a related bug to this (I believe by involving some traits with associated types) that I would like to report, though I was able to raise mine on Stable (1.70.0) without using the feature flag. Should I make a separate bug report or attach it here?


Question: <ins> warning: the feature `inherent_associated_types` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/variance-computation-requires-equality.rs:3:12 | LL | #![feature(inherent_associated_types)] |            ^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: see issue #8995 <https://github.com/rust-lang/rust/issues/8995> for more information = note: `#[warn(incomplete_features)]` on by default warning: 1 warning emitted </ins>

Regression in nightly-2023-02-21 found 9 bors merge commits in the specified range commit[0] 2023-02-19: Auto merge of - cjgillot:codegen-overflow-check, r=tmiasko commit[1] 2023-02-19: Auto merge of - clubby789:builtin-derived-attr, r=jackh726 commit[2] 2023-02-20: Auto merge of - fmease:iat-type-directed-probing, r=jackh726 commit[3] 2023-02-20: Auto merge of - tmiasko:read-buf, r=the8472 commit[4] 2023-02-20: Auto merge of - camelid:rustdoc-all-only-stable, r=GuillaumeGomez commit[5] 2023-02-20: Auto merge of - b-naber:proj-relate-variance, r=lcnr commit[6] 2023-02-20: Auto merge of - megakorre:issue_105700, r=petrochenkov commit[7] 2023-02-20: Auto merge of - matthiaskrgr:rollup-4tdvnx6, r=matthiaskrgr commit[8] 2023-02-20: Auto merge of - lnicola:rust-analyzer-2023-02-20, r=lnicola ERROR: no CI builds available between and within last 167 days I guess ?
Seems this has been fixed on the latest nightly, marked as E-needs-test. labels: +E-needs-test
this regressed again in


Question: } #[cfg(not(target_vendor = "win7"))] <del> #[link(name = "synchronization")] </del> <ins> // Use raw-dylib to import synchronization functions to workaround issues with the older mingw import library. #[cfg_attr( target_arch = "x86", link( name = "api-ms-win-core-synch-l1-2-0", kind = "raw-dylib", import_name_type = "undecorated" ) )] #[cfg_attr( not(target_arch = "x86"), link(name = "api-ms-win-core-synch-l1-2-0", kind = "raw-dylib") )] </ins> extern "system" { pub fn WaitOnAddress( address: *const c_void,

The following GitHub action fails with nightly-2024-02-27 but passes with nightly-2024-02-26 for (I believe) any project with a file: The error I got is the following: This only affects x8664-pc-windows-gnu (not MVSC), and switching from to fixes the issue. I have reproduced the issue in I may end up deleting that repo in the future, so for posterity, I've included all the code below: <details<summaryExample project to reproduce the issue:workflows (See above) src </detailsThe original discovery of this issue is reported in Running yielded the following for the latest nightly version without the issue: Running on three versions with_ the issue (the next nightly version, the latest nightly version, and the current beta) yielded the following: This issue is not present in rustc 1.77.2 (the latest stable version).
The imports should mostly be shared between msvc and gnu so the fact the targets differ is a bit puzzling. My hypothesis would be that mingw on Windows Server 2019 is using an older version of an import library that maps one or more functions to the wrong DLL. Specifically I think this could be caused by the import library. cc in case you've heard of anything like this before
I doubt it's a problem with the old MinGW-w64; in that case, the program would fail to link. I helped with a similar issue recently, and it was caused by the wrong being loaded. There are two DLLs called that, and if a manifest is not provided, Windows will load the wrong one:
Hm... I ran on both windows-2019 and windows-latest and the import tables do look different (see ). <details<summarywindows-2019</summary</details<details<summarywindows-latest</summary</detailsNote that is listed under in windows-2019 but it's more correctly listed under in windows-latest.
Yeah, that is probably the culprit but mingw-w64 links from since mid 2016: If it's caused by miingw-w64 toolchain preinstalled on image it must be terribly out of date.
Quite possibly it is that out of date. The other explanation would be it's coming from somewhere else, which Is a bit worrying.


Question: } #[cfg(not(target_vendor = "win7"))] <del> #[link(name = "synchronization")] </del> <ins> // Use raw-dylib to import synchronization functions to workaround issues with the older mingw import library. #[cfg_attr( target_arch = "x86", link( name = "api-ms-win-core-synch-l1-2-0", kind = "raw-dylib", import_name_type = "undecorated" ) )] #[cfg_attr( not(target_arch = "x86"), link(name = "api-ms-win-core-synch-l1-2-0", kind = "raw-dylib") )] </ins> extern "system" { pub fn WaitOnAddress( address: *const c_void,

Based on , my first impression is that mingw-w64 isn't preinstalled on the image. Unless Windows Subsystem for Linux is relevant, I assume that the mingw-w64 toolchain is installed as part of the run of .
Various tools like Perl might come with GCC. Could you determine location of and ?
I'm not sure. I've only been able to reproduce this via a GitHub action, not on my own machine, although I might be able to use something like to explore around. Alternatively, I could just run a fixed list of commands. If there's a set of commands I can run to answer any questions you have, please let me know. I'm not sure how the Rust toolchain determines which version of to run when building Rust code, but that seems like something you might know. EDIT: Based on your question, I might need to just run with the two applications you asked about. EDIT2: and are both in according to .
Here are the versions of based on running :
Thanks, apparently there was a bug in mingw-w64 fixed in 2020: IIRC this toolchain is older than that so it's indeed a bug in mingw-w64 shipped with this .
Oh, weird. also comes shipped with so this image generally has up-to-date packages. I also didn't see mingw or mingw-w64 mentioned anywhere in its README, so now I'm wondering if there's a bug in the image itself. I expect this means that no action will be needed for this particular issue unless we want to be more robust to bad environments like this. EDIT: It looks like it's defined here: EDIT2: It was documented after all. I had to search for "gcc", not "mingw".
I was rather confused because states that the latest version from the 8.x series is 8.0.2, but the version installed of in the the Windows 2019 image is 8.1.0, which seems like it shouldn't exist. However, based on the releases of , the number after the is probably what's important, which means that we're on version 6.0.0, which is indeed before the fix. I might ask in the project to see if it's worth updating mingw64 for this reason.


Question: } #[cfg(not(target_vendor = "win7"))] <del> #[link(name = "synchronization")] </del> <ins> // Use raw-dylib to import synchronization functions to workaround issues with the older mingw import library. #[cfg_attr( target_arch = "x86", link( name = "api-ms-win-core-synch-l1-2-0", kind = "raw-dylib", import_name_type = "undecorated" ) )] #[cfg_attr( not(target_arch = "x86"), link(name = "api-ms-win-core-synch-l1-2-0", kind = "raw-dylib") )] </ins> extern "system" { pub fn WaitOnAddress( address: *const c_void,

EDIT: Filed Depending on their response, if they decide not to update, it's possible could be fixed instead to stop trying to install Rust over an incompatible version of MinGW.
For some reason, my original issue description code snippet mentioned instead of . I think that's because I copy/pasted the wrong version, when I was seeing whether the workaround worked (which I believe it did). I apologize if that caused any confusion. I've now edited the description to fix this mistake.
Given that seems to be in progress and would close this issue, I mentioned that in for extra transparency.
Thank you for all your help on this! It's awesome that all this happened in only 4 days. I can confirm on my end that this issue is now fully resolved on the latest nightly release of Rust (2024-04-19).


Question: ) -> FfiResult<'tcx> { use FfiResult::*; <del> let transparent_safety = def.repr().transparent().then(|| { // Can assume that at most one field is not a ZST, so only check // that field's type for FFI-safety. </del> <ins> let transparent_with_all_zst_fields = if def.repr().transparent() { </ins> if let Some(field) = transparent_newtype_field(self.cx.tcx, variant) { <del> return self.check_field_type_for_ffi(cache, field, args); </del> <ins> // Transparent newtypes have at most one non-ZST field which needs to be checked.. match self.check_field_type_for_ffi(cache, field, args) { FfiUnsafe { ty, .. } if ty.is_unit() => (), r => return r, } false </ins> } else { <del> // All fields are ZSTs; this means that the type should behave // like (), which is FFI-unsafe... except if all fields are PhantomData, // which is tested for below FfiUnsafe { ty, reason: fluent::lint_improper_ctypes_struct_zst, help: None } </del> <ins> // ..or have only ZST fields, which is FFI-unsafe (unless those fields are all // `PhantomData`). true </ins> } <del> }); // We can't completely trust repr(C) markings; make sure the fields are // actually safe. </del> <ins> } else { false }; // We can't completely trust `repr(C)` markings, so make sure the fields are actually safe. </ins> let mut all_phantom = !variant.fields.is_empty(); for field in &variant.fields { <del> match self.check_field_type_for_ffi(cache, &field, args) { FfiSafe => { all_phantom = false; } FfiPhantom(..) if !def.repr().transparent() && def.is_enum() => { return FfiUnsafe { ty, reason: fluent::lint_improper_ctypes_enum_phantomdata, help: None, }; } FfiPhantom(..) => {} r => return transparent_safety.unwrap_or(r), </del> <ins> all_phantom &= match self.check_field_type_for_ffi(cache, &field, args) { FfiSafe => false, // `()` fields are FFI-safe! FfiUnsafe { ty, .. } if ty.is_unit() => false, FfiPhantom(..) => true, r @ FfiUnsafe { .. } => return r, </ins> } } <del> if all_phantom { FfiPhantom(ty) } else { transparent_safety.unwrap_or(FfiSafe) } </del> <ins> if all_phantom { FfiPhantom(ty) } else if transparent_with_all_zst_fields { FfiUnsafe { ty, reason: fluent::lint_improper_ctypes_struct_zst, help: None } } else { FfiSafe } </ins> } /// Checks if the given type is "ffi-safe" (has a stable, well-defined

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.


Question: ) -> FfiResult<'tcx> { use FfiResult::*; <del> let transparent_safety = def.repr().transparent().then(|| { // Can assume that at most one field is not a ZST, so only check // that field's type for FFI-safety. </del> <ins> let transparent_with_all_zst_fields = if def.repr().transparent() { </ins> if let Some(field) = transparent_newtype_field(self.cx.tcx, variant) { <del> return self.check_field_type_for_ffi(cache, field, args); </del> <ins> // Transparent newtypes have at most one non-ZST field which needs to be checked.. match self.check_field_type_for_ffi(cache, field, args) { FfiUnsafe { ty, .. } if ty.is_unit() => (), r => return r, } false </ins> } else { <del> // All fields are ZSTs; this means that the type should behave // like (), which is FFI-unsafe... except if all fields are PhantomData, // which is tested for below FfiUnsafe { ty, reason: fluent::lint_improper_ctypes_struct_zst, help: None } </del> <ins> // ..or have only ZST fields, which is FFI-unsafe (unless those fields are all // `PhantomData`). true </ins> } <del> }); // We can't completely trust repr(C) markings; make sure the fields are // actually safe. </del> <ins> } else { false }; // We can't completely trust `repr(C)` markings, so make sure the fields are actually safe. </ins> let mut all_phantom = !variant.fields.is_empty(); for field in &variant.fields { <del> match self.check_field_type_for_ffi(cache, &field, args) { FfiSafe => { all_phantom = false; } FfiPhantom(..) if !def.repr().transparent() && def.is_enum() => { return FfiUnsafe { ty, reason: fluent::lint_improper_ctypes_enum_phantomdata, help: None, }; } FfiPhantom(..) => {} r => return transparent_safety.unwrap_or(r), </del> <ins> all_phantom &= match self.check_field_type_for_ffi(cache, &field, args) { FfiSafe => false, // `()` fields are FFI-safe! FfiUnsafe { ty, .. } if ty.is_unit() => false, FfiPhantom(..) => true, r @ FfiUnsafe { .. } => return r, </ins> } } <del> if all_phantom { FfiPhantom(ty) } else { transparent_safety.unwrap_or(FfiSafe) } </del> <ins> if all_phantom { FfiPhantom(ty) } else if transparent_with_all_zst_fields { FfiUnsafe { ty, reason: fluent::lint_improper_ctypes_struct_zst, help: None } } else { FfiSafe } </ins> } /// Checks if the given type is "ffi-safe" (has a stable, well-defined

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


Question: self.pos } <ins> // This is only used by a test which asserts that the initialization-tracking is correct. #[cfg(test)] pub fn initialized(&self) -> usize { self.initialized } </ins> #[inline] pub fn discard_buffer(&mut self) { self.pos = 0;

I tried this code: I expected to see this happen: Instead, this happened: The problem doesn't occur with optimization enabled. It most recently worked on: Also fails on: modify labels: +regression-from-stable-to-stable -regression-untriaged <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Thanks for reporting this! This is an issue with a debug build so it's unlikely to be prioritized high but I'm interested in helping out because this is very goofy. The slow code here is the Iterator impl on slices. I think in the last stable release we switched the implementation of BufReader to eventually use ReadBuf, and the slow code is ReadBuf initializing the remaining uninitialized capacity. It does this by iterating over a slice, and that iteration is the slow bit. What I don't get here is why we need to initialize at all. That doesn't seem right.
WG-prioritization assigning highest priority since this looks a pretty visible runtime perf. regression (). If the assessment should be revised, please feel free to comment. label -I-prioritize +P-critical i-slow
I've tried bisecting with and feeding this command: . Regression seems to be in and confirm <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
:joy: I was so sure this wasn't my fault. More fool me for not bisecting it myself.
(This probably shows an opportunity to add a benchmark to the newly-established "runtime benchmarks" (rather than the compilation-time benchmarks that has classically focused on...)
After sleeping on this, I realized that there's no real reason to expect the worlds-worst-memset code which is the source of the slowdown to be totally optimized out with . And of course it isn't. This is also a substantial regression with optimizations.


Question: self.pos } <ins> // This is only used by a test which asserts that the initialization-tracking is correct. #[cfg(test)] pub fn initialized(&self) -> usize { self.initialized } </ins> #[inline] pub fn discard_buffer(&mut self) { self.pos = 0;

Here's a version of the original program that's touched up a bit: On 1.63 I see runtime ~0.43 s, and on 1.64 ~4.8 s. So we have a slowdown of around 10x, though I suspect that number could be ratcheted up higher.
claim
Awesome, thanks for the really quick fix!


Question: struct Bar; impl Foo for Bar {} // error: `Foo` is not a trait <ins> fn baz<T: Foo>(t: T) {} // error: `Foo` is not a trait </ins> ``` Another erroneous code example: ```compile_fail,E0404 <del> struct Foo; </del> <ins> type Foo = Iterator<Item=String>; </ins> <del> fn bar<T: Foo>(t: T) {} // error: `Foo` is not a trait </del> <ins> fn bar<T: Foo>(t: T) {} // error: `Foo` is a type alias </ins> ``` Please verify that the trait's name was not misspelled or that the right

I managed to reproduce the problem with this snippet: The compiler yells E0404 at me, but fair enough I always ask it to a bit more about it :) However this time, it only says this: This is confusing because the snippet above doesn't involve the keyword so I didn't understand initially what I was doing wrong, then I read the error message again: I first tried this, and it worked, but having to repeat the whole syntax everywhere wasn't too compelling, hence the alias: The compiler error message makes it very clear that I can't alias a trait, but the E0404 explanation doesn't mention it at all. I hope the description could also include this use case as I've seen sometimes EXXXX explanations go over several facets of the same problem. That won't help me, but maybe others that may trip on the same problem. I would have submitted a pull request for the docs myself, but I have no idea why you can't use type aliases for traits so I can't it ;) I'm using stable Rust 1.19.0 (on Fedora).
One more thing, even though the compiler lets me create an alias for a trait, I don't know when I can use such an alias. Maybe this should be explained too.
Current output (in nightly):
Current output: No structured suggestion for the nightly feature (should be and the feature flag).


Question: <ins> #![feature(allow_internal_unstable)] // Macro to help ensure CONST_ERR lint errors // are not silenced in external macros. // https://github.com/rust-lang/rust/issues/65300 #[macro_export] #[allow_internal_unstable(type_ascription)] macro_rules! static_assert { ($test:expr) => { #[allow(dead_code)] const _: () = [()][!($test: bool) as usize]; } } </ins>

The following does not error locally / on the playground If I copy paste the macro into the same file, it errors as expected Checking other macros, error as expected.
This feels like it's related to a similar issue () I created a while back.
cc
This is probably because the "error" is just a lint. And we appear to silence it in external macros. We shouldn't do that. IIRC this is just a flag that needs to be set for the lint macro
Yes, we need to set reportinexternal_macro param on the lint I believe
Ah, that makes sense! Building locally with the parameter set to confirm. it does ^^ will check the samples in there too.


Question: <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. static FOO: &'static [u8] = bytes!("hello, world"); pub fn main() { let b = match true { true => bytes!("test"), false => unreachable!() }; assert_eq!(b, "test".as_bytes()); assert_eq!(FOO, "hello, world".as_bytes()); } </ins>

With landed, the lifetime of is now problematic. Specifically, the following used to work and now fails: The lifetime of is now limited to that branch of the match, so it doesn't live long enough to be assigned to . I'm not sure if this means lifetimes need to change. The other option is that needs to return a . Unfortunately, the only way to do that right now is to make it equivalent to , which makes it no longer usable as the value of a constant (e.g. ). I'm thinking the right solution is to make it legal for me to say . I can type that right now, but the lifetime seems to be wholly ignored, as I get the exact same error with the following as I do with the example above: If becomes a valid expression with the lifetime, then could start evaluating to that and everything should work as expected. Furthermore, it would be nice (but perhaps not required) if , where all elements are compile-time constants, would implicitly be given the lifetime.
/cc
Yeah, this is kind of annoying. I worked around it in one specific case by having bytes! expand as follows: I certainly think one should be allowed to write a concrete lifetime as part of a slice or borrow expression, and ought to be legal -- we'll obviously have to impose more stringent constant-related rules. In the short term, we could adjust to expand in the pattern I showed above. What was unclear to me was whether this is sufficient workaround, or whether we'll want something more general. Interestingly, even if we used full inference, the expression you gave above would be illegal unless we introduce a special case for static byte strings, because it generates a conditional temporary (only on one arm of the match) and we can't handle the cleanup for such a case without zeroing, which we plan to remove (well, I guess we could also have a special case for temporary types [like ) that do not require drop glue, but I'd rather not).
Perhaps the simplest fix for now is to adjust the macro itself to expand to a static item as I showed. I should probably have done that more generally but I was ready to land that expletive branch already.
Won't that prevent from being able to expand to a static?
I already adjusted like that and is correct, it prevents , which is definitely already used in our codebase.
Ah, unfortunate.


Question: <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. static FOO: &'static [u8] = bytes!("hello, world"); pub fn main() { let b = match true { true => bytes!("test"), false => unreachable!() }; assert_eq!(b, "test".as_bytes()); assert_eq!(FOO, "hello, world".as_bytes()); } </ins>

(I actually think we should allow statics to include nested blocks with other statics, but I guess that's a separate bug) Well, I'm not sure what's the easiest fix in that case, I guess just to fix the semantics of so that it guarantees static data. I'm not 100% sure what's implied by such a fix: it doesn't seem too hard ;)
cc


Question: <ins> // Copyright 2016 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. #[macro_export] macro_rules! m { () => { use $crate; } } </ins>

When on latest rust nightly , you get an ICE when compiling .
Its a pretty recent regression, it can't be reproduced with .
Okay, managed to minimize it: Looks like a regression of . cc any ideas on this?
Yeah, this was caused by an oversight in -- fixed in .


Question: <del> Subproject commit c388361cc2db82568d5e90fefea864f0af8d35e9 </del> <ins> Subproject commit a0ba079b6af0f8c07c33dd8af72a51c997e58967 </ins>

Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. 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 compiler team prioritization.
Cc The error is with the following backtrace
Ah but further up the call stack we have so I think this will be fixed by


Question: .map(|(id, title, items)| LinkBlock::new(Link::new(id, title), "", items)) .collect(); sidebar_assoc_items(cx, it, &mut blocks); <ins> if !t.is_object_safe(cx.tcx()) { blocks.push(LinkBlock::forced( Link::new("object-safety", "Object Safety"), "object-safety-note", )); } </ins> blocks.push(LinkBlock::forced(Link::new("implementors", "Implementors"), "impl")); if t.is_auto(cx.tcx()) { blocks.push(LinkBlock::forced(

So that it is easy for user to recognize object-safe traits. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
for the rustdoc side, just query the doc context with a given traitdef_id.
claim
Can you tell what are the relevant parts of rustdoc that needs to be changed?
sorry for late rely :) Add a field to , its value can be queried with like . Then you can append the object-safety info into the render part here I know little about the render code, could you leave some notes about that?
No, please do not add more fields to Trait. Query at the place it is used. I don't know much about render, may have suggestions.
I'm actually not sure what they want the end result to look like, so I don't know where to tell them to update the code. ;)
maybe it could be a cube icon to the right of the new button? On hover, there would be a tooltip saying or . I'm not sure where you get icons for rustdoc, but have a cube and cube-transparent icon that could be used for object-safe, and object-unsafe traits respectively. The could be reduced to fit in with the rest of the icons in rustdoc. If doesn't want to work on it I'd be happy to give it a go.
Following up from the PR with some UI discussion. I'd prefer not to add more icons up at the top of the page; we're already a bit crowded with icons. And there's no icon that has a broadly understood meaning of "object safe". I like the approach in , to write out "This trait is object-safe." But that PR puts it all the way at the top of the page, which is very high priority - and I would say object safety is more medium priority, so it should be lower on the page. One possibility would be to make an subheading in the top-doc docblock, but that results in using a lot of space for this. Our h2's are big! What about this: Under "Implementors", we could have at the very top "This trait is object safe. References to types that implement this trait can be automatically coerced to ".


Question: .map(|(id, title, items)| LinkBlock::new(Link::new(id, title), "", items)) .collect(); sidebar_assoc_items(cx, it, &mut blocks); <ins> if !t.is_object_safe(cx.tcx()) { blocks.push(LinkBlock::forced( Link::new("object-safety", "Object Safety"), "object-safety-note", )); } </ins> blocks.push(LinkBlock::forced(Link::new("implementors", "Implementors"), "impl")); if t.is_auto(cx.tcx()) { blocks.push(LinkBlock::forced(

My reasoning here is that conceptually, is somewhat like an implementor of the trait.
I don't think this is necessarily true, you can have a that doesn't implement . But putting the text under "implementors" seems as good a place as any
Just out of curiosity, how can I have a that doesn’t implement ?
I don't think that's actually true, I misremembered.
We have one on: Would anyone else like to weigh in? Good enough to proceed with implementation?
Any update on this? :)
I'm not sure if it's already been suggested, but what about only showing a note if the trait is not object-safe?
I like suggestion to only show when a trait is not object safe, since that's the more unusual condition. If we do that, it doesn't fit logically under "Implementors" anymore. If we proceed with only marking non-object-safe traits, here are a couple of ideas: Add a section after the top-doc, but before "Implementors", called "Object Safety", and put the text there. Add information to the documentation of any method that causes the trait to be not object-safe.
I think it’s still fine to mention under “Implementors” like “This trait is not object safe: doesn’t implement ”, but I also like the idea of the new section. I see this issue doesn’t have an assignee currently, can I claim this?
You can but since we didn't reach a consensus, any PR would hang around until we reach one.


Question: let index = out.join("std").join("index.html"); builder.open_in_browser(index); } else { <del> for requested_crate in &*self.crates { </del> <ins> for requested_crate in crates { </ins> if STD_PUBLIC_CRATES.iter().any(|&k| k == requested_crate) { let index = out.join(requested_crate).join("index.html"); builder.open_in_browser(index);

I have pinned down the regression to a specific commit, thanks to recommending me . searched nightlies: from nightly-2024-07-28 to nightly-2024-07-30 regressed nightly: nightly-2024-07-30 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.9</summaryHost triple: aarch64-apple-darwin Reproduce with: : </details
Based on the commits in that rollup, I feel like might be the culprit, but it isn't obvious to me why that might be the case (cc
Thanks for the ping, will fix this.


Question: impl<'a> Resolver<'a> { fn resolution(&self, module: Module<'a>, ident: Ident, ns: Namespace) -> &'a RefCell<NameResolution<'a>> { <ins> let ident = ident.unhygienize(); </ins> *module.resolutions.borrow_mut().entry((ident, ns)) .or_insert_with(|| self.arenas.alloc_name_resolution()) }

Test case: Compiles successfully on , causes an ICE on . Diff contains only , CC Found while trying to minimize , but filed separately since the error message is different and this one has a small test case.
Do you have a backtrace?
Yes of course. Sorry I forgot to include it: rust error: internal compiler error: attempted .defid() on invalid def: Err note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'Box<Any',


Question: impl<'a> Resolver<'a> { fn resolution(&self, module: Module<'a>, ident: Ident, ns: Namespace) -> &'a RefCell<NameResolution<'a>> { <ins> let ident = ident.unhygienize(); </ins> *module.resolutions.borrow_mut().entry((ident, ns)) .or_insert_with(|| self.arenas.alloc_name_resolution()) }

stack backtrace: 1: 0x7fc35e73fdf3 - std::sys::imp::backtrace::tracing::imp::write::hdfa3e34b856f69a3 2: 0x7fc35e74e5dd - std::panicking::defaulthook::{{closure}}::h20f8c1082e0ce86e 3: 0x7fc35e74e17b - std::panicking::defaulthook::hd31552ac08c2a241 4: 0x7fc35e74ea68 - std::panicking::rustpanicwithhook::h73969d230a072c1a 5: 0x7fc357eda667 - std::panicking::beginpanic::hb89a2261f4776ce3 6: 0x7fc357eef99f - rustcerrors::Handler::bug::h13b3b29154320abd 7: 0x7fc35bab053a - rustc::session::optspanbugfmt::{{closure}}::hfea18dd68f59976d 8: 0x7fc35baafff7 - rustc::session::optspanbugfmt::h7d370a0810dbdbbd 9: 0x7fc35baafce2 - rustc::session::bugfmt::hcde5f50c54004a4f 10: 0x7fc35b984552 - rustc::hir::def::Def::defid::h728c22aafbe84efc 11: 0x7fc35c6ddb3a - rustcprivacy::ObsoleteVisiblePrivateTypesVisitor::pathisprivatetype::h24756a49a68d1da9 12: 0x7fc35c6d53db - rustc::hir::intravisit::walkty::h64b13c0c45b7a09a 13: 0x7fc35c6d49ba - rustc::hir::intravisit::Visitor::visitfn::ha8ad665c42b1d643 14: 0x7fc35c6de7cf - <rustcprivacy::ObsoleteVisiblePrivateTypesVisitor<'a,


Question: impl<'a> Resolver<'a> { fn resolution(&self, module: Module<'a>, ident: Ident, ns: Namespace) -> &'a RefCell<NameResolution<'a>> { <ins> let ident = ident.unhygienize(); </ins> *module.resolutions.borrow_mut().entry((ident, ns)) .or_insert_with(|| self.arenas.alloc_name_resolution()) }

'tcxas rustc::hir::intravisit::Visitor<'tcx::visititem::hae9f32c7942ccca1 15: 0x7fc35c6deab5 - <rustcprivacy::ObsoleteVisiblePrivateTypesVisitor<'a, 'tcxas rustc::hir::intravisit::Visitor<'tcx::visititem::hae9f32c7942ccca1 16: 0x7fc35c6e1b7a - rustcprivacy::checkcrate::h5ba75e3c4ebe0690 17: 0x7fc35eaef747 - rustcdriver::driver::phase3runanalysispasses::{{closure}}::h388b9236cf305089 18: 0x7fc35ead66d6 - rustcdriver::driver::phase3runanalysispasses::h080c1a734c4f2909 19: 0x7fc35eac5425 - rustcdriver::driver::compileinput::hab55539b85c4ceed 20: 0x7fc35eb0ea51 - rustcdriver::runcompiler::h128b89b79f649304 21: 0x7fc35ea236fb - std::panicking::try::docall::h15bca94dda232804 22: 0x7fc35e757b06 - rustmaybecatchpanic 23: 0x7fc35ea44d01 - <F as alloc::boxed::FnBox<A::callbox::h8832766c4bda585b 24: 0x7fc35e74d470 - std::sys::imp::thread::Thread::new::threadstart::h7d03d727f96da002 25: 0x7fc357684453 - startthread 26: 0x7fc35e4147de - GI__clone 27: 0x0 - <unknown
triage: P-high Seems bad. Assigning to based on bisection.
Fixed in .


Question: impl<'a> Resolver<'a> { fn resolution(&self, module: Module<'a>, ident: Ident, ns: Namespace) -> &'a RefCell<NameResolution<'a>> { <ins> let ident = ident.unhygienize(); </ins> *module.resolutions.borrow_mut().entry((ident, ns)) .or_insert_with(|| self.arenas.alloc_name_resolution()) }

Servo compiles with rustc 2016-12-18, but not with 2016-12-21. Diff: The crate fails to build with: The method being called here is: Its return type is which is . This call is in another impl of the same method of the same trait: Adding an explicit type annotation works around this error, but only to uncover another very similar one, then another. The third one was in code generated by serde’s , so I gave up that approach. So far I haven’t managed to reduce a test case smaller than "most of Servo", sorry. I’m suspicious of (which is part of ) because it’s commit message mentions inference. I’m not building a compiler to confirm.
CC
Also fails in , so is not to blame. New diff: I don’t have another guess, and doing a full bisect would take a very long time…
I can't find the cause in that range, at least nothing changed in the compiler AFAICT. Can you try (the commit before larger rollup)?
Expanding the macro: (Even simplifying it, this is not using ) gives:
Alright, that matches what I've seen from What about a couple more steps of bisecting? Or maybe compiling this crate with the "servo" feature off (which, AFAICT, turns off all the macros 1.1 - they might be responsible).
Swapping the order of the two arms: Changing the pattern to : Hacking to not use the stable version of the compiler (so effectively disabling the feature and enabling the one) also gives the same error.
New range, based on manual bisect: good, bad. Diff: , which leaves only in-between. CC Also found more clues. More context for the code where the error happens: is a module generated by a macro, that contains re-exports of other modules: If I add a similar not in a macro: or if I change the original code to use the real path without going through a , this seems to work around this issue completely. … only to uncover another one:
Found another ICE, I don’t know if it’s related: .


Question: impl<'a> Resolver<'a> { fn resolution(&self, module: Module<'a>, ident: Ident, ns: Namespace) -> &'a RefCell<NameResolution<'a>> { <ins> let ident = ident.unhygienize(); </ins> *module.resolutions.borrow_mut().entry((ident, ns)) .or_insert_with(|| self.arenas.alloc_name_resolution()) }

Found a smaller test case for the inference issue: rust fn main() {} pub mod a { pub struct FontFamily; impl FontFamily { pub fn tocss(&self) -::std::fmt::Result { Ok(()) } } } macrorules! reexport { () ={ mod b { pub use a; } } } reexport!(); pub mod c { use b::a::FontFamily; struct FontFace { family: FontFamily } impl FontFace { pub fn tocss(&self) -::std::fmt::Result { try!(()); Ok(()) } } }
That "other ICE" is actually a direct observation of the bug, whereas this inference issue is some weird side-effect of the way we handle errors that don't stop compilation.
never mind, apparently it fails locally
triage: P-high Seems bad. Assigning to based on bisection.
Does this affect beta ()?
At the moment the latest successful nightly build is 3 days old. I don’t know how often playpen’s nigthly is updated. merged 2 days ago. (This is the rollup PR that merged , which introduced this issue if I did my manual bisecting correctly.) As far as I can tell no, is not reachable from and so beta is not affected.
Fixed in .


Question: "rustc_hir", "rustc_middle", "rustc_span", <ins> "scoped-tls", </ins> "tracing", ]

is left set to a dangling pointer if unwinds. This is unsound because a later call to will use that dangling pointer. There is a similar issue with and unwinding. since you're on the Stable MIR cc list: cc
if you can add it as a dependency, using would probably be better than rolling your own version.
Yea, that makes sense. I think we should look into using it for the module, too, which is how we get a within the compiler itself