Question: DependencyType::TargetSelfContained, ); } <ins> let crt_path = builder.ensure(native::CrtBeginEnd { target }); </ins> for &obj in &["crtbegin.o", "crtbeginS.o", "crtend.o", "crtendS.o"] { <del> let src = compiler_file(builder, builder.cc(target), target, obj); </del> <ins> let src = crt_path.join(obj); </ins> let target = libdir_self_contained.join(obj); builder.copy(&src, &target); target_deps.push((target, DependencyType::TargetSelfContained));

where there's likely not a native toolchain and rustc is forced to work out the answers for itself (as an aside no longer works as the "linker" for musl targets, since it doesn't support which is enabled in rustc as of the last release) I'm worrying about the latter case and I think from above the fix for that is: to add the terminator in builds as well as ones and include it in the target package alongside the (so rustup etc fetch it) the link command rustc emits for the musl target to include before Some side questions: Does the above sound sensible to people? Do we need to include any of too? (I think not, but I'm no expert :shrug:) Do other targets need similar treatment? musl?
In the latter case it would make sense to me for rustc to invoke an actual linker (///etc) since at the moment it goes via a compiler but has to tell the compiler to not do anything and just to pass the link args to the linker anyway. This is off topic for this discussion though.
If we need to improve the self-contained mode specifically, then I think we can just ship the begin/end objects and link to them like gcc does obsoleting the comment cited in That appears to be the simplest solution. If that doesn't work out (e.g. due to licensing), then the necessary parts can be to and linked as , as you suggested above.
Which / objects were you thinking? 's? LLVM's? If you're right and it's the compiler that ships the begin/end then maybe it's right for to have it's own (though given that the link might contain code compiled by random compilers (from scripts) as well as compiled by , which is "the compiler" for the sake of this discussion)?
's? LLVM's? I don't know, but looks like they should be compatible. At least on Ubuntu both gcc and clang link to gcc's objects. The gcc ones can be just copied by rustbuild if the license allows, the LLVM ones can be used if we need to build them by ourselves (they are a part of compiler-rt).
adds crtbegin/crtend objects to Rust distribution and links to them in self-contained mode as was suggested in , so it should fix this issue.
I still have this problem with clang's compiler-rt:


Question: cx.generated_synthetics.insert((ty, trait_def_id)); <ins> let hir_imp = impl_def_id.as_local() .map(|local| cx.tcx.hir().expect_item(local)) .and_then(|item| if let hir::ItemKind::Impl(i) = &item.kind { Some(i) } else { None }); let items = match hir_imp { Some(imp) => imp .items .iter() .map(|ii| cx.tcx.hir().impl_item(ii.id).clean(cx)) .collect::<Vec<_>>(), None => cx.tcx .associated_items(impl_def_id) .in_definition_order() .map(|x| x.clean(cx)) .collect::<Vec<_>>(), }; </ins> impls.push(Item { name: None, attrs: Default::default(),

Interesingly, and shockingly If you remove and , this doesn't panic. <details<summaryWhats up with the diff? </summaryThe assetion format is differnt to usual as I've patch rustc with to make it readable, but this can also be repoduced with the latest nightly </details modify labels: +A-rustdoc-json +T-rustdoc
MCVE: One has while the other has - I bet one is going through HIR and the other is going through metadata, that could explain why the generic parameter matters.
I have a similar MCVE generated from , but the only item that differs in the assertion is the visibility: The left has a visibility of , and the right has a visibility of . A similar MCVE, with as a parameter, has as an input for the right side, but not for the left (and the / visibility issue):


Question: <ins> error: expected one of `(`, `,`, `=`, `{`, or `}`, found `#` --> $DIR/help-set-edition-ice-122130.rs:2:6 | LL |     s#[c"owned_box"] |      ^ expected one of `(`, `,`, `=`, `{`, or `}` | = note: you may be trying to write a c-string literal = note: c-string literals require Rust 2021 or later = help: pass `--edition 2021` to `rustc` = note: for more on editions, read https://doc.rust-lang.org/edition-guide error: expected item, found `"owned_box"` --> $DIR/help-set-edition-ice-122130.rs:2:9 | LL |     s#[c"owned_box"] |         ^^^^^^^^^^^ expected item | = note: for a full list of items that can appear in modules, see <https://doc.rust-lang.org/reference/items.html> error: aborting due to 2 previous errors </ins>

<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'called on an value: failed while formatting fluent string : '', 'thread 'rustc' panicked at 'called on an value: failed while formatting fluent string : '' 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: --
Slightly smaller:
cc
Somehow this subdiag enum being to a diagnostic causes but the looks okay to me...?
Also suspicious:
Seems like for the subdiag whose fluent messages contain a variable, they need to be eagerly translated via instead of using . However I'm not very familiar with this distinction.


Question: <ins> // Suggest to a user to use the print macros // instead to use the printf. fn main() { let x = 4; printf("%d", x); //~^ ERROR cannot find function `printf` in this scope //~| HELP you may have meant to use the `print` macro } </ins>

We already translate from C-style formatting strings to Rust formatting strings when passed to the family of macros. We should also detect invalid calls from other languages that were meant to be macro calls: currently emits the dry while it could be <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Mentoring on this issue label +E-mentor


Question: #[subdiagnostic] pub req_introduces_loc: Option<ReqIntroducedLocations>, <ins> pub has_param_name: bool, pub param_name: String, </ins> pub spans_empty: bool, pub has_lifetime: bool, pub lifetime: String,

[ ] Previous Stable [ ] Current Stable [ ] Current Beta [X] Current Nightly No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This is another case for And except for the missing argument issue, there is an copy-paste bug in :


Question: <ins> // force-host // no-prefer-dynamic #![crate_type = "proc-macro"] extern crate proc_macro; use proc_macro::TokenStream; #[proc_macro_attribute] pub fn vec_ice(_attr: TokenStream, input: TokenStream) -> TokenStream { // This redundant convert is necessary to reproduce ICE. input.into_iter().collect() } </ins>

Follow up to and , as per Minimize a test that exercises the same codepath as
As already stated in the proc macro can be reduced to:
How do you write a UI test that depends on 3rd-party libraries?
is an example of a test that relies on a procmacro, and we can use snippet for the necessary proc_macro being tested.


Question: match view_path.node { ViewPathSimple(binding, ref full_path) => { <del> let source_name = full_path.segments.last().unwrap().identifier.name; if source_name.as_str() == "mod" || source_name.as_str() == "self" { </del> <ins> let mut source = full_path.segments.last().unwrap().identifier; let source_name = source.name.as_str(); if source_name == "mod" || source_name == "self" { </ins> resolve_error(self, view_path.span, ResolutionError::SelfImportsOnlyAllowedWithin); <ins> } else if source_name == "$crate" && full_path.segments.len() == 1 { let crate_root = self.resolve_crate_var(source.ctxt); let crate_name = match crate_root.kind { ModuleKind::Def(_, name) => name, ModuleKind::Block(..) => unreachable!(), }; source.name = crate_name; self.session.struct_span_warn(item.span, "`$crate` may not be imported") .note("`use $crate;` was erroneously allowed and  will become a hard error in a future release") .emit(); </ins> } <del> let subclass = ImportDirectiveSubclass::single(binding.name, source_name); </del> <ins> let subclass = ImportDirectiveSubclass::single(binding.name, source.name); </ins> let span = view_path.span; self.add_import_directive(module_path, subclass, span, item.id, vis); }

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: //! //! [rustc dev guide]: https://rustc-dev-guide.rust-lang.org/mir/index.html <del> // ignore-tidy-filelength </del> use crate::mir::interpret::{GlobalAlloc, Scalar}; use crate::mir::visit::MirVisitable; use crate::ty::adjustment::PointerCast;

moved the file to over 3k LOC, but I didn't fix it there and instead just annotated the file so tidy ignores it. We should probably split the mir types into separate submodules by the way they are used in MIR. I think we can start by pulling out e.g. terminators and all their sub-types to a submodule <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim Will be interested in picking this up


Question: all( not(target_arch = "aarch64"), not(target_arch = "powerpc"), <ins> not(target_arch = "s390x"), </ins> not(target_arch = "x86_64") ), all(target_arch = "aarch64", any(target_os = "macos", target_os = "ios")),

fails this test on native : (This is not a new failure, but I am cleaning up issues from downstream Red Hat bugzilla.)
We started discussing this in , and looking at the clang implementation here: I tried that minimal step with , but it still gives the same "Cannot select" error. I don't see any lowering of in like other targets, only stuff implementing the calling convention. So I guess we do need custom support, or perhaps the clang bits could be moved down into the LLVM lowering?
Hi , I ran into the same problem and noticed you had already opened an issue. I've now submitted a PR to implement valist and vaarg for s390x to fix this.


Question: let hir_id = self.tcx().hir().as_local_hir_id(def_id).unwrap(); let instantiated_ty = self.resolve(&opaque_defn.concrete_ty, &hir_id); <ins> debug_assert!(!instantiated_ty.has_escaping_bound_vars()); </ins> let generics = self.tcx().generics_of(def_id); let definition_ty = if generics.parent.is_some() {

cc
Am I correct in assuming that this should not compile, but report an error about returning a reference to the local variable ? Or is the self-borrowing generator part what makes this work? so the is part of the generator struct and the is the yielded thing? I'll try pretty printing to the expanded HIR, since I'm not sure what's going on there
Expanded version:
No, this should definitely compile. isn't yielded, but yes, it's a local variable inside the generator (that references another local variable in the generator).
Hmm, so because the generator contains references, it has lifetimes, but these lifetimes actually refer to the generator again? Do we have a special kind of lifetime that we use for this? We should just ignore those generator lifetimes for existential types.
There's no special lifetime afaik (cc
We should ignore all bound regions. Function pointers have the same issue:


Question: src_href: src_href.as_deref(), }; <del> let heading = item_vars.render().unwrap(); buf.write_str(&heading); </del> <ins> item_vars.render_into(buf).unwrap(); </ins> match *item.kind { clean::ModuleItem(ref m) => item_module(buf, cx, item, &m.items),

A further performance improvement here would be to make sure that impls , in which case we could use rather than , avoiding the allocation of a temporary here. internally seems to just hold a and it has and methods already, so perhaps it would make sense to implement that trait? I'm not sure how big/relevant the performance improvement would be. Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Since implementers get a generated for them by Askama's macro, the simpler way to get the meat of this change would probably be to call
claim Let me take a stab at it :)


Question: expr: &hir::Expr<'_>, found: Ty<'tcx>, expected: Ty<'tcx>, <ins> mismatch_span: Span, </ins> ) -> bool { let map = self.tcx.hir();

I tried this code on nightly: I expected to see this happen: compiler does not panic. Instead, this happened: compiler panics and suggests I open a bug report. I initially posted to , but says this is a different issue, despite panicking on the same line in . (Though I'm realizing now that might be the proximal cause but not very related to the root cause.) : <details<summaryPanic message</summary<p</p</detailsThanks all for maintaining Rust, by the way.
Thanks!
searched nightlies: from nightly-2022-12-01 to nightly-2023-01-21 regressed nightly: nightly-2023-01-07 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
It's , i'll fix it unless someone beats me to it since I'm busy this weekend
Hi it's Justin from Commure :wave:. I found a compiler panic you made :grinning:
sorry for causing you trouble


Question: && adt.is_fundamental() { for ty in generics { <del> if let Some(did) = ty.def_id(self.cache) { dids.insert(did); } </del> <ins> dids.extend(ty.def_id(self.cache)); </ins> } } }

Generated rustdoc JSON for every one of dozens of crates I've looked at seems to contain unexpected inlined items that look like an block and its contents. I expected to see this happen: rustdoc JSON file contains only the items defined or re-exported by the corresponding crate. Instead, this happened: the rustdoc JSON file contains items like this: In this example, is and here are the names of the items contained in that impl (also part of the rustdoc JSON): Similarly, you can find items from : Invocation for generating rustdoc JSON: : You can find a variety of pre-generated rustdoc JSON files with this issue here: Briefly discussed in Zulip: https://rust- I'll have to work around this behavior to shield , which uses the same codebase as the playground link above. I can hold off on updating the playground for, say, another week, but at some point I'll need to upgrade it to include my workaround which means those items will cease being shown. label +T-rustdoc +A-rustdoc-json
Possibly duplicate of
Might be! Definitely at least some overlap, not entirely sure if duplicate. Do you mind if I ship the workaround for this in cargo-semver-checks and the playground, which will hide these items from our lints and from queries in the playground?
Yeah, it's easy enough to reproduce in raw json, I'm not worried about the repro breaking.


Question: <ins> error: trait objects without an explicit `dyn` are deprecated --> $DIR/issue-61963.rs:20:14 | LL |     bar: Box<Bar>, |              ^^^ help: use `dyn`: `dyn Bar` | note: lint level defined here --> $DIR/issue-61963.rs:3:9 | LL | #![deny(bare_trait_objects)] |         ^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>

One of the many new (or newly enabled by default) warnings in Servo in today’s Nightly: The suggestion is wrong, which means also fails and therefore does not apply fixes for (the many) other warnings where the suggestion is correct.
Triage: Preliminarily assigning P-high before Felix reviews this.
Also cc since iirc you did some macro related work here.
Possible solution: when a warning’s span is exactly a macro invocation, don’t emit a “suggested fix” that is likely wrong. (But still emit a warning.)
We have that check for most suggestions, but it might be missing for . Was this in latest nightly? I know a couple of these have been fixed in the past few weeks.
This is in rustc 1.37.0-nightly ( 2019-06-18). works around this and allows ’ing the rest of the warnings (namely old syntax for inclusive ranges) or warnings in other crates.
Oh. I just noticed the suggestion. I’d missed it in that blob of text.
Apologies for the time this has taken - I've struggled to find time to dig in to this. So far, I've managed to make a smaller example (it still depends on , and ) that reproduces the issue, you can find it in (run in the directory).
Thanks to some help from I've now got a minimal test case w/out any dependencies that outputs the same tokens that the reduced example from servo did (you can see it in ). When inspecting the span that the lint is emitted for, it isn't marked as coming from a macro expansion, and it appears that it was created that way during the macro expansion. I'd appreciate any opinions on what the correct fix is here - is it a bug in / that they output what appears to be incorrect spans? Should rustc be able to handle this case? If so, where should I be looking to mark the span or what check should I be performing to identify it as a result of macro expansion?
cc
I believe this is a compiler bug, not something that needs a fix in syn or quote. is a call_site span. It is the span of tokens in macro output that are not attributable to any particular input token. Usually that will be most of the tokens in any macro output; diagnostics need to take this into account.


Question: <ins> // Note: this test is paired with logo-class.rs. // @has logo_class_default/struct.SomeStruct.html '//*[@class="logo-container"]/img[@class="rust-logo"]' '' // @has logo_class_default/struct.SomeStruct.html '//*[@class="sub-logo-container"]/img[@class="rust-logo"]' '' pub struct SomeStruct; </ins>

In RustCrypto crates we use which changes style depending on preferred theme using CSS rules. You can see the for an example which uses it. But the problem is how the logo gets rendered on dark themes: ! ! The reason for such horrible result is the white shadow filter applied to the logo. I understand why it was , but I think it's a wrong approach, especially for projects which aim to properly support dark themes in their media files.
There was a mention back when this was implemented about how it is not possible for a media query approach to work, when I look at the sha2 docs it looks like ! because I use a light theme generally in my browser, but have rustdoc explicitly set to a dark theme. I'm confused why the outline is being applied to these docs though, was meant to only apply it to the default rust logo, and I don't see any relevant newer PRs when searching for .
I believe I broke this in In we are supposed to apply the class only when the logo is the default one. In I missed that distinction and now the always gets the rust-logo class, even when it's a custom logo. I'll fix.
By the way, to confirm what said: the media query embedded in the SVG isn't really right. That gets the browser's preferred light/dark mode, but the user may have overridden that in rustdoc settings. As a concrete example, I'm using Chrome on Linux, which doesn't have a light/dark mode setting. I can select a dark theme in rustdoc settings, which will get me this for the Rust Crypto logo (with applied): ! That's still an improvement over the status quo, and overall I think it's fine. But if we really wanted to support theme-sensitive logos perfectly, I think we'd need to offer separate configuration options for a light logo and a dark logo.
I believe that the media query approach is a correct one in principle. But I agree that, unfortunately, the current state of browsers is far from ideal, e.g. it would be nice to have a way to switch preferred mode for a page using CSS or JS. I'm using Chrome on Linux, which doesn't have a light/dark mode setting Well, it kind of has. Try launching it with (I don't have Chrome installed, but I think it should work similarly).


Question: .and_modify(|e| { *e = (e.0.clone(), Some(rhs.ty().unwrap().clone())) }) <del> .or_insert((None, Some(rhs.ty().unwrap().clone()))); </del> <ins> .or_insert(( PolyTrait { trait_: trait_.clone(), generic_params: Vec::new(), }, Some(rhs.ty().unwrap().clone()), )); </ins> continue; }

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: else_ty) } None => { <del> check_block_no_value(fcx, then_blk); ty::mk_nil() </del> <ins> infer::common_supertype(fcx.infcx(), infer::IfExpressionWithNoElse(sp), false, then_ty, ty::mk_nil()) </ins> } };

I apologize in advance if this is a separate issue. With the map() generic function from the tutorial: That code gives a nice error message: However, remove the assignment and what should be the same error message becomes:
Yes, that is unrelated to this issue. You're seeing an expected type mismatch error since the return type of main() is () and your samples result in two different non-() results.
Thanks I was one hour into learning Rust when I came across this. I understand what is going on now. I still think the error message could be improved to mention that "expected " is referring to the return type of main(). That simple clue could help people not as familiar with Rust to remember the semicolon rule to turn a statement into an expression.
Not critical for 0.7, but improving error messages is always good. Nominating for milestone 5.
declined. this is bad but it's not a blocker.
Confirmed that the situation is unchanged.
This is still an issue.
Bug triage. Still an issue.
Very, very small change:


Question: if !self.any_library { // If we are building an executable, only explicitly extern // types need to be exported. <del> if has_custom_linkage(self.tcx, search_item) { </del> <ins> let codegen_attrs = if self.tcx.def_kind(search_item).has_codegen_attrs() { self.tcx.codegen_fn_attrs(search_item) } else { CodegenFnAttrs::EMPTY }; let is_extern = codegen_attrs.contains_extern_indicator(); let std_internal = codegen_attrs.flags.contains(CodegenFnAttrFlags::RUSTC_STD_INTERNAL_SYMBOL); if is_extern || std_internal { </ins> self.reachable_symbols.insert(search_item); } } else {

I tried this code: I expected to see this happen: Compiles successfully. Instead, this happened: Fails with this error: nightly-2024-06-26 and earlier. nightly-2024-06-27 and later, starting with . See for a discussion of the issue. : cc
To elaborate, the difference is in symbols.o. Here's a dump of symbols.o before the change: And here's after: Spot the difference. Spoiler: is now present.
So is that right or wrong? The static is "used" so marking it exported to ensure it does not get optimized away seems to make sense? I don't understand why this is a problem only on Windows.
Well that's not a problem per se but if we want to do that then we have to do it properly. is defined as a in (on my machine). This is linked directly and not in a lib file. So it's already being included. There's no reason for to include it. The only issue is that is being emitted as a comdat, meaning the linker is still allowed to remove it. We could just not do that (or add a linker directive). But that's a pre-existing issue.
I don't understand any part of that.^^ Should my PR get reverted or is there a better way to fix this regression? If there is a better way, I am afraid I lack the knowledge to implement and test it. I don't understand symbol handling on Linux, let alone on Windows.
I don't know enough about the Rust compiler to say. My complete guess would be that was silently broken before but now it's nosily broken.
Hm, who would understand our Windows linking story? ?
After CGU partitioning, we try to internalize symbols when possible. What is surprising to me is that this process only looks at export level, ignoring used attribute (in the contrast to say the internalization during fat LTO). Consequently we have a situation where synthetic object file references a symbol that is no longer exported (on Linux that does not result in a linking error, even though reference is unresolved). Anyway, if the consequence of would be to export those symbols for no reason, that seems rather counter productive to me.


Question: if !self.any_library { // If we are building an executable, only explicitly extern // types need to be exported. <del> if has_custom_linkage(self.tcx, search_item) { </del> <ins> let codegen_attrs = if self.tcx.def_kind(search_item).has_codegen_attrs() { self.tcx.codegen_fn_attrs(search_item) } else { CodegenFnAttrs::EMPTY }; let is_extern = codegen_attrs.contains_extern_indicator(); let std_internal = codegen_attrs.flags.contains(CodegenFnAttrFlags::RUSTC_STD_INTERNAL_SYMBOL); if is_extern || std_internal { </ins> self.reachable_symbols.insert(search_item); } } else {

Ah, the behaviour was working to spec before: So I think I'd agree that is the wrong approach and should be reverted because this currently ends up conflating different things. Maybe changes elsewhere would fix this but I don't want to speculate.
the separate issue you pointed out earlier in is presumably still relevant for ?
Could this explain recent CI flakiness? The failure at and a couple other failed merges (linked on that thread, also the retries) have been msvc linker errors.
That's unfortunate. :/ Our reachable symbol code is such a spaghetti mess... I guess I'll just have to copy-paste more things into Miri then. :shrug: I am traveling right now, I'd appreciate if someone else could do the revert.
The following patch should fix the incorrect internalization I mentioned earlier: As for the question whether those symbols should be exported in the first place, it might be necessary for COFF and . The following code suggests that would not have the desired effect otherwise I don't have access to windows environment at the moment to verify that, so I don't plan to work on this myself.
Ooh this is also the stuff that also broke several ci-runs already ...
Looks like this did not fully fix the ci failures :melting_face:
Makes sense: some CI failures look non-deterministic, while we'd expect this error not to be.
Alternative approach for Miri:


Question: <ins> error[E0271]: type mismatch resolving `<&i32 as Deref>::Target == String` --> $DIR/default-body-type-err.rs:7:22 | LL |     fn lol(&self) -> impl Deref<Target = String> { |                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `i32`, found struct `String` LL | LL |         &1i32 |         ----- return type was inferred to be `&i32` here error: aborting due to previous error For more information about this error, try `rustc --explain E0271`. </ins>

Here's a MVCE: I expected to see this happen: compilation fails because I'm clearly returning an instead of a Instead, this happened: bad codegen ("async fn resumed after completion") :
This is specifically a bug with default body in traits, this doesn't happen in s. I'll check it out, it's probably a very simple fix.


Question: <ins> trait Trait {} impl Trait for i32 {} // Since `Assoc` doesn't actually exist, it's "stranded", and won't show up in // the list of opaques that may be defined by the function. Make sure we don't // ICE in this case. fn produce<T>() -> impl Trait<Assoc = impl Trait> { //~^ ERROR associated type `Assoc` not found for `Trait` 16 } fn main () {} </ins>

<!-- ICE: Rustc '' 'error: internal compiler error: could not unify with revealed type:', 'error: internal compiler error: could not unify with revealed type:' 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: [checkwellformed] checking that is well-formed [checkmodtype_wf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
crashes since cc
Note: ICEs aren't crashes, we have a separate label for crashes (they mean segfaults and similar)
ungraceful exit of the compiler has been observed since :upsidedownface:
This has nothing to do with non-lifetime binders. I somewhat expect that when a "minimized" repro is tagged with a feature tag, there has been an attempt to check that the ICE is actually dependent on the feature, since that affects the prioritization of the issue.


Question: <ins> error[E0133]: use of extern static is unsafe and requires unsafe function or block --> $DIR/issue-28575.rs:8:5 | LL |     FOO() |     ^^^ use of extern static | = note: extern statics are not controlled by the Rust type system: invalid data, aliasing violations or data races will cause undefined behavior error: aborting due to previous error For more information about this error, try `rustc --explain E0133`. </ins>

rustc+cargo 1.40.0 Debian testing packages report the following ICE (which does not go away after a cargo clean): It can be reproduced by trying to build against
Can you try this on nightly?
Once the ICEBreakers-CleanupCrew is announced (which I think will be happening very soon), we should advertise this bug on it (at least the reduction to MCVE part of it); see
triage: P-high for initial investigation (i.e. identifying actual severity), removing nomination.
ping icebreakers-cleanup-crew
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rust- cc
Note that when I had a go at building on my Mac laptop, it failed with this message: This is due to in the source crate: So if you are on a Mac laptop, it may or may not be worth your effort to investigate this. (It is probably easy to work around, but I figure I'd let people know up front.)
Oops, right, you'll want to just drop that line. It shouldn't have any other effect, its only there due to (at least previously, based on my super-cursory read) libstd calling regular fsync() on OSX, which historically, well, didn't fsync.
I looked at this a bit more. I see the ICE on stable and beta. I do not see the ICE on nightly.


Question: <ins> error[E0133]: use of extern static is unsafe and requires unsafe function or block --> $DIR/issue-28575.rs:8:5 | LL |     FOO() |     ^^^ use of extern static | = note: extern statics are not controlled by the Rust type system: invalid data, aliasing violations or data races will cause undefined behavior error: aborting due to previous error For more information about this error, try `rustc --explain E0133`. </ins>

On nightly, I instead get the following error: <details<summaryClick here to see error diagnostics</summary</details
Possibly associated: Possibly associated: I am not seeing the ICE in: searched nightlies: from nightly-2019-10-01 to nightly-2019-11-01 regressed nightly: nightly-2019-10-08 searched commits: from to regressed commit: source code: built against <details<summaryCOLLAPSIBLE ERROR STACKTRACE</summary<p</detailssearched nightlies: from nightly-2019-11-01 to nightly-2020-01-31 fixed nightly: nightly-2019-12-08 searched commits: from to fix commit: source code: built against Possibly here: -
Reduced for in the crate (still depends on ):
This is happening somewhere in item-bodies checking, if I remove the body of with the error goes away.
Ok, I don't have more time to spend on this, I pushed some deletions to
Got it down to two files, but they have to be in different crates: : :
A little smaller: : : <details<summarybacktrace</summary</details
This is a duplicate of , judging by the error message and the fact that I just confirmed as the fixing commit for the reduced example that I created over there. modify labels to -E-needs-mcve.


Question: <ins> error[E0133]: use of extern static is unsafe and requires unsafe function or block --> $DIR/issue-28575.rs:8:5 | LL |     FOO() |     ^^^ use of extern static | = note: extern statics are not controlled by the Rust type system: invalid data, aliasing violations or data races will cause undefined behavior error: aborting due to previous error For more information about this error, try `rustc --explain E0133`. </ins>

Take the following code: Attempting to compile this results in the following: I think the compiler should fail with something along the lines of "you attempted to use a complex type () where I expected an immediate".
edit: not sure if these symptoms are the same, but here's what I stumbled across. The following code generates a similar result for me: The and struct seem to be required, else the ICE is not triggered. Output
No longer reproduces:


Question: <ins> error[E0133]: use of extern static is unsafe and requires unsafe function or block --> $DIR/issue-28575.rs:8:5 | LL |     FOO() |     ^^^ use of extern static | = note: extern statics are not controlled by the Rust type system: invalid data, aliasing violations or data races will cause undefined behavior error: aborting due to previous error For more information about this error, try `rustc --explain E0133`. </ins>

We handle intrinsics in an odd way, we "inline" them in the current crate, and this might be a symptom of that twisted logic.
intrinsic-ABI functions should probably be disallowed as function pointers. That is, you should only be allowed to call them. This is the current situation, as calls to intrinsics actually just generate code at the call site.
That's not the problem, really, I believe we already have code to generate the shims. The problem is that we don't resolve intrinsics sanely and we rely on the ABI in the type, instead of always dealing with the paths to them and whatnot.
I don't think we have code for creating the shims, even. It's more that the ABI isn't actually defined anywhere, and we use an alternate callee to avoid generating an actual call.
We haven't had code for generating shims around intrinsics for a long time. As alludes to, this is because in almost all cases the actual function would be one or two instructions long. This is consistent with how C/C++ compilers handle intrinsics, generating code inline. Best I can tell, whether or not a given intrinsic can be used as a function in C is dependent on the intrinsic in question.
No longer ICEs ()
It requires now.
Ah, ok. Still no longer ICEs, but fails with a linker error (), if the distinction matters.
I think this has been fixed -- marking as E-needstest. Did you mean to self-assign this?
This seems like it could be made into an easy issue for newcomers.
This is now caught by .


Question: <ins> error[E0133]: use of extern static is unsafe and requires unsafe function or block --> $DIR/issue-28575.rs:8:5 | LL |     FOO() |     ^^^ use of extern static | = note: extern statics are not controlled by the Rust type system: invalid data, aliasing violations or data races will cause undefined behavior error: aborting due to previous error For more information about this error, try `rustc --explain E0133`. </ins>

rustc just crashes with no useful errors. I guess you're not supposed to be able to do this anyway and it works if either are const instead of static but it shouldn't crash. Tested with latest nightly and 1.0.0-beta.2 on windows 64-bit.
No longer crashes:
E-needstest.
Triage: not aware of any tests being .
It seems that the E0394 error was removed in and the tests were moved from compile-fail and ui/error-codes to run-pass.


Question: // *in Rust code* may unwind. Foreign items like `extern "C" { // fn foo(); }` are assumed not to unwind **unless** they have // a `#[unwind]` attribute. <del> } else if !cx.tcx.is_foreign_item(id) { </del> <ins> } else if id.map(|id| !cx.tcx.is_foreign_item(id)).unwrap_or(false) { </ins> Some(true) } else { None

and are both broken on s390x since Rust 1.28. When is built without debuginfo, the tests hang with their backtracing processes stuck in a loop. With debuginfo, it fails with output like: I believe the problem is this part of : where doesn't identify that is a 64-bit platform. See also alexcrichton/backtrace-rs. I plan to update that here when it's published, and make a similar fix in .
fixes the backtrace when is built with debuginfo, but I'm still getting a hang without. In GDB, it looks like the unwinder gets to the that catches panics, then loops unwinding that same PC forever. This part of the regression is older -- happens on 1.27.2 as well, but 1.26.2 is fine. Binaries from the older version don't appear to have a distinct symbol at all, but maybe that's just inlined differently. I'm bisecting for that hang now.
Bisecting pointed me at (cc which attributes to all functions. For s390x the base features actually include a removal, . But it doesn't look like the features are applied to the synthesized (), and as a result it doesn't get inlined anymore since it has more features (w/ ) than the callee. We probably should apply target-features to as well. I don't know why the non-inlined can't be unwound -- maybe we need to force ? By default GDB backtrace stops at crate , but tries to go further: Maybe Rust's could have a similar defensive check, at least.
Nice find Definitely makes sense to me, and this should be fixed up (at least the business) in
With , , and , I believe we have this fixed.


Question: Box::new(MaybeUninit::uninit()) } <del> // FIXME: add a test for a bigger box. Currently broken, see // https://github.com/rust-lang/rust/issues/58201. </del> <ins> // https://github.com/rust-lang/rust/issues/58201 #[no_mangle] pub fn box_uninitialized2() -> Box<MaybeUninit<[usize; 1024 * 1024]>> { // CHECK-LABEL: @box_uninitialized2 // CHECK-NOT: store // CHECK-NOT: alloca // CHECK-NOT: memcpy // CHECK-NOT: memset Box::new(MaybeUninit::uninit()) } </ins> // Hide the LLVM 15+ `allocalign` attribute in the declaration of __rust_alloc // from the CHECK-NOT above. We don't check the attributes here because we can't rely

The following code generates some really awful LLVM IR: The same happens with . Cc who made me write these tests, and
Feels like an LLVM limitation to me. It should be replacing the with a (or a of poison when that becomes available).
For reference: LLVM is capable of optimizing a memcpy of undef alloca away, this just runs into the usual limitation that all of memcpyopt doesn't work across BBs.
This is such a long-standing issue. Seems like it might be wise to have someone working on fixing this.
Someone has already worked on this, see It's a bit hard to track, but unfortunately this got reverted again (multiple times). I suspect that this is only going to get really resolved once memcpyopt moves to memssa -- which someone has also worked on in the past (), but which never really went anywhere.
The alloca and memcpy are no longer present on nightly, as a result of .
The FIXME in the test is still there, needs a test.


Question: addClass(search, "hidden"); removeClass(main, "hidden"); document.title = titleBeforeSearch; <ins> // We also remove the query parameter from the URL. if (browserSupportsHistoryApi()) { history.replaceState("", window.currentCrate + " - Rust", getNakedUrl() + window.location.hash); } </ins> } // used for special search precedence

mdbook v4.6+ has a feature that pressing ESC removes query components from URLs (for example ). The feature was implemented in rust-lang/mdBook. It would be nice if rustdoc offers the same kind of that feature. This is, for example, an URL that contains query components in rustdoc: When users share URLs to an API, they don't have to remove the query manually.
could you share some thoughts about this feature request? If possible, could you mentor contributors how to implement this ?
I think it's a good idea. Gonna take a look at how to do it.
Can we reopen this issue ? I think only removes the query component when we remove keywords in search bar. This issue is about adding a keyboard shortcut.
Oh I see, my bad. Reopening!


Question: self.parent_scope.module = old_module; } else { match &item.kind { <del> ItemKind::Impl(box ast::Impl { of_trait: Some(..), .. }) => { </del> <ins> ItemKind::Impl(box ast::Impl { of_trait: Some(trait_ref), .. }) => { if let Some(partial_res) = self.resolver.get_partial_res(trait_ref.ref_id) && let Some(res) = partial_res.full_res() && let Some(trait_def_id) = res.opt_def_id() && !trait_def_id.is_local() && self.visited_mods.insert(trait_def_id) { self.resolve_doc_links_extern_impl(trait_def_id, false); } </ins> self.all_trait_impls.push(self.resolver.local_def_id(item.id).to_def_id()); } ItemKind::MacroDef(macro_def) if macro_def.macro_rules => {

<!-- 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. --Nightly 2022-08-11 worked fine, trying to upgrade from it. : <details<summary<strongBacktrace</strong</summary<p</p</details
, same rustc version
label E-needs-mcve -T-compiler +T-rustdoc
Error: Label needs-mcve can only be set by Rust team members Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
I don't have a MCVE but the same problem on the same nightly version happens with a dependency of . Sounds awfully similar to also involving deps, but that one's definitely fixed.
Pinging since they're the last one who worked on this. Maybe you have an idea?
Somewhat minimal example: Removing the impl avoids the bug.
This happens with beta too:
Fixed in


Question:
var params = getQueryStringParams(); if (params && params.search) { var search = getSearchElement();  search.innerHTML = "
Loading search results...
";   search.innerHTML = "
" + getSearchLoadingText() + "
";  showSearchResults(search); }

Enable "Directly go to item in search if there is only one result" option on Settings ! Search an unique item in search box generated by rustdoc, it will lead you to the doc of that item. Click the go back button in browser, the page will change to previous search result and go forward to the doc of the searched item. How to reproduce the issue: Go to std doc: Search for "PhantomData" Click the go back button in browser. : 1.47.0-nightly ( 2020-08-20) cc
Well, you can but since there is only one result, it puts you back haha. (Ok, we can consider it as bug, but it's a funny one)
The single search result page can be elided using the to disappear it, leaving the back button to take you to before the search. I believe this would be the desired behavior?
What about detecting the key release to check if there's a single item and redirect, instead of redirecting after calculating the results?


Question: /// `&mut T` references can be freely coerced into `&T` references with the same referent type, and /// references with longer lifetimes can be freely coerced into references with shorter ones. /// <ins> /// Reference equality by address, instead of comparing the values pointed to, is accomplished via /// implicit reference-pointer coercion and raw pointer equality via [`ptr::eq`], while /// [`PartialEq`] compares values. /// /// [`ptr::eq`]: ptr/fn.eq.html /// [`PartialEq`]: cmp/trait.PartialEq.html /// /// ``` /// use std::ptr; /// /// let five = 5; /// let other_five = 5; /// let five_ref = &five; /// let same_five_ref = &five; /// let other_five_ref = &other_five; /// /// assert!(five_ref == same_five_ref); /// assert!(five_ref == other_five_ref); /// /// assert!(ptr::eq(five_ref, same_five_ref)); /// assert!(!ptr::eq(five_ref, other_five_ref)); /// ``` /// </ins> /// For more information on how to use references, see [the book's section on "References and /// Borrowing"][book-refs]. /// /// [book-refs]: ../book/second-edition/ch04-02-references-and-borrowing.html /// <ins> /// # Trait implementations /// </ins> /// The following traits are implemented for all `&T`, regardless of the type of its referent: /// /// * [`Copy`]

This page: It's not obvious that reference equality is accomplished via implicit reference-pointer coercion plus . The docs mention this, but I would not look there to find reference equality. The reference primitive page is someplace I would look for info about reference equality. Update this page to discuss reference equality, and link to .
Can I help with this issue?
Still waiting for your reply
Sorry, it looks like got to this now, in


Question: // Ensure that `libLLVM.so` ends up in the newly build compiler directory, // so that it can be found when the newly built `rustc` is run. <del> dist::maybe_install_llvm_dylib(builder, target_compiler.host, &sysroot); </del> <ins> dist::maybe_install_llvm_runtime(builder, target_compiler.host, &sysroot); dist::maybe_install_llvm_target(builder, target_compiler.host, &sysroot); </ins> // Link the compiler binary itself into place let out_dir = builder.cargo_out(build_compiler, Mode::Rustc, host);

Since , has been distributed in the component in two locations: (presumably as a runtime dependency of ) (not sure, maybe for linking custom drivers?) likely belongs in the component, if the duplication can't be avoided <hr/The difference can be seen in these consecutive nightlies' components: has just the second maybe it's used via relative by ? separate codegen backends are gone, maybe we should just try removing it? first nightly to include has both copies All 3 of those files are identical (even across nightlies, yay for deterministic builds): One fascinating aspect is that the size only increases from to , despite alone being uncompressed, so compression is really helping. Even the only goes from to . (I'm using archive sizes from the and directory listings in , FWIW) <hr/This part of the build system seems relevant, but I'm not sure which of the two this creates: cc
cc -- you've touched code related to this a bunch recently I think, so maybe would have some time to investigate fixing this. I suspect we want to only ship one LLVM per tarball, at least, though ideally we would only have just the one LLVM library total as well.
Half-way through writing up this issue I realized the connection. I'd suggest we try to get rid of the copy and see what breaks, it's possible it's been dead weight for a while now. And only if we have to keep both for some odd reason, we'd move it to .
The purposely orders the tarred files so that similar filenames are adjacent in the compression stream, especially in hope of helping with such duplicate files. I think we may still want the copy for the odd cross-compiled tool using , but that definitely belongs in .
Is that... even possible? Is a per-target component in the same way is?
Yes it is -- try -- but I don't know if anyone really needs that...
Actually, can you try something like cross-compiling a copy of to , after deleting the per-target ? I suspect that it would actually run just fine on a host, because 's s should only really contain the information and maybe some object code that is missing (which we could get rid of if we kept MIR for everything but idk how feasible that is). That is, the result of linking against should still use at runtime, so in is unnecessary. But maybe I'm missing something.


Question: // Ensure that `libLLVM.so` ends up in the newly build compiler directory, // so that it can be found when the newly built `rustc` is run. <del> dist::maybe_install_llvm_dylib(builder, target_compiler.host, &sysroot); </del> <ins> dist::maybe_install_llvm_runtime(builder, target_compiler.host, &sysroot); dist::maybe_install_llvm_target(builder, target_compiler.host, &sysroot); </ins> // Link the compiler binary itself into place let out_dir = builder.cargo_out(build_compiler, Mode::Rustc, host);

Like running the cross-compiled on a host without anything more than the component?
Hmm, I can't actually get cross-builds to work with . I this to : ... so it would pick that up from the sysroot. Trying to cross-compile i686, I get: I do have both i686 and x8664 builds of in the sysroot. I suspect the error is because the i686 build has different metadata than my host build, so it can't find the one it wants for the host. That may mean that is really tied to being used on the same host. It works if I just compile native x86_64 though. Then I tried removing the , and it gets essentially the same error as : AFAICS, building normal crates still works fine with that extra removed though. In short: Cross-compiling with seems broken -- maybe it should be shipped native-only. The only difference would be in the manifest created for rustup. Linking to crates will inherit , so that needs to be in the library path.
Ah, fascinating. What happens if you build such an executable and then remove the component entirely? Can it pick up the dylibs outside or does it hardcode the paths inside?
The final executable still isn't actually linked to LLVM, since it didn't need any of those symbols: I can run this with , which set , or even if I set that path myself. But doesn't work if we've removed that library, since needs itself.
Okay, it being dependent on makes sense. Overall, probably the safe thing to do would be to move the duplicate to , oh well.
Oh, also needs LLVM, and those binaries are installed in with RUNPATH . I guess they might be able to find the LLVM in anyway?


Question: let mode = match tcx.hir().body_owner_kind(hir_id) { HirKind::Closure => return None, <del> HirKind::Fn if tcx.is_const_fn(def_id) => ConstKind::ConstFn, </del> <ins> // Note: this is deliberately checking for `is_const_fn_raw`, as the `is_const_fn` // checks take into account the `rustc_const_unstable` attribute combined with enabled // feature gates. Otherwise, const qualification would _not check_ whether this // function body follows the `const fn` rules, as an unstable `const fn` would // be considered "not const". More details are available in issue #67053. HirKind::Fn if tcx.is_const_fn_raw(def_id) => ConstKind::ConstFn, </ins> HirKind::Fn => return None, HirKind::Const => ConstKind::Const,

As shown in const-qualification can ignore some s, in the context of libcore / rustc crates: This should not compile without "miri unleashed"; const-qualification does not see this function as const since the unstable feature is not enabled, and thus does not check it. It outside of libcore, nor . cc More discussion is also available . I have a fix and will post a PR shortly. There are a couple of existing cases in where this matters (for and ), and I'll fix those at the same time.


Question: /// # Examples /// /// ``` <del> /// #![feature(ptr_hash)] </del> /// use std::collections::hash_map::DefaultHasher; /// use std::hash::{Hash, Hasher}; /// use std::ptr;

Implemented in as .
Updated from: to: in . Thanks
Seems straightforward enough to me. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [ ] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete.
Question: We have , should we have as well?
We could, but that’s going quickly into diminishing returns IMO. You can always use something like


Question: <del> use crate::spec::{LinkerFlavor, PanicStrategy, Target, TargetResult}; </del> <ins> use crate::spec::{LinkerFlavor, Target, TargetResult}; </ins> pub fn target() -> TargetResult { let mut base = super::windows_msvc_base::opts();

The and targets force panic=abort. said : This looks related to , which points at these now-merged LLVM changes: It's possible that we do not need to force panic=abort anymore for arm64 Windows as a result. What's the best way to determine if this is still required?
Theoretically the way to fix this issue is: First Next, run the build Finally, run the tests If that all passes, then the change can land! The tests may be able to be skipped, and some tests may fail, so it may be possible to switch the defaults and we can fixup bugs later. I don't personally have hardware to test these changes on myself, though.
I occasionally have access to a Windows arm64 laptop, so I'll try and get a rustc build going on it at some point.


Question: //~^ ERROR doesn't implement } <del> pub fn main() { } </del> <ins> trait Foo<T> { const SIZE: usize = core::mem::size_of::<Self>(); //~^ ERROR the size for values of type `Self` cannot be known at compilation time } trait Bar: std::fmt::Display { const SIZE: usize = core::mem::size_of::<Self>(); //~^ ERROR the size for values of type `Self` cannot be known at compilation time } trait Baz where Self: std::fmt::Display { const SIZE: usize = core::mem::size_of::<Self>(); //~^ ERROR the size for values of type `Self` cannot be known at compilation time } trait Qux<T> where Self: std::fmt::Display { const SIZE: usize = core::mem::size_of::<Self>(); //~^ ERROR the size for values of type `Self` cannot be known at compilation time } trait Bat<T>: std::fmt::Display { const SIZE: usize = core::mem::size_of::<Self>(); //~^ ERROR the size for values of type `Self` cannot be known at compilation time } fn main() { } </ins>

The following code errors, and the error contains a suggestion how to fix the error: The error message states: Obviously, writing is invalid syntax.
It seems the issue is that it's inserting the suggestion after the trait name and before the generics, rather than after the generics.
No-nightly-features code that exhibits the same problem: label -requires-nightly (should the F-labels go as well?)


Question: AscribeUserTy, /// The data of a user variable, for debug info. VarDebugInfo, <del> /// PlaceMention statement. PlaceMention, </del> } #[derive(Copy, Clone, Debug, PartialEq, Eq)]

<!-- 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: You need edition 2015 or 2018 to reproduce this. `
Looks to me like the problem is that doesn't realize that a makes the place not dead.
The bug is . is a nonuse, but should get the same treatment as a . I feel obligated to mention that I have repeatedly warned that these bugs are going to happen. We should really stop using in optimizations. It was written for borrowck. (To be clear: I am as much at fault for this as anyone, I originally wrote this code).
I was wondering why always has strangely unhelpful information for optimizations...
Why is this not just a bug in PlaceContext assignment?
See my comment in the PR - in general, my understanding is that the definition of placecontext is what it is because that's what makes sense in some other part of the compiler. If we start changing placecontext now to have the information that's useful to optimizations, I worry we'll just end up making those parts of the compiler buggy


Question: let node_id = scope.node_id(self.tcx, &self.region_scope_tree); match self.tcx.hir.find(node_id) { Some(hir_map::NodeStmt(_)) => { <del> db.note("consider using a `let` binding to increase its lifetime"); </del> <ins> if *sub_scope != ty::ReStatic { db.note("consider using a `let` binding to increase its lifetime"); } </ins> } _ => {} }

suggests but still won't give us a lifetime. We should not emit the if the required lifetime is for the inside the source presume there's some code already checking for producing the "borrowed value must be valid for the static lifetime" message, find that code and bubble up the knowledge about that until you have it in the scope of the "consider using a binding to increase its lifetime" message 't emit the message in that case 'll already fail a bunch of tests, I don't think you need any new tests. Running should succeed and give you a bunch of changes to commit. Check that all changes make sense and just commit them.
can I take this on if nobody is working on this?
All yours!
closing it, as required code change has been merged.


Question: <ins> error[E0596]: cannot borrow immutable `Box` content `*x` as mutable --> $DIR/issue-36400.rs:15:12 | 14 |     let x = Box::new(3); |         - consider changing this to `mut x` 15 |     f(&mut *x); |            ^^ cannot borrow as mutable error: aborting due to previous error </ins>

This code: produces a helpful error message: But the analogous code using a : gives an error which doesn't point at the binding :
This is fixed today. I'm going to mark as E-needstest since it feels like the kind of thing that's easy to regress on -- a UI test would be best here.


Question: <ins> error[E0596]: cannot borrow immutable `Box` content `*x` as mutable --> $DIR/issue-36400.rs:15:12 | 14 |     let x = Box::new(3); |         - consider changing this to `mut x` 15 |     f(&mut *x); |            ^^ cannot borrow as mutable error: aborting due to previous error </ins>

Before , this caused an LLVM error Afterwards, this causes an ICE (the rustc size is the correct one):
I am now getting a segfault in LLVM, but I'm uncertain whether that's actually the case, or just a local build problem.
Looks like called on a NULL pointer? Probably some missing check that something is indeed unsized, with actual metadata to go alongside it.
Appears to be fixed today. E-needstest.
It seems that a better diagnostic output is needed:
Why? I believe it's implemented as a feature now (maybe it should be ?).
it's unrelated to this issue, but rather to 's solution, merits at least a clarifying label pointing at the , as otherwise the compiler output makes you look at the following line exclusively, which isn't the cause for the . I know it definitely confused me_ :) Back to this issue, yes, the test in should be .


Question: <ins> error[E0596]: cannot borrow immutable `Box` content `*x` as mutable --> $DIR/issue-36400.rs:15:12 | 14 |     let x = Box::new(3); |         - consider changing this to `mut x` 15 |     f(&mut *x); |            ^^ cannot borrow as mutable error: aborting due to previous error </ins>

Triage: this no longer ICEs. <details<summaryMeta</summary: rustc 1.16.0 ( 2017-03-10) binary: rustc commit-hash: commit-date: 2017-03-10 host: x86_64-pc-windows-gnu release: 1.16.0 LLVM version: 3.9 </details


Question: [[package]] name = "ar_archive_writer" <del> version = "0.4.0" </del> <ins> version = "0.4.2" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "de11a9d32db3327f981143bdf699ade4d637c6887b13b97e6e91a9154666963c" </del> <ins> checksum = "01667f6f40216b9a0b2945e05fed5f1ad0ab6470e69cb9378001e37b1c0668e4" </ins> dependencies = [ "object 0.36.2", ]

<!-- 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. --I tried to build using a simple then . I expected to see this happen: linking success. Instead, this happened: MSVC link returns LNK2005 and fails to the static library. It most recently worked on: 1.77.2 <!-- Provide the version you are using that has the regression. --: This is caused by both and When creating stdlibs, each MR causes the Rust compiler to add an export of ; one comes from api-ms-win-core-synch-l1-2-0.dll and the other from This error will not be found until one consumes the Rust-generated library. I am filing this report to consolidate the ones in and <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details modify labels: +regression-from-stable-to-stable -regression-untriaged
cc
Using for a rust staticlib seems weird to me but cc
The purpose is to allow reexporting a subset of symbols on MSVC. This can be achieved with partial linking elsewhere, but this is not doable on Windows. I wrote about a specific application here:
Sorry, I'm confused, are you trying to create a dynamic or static library? The article that you linked to talks about static libraries, but the backtrace in the OP shows that you are creating a dynamic library.
Both: I'm using the Rust-produced static library through , plus a module definition file, to create a dynamic library. This is because (apart from size considerations) GNOME's gobject-introspection needs a shared library, and Meson will only accept targets that are generated by itself. Further context is here:
In this particular case, because of the imports present in the stdlib, linking something against the Rust-produced static librsvg is enough to trigger the issue.
I am still struggling to understand why is needed, at least for MSVC.


Question: [[package]] name = "ar_archive_writer" <del> version = "0.4.0" </del> <ins> version = "0.4.2" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "de11a9d32db3327f981143bdf699ade4d637c6887b13b97e6e91a9154666963c" </del> <ins> checksum = "01667f6f40216b9a0b2945e05fed5f1ad0ab6470e69cb9378001e37b1c0668e4" </ins> dependencies = [ "object 0.36.2", ]

So the DLL is created here: is used so that the DLL includes every single object in the staticlib, even if it's unneeded or indeed causes conflicts. But then is used to add a which presumably defines what actually gets exported from the DLL. What I'm not understanding is what would be different if, for MSVC, it just linked normally without ? I.e. using instead.
On MSVC, static linking doesn't let you reexport dependencies' symbols automatically, they're subject to DCE. . However, PE-COFF static libraries don't support symbol visibility, so the is there to make all Rust symbols private and keep only the librsvg ones. See e.g. and for consequences of not blocking out symbols like .
Sure but the should work regardless of if is used or not because using the export will force the linker to go looking for the symbol(s) listed in the file. E.g. as a test I have the following static lib (using to make symbols easier to find): Which I compile into a static lib using: rustc -O --crate-type=staticlib And I have the following file: Which for simplicity I compile via rustc but I'm using an empty file and also raw linker arguments: rustc -O --crate-type=cdylib -C link-args=" " This compiles and if I see the two functions I wanted: No std symbols are exported.
Independent of whether whole-archive is necessary for this specific use case, we should support linking rust staticlibs with whole-archive, even if because of the fact that not linking with whole-archive can mask linker errors, which will later show up when any change to the cgu partitioning is made, which often causes people to report a regression even though their crate is at fault.
If I repeat the above using even in this simple case I get a bunch of errors, not just : I'm not really sure if rustc can currently guarantee that whole archive will work without doing some of the work of a linker. Which sounds like a new feature and not specific to MSVC.
All duplicate symbol errors for are caused by That it works without is by accident and likely to break in case of cgu partitioning changes.


Question: [[package]] name = "ar_archive_writer" <del> version = "0.4.0" </del> <ins> version = "0.4.2" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "de11a9d32db3327f981143bdf699ade4d637c6887b13b97e6e91a9154666963c" </del> <ins> checksum = "01667f6f40216b9a0b2945e05fed5f1ad0ab6470e69cb9378001e37b1c0668e4" </ins> dependencies = [ "object 0.36.2", ]

Sure, and then if I compile the static library with and use whole archive then I get a whole slew of errors, which I'll spoiler for length <details<summarylinker errors</summary</details
There are also some technical details in that kleisauke linked. windows-gnu is unaffected because it uses legacy import libraries format.
To get back to address case we could either: Filter symbols when building a staticlib Try using COMDAT in generated raw-dylibs (might not work in this situation)
Filter in what way?
When linking raw dylibs into a staticlib we could exclude the objects containing . Except for one.


Question: if let (Some(fmt_str), expr) = self.check_tts(cx, &mac.args.inner_tokens(), true) { if fmt_str.symbol == Symbol::intern("") { let mut applicability = Applicability::MachineApplicable; <del> let suggestion = if let Some(e) = expr { snippet_with_applicability(cx, e.span, "v", &mut applicability) } else { applicability = Applicability::HasPlaceholders; Cow::Borrowed("v") </del> <ins> let suggestion = match expr { Some(expr) => snippet_with_applicability(cx, expr.span, "v", &mut applicability), None => { applicability = Applicability::HasPlaceholders; Cow::Borrowed("v") }, </ins> }; span_lint_and_sugg(

The following sample crashed rustc: Removing the , or unwrapping the (leaving only ), or replacing the predicate (leaving ), solves the crash. Reproduced on Windows 64-bit, Fedora 32-bit, Ubuntu 64-bit. Full crash log (thanks to ) @ Short crash message:
Fixed pending
Fixed in


Question: if let (Some(fmt_str), expr) = self.check_tts(cx, &mac.args.inner_tokens(), true) { if fmt_str.symbol == Symbol::intern("") { let mut applicability = Applicability::MachineApplicable; <del> let suggestion = if let Some(e) = expr { snippet_with_applicability(cx, e.span, "v", &mut applicability) } else { applicability = Applicability::HasPlaceholders; Cow::Borrowed("v") </del> <ins> let suggestion = match expr { Some(expr) => snippet_with_applicability(cx, expr.span, "v", &mut applicability), None => { applicability = Applicability::HasPlaceholders; Cow::Borrowed("v") }, </ins> }; span_lint_and_sugg(

While I was playing with the new rustc 0.6, I encountered an internal compiler error The source code is here: Compiler version is 0.6, built with gcc, on OS X 10.7.5
If you run rustc under gdb and break on , could you paste the backtrace here?
OK. Here is the backtrace:
Looks like stack exhaustion to me. What happens if you remove ?
The code compiles with no problem when I wrap the rest of the code with mod block. Like:
This yields a proper error message now; closing.


Question: if let (Some(fmt_str), expr) = self.check_tts(cx, &mac.args.inner_tokens(), true) { if fmt_str.symbol == Symbol::intern("") { let mut applicability = Applicability::MachineApplicable; <del> let suggestion = if let Some(e) = expr { snippet_with_applicability(cx, e.span, "v", &mut applicability) } else { applicability = Applicability::HasPlaceholders; Cow::Borrowed("v") </del> <ins> let suggestion = match expr { Some(expr) => snippet_with_applicability(cx, expr.span, "v", &mut applicability), None => { applicability = Applicability::HasPlaceholders; Cow::Borrowed("v") }, </ins> }; span_lint_and_sugg(

When you download the 0.6 tarball and execute ./configure && make, a download occurs. and a wget info dump appears. It would be really awesome if this piece was integrated with the tarball. Not all environments are friendly to downloading arbitrary code off the net. E.g., I might be in a SCIF[1] and experimenting with Rust on a machine disconnected from the public net. Or I might be on a laptop working in a no-wifi area. :-/ (I know this is probably a real low priority issue, but it IS a (usually minor) hassle) [1]
Please note that you can avoid that if you already have a (compatible) locally installed rust compiler. Check the --local-rust and --local-rust-root parameters for ./configure. Also, I'm against bundling binaries in source tarballs. They are target-dependent and bundling all of them will make the released archive quite large. Downloading an external bootstrapper is a minor issue for downstream packagers too, though. See
far-future
Yeah, you can also just populate the directory in your builddir with an appropriate snapshot tarball. There's not much else we can do here. Putting binaries in a source tarball feels even worse, to me. Closing as I don't expect we're going to much change the requirements here and have several workable workarounds.


Question: if let (Some(fmt_str), expr) = self.check_tts(cx, &mac.args.inner_tokens(), true) { if fmt_str.symbol == Symbol::intern("") { let mut applicability = Applicability::MachineApplicable; <del> let suggestion = if let Some(e) = expr { snippet_with_applicability(cx, e.span, "v", &mut applicability) } else { applicability = Applicability::HasPlaceholders; Cow::Borrowed("v") </del> <ins> let suggestion = match expr { Some(expr) => snippet_with_applicability(cx, expr.span, "v", &mut applicability), None => { applicability = Applicability::HasPlaceholders; Cow::Borrowed("v") }, </ins> }; span_lint_and_sugg(

As seen in , LLVM has lots of places where it will insert calls to libm directly, not switching stacks. One of places that I recall seeing this before is the translation of the instruction. Rust has floating point modulus and presumably it is doing it in the red zone.
We can solve this with an lang item.
Is this an issue with calls to compiler-rt too? Or are they compiled in some special way to avoid the issue?
Nominating for milestone 5, production-ready
, , and are also all generated. As far as I can tell, we can't prevent it from generating these by altering the IR we output.
We can possibly be selective about when we emit memcpy/memmov, second guessing LLVM (like, never for big things)
accepted for production-ready milestone
Closing due to segmented stacks being gone (stack switches no longer a thing)


Question: fBopt-levelfR=fIVALfR Optimize with possible levels 0[en]3 <ins> .SH ENVIRONMENT VARIABLES Some of these affect the output of the compiler, while others affect programs which link to the standard library. .TP fBRUST_TEST_THREADSfR The test framework Rust provides executes tests in parallel. This variable sets the maximum number of threads used for this purpose. .TP fBRUST_TEST_NOCAPTUREfR A synonym for the --nocapture flag. .TP fBRUST_MIN_STACKfR Sets the minimum stack size for new threads. .TP fBRUST_BACKTRACEfR If set, produces a backtrace in the output of a program which panics. </ins> .SH "EXAMPLES" To build an executable from a source file with a main function: $ rustc -o hello hello.rs

I was looking for a collection of environment variables that honours but was unable to find a definitive list. There are a few mentions of variables such as , and on google but none of them are documented in Would it be possible to add these to the manual for future reference under an section much like and ?
Yup, that'd be great.
Lots of these are duplicates, but
This looks like an actual list of all of them right now:
FYI: Just (Document RUSTTESTTASKS in the "book") in response to spurious test failures due to parallel text execution.
Full list as of now:
(I gusess some of these are not actually env vars)


Question: self.tcx.struct_span_lint_hir( lint::builtin::RUST_2021_INCOMPATIBLE_CLOSURE_CAPTURES, closure_hir_id, <del> closure_head_span, </del> <ins> closure_head_span, </ins> |lint| { let mut diagnostics_builder = lint.build( format!(

I tried this code: This does not issue a warning for , however it fails to compile with enabled: I would expect to give a suggestion to add . Found in the 2021 crater run for: I'm uncertain if this is a duplicate of or , they seem very similar, but this case is specific to implementing Drop. : cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim


Question: <del> Subproject commit 5399a24c66cb6164cf32280e7d300488c90d5765 </del> <ins> Subproject commit b31c30a9bb4dbbd13c359d0e2bea7f65d20adf3f </ins>

I get a segfault when I try to run on the following code: I see the same behavior with the latest nightly . I see no error with 1.77.0 or earlier. It also works fine on Linux, and on an older Intel Macbook. I also updated to the latest XCode to make sure all parts of my toolchain were up to date. Doing so did not make the segfault go away.
The problem disappears if I turn off incremental compilation by adding this to the :
I believe this bisects to LLVM 18 from cc
We are hitting an LLVM assertion:
Could someone please run and then repeat the rustc command with and share the bitcode files?
I can reproduce it, and I will try to reduce it.
Upstream issue: Reduced:
It has already been backported to LLVM 18: label +llvm-fixed-upstream


Question: <del> Subproject commit 5399a24c66cb6164cf32280e7d300488c90d5765 </del> <ins> Subproject commit b31c30a9bb4dbbd13c359d0e2bea7f65d20adf3f </ins>

<!-- 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. --This bug is spotted jointly by and We tried this code (minimized by and I expected to see this happen: The program should exit without error. Instead, this happened: segmentation fault. Notice that the code will pass . (). The error is reproducible with larger than . The error seems to be related, as does not reproduce the bug. There seems to be no bug in LLVM IR. noticed that produces different asm compared with the one in the ELF output. Notice that we encountered an ICE while exploring the code (for now, we are not sure whether the ICE is related to SEGV, we can file a separate report for ICE if needed). Basically, invoking the rustc consecutively, one will get (cleaning up the directory can help): <!-- 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. --Both nightly and stable versions are affected :
may be running into
This started on stable in 1.73, and bisects to : A couple notes, when using cargo: incremental compilation is not enabled on release builds for people who opt into optimizing dependencies even in debug builds: incremental compilation is not enabled for dependencies either, only local crates It would be interesting to see exactly what impacts codegen here when enabling incremental compilation of a single session (but at the same time, it seems probable that not many users should encounter this issue in the more common configurations?).
Some additional context: the code is largely related to ecow. In case people compile typst/ecow related code with incremental build and level 1 optimization enabled and run into segmentation fault, this should be the bug behind it.
So the error happens just from adding , without there actually being a previous incremental cache there? Wow. Cc Seems likely that the LLVM 17 update is involved. Cc
I can confirm that this reproduces with an empty cache -- which should be good news in terms of debugging the issue. I'm pretty sure this is a ThinLTO-related bug and incremental somehow configures CGUs and LLVM settings in a way that triggers the bug. The segfault does not reproduce when compiling with .


Question: <del> Subproject commit 5399a24c66cb6164cf32280e7d300488c90d5765 </del> <ins> Subproject commit b31c30a9bb4dbbd13c359d0e2bea7f65d20adf3f </ins>

Running the miscompiled binary in gdb (with ) gives:
Yeah, that would crash...
I think this is a minimal reproducer: We infer that the result of this function is nonnull...
Upstream issue:
WG-prioritization assigning priority (). label -I-prioritize +P-high


Question: <ins> #![feature(unboxed_closures)] #![feature(fn_traits)] fn main() { let handlers: Option<Box<dyn for<'a> FnMut<&'a mut (), Output=()>>> = None; handlers.unwrap().as_mut().call_mut(&mut ()); //~ ERROR: `&mut ()` is not a tuple } </ins>

Reduced example
e
The first compilation error -- the example with looks fine to me. Types used for static variables must outlive the lifetime. The compiler can prove that outlives only if . Hence lifetimes are inferred in lieu of the anonymous lifetimes. Since your variable does not live for the whole lifetime, it cannot be used as you are trying to. Maybe the actual bug is that should desugar to , as it would be for ? It may be weird to special-case only the traits though -- i.e. if you define your own trait , then just means for some lifetime to be inferred by the compiler, it does not mean . Your reduced example is actually different since it actually does not involve static data. It seems to be the same bug as in , and hence is a bug with the feature. Going from to (note the tuple of size ) makes the ICE go away.
Fixed by


Question: #[cfg(test)] mod tests; <ins> #[doc(no_inline)] </ins> pub use hir::*; pub use hir_id::*; pub use lang_items::{LangItem, LanguageItems};

We have some relative links in doc, e.g., the link of in the comments for : but we will get the page if we click it in , which is re-exported. So I think we can fix this by two ways: 't use relative path in rustc doc 't generate new link for re-exported items, use the same links with the original definition but for the second option, we may have private middle mods, so it may be not a solution. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
I'm thinking of tackling this issue, is this Issue aimed at removing this invalid path once and for all? (Sorry if I'm wrong as I'm trying to contribute for the first time)
claim
Hi just checking if you are still working on the issue? If so, apologies please ignore this. Otherwise I'm happy to take over. Thanks
take it


Question: src = t!(fs::canonicalize(src)); } else { let link = t!(fs::read_link(src)); <del> t!(self.symlink_file(link, dst)); </del> <ins> t!(self.config.symlink_file(link, dst)); </ins> return; } }

broke the rust-analyzer config we suggest in the dev-guide: https://rustc-dev- since now rustfmt is in instead of . Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Hi! Just to clarify, the idea is to change to code to match the docs?
I think the idea is changing the docs to match the new behavior.
For reference:
I'd prefer to change the code so that we don't force all contributors to update their config.
I don't think we can put the binary back, or at least, that feels iffy - we'd be trying to overlap two different sysroots. rustfmt used to be statically linked to libstd and librustc_driver, but that's no longer the case.
I suppose we could try to create a symlink from the old path to the new one? That might work, not sure.
Maybe add a proxy? On Linux it might just be
A symlink seems like a good solution to me.
Does the symlink still finds the correct so?
try it and see
I'll experiment adding a symlink.
On Windows, creating a symlink does not find the needed DLLs. Trying to execute the symlink pops two msgbox saying that it doesn't find the and DLLs. You would need to symlink also the DLLs. On Linux, it does find the correct SOs.
Symlinking also works on macOS.
Ok, this is pretty messy. How about doing both: Add the symlink, which will work with both the old and new config on Mac and Linux Update the recommended config in the dev-guide, which will help contributors fix the error message on Windows and from there we can work long-term to using the same toolchain for rustfmt and other tools, without having a time pressure.
cc ,
May I get some guidance and the creation of the symlink? Do I use rust to create the symlink in after the rustfmt_path line or do I use a bash command? If I do use a bash command, is there a file I should be adding it to? Thank you!
use
And just to confirm, I use that symlink function here?


Question: src = t!(fs::canonicalize(src)); } else { let link = t!(fs::read_link(src)); <del> t!(self.symlink_file(link, dst)); </del> <ins> t!(self.config.symlink_file(link, dst)); </ins> return; } }

yes
I think it would be possible to move rustfmt back to the same sysroot as the bootstrap compiler by only taking , and from the nightly rustc component and not copying any other files like the rustc binary. and both contain a hash in their name unique for each rustc version. should contain the rustc version, so that shouldn't conflict either.
Doing the same with the DLLs on Windows could also work.
related (different error with rustfmt, but caused by the same change):
Hi any progress on the symlink? happy to help out if you're running into trouble :)
Hey ! Thanks for reaching out! I'll be starting tomorrow and will reach out to you if/when I need help! Apologies for the delay!


Question: <ins> // Regression test for #100143 use std::iter::Peekable; pub struct Span<F: Fn(&i32)> { inner: Peekable<ConditionalIterator<F>>, } pub struct ConditionalIterator<F> { f: F, } // @has 'fn_bound/struct.ConditionalIterator.html' '//h3[@class="code-header in-band"]' 'impl<F: Fn(&i32)> Iterator for ConditionalIterator<F>' impl<F: Fn(&i32)> Iterator for ConditionalIterator<F> { type Item = (); fn next(&mut self) -> Option<Self::Item> { todo!() } } </ins>

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: // Types of fields (other than the last) in a struct must be sized. FieldSized, <ins> // Only Sized types can be made into objects ObjectSized, </ins> } pub type Obligations<'tcx> = subst::VecPerParamSpace<Obligation<'tcx>>;

cc
cc too, presumably a consequence of the trait reform/new vtable lookup code
Hmm, yes. Probably we can fix this by just...allowing it to skolemize an open existential type. I just didn't expect this to ever happen.
actually, while debugging this I remembered that it is not possible to make an object out of an unsized type. We need to add a check for this I guess!
Explanation from PR: In the general case, at least, it is not possible to make an object out of an unsized type. This is because the object type would have to store the fat pointer information for the self value and the vtable -- meaning it'd have to be a fat pointer with three words -- but for the compiler to know that the object requires three words, it would have to know the self-type of the object (is self a thin or fat pointer?), which of course it doesn't.


Question: pub fn read_line(&self, buf: &mut String) -> io::Result<usize> { self.lock().read_line(buf) } <ins> // Locks this handle with any lifetime. This depends on the // implementation detail that the underlying `Mutex` is static. fn lock_any<'a>(&self) -> StdinLock<'a> { StdinLock { inner: self.inner.lock().unwrap_or_else(|e| e.into_inner()) } } /// Consumes this handle to the standard input stream, locking the /// shared global buffer associated with the stream and returning a /// readable guard. /// /// The lock is released when the returned guard goes out of scope. The /// returned guard also implements the [`Read`] and [`BufRead`] traits /// for accessing the underlying data. /// /// It is often simpler to directly get a locked handle using the /// [`stdin_locked`] function instead, unless nearby code also needs to /// use an unlocked handle. /// /// # Examples /// /// ```no_run /// #![feature(stdio_locked)] /// use std::io::{self, Read}; /// /// fn main() -> io::Result<()> { ///     let mut buffer = String::new(); ///     let mut handle = io::stdin().into_locked(); /// ///     handle.read_to_string(&mut buffer)?; ///     Ok(()) /// } /// ``` #[unstable(feature = "stdio_locked", issue = "none")] pub fn into_locked(self) -> StdinLock<'static> { self.lock_any() } </ins> } #[stable(feature = "std_debug", since = "1.16.0")]

Given the following code: The current output is: I think it's typical for a newcomer to want to get a iterator by chaining method calls like . There's no obvious reason why that shouldn't work. The examples in the documentation do typically show being assigned to a variable prior to calling its method, but don't explain why that's necessary. I think the "borrow" terminology is misleading, but there might not be a concise way to describe what's actually going on to the user. The "temporary value is freed at the end of this statement" is probably correct. The "creates a temporary which is freed while still in use" is probably more correctly "creates a temporary that is required to outlive (or live exactly as long as) the result of...", followed by a pointer to the method invocation, with text of " method call". Maybe it should also point out the lifetime argument in the return type. I tried and failed to find a satisfactory explanation of what exactly was borrowing from the temporary value produced by . When I looked through the library source code, the only references in were those created by locking a , and the in question is static. I'm guessing the existence of a borrow is assumed rather than inferred from analyzing the function body of . The assumption might be the result of the anonymous lifetime argument on the output type from , which imposes a requirement that the doesn't outlive (or has the same lifetime as?) the value that is the receiver of . The correct fix might be to change the locked stdin handles to all use lifetimes, but I will probably file that as a separate issue.
label +A-borrow-checker +A-lifetimes +D-confusing +D-incorrect +D-newcomer-roadblock
IMO the intent is clear here. Without changing the API, why exactly is Rust unable to lift 'a &'static X to 'static & 'static X, if X also contains only 'static lifetimes? I don't think raw references have a meaningful dropper; borrowck is able to freely resolve any derived lifetimes on impls that don't depend on anything else to 'static; I'm pretty sure under current rules we should be able to substitute latter for earlier and get exactly the same behaviour.
This is due to .


Question: pub fn read_line(&self, buf: &mut String) -> io::Result<usize> { self.lock().read_line(buf) } <ins> // Locks this handle with any lifetime. This depends on the // implementation detail that the underlying `Mutex` is static. fn lock_any<'a>(&self) -> StdinLock<'a> { StdinLock { inner: self.inner.lock().unwrap_or_else(|e| e.into_inner()) } } /// Consumes this handle to the standard input stream, locking the /// shared global buffer associated with the stream and returning a /// readable guard. /// /// The lock is released when the returned guard goes out of scope. The /// returned guard also implements the [`Read`] and [`BufRead`] traits /// for accessing the underlying data. /// /// It is often simpler to directly get a locked handle using the /// [`stdin_locked`] function instead, unless nearby code also needs to /// use an unlocked handle. /// /// # Examples /// /// ```no_run /// #![feature(stdio_locked)] /// use std::io::{self, Read}; /// /// fn main() -> io::Result<()> { ///     let mut buffer = String::new(); ///     let mut handle = io::stdin().into_locked(); /// ///     handle.read_to_string(&mut buffer)?; ///     Ok(()) /// } /// ``` #[unstable(feature = "stdio_locked", issue = "none")] pub fn into_locked(self) -> StdinLock<'static> { self.lock_any() } </ins> } #[stable(feature = "std_debug", since = "1.16.0")]

is declared as follows: Because there is only one input lifetime (the elided lifetime of ), it is assigned to the output lifetime , which is why the lock can live at most as long as the temporary.
Thanks. I think this might be a bug in libstd (using instead of as the return type), but I'll file that separately. What I think is a diagnostic inaccuracy is that the error message refers to a borrow, when, by inspection of the library source code, no borrow is taking place in . (Unless I'm missing something?) What I think is happening is that the compiler is enforcing that lives no longer than the temporary produced by , and is misleadingly calling that a borrow in the error message.
As a simplified example: The error message refers to a borrow even when the output type of does not refer to at all!
that's because of the elision rules: on the declaration you're implicitly telling the compiler that the lifetime of the borrow matches the lifetime of the type. .
Thanks. I think the error messages could use a little more detail about how something that the borrow checker sees as a borrow may be an artifact of lifetime constraints in a function signature rather than an actual borrow in the function body. It certainly surprised me the first time I ran into it. (Maybe only in the explanatory text in the compiler error index. It looks like E0597 could also benefit from that detail, because it's a similar case, and an example in E0716 produces E0597.)
Shorter example, probably better suited for an example in the compiler error index:


Question: <ins> error[E0310]: the associated type `<&'a V as IntoIterator>::Item` may not live long enough --> $DIR/issue-71546.rs:12:27 | LL |       let csv_str: String = value |  ___________________________^ LL | |         .into_iter() LL | |         .map(|elem| elem.to_string()) | |_____________________________________^ | = help: consider adding an explicit lifetime bound `<&'a V as IntoIterator>::Item: 'static`... = note: ...so that the type `<&'a V as IntoIterator>::Item` will meet its required lifetime bounds... note: ...that is required by this bound --> $DIR/issue-71546.rs:10:55 | LL |     for<'a> <&'a V as IntoIterator>::Item: ToString + 'static, |                                                       ^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0310`. </ins>

Playground: UPDATE: MCVE is here: Code: Crashes compiler with
Would be nice to figure out if this is a regression or not and if it is when has this regressed. ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
It has been present since at least 2019-08-01 according to bisect-rustc
Simplified code to remove dependencies This compiles for 1.20.0 and not for 1.30.0 (setting edition to 2015) I'll try and pinpoint at least the version where it causes the ICE
From what I can tell the first time this ICE would happen is in 1.24.0
Assigning
Even simpler:
Triage: This ICE has been fixed in the latest nightly, I assume it's fixed by . Marking as .
Wait, the original code and still triggers the ICE... glacier was tracking with but it seems the others encounter another roadblock. Dropping .
No longer ICEs since , likely from


Question: #![feature(cfg_target_has_atomic)] #![feature(cfg_target_thread_local)] #![feature(char_error_internals)] <ins> #![feature(char_internals)] </ins> #![feature(clamp)] #![feature(concat_idents)] #![feature(const_cstr_unchecked)]

The following program causes UB: Miri says: The problem is this code: This calls unless the new code point is in , but what about surrogates in ? This code is unchanged since its introduction in I am not sure what the intended safety contract of is. That method is not marked but clearly should be -- it calls . So my guess is the safety precondition is that must not be part of a surrogate pair, but the thing is, calls it without actually ensuring that condition. The condition it does ensure is that the codepoint is not in , but that does not help.
is excluded from Unicode scalar values a.k.a. , but it’s fine as a Unicode code point. I think this bug is not in the contract of (which is private anyway) but in its implementation, namely going through . The fix is to either duplicate the logic of into , or (to avoid duplication) move that logic to a new function in libcore that takes a parameter and that is called by both and . This function would need to be public because is in a different crate, but it should be prema-unstable and .
I would classify the priority of this bug as low. Although this call to is UB, I expect Miri checking for it explicitly is the only case where that has any consequence in today’s implementation: behaves as expected (for the purpose of WTF-8) in the surrogate range and does not exploit this UB The "layout" of in rustc excludes values beyond but not surrogates:
By the way, the docs at feel insufficient: Which values are invalid? Similarly, and say that represents Unicode Scalar values, but I couldn’t find it documented anywhere that constructing an out of range is Undefined Behavior rather than "merely" a logic bug. Is this specified elsewhere? What is the closest we have to a written down normative resource that specifies what is or isn’t UB in the the Rust language? (For APIs I assume this is the responsibility of their respective doc-comments.)
I agree the impact is low, but it's not just Miri -- this blocks , which is how I discovered the problem. That would be
But then what is "unchecked" about it? Elsewhere in that file the code is careful not to construct a from a without checking for surrogates: That made me assume the author was aware that surrogates in are UB.


Question: #![feature(cfg_target_has_atomic)] #![feature(cfg_target_thread_local)] #![feature(char_error_internals)] <ins> #![feature(char_internals)] </ins> #![feature(clamp)] #![feature(concat_idents)] #![feature(const_cstr_unchecked)]

The type contains a (generalized-UTF-8-encoded) sequence of code point (including potentially surrogates) that doesn’t form a surrogate pair. doesn’t check for surrogate pairs. is a public method that is documented as returning a scalar value, therefore excluding all surrogates. Ok I looked into it, there are three different people involved. The original code in 2014 was YOLO Later in 2014, moved to duplicating logic instead. In 2015, PR which first imported WTF-8 support in libstd deduplicated that logic by adding a function that takes . (I knew that approach sounded familiar…) In 2016, PR changed the signature of and in passing removed . It made use + instead, presumably in the middle of updating many callers other.
Okay, so the fix would be to revert the part of that removed ?
That or copy into . I find them both not great, so meh.
Even with that done, there's still UB in another testcase: This is converting something to a before calling -- so probably the same issue as the above, just for a different encoding.


Question: ), .. }) => { <del> let hir::Ty { span, .. } = inputs[local.index() - 1]; </del> <ins> let hir::Ty { span, .. } = *inputs.get(local.index() - 1)?; </ins> Some(span) } _ => None,

<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'index out of bounds: the len is 1 but the index is 1'', 'thread 'rustc' panicked at 'index out of bounds: the len is 1 but the index is 1'' 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: [mirborrowck] borrow-checking [analysis] running analysis passes on this crate --
cc
label +D-diagnostic-infra -needs-triage


Question: true } <ins> // Suggest to change `Option<&Vec<T>>::unwrap_or(&[])` to `Option::map_or(&[], |v| v)`. #[instrument(level = "trace", skip(self, err, provided_expr))] pub(crate) fn suggest_deref_unwrap_or( &self, err: &mut Diag<'_>, error_span: Span, callee_ty: Option<Ty<'tcx>>, call_ident: Option<Ident>, expected_ty: Ty<'tcx>, provided_ty: Ty<'tcx>, provided_expr: &Expr<'tcx>, is_method: bool, ) { if !is_method { return; } let Some(callee_ty) = callee_ty else { return; }; let ty::Adt(callee_adt, _) = callee_ty.peel_refs().kind() else { return; }; let adt_name = if self.tcx.is_diagnostic_item(sym::Option, callee_adt.did()) { "Option" } else if self.tcx.is_diagnostic_item(sym::Result, callee_adt.did()) { "Result" } else { return; }; let Some(call_ident) = call_ident else { return; }; if call_ident.name != sym::unwrap_or { return; } let ty::Ref(_, peeled, _mutability) = provided_ty.kind() else { return; }; // NOTE: Can we reuse `suggest_deref_or_ref`? // Create an dummy type `&[_]` so that both &[] and `&Vec<T>` can coerce to it. let dummy_ty = if let ty::Array(elem_ty, size) = peeled.kind() && let ty::Infer(_) = elem_ty.kind() && size.try_eval_target_usize(self.tcx, self.param_env) == Some(0) { let slice = Ty::new_slice(self.tcx, *elem_ty); Ty::new_imm_ref(self.tcx, self.tcx.lifetimes.re_static, slice) } else { provided_ty }; if !self.can_coerce(expected_ty, dummy_ty) { return; } let msg = format!("use `{adt_name}::map_or` to deref inner value of `{adt_name}`"); err.multipart_suggestion_verbose( msg, vec![ (call_ident.span, "map_or".to_owned()), (provided_expr.span.shrink_to_hi(), ", |v| v".to_owned()), ], Applicability::MachineApplicable, ); } </ins> /// Suggest wrapping the block in square brackets instead of curly braces /// in case the block was mistaken array syntax, e.g. `{ 1 }` -> `[ 1 ]`. pub(crate) fn suggest_block_to_brackets(

Given : Current error, for the motivating use case above: It should be possible for rustc to suggest replacing this specific instantiation of with . Maybe similarly for some other common cases: . Originally posted by in label -T-rustdoc T-compiler


Question: /// ``` #[stable(feature = "rust1", since = "1.0.0")] pub fn lock(&self) -> StdinLock<'_> { <del> StdinLock { inner: self.inner.lock().unwrap_or_else(|e| e.into_inner()) } </del> <ins> self.lock_any() </ins> } /// Locks this handle and reads a line of input, appending it to the specified buffer.


Question: /// ``` #[stable(feature = "rust1", since = "1.0.0")] pub fn lock(&self) -> StdinLock<'_> { <del> StdinLock { inner: self.inner.lock().unwrap_or_else(|e| e.into_inner()) } </del> <ins> self.lock_any() </ins> } /// Locks this handle and reads a line of input, appending it to the specified buffer.