Question: } } <ins> /// Constructs a new locked handle to the standard output of the current /// process. /// /// Each handle returned is a guard granting locked access to a shared /// global buffer whose access is synchronized via a mutex. If you need /// more explicit control over locking, for example, in a multi-threaded /// program, use the [`io::stdout`] function to obtain an unlocked handle, /// along with the [`Stdout::lock`] method. /// /// The lock is released when the returned guard goes out of scope. The /// returned guard also implements the [`Write`] trait for writing data. /// /// ### Note: Windows Portability Consideration /// When operating in a console, the Windows implementation of this stream does not support /// non-UTF-8 byte sequences. Attempting to write bytes that are not valid UTF-8 will return /// an error. /// /// # Examples /// /// ```no_run /// #![feature(stdio_locked)] /// use std::io::{self, Write}; /// /// fn main() -> io::Result<()> { ///     let mut handle = io::stdout_locked(); /// ///     handle.write_all(b"hello world")?; /// ///     Ok(()) /// } /// ``` #[unstable(feature = "stdio_locked", issue = "none")] pub fn stdout_locked() -> StdoutLock<'static> { stdout().into_locked() } </ins> pub fn cleanup() { if let Some(instance) = STDOUT.get() { // Flush the data and disable buffering during shutdown

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: } } <ins> /// Constructs a new locked handle to the standard output of the current /// process. /// /// Each handle returned is a guard granting locked access to a shared /// global buffer whose access is synchronized via a mutex. If you need /// more explicit control over locking, for example, in a multi-threaded /// program, use the [`io::stdout`] function to obtain an unlocked handle, /// along with the [`Stdout::lock`] method. /// /// The lock is released when the returned guard goes out of scope. The /// returned guard also implements the [`Write`] trait for writing data. /// /// ### Note: Windows Portability Consideration /// When operating in a console, the Windows implementation of this stream does not support /// non-UTF-8 byte sequences. Attempting to write bytes that are not valid UTF-8 will return /// an error. /// /// # Examples /// /// ```no_run /// #![feature(stdio_locked)] /// use std::io::{self, Write}; /// /// fn main() -> io::Result<()> { ///     let mut handle = io::stdout_locked(); /// ///     handle.write_all(b"hello world")?; /// ///     Ok(()) /// } /// ``` #[unstable(feature = "stdio_locked", issue = "none")] pub fn stdout_locked() -> StdoutLock<'static> { stdout().into_locked() } </ins> pub fn cleanup() { if let Some(instance) = STDOUT.get() { // Flush the data and disable buffering during shutdown

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: #![feature(inherent_associated_types)] #![allow(incomplete_features)] <ins> #![deny(single_use_lifetimes)] </ins> struct Foo<T>(T);

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: : I expected to see this happen: explanation suggestion compiles: Instead, this happened: explanation Suggestion does not compile: ` <!-- 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. --:


Question: | help: try using `=` instead | <del> LL -     let x == 2; LL +     let x = 2; | </del> <ins> LL |     let x = 2; |           ~ </ins> error: aborting due to 1 previous error

<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' File: --snippet: 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: --
cc
I suspect that we don't really need anymore, tbh.
Addressed in Every time I convince myself that "synthesizing a is ok this time", I'm proved wrong.
WG-prioritization assigning priority (). label -I-prioritize +P-medium


Question: use rustc::hir; use rustc::hir::itemlikevisit::ItemLikeVisitor; use rustc::hir::def_id::DefId; <del> use rustc::ty::{self, TyCtxt}; </del> <ins> use rustc::ty::{self, TyCtxt, TypeFoldable}; </ins> use rustc::ty::query::Providers; use rustc::util::nodemap::{FxHashMap, FxHashSet}; use std::collections::hash_map::Entry::{Occupied, Vacant};

The second error in this snippet is "nonsense" because it says the type parameter is not constrained, while the real error was already reported — the actual type could not be imported. Found in: rustc 1.13.0-nightly ( 2016-09-26)
.


Question: match *seq_tt { TokenTree::MetaVarDecl(_, _, id) => id.name == "vis", TokenTree::Sequence(_, ref sub_seq) => <del> sub_seq.op == quoted::KleeneOp::ZeroOrMore, </del> <ins> sub_seq.op == quoted::KleeneOp::ZeroOrMore || sub_seq.op == quoted::KleeneOp::ZeroOrOne, </ins> _ => false, } }) {

The following code will cause the compiler to fail: Playground link: It should error that the inner matcher can match an empty string and reject it, just as it does if is used in place of .
The fix should be very easy, since this was already fixed for repetitions in (original bug: ): Looks like just needs to be checked against , too.
cc
Note that with on the outside, this errors properly, although with inconsistent error messages: if the inner repetition uses only, the error is "repetition matches empty token tree", but it seems that if any of the repetitions are , then the error is "multiple successful parses".
The behaviour in my previous comment is because the check for "repetition matches empty token tree" is done at definition time, but does not catch ; this is caught at expansion time however. Ideally all of this will be moved to definition time and the expansion-time check should probably be a) corrected to address the first comment and b) possibly become an ICE, since it should never be encountered since the RFC 550 rules should eliminate all ambiguity at definition time?
Hmm... I don't really remember how most of this code works... Just grepping, but it looks like there are a couple of other places we might want to look at:
I've opened


Question:
{{- layout.external_html.before_content | safe -}}  {#- -#}
☰
 {#- -#}   {#- -#}
 {#- -#}  {#- -#}
 {#- -#}    {#- -#}
 {#- -#} {%- if layout.logo -%}  {#- -#} {%- else -%}  {#- -#} {%- endif -%}
   {#- -#} {{- sidebar | safe -}}  {#- -#}  {#- -#}
 {#- -#}
 {#- -#}   {#- -#}  {#- -#}    {#- -#} {%- if layout.logo -%}  {%- else -%}  {%- endif -%}   {#- -#}  {#- -#}
 {#- -#}

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: obj } <del> #[inline] </del> <ins> // See comment on do_try above for why #[inline(never)] is needed on bootstrap. #[cfg_attr(bootstrap, inline(never))] #[cfg_attr(not(bootstrap), inline)] </ins> fn do_call<F: FnOnce() -> R, R>(data: *mut u8) { unsafe { let data = data as *mut Data<F, R>;

This is a regression from the last couple of days. Looks like the compiler for something forever. Curiously, the run with completes successfully. I'll investigate in more detail. The list of tests: All of the tests are supposed to report errors.
Here's the backtrace:
Looks like this is caused by the recent unwinding changes. cc
GCC toolchain version on which this reproduced:
Does this happen with stage 1 rustc or stage 2 rustc?
Stage 1, e.g. I'll check stage 2 now.
( is confirmed to be the cause, removing .)
I have a pretty good idea of what the problem might be. I'm traveling right now but I'll try to have a PR up by tonight.
The issue doesn't reproduce with a stage 2 compiler. That's great news long term, but broken stage 1 still makes any compiler work involving testing hard.
I don't have a Windows machine to test on right now, but can you try marking and with in to see if that fixes the issue?
can you try marking and with in to see if that fixes the issue? It does! Thanks for a workaround.


Question: <ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // aux-build:issue_41053.rs pub trait Trait { fn foo(&self) {} } pub struct Foo; impl Iterator for Foo { type Item = Box<Trait>; fn next(&mut self) -> Option<Box<Trait>> { extern crate issue_41053; impl ::Trait for issue_41053::Test { fn foo(&self) {} } Some(Box::new(issue_41053::Test)) } } fn main() { Foo.next().unwrap().foo(); } </ins>

I was going through some refactoring and the compiler exploded. No unsafe. The last bits of code I was playing with can be found , before I tried to refactor the example, the tests were building and passing. The macro that might be to blame is . I parked a branch with the code that made it blew up, you can find it here works, blows up. a happy compiler, worst case an unhappy one a dead compiler : Backtrace:
Minimal example:
Thanks that was a quick fix. Do you have a workaround until the fix makes it to master?
The ICE occurs when you have an item referenced in an impl signature is imported from an statement occurs within an impl. To work around the ICE, you can move the call to to a different free function.
Got it, it works , thanks!


Question: <ins> error[E0220]: associated type `Assoc` not found for `Trait` --> $DIR/stranded-opaque.rs:8:31 | LL | fn produce<T>() -> impl Trait<Assoc = impl Trait> { |                               ^^^^^ associated type `Assoc` not found error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0220`. </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: val } <ins> fn emit_s390x_va_arg<'ll, 'tcx>( bx: &mut Builder<'_, 'll, 'tcx>, list: OperandRef<'tcx, &'ll Value>, target_ty: Ty<'tcx>, ) -> &'ll Value { // Implementation of the s390x ELF ABI calling convention for va_args see // https://github.com/IBM/s390x-abi (chapter 1.2.4) let va_list_addr = list.immediate(); let va_list_layout = list.deref(bx.cx).layout; let va_list_ty = va_list_layout.llvm_type(bx); let layout = bx.cx.layout_of(target_ty); let in_reg = bx.append_sibling_block("va_arg.in_reg"); let in_mem = bx.append_sibling_block("va_arg.in_mem"); let end = bx.append_sibling_block("va_arg.end"); // FIXME: vector ABI not yet supported. let target_ty_size = bx.cx.size_of(target_ty).bytes(); let indirect: bool = target_ty_size > 8 || !target_ty_size.is_power_of_two(); let unpadded_size = if indirect { 8 } else { target_ty_size }; let padded_size = 8; let padding = padded_size - unpadded_size; let gpr_type = indirect || !layout.is_single_fp_element(bx.cx); let (max_regs, reg_count_field, reg_save_index, reg_padding) = if gpr_type { (5, 0, 2, padding) } else { (4, 1, 16, 0) }; // Check whether the value was passed in a register or in memory. let reg_count = bx.struct_gep( va_list_ty, va_list_addr, va_list_layout.llvm_field_index(bx.cx, reg_count_field), ); let reg_count_v = bx.load(bx.type_i64(), reg_count, Align::from_bytes(8).unwrap()); let use_regs = bx.icmp(IntPredicate::IntULT, reg_count_v, bx.const_u64(max_regs)); bx.cond_br(use_regs, in_reg, in_mem); // Emit code to load the value if it was passed in a register. bx.switch_to_block(in_reg); // Work out the address of the value in the register save area. let reg_ptr = bx.struct_gep(va_list_ty, va_list_addr, va_list_layout.llvm_field_index(bx.cx, 3)); let reg_ptr_v = bx.load(bx.type_i8p(), reg_ptr, bx.tcx().data_layout.pointer_align.abi); let scaled_reg_count = bx.mul(reg_count_v, bx.const_u64(8)); let reg_off = bx.add(scaled_reg_count, bx.const_u64(reg_save_index * 8 + reg_padding)); let reg_addr = bx.gep(bx.type_i8(), reg_ptr_v, &[reg_off]); // Update the register count. let new_reg_count_v = bx.add(reg_count_v, bx.const_u64(1)); bx.store(new_reg_count_v, reg_count, Align::from_bytes(8).unwrap()); bx.br(end); // Emit code to load the value if it was passed in memory. bx.switch_to_block(in_mem); // Work out the address of the value in the argument overflow area. let arg_ptr = bx.struct_gep(va_list_ty, va_list_addr, va_list_layout.llvm_field_index(bx.cx, 2)); let arg_ptr_v = bx.load(bx.type_i8p(), arg_ptr, bx.tcx().data_layout.pointer_align.abi); let arg_off = bx.const_u64(padding); let mem_addr = bx.gep(bx.type_i8(), arg_ptr_v, &[arg_off]); // Update the argument overflow area pointer. let arg_size = bx.cx().const_u64(padded_size); let new_arg_ptr_v = bx.inbounds_gep(bx.type_i8(), arg_ptr_v, &[arg_size]); bx.store(new_arg_ptr_v, arg_ptr, bx.tcx().data_layout.pointer_align.abi); bx.br(end); // Return the appropriate result. bx.switch_to_block(end); let val_addr = bx.phi(bx.type_i8p(), &[reg_addr, mem_addr], &[in_reg, in_mem]); let val_type = layout.llvm_type(bx); let val_addr = if indirect { let ptr_type = bx.cx.type_ptr_to(val_type); let ptr_addr = bx.bitcast(val_addr, bx.cx.type_ptr_to(ptr_type)); bx.load(ptr_type, ptr_addr, bx.tcx().data_layout.pointer_align.abi) } else { bx.bitcast(val_addr, bx.cx.type_ptr_to(val_type)) }; bx.load(val_type, val_addr, layout.align.abi) } </ins> pub(super) fn emit_va_arg<'ll, 'tcx>( bx: &mut Builder<'_, 'll, 'tcx>, addr: OperandRef<'tcx, &'ll Value>,

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 frame = &self.token_cursor.frame; <del> match frame.tree_cursor.look_ahead(dist - 1) { </del> <ins> looker(&match frame.tree_cursor.look_ahead(dist - 1) { </ins> Some(tree) => match tree { <del> TokenTree::Token(token) => looker(token), </del> <ins> TokenTree::Token(token) => token, </ins> TokenTree::Delimited(dspan, delim, _) => { <del> looker(&Token::new(token::OpenDelim(delim.clone()), dspan.open)) </del> <ins> Token::new(token::OpenDelim(delim), dspan.open) </ins> } }, <del> None => looker(&Token::new(token::CloseDelim(frame.delim), frame.span.close)), } </del> <ins> None => Token::new(token::CloseDelim(frame.delim), frame.span.close), }) </ins> } /// Returns whether any of the given keywords are `dist` tokens ahead of the current one.

Between nightly-2020-09-05 and nightly-2020-09-06, libproc_macro stopped preserving the jointness of a trailing joint punctuation token in a TokenStream (likely ; This breaks some real-world code such as the following, though only with old versions of some libraries as far as I have found. I don't know which behavior above is correct but I would like it to be intentionally decided so that we know what behavior to implement in proc-macro2. fails to compile since nightly-2020-09-06:
This has also broken 's webrender-wrench, which relied on this behavior in one of the dependencies. -- do you think a revert makes sense perhaps? Is there a patch expected soon-ish?
Marking this as P-critical based on the


Question: } else { (None, &[][..], 0) }; <ins> let mut can_suggest_clone = true; </ins> if let Some(def_id) = def_id && let node = self.infcx.tcx.hir_node_by_def_id(def_id) && let Some(fn_sig) = node.fn_sig()

... and trying to use afterwards, which triggers Example: currently yields I suggest that it should also contain
AsRef is a library trait, so IMO we should not do that. Also to me "value moved here" is pretty much the "you need to use this as reference".
While this might be obvious to us, I've had students struggling strongly with these errors. When I tell them "just add an ampersand", they're like "Oh, that makes total sense". I don't see that as reason not to do it. Could you elaborate?
This should also handle , , .
and aren't as clear, since the object will be modified, so the user might also want to , but that can later be signalled through and/or multiple suggestions
Obvious way of doing this would involve making a language item or otherwise special in some other way. To me it is pretty clear that language and the standard library should be as independent as possible and IME a diagnostic is a pretty minor gain for the special casing involved. One could imagine a similar diagnostic independent of library traits (e.g. always suggest a reference for "value moved here" if there’s a trait implementation for also), but then the problem of suggestion not being always correct kicks in. So, I will not oppose a change that implements this without making any more of the libstd/libcore special and is always correct, but I have no idea how anybody even begin approaching this problem.
I fully agree that that is not desirable In clippy we have similar diagnostics which in this case would simply check for (see for all the paths that we resolve manually).
Triage: this still produces the same error message. Given the concerns voiced above, should this issue stay open? I suppose we could leave this open should someone come up with a clever way to handle this without special casing , but that seems unlikely.
We have diagnostic items nowadays, so we can make a diagnostic item and detect in in these situations. Though I'm not sure how easy it is to detect. The error may get reported far too late
Current :


Question: <del> FROM centos:5 </del> <ins> # We use Debian 6 (glibc 2.11, kernel 2.6.32) as a common base for other # distros that still need Rust support: RHEL 6 (glibc 2.12, kernel 2.6.32) and # SLES 11 SP4 (glibc 2.11, kernel 3.0). FROM debian:6 </ins> WORKDIR /build <del> # Centos 5 is EOL and is no longer available from the usual mirrors, so switch # to http://vault.centos.org/ RUN sed -i 's/enabled=1/enabled=0/' /etc/yum/pluginconf.d/fastestmirror.conf RUN sed -i 's/mirrorlist/#mirrorlist/' /etc/yum.repos.d/*.repo RUN sed -i 's|#(baseurl.*)mirror.centos.org/centos/$releasever|1vault.centos.org/5.11|' /etc/yum.repos.d/*.repo </del> <ins> # Debian 6 is EOL and no longer available from the usual mirrors, # so we'll need to switch to http://archive.debian.org/ RUN sed -i '/updates/d' /etc/apt/sources.list &&  sed -i 's/httpredir/archive/' /etc/apt/sources.list </ins> <del> RUN yum upgrade -y && yum install -y  curl  </del> <ins> RUN apt-get update &&  apt-get install --allow-unauthenticated -y --no-install-recommends  automake  </ins> bzip2  <ins> ca-certificates  curl  file  g++  g++-multilib  </ins> gcc  <del> gcc-c++  </del> <ins> gcc-multilib  git  lib32z1-dev  libedit-dev  libncurses-dev  </ins> make  <del> glibc-devel  </del> <ins> patch  </ins> perl  <del> zlib-devel  file  xz  which  pkgconfig  </del> <ins> pkg-config  unzip  </ins> wget  <del> autoconf  gettext </del> <ins> xz-utils  zlib1g-dev </ins> ENV PATH=/rustroot/bin:$PATH <del> ENV LD_LIBRARY_PATH=/rustroot/lib64:/rustroot/lib </del> <ins> ENV LD_LIBRARY_PATH=/rustroot/lib64:/rustroot/lib32:/rustroot/lib </ins> ENV PKG_CONFIG_PATH=/rustroot/lib/pkgconfig WORKDIR /tmp <ins> RUN mkdir /home/user </ins> COPY host-x86_64/dist-x86_64-linux/shared.sh /tmp/ # We need a build of openssl which supports SNI to download artifacts from

The docs currently claim that the minimum Linux kernel version for is 2.6.18 (released September 20th, 2006). This is because RHEL 5 used that kernel version. However, RHEL 5 entered ELS on March 31, 2017. Should we continue to support RHEL 5 for , or should we increase the minimum Linux Kernel version to 2.6.27 (2nd LTS) or 2.6.32 (RHEL 6, 3rd LTS)? . Even bumping the min-version to 2.6.27 would allow us to remove most of the Linux-specific hacks in . Example: .
Given that RHEL is the only reason we keep comically old kernel versions around, I would propose that Rust only support RHEL until Maintenance Support ends. This is (essentially) what we already did for RHEL 4. Rust never supported RHEL 4, and back when RHEL 5 still had maintenance support. It would be nice to get someone from Red Hat or a RHEL customer to comment. This policy would allow us to increment the minimum kernel from 2.6.18 to 2.6.32 (and remove a lot of Linux-specific hacks). Note that RHEL has a weird (and very long) support system for RHEL 4, 5, and 6 (sources: and ). It has 5 major steps: Full Support Normal support of the OS Maintenance Support 1 Bug/Security fixes Limited hardware refresh Maintenance Support 2 Bug/Security fixes The end of this phase is considered "Product retirement" Extended Life Cycle Support (ELS) Additional paid product from Red Hat Gives updates for a longer period of time No additional releases/images Extended Life Phase (ELP) No more updates Limited Technical Support End date not given by Red Hat Current status of RHEL versions: RHEL 4 Not supported by Rust Currently in ELP (no end date specified) ELS ended March 31, 2017 RHEL 5 Supported by Rust Currently in ELS Maintenance Support ended March 31, 2017 ELS ends November 30, 2020 RHEL 6 Supported by Rust Currently in Maintenance Support 2 Maintenance Support ends November 30, 2020
cc which I think they could be related.


Question: <del> FROM centos:5 </del> <ins> # We use Debian 6 (glibc 2.11, kernel 2.6.32) as a common base for other # distros that still need Rust support: RHEL 6 (glibc 2.12, kernel 2.6.32) and # SLES 11 SP4 (glibc 2.11, kernel 3.0). FROM debian:6 </ins> WORKDIR /build <del> # Centos 5 is EOL and is no longer available from the usual mirrors, so switch # to http://vault.centos.org/ RUN sed -i 's/enabled=1/enabled=0/' /etc/yum/pluginconf.d/fastestmirror.conf RUN sed -i 's/mirrorlist/#mirrorlist/' /etc/yum.repos.d/*.repo RUN sed -i 's|#(baseurl.*)mirror.centos.org/centos/$releasever|1vault.centos.org/5.11|' /etc/yum.repos.d/*.repo </del> <ins> # Debian 6 is EOL and no longer available from the usual mirrors, # so we'll need to switch to http://archive.debian.org/ RUN sed -i '/updates/d' /etc/apt/sources.list &&  sed -i 's/httpredir/archive/' /etc/apt/sources.list </ins> <del> RUN yum upgrade -y && yum install -y  curl  </del> <ins> RUN apt-get update &&  apt-get install --allow-unauthenticated -y --no-install-recommends  automake  </ins> bzip2  <ins> ca-certificates  curl  file  g++  g++-multilib  </ins> gcc  <del> gcc-c++  </del> <ins> gcc-multilib  git  lib32z1-dev  libedit-dev  libncurses-dev  </ins> make  <del> glibc-devel  </del> <ins> patch  </ins> perl  <del> zlib-devel  file  xz  which  pkgconfig  </del> <ins> pkg-config  unzip  </ins> wget  <del> autoconf  gettext </del> <ins> xz-utils  zlib1g-dev </ins> ENV PATH=/rustroot/bin:$PATH <del> ENV LD_LIBRARY_PATH=/rustroot/lib64:/rustroot/lib </del> <ins> ENV LD_LIBRARY_PATH=/rustroot/lib64:/rustroot/lib32:/rustroot/lib </ins> ENV PKG_CONFIG_PATH=/rustroot/lib/pkgconfig WORKDIR /tmp <ins> RUN mkdir /home/user </ins> COPY host-x86_64/dist-x86_64-linux/shared.sh /tmp/ # We need a build of openssl which supports SNI to download artifacts from

It also may be worth to drop support of Windows XP and Vista (especially considering that panics are broken on XP since June 2016, see: ). Previously it was discussed . cc
Besides , which other things would we be able to clean up?
Good question! There are 6 workarounds in for older Linux versions (that I could find). Increasing the minimum version to 2.6.32 (aka 3rd Kernel LTS, aka RHEL 6) would fix 5 of them. Code links are inline: (mentioned above, in 2.6.23) ( in 2.6.24, there is also the mention of a bug occuring on "some linux kernel at some point") to atomically set the flag on the pipe fds ( in 2.6.27) ( in 2.6.27) to permit use of ( in 2.6.28) ( in 4.5, not fixed by this proposal) As you can see, the workarounds fixed by this proposal all have a similar flavor.
I am Red Hat's maintainer for Rust on RHEL -- thanks for the cc. I try to keep an eye on new issues, but this one slipped past me. Red Hat only ships the Rust toolchain to customers for RHEL 7 and RHEL 8. If our customers would like to use Rust on older RHEL, they can do so via , and we'll support them in the same way we would for any other third-party software. Internally we do also build and use on RHEL 6, mostly because it's needed to ship Firefox updates. This is where it gets a little hairy, because each RHEL N is bootstrapped on RHEL N-1 and often kept that way -- meaning a lot of our RHEL 6 builders are still running on a RHEL 5 kernel. I would have to apply local workarounds if upstream Rust loses the ability to run on 2.6.18 kernels. We prefer to keep fixes upstream as much as possible, both for open sharing and to avoid bitrot. Is there much of a benefit to removing the current workarounds? I agree all of that code is annoying and cumbersome, but it's already written, and as far as I know it hasn't been a maintenance burden. Do you see otherwise?


Question: <del> FROM centos:5 </del> <ins> # We use Debian 6 (glibc 2.11, kernel 2.6.32) as a common base for other # distros that still need Rust support: RHEL 6 (glibc 2.12, kernel 2.6.32) and # SLES 11 SP4 (glibc 2.11, kernel 3.0). FROM debian:6 </ins> WORKDIR /build <del> # Centos 5 is EOL and is no longer available from the usual mirrors, so switch # to http://vault.centos.org/ RUN sed -i 's/enabled=1/enabled=0/' /etc/yum/pluginconf.d/fastestmirror.conf RUN sed -i 's/mirrorlist/#mirrorlist/' /etc/yum.repos.d/*.repo RUN sed -i 's|#(baseurl.*)mirror.centos.org/centos/$releasever|1vault.centos.org/5.11|' /etc/yum.repos.d/*.repo </del> <ins> # Debian 6 is EOL and no longer available from the usual mirrors, # so we'll need to switch to http://archive.debian.org/ RUN sed -i '/updates/d' /etc/apt/sources.list &&  sed -i 's/httpredir/archive/' /etc/apt/sources.list </ins> <del> RUN yum upgrade -y && yum install -y  curl  </del> <ins> RUN apt-get update &&  apt-get install --allow-unauthenticated -y --no-install-recommends  automake  </ins> bzip2  <ins> ca-certificates  curl  file  g++  g++-multilib  </ins> gcc  <del> gcc-c++  </del> <ins> gcc-multilib  git  lib32z1-dev  libedit-dev  libncurses-dev  </ins> make  <del> glibc-devel  </del> <ins> patch  </ins> perl  <del> zlib-devel  file  xz  which  pkgconfig  </del> <ins> pkg-config  unzip  </ins> wget  <del> autoconf  gettext </del> <ins> xz-utils  zlib1g-dev </ins> ENV PATH=/rustroot/bin:$PATH <del> ENV LD_LIBRARY_PATH=/rustroot/lib64:/rustroot/lib </del> <ins> ENV LD_LIBRARY_PATH=/rustroot/lib64:/rustroot/lib32:/rustroot/lib </ins> ENV PKG_CONFIG_PATH=/rustroot/lib/pkgconfig WORKDIR /tmp <ins> RUN mkdir /home/user </ins> COPY host-x86_64/dist-x86_64-linux/shared.sh /tmp/ # We need a build of openssl which supports SNI to download artifacts from

If there are any known issues with such Linux compatibility code, I am definitely willing to take assignment for fixing them.
(Not a Rust maintainer, but I'm a Rust user and maintain a lot of other OSS software so I have well-developed feelings around supporting Very Old Software :-)) Do you have any sense of on what timeline Rust would be able to drop support for 2.6.18 kernels without causing you pain? In general I don't think people mind supporting configurations that have users and are painful to work around, but needing to support them for forever is a bitter pill to swallow! Particularly as they get harder and harder to test over time (already I have no idea how to test on really old kernels besides building it myself). So if there was an estimate "we'd like to be able to support this until Q2 2020", even if it's not set in stone, I think that would be very helpful!
The other benefit would be that Rust wouldn't have to use CentOS 5 for CI, which means we don't have to patch LLVM (and Emscripten LLVM) to compile on those systems. Of course that's also fairly limited in scope.
As soon as we stop shipping Firefox and Thunderbird updates on RHEL 6, I won't need Rust there anymore. AFAIK this does correspond to the end of Maintenance Support, November 30, 2020. Then I'll be on to RHEL 7 builders as my minimum, probably still with some RHEL 6 2.6.32 kernels involved. It should be fine for me if we update CI to CentOS 6. This is mostly concerned with how the release binaries are linked to GLIBC symbol versions, which is all in userspace. It's a broader community question whether any other Rust users still care about running on RHEL or CentOS 5. (Small caveat - glibc support for a symbol can still return , .)
I noticed that Red Hat also has Extended Life Cycle Support (ELS) for RHEL 6 until June 30, 2024. Will you need RHEL 5 to work during this time? I don't know how ELS works with Firefox updates. Also, is there any reason RHEL 4 support wasn't an issue prior to March 31, 2017 (while RHEL 5 was still normally supported)?


Question: <del> FROM centos:5 </del> <ins> # We use Debian 6 (glibc 2.11, kernel 2.6.32) as a common base for other # distros that still need Rust support: RHEL 6 (glibc 2.12, kernel 2.6.32) and # SLES 11 SP4 (glibc 2.11, kernel 3.0). FROM debian:6 </ins> WORKDIR /build <del> # Centos 5 is EOL and is no longer available from the usual mirrors, so switch # to http://vault.centos.org/ RUN sed -i 's/enabled=1/enabled=0/' /etc/yum/pluginconf.d/fastestmirror.conf RUN sed -i 's/mirrorlist/#mirrorlist/' /etc/yum.repos.d/*.repo RUN sed -i 's|#(baseurl.*)mirror.centos.org/centos/$releasever|1vault.centos.org/5.11|' /etc/yum.repos.d/*.repo </del> <ins> # Debian 6 is EOL and no longer available from the usual mirrors, # so we'll need to switch to http://archive.debian.org/ RUN sed -i '/updates/d' /etc/apt/sources.list &&  sed -i 's/httpredir/archive/' /etc/apt/sources.list </ins> <del> RUN yum upgrade -y && yum install -y  curl  </del> <ins> RUN apt-get update &&  apt-get install --allow-unauthenticated -y --no-install-recommends  automake  </ins> bzip2  <ins> ca-certificates  curl  file  g++  g++-multilib  </ins> gcc  <del> gcc-c++  </del> <ins> gcc-multilib  git  lib32z1-dev  libedit-dev  libncurses-dev  </ins> make  <del> glibc-devel  </del> <ins> patch  </ins> perl  <del> zlib-devel  file  xz  which  pkgconfig  </del> <ins> pkg-config  unzip  </ins> wget  <del> autoconf  gettext </del> <ins> xz-utils  zlib1g-dev </ins> ENV PATH=/rustroot/bin:$PATH <del> ENV LD_LIBRARY_PATH=/rustroot/lib64:/rustroot/lib </del> <ins> ENV LD_LIBRARY_PATH=/rustroot/lib64:/rustroot/lib32:/rustroot/lib </ins> ENV PKG_CONFIG_PATH=/rustroot/lib/pkgconfig WORKDIR /tmp <ins> RUN mkdir /home/user </ins> COPY host-x86_64/dist-x86_64-linux/shared.sh /tmp/ # We need a build of openssl which supports SNI to download artifacts from

This issue came up for me when dealing with opening files in , see for more info. No single RHEL 5 issue is that bad, it's mainly just the sum of a bunch of tiny issues.
I'm not on that team, but AFAIK we don't ship Firefox updates for ELS. The last build I see for RHEL 5 was . Maybe there could be an exception for a severe security issue, but I really doubt we'd rebase to newer Firefox for that, which means Rust requirements won't change. New Firefox ESR versions do require a newer Rust toolchain too, which is generally why we have to keep up. Otherwise we could just freeze some older compat rustc while upstream moves on. Rust wasn't required until Firefox 52.
that makes perfect sense to me, thanks for clarifying. So the proposed policy would be: Support RHEL until RHEL is retired (i.e. ends normal support). This would mean: Supporting RHEL 5 (v2.6.18) until November 30, 2020 Supporting RHEL 6 (v2.6.32) until June 30, 2024 Supporting RHEL 7 (v3.10) until May, 2029 This is a much longer support tail than any other Linux distros (that I know of), so it would also be the effective minimum kernel version of , , and their dependencies. How does that sound to people? EDIT: The alternative to this would be Support RHEL until it is retired, taking the table above and incrementing the RHEL versions by 1. It would also mean being able to drop RHEL 5 support now.
Sure, that's ideal for me. :smile: As mentioned, is just needed for kernel support, as far as I'm concerned. Userspace concerns like GLIBC symbol versions can stick to currently supported for my needs.
Red Hat should backport the features we need (CLOEXEC and getrandom, in particular) to whatever kernels that it wants Rust to support. I don't know any good reason why they don't do so, other than it's cheaper to convince the whole world to keep supporting older kernel versions than it is to do the backports. We should change that dynamic.


Question: <del> FROM centos:5 </del> <ins> # We use Debian 6 (glibc 2.11, kernel 2.6.32) as a common base for other # distros that still need Rust support: RHEL 6 (glibc 2.12, kernel 2.6.32) and # SLES 11 SP4 (glibc 2.11, kernel 3.0). FROM debian:6 </ins> WORKDIR /build <del> # Centos 5 is EOL and is no longer available from the usual mirrors, so switch # to http://vault.centos.org/ RUN sed -i 's/enabled=1/enabled=0/' /etc/yum/pluginconf.d/fastestmirror.conf RUN sed -i 's/mirrorlist/#mirrorlist/' /etc/yum.repos.d/*.repo RUN sed -i 's|#(baseurl.*)mirror.centos.org/centos/$releasever|1vault.centos.org/5.11|' /etc/yum.repos.d/*.repo </del> <ins> # Debian 6 is EOL and no longer available from the usual mirrors, # so we'll need to switch to http://archive.debian.org/ RUN sed -i '/updates/d' /etc/apt/sources.list &&  sed -i 's/httpredir/archive/' /etc/apt/sources.list </ins> <del> RUN yum upgrade -y && yum install -y  curl  </del> <ins> RUN apt-get update &&  apt-get install --allow-unauthenticated -y --no-install-recommends  automake  </ins> bzip2  <ins> ca-certificates  curl  file  g++  g++-multilib  </ins> gcc  <del> gcc-c++  </del> <ins> gcc-multilib  git  lib32z1-dev  libedit-dev  libncurses-dev  </ins> make  <del> glibc-devel  </del> <ins> patch  </ins> perl  <del> zlib-devel  file  xz  which  pkgconfig  </del> <ins> pkg-config  unzip  </ins> wget  <del> autoconf  gettext </del> <ins> xz-utils  zlib1g-dev </ins> ENV PATH=/rustroot/bin:$PATH <del> ENV LD_LIBRARY_PATH=/rustroot/lib64:/rustroot/lib </del> <ins> ENV LD_LIBRARY_PATH=/rustroot/lib64:/rustroot/lib32:/rustroot/lib </ins> ENV PKG_CONFIG_PATH=/rustroot/lib/pkgconfig WORKDIR /tmp <ins> RUN mkdir /home/user </ins> COPY host-x86_64/dist-x86_64-linux/shared.sh /tmp/ # We need a build of openssl which supports SNI to download artifacts from

The alternative to this would be Support RHEL N until it is retired I think we should not officially support retired OS versions (well, maybe with some grace period), so I prefer this option. Supporting 14 year old kernels seems a bit too much to me. each RHEL N is bootstrapped on RHEL N-1 and often kept that way -- meaning a lot of our RHEL 6 builders are still running on a RHEL 5 kernel Is it possible to apply kernel patches to those builders to add support for functionality like CLOEXEC? Or build Firefox separately on RHEL 6?
I think it won't be fruitful for us to debate the merits of stable enterprise kernels, but no, this is not a possibility. An alternative take is "Red Hat should be responsible for the work in Rust to maintain the support they want" -- here I am, ready and willing. I definitely can't change those kernels. The ones that are stuck on N-1 are precisely to avoid rocking the boat, and backporting features is a big change. Some of our arches do eventually update the builders to their matching N kernel, but some don't, and I don't know all the reasons. If the workarounds are removed, then I will have to reapply them in our own builds. This assumes I keep using only our own binaries -- if I ever have to re-bootstrap from upstream binaries for stage0, I would also have to use some interception (like ) to hack in the workarounds. This is all possible, but much worse than the status quo of maintaining support here.
I think this sounds reasonable. We aren't going to be able to update these kernels, it's just a question of when we would drop support for these OSes. Especially given that we wont need RHEL 5 CI support, I think that leaving things as they are is fine. I opened this issue to verify two things: 1) That we weren't intending on supporting RHEL 5 "forever", and had a clear date when to drop support. 2) That someone from Red Hat actively cared about supporting these older kernels. It looks like both these things are true. We should remove RHEL 5 workarounds after November 30, 2020. This issue can be postponed until then.


Question: <del> FROM centos:5 </del> <ins> # We use Debian 6 (glibc 2.11, kernel 2.6.32) as a common base for other # distros that still need Rust support: RHEL 6 (glibc 2.12, kernel 2.6.32) and # SLES 11 SP4 (glibc 2.11, kernel 3.0). FROM debian:6 </ins> WORKDIR /build <del> # Centos 5 is EOL and is no longer available from the usual mirrors, so switch # to http://vault.centos.org/ RUN sed -i 's/enabled=1/enabled=0/' /etc/yum/pluginconf.d/fastestmirror.conf RUN sed -i 's/mirrorlist/#mirrorlist/' /etc/yum.repos.d/*.repo RUN sed -i 's|#(baseurl.*)mirror.centos.org/centos/$releasever|1vault.centos.org/5.11|' /etc/yum.repos.d/*.repo </del> <ins> # Debian 6 is EOL and no longer available from the usual mirrors, # so we'll need to switch to http://archive.debian.org/ RUN sed -i '/updates/d' /etc/apt/sources.list &&  sed -i 's/httpredir/archive/' /etc/apt/sources.list </ins> <del> RUN yum upgrade -y && yum install -y  curl  </del> <ins> RUN apt-get update &&  apt-get install --allow-unauthenticated -y --no-install-recommends  automake  </ins> bzip2  <ins> ca-certificates  curl  file  g++  g++-multilib  </ins> gcc  <del> gcc-c++  </del> <ins> gcc-multilib  git  lib32z1-dev  libedit-dev  libncurses-dev  </ins> make  <del> glibc-devel  </del> <ins> patch  </ins> perl  <del> zlib-devel  file  xz  which  pkgconfig  </del> <ins> pkg-config  unzip  </ins> wget  <del> autoconf  gettext </del> <ins> xz-utils  zlib1g-dev </ins> ENV PATH=/rustroot/bin:$PATH <del> ENV LD_LIBRARY_PATH=/rustroot/lib64:/rustroot/lib </del> <ins> ENV LD_LIBRARY_PATH=/rustroot/lib64:/rustroot/lib32:/rustroot/lib </ins> ENV PKG_CONFIG_PATH=/rustroot/lib/pkgconfig WORKDIR /tmp <ins> RUN mkdir /home/user </ins> COPY host-x86_64/dist-x86_64-linux/shared.sh /tmp/ # We need a build of openssl which supports SNI to download artifacts from

EDIT: For our use case in , we were able to add compatibility for RHEL 5 .
See for a recent case where supporting such ancient kernels required extra manual work ( to the 2 lines mentioned by above). I am not sure how often that comes up, but probably the hardest part is to even notice that it happens -- and even then those codepaths will likely linger untested.
Yes, but this will still be true in general. If the CI kernel is newer than whatever kernel baseline we choose, it will be possible for newer syscalls to pass undetected. I don't know if we have any control over that -- can we choose a particular VM image? So that leaves us with a stated policy of support. The more that developers are aware of such issues, the better, but I'm the one most likely to notice when my build actually fails. If I come back with a fix, I at least need the project to be receptive. I haven't been in the habit of building nightly on our RHEL6 builders, but maybe I should! Catching this early is better for everyone involved...
That seems reasonable. How quick is the Rust related bootstrapping? Could it be run automatically (or more frequently)? This is an interesting point. If I hadn't made that change, would have kept working on RHEL 5, it just would have leaked an FD. I'm not sure how we would even test for this sort of thing. This isn't a RHEL 5 specific concern, I just don't know how Rust tests these types of resource leak issues in general.
About 2 hours. Automation is harder, since I believe our build system needs my credentials, but I'll look into what is possible here. Yeah, that's a lot more subtle than an !


Question: // For each token tree in `input`, parse the token into a `self::TokenTree`, consuming // additional trees if need be. <del> let mut trees = input.trees(); </del> <ins> let mut trees = input.trees().peekable(); </ins> while let Some(tree) = trees.next() { // Given the parsed tree, if there is a metavar and we are expecting matchers, actually // parse out the matcher (i.e., in `$id:ident` this would parse the `:` and `ident`). let tree = parse_tree(tree, &mut trees, parsing_patterns, sess, node_id, features, edition); match tree { TokenTree::MetaVar(start_sp, ident) if parsing_patterns => { <del> let span = match trees.next() { </del> <ins> // Not consuming the next token immediately, as it may not be a colon let span = match trees.peek() { </ins> Some(&tokenstream::TokenTree::Token( Token { kind: token::Colon, span: colon_span }, _, )) => { <ins> // Consume the colon first trees.next(); // It's ok to consume the next tree no matter how, // since if it's not a token then it will be an invalid declaration. </ins> match trees.next() { Some(tokenstream::TokenTree::Token(token, _)) => match token.ident() { Some((fragment, _)) => {

Here's some code incorrectly defining a macro, because it's missing a fragment specifier. Here's the error message rustc gives me: It's potentially confusing that the error points to the source after the name with the missing fragment specifier. Especially in a complicated macro, it would be better if it pointed to the item which was actually missing the fragment specifier. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Some more context at


Question: let arenas = ty::CtxtArenas::new(); let hir_map = driver::make_map(&sess, &mut hir_forest); <del> abort_on_err(driver::phase_3_run_analysis_passes(&sess, </del> <ins> let krate_and_analysis = abort_on_err(driver::phase_3_run_analysis_passes(&sess, </ins> &cstore, hir_map, &arenas, &name, resolve::MakeGlobMap::No, <del> |tcx, _, analysis, _| { </del> <ins> |tcx, _, analysis, result| { // Return if the driver hit an err (in `result`) if let Err(_) = result { return None } </ins> let _ignore = tcx.dep_graph.in_ignore(); let ty::CrateAnalysis { access_levels, .. } = analysis;

Any of the following uses of cause an ICE in , but not in : Use of in a local is fine; these all simply report the error without an ICE.
I believe this may be a regression caused by . Working on a fix. Edit: Maybe not, actually. Either way I'm looking into it.


Question: CFG_DISABLE_UNSTABLE_FEATURES=1 endif ifeq ($(CFG_RELEASE_CHANNEL),beta) <del> CFG_RELEASE=$(CFG_RELEASE_NUM)-beta </del> <ins> CFG_RELEASE=$(CFG_RELEASE_NUM)-beta$(CFG_PRERELEASE_VERSION) </ins> # When building beta distributables just reuse the same "beta" name # so when we upload we'll always override the previous beta. This # doesn't actually impact the version reported by rustc - it's just

current beta is 'rustc 1.1.0-beta' but it should be 'rustc 1.1.0-beta.1'


Question: <ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // no-prefer-dynamic #![crate_type = "proc-macro"] #![feature(proc_macro, proc_macro_lib)] extern crate proc_macro; use proc_macro::TokenStream; #[proc_macro_derive(Foo)] pub fn derive_foo(input: TokenStream) -> TokenStream { input } #[proc_macro_derive(Bar)] pub fn derive_bar(input: TokenStream) -> TokenStream { panic!("lolnope"); } </ins>

Inlined from Another issue. If a struct has two different custom derives on it and the second one panics, the error span will point to the first one, not the one which panicked. Reproduction Script
was "Reproduction Script" supposed to be a link? I'm spinning this off from as I don't think it's going to block stabilization and/or closing that issue.
Reproduction script there is a summary tag
<details<summaryReproduction Script</summaryIn a crate called In another crate The error will highlight even though panicked. </details
This seems to be fixed now, so this issue can be closed.
I ran this as a test, and got the following output:


Question: original_path, target_place, span, <ins> use_spans, </ins> ) } IllegalMoveOriginKind::InteriorOfTypeWithDestructor { container_ty: ty } => {

gives the error: Error0507 gives a wrong suggestion here:
Error: Label D-invalid-suggestion can only be set by Rust team members Please let know if you're having trouble with this bot.
modify labels: A-suggestion-diagnostics C-bug T-compiler


Question: <ins> // Regression test for https://github.com/rust-lang/rust/issues/122549 // was fixed by https://github.com/rust-lang/rust/pull/122749 trait ConstChunksExactTrait<T> { fn const_chunks_exact<const N: usize>(&self) -> ConstChunksExact<'a, T, { N }>; //~^ ERROR undeclared lifetime } impl<T> ConstChunksExactTrait<T> for [T] {} //~^ ERROR not all trait items implemented, missing: `const_chunks_exact` struct ConstChunksExact<'rem, T: 'a, const N: usize> {} //~^ ERROR use of undeclared lifetime name `'a` //~^^ ERROR lifetime parameter //~^^^ ERROR type parameter impl<'a, T, const N: usize> Iterator for ConstChunksExact<'a, T, {}> { //~^ ERROR the const parameter `N` is not constrained by the impl trait, self type, or predicates //~^^ ERROR mismatched types type Item = &'a [T; N]; } fn main() { let slice = &[1i32, 2, 3, 4, 5, 6, 7, 8, 9, 10]; let mut iter = [[1, 2, 3], [4, 5, 6], [7, 8, 9]].iter(); for a in slice.const_chunks_exact::<3>() { assert_eq!(a, iter.next().unwrap()); } } </ins>

<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'unexpected inference var std::option::Option<&'?16 [i32; ?0c: usize]'', 'thread 'rustc' panicked at 'unexpected inference var std::option::Option<&'?16 [i32; ?0c: usize]'' File: --snippet, probably from Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<perror[E0261]: use of undeclared lifetime name -- | 2 | fn constchunksexact<const N: usize(&self) -ConstChunksExact<'a, T, { N }; | ^^ undeclared lifetime | help: consider introducing lifetime here | 2 | fn constchunksexact<'a, const N: usize(&self) -ConstChunksExact<'a, T, { N }; | +++ help: consider introducing lifetime here | 1 | trait ConstChunksExactTrait<'a, T{ | +++ error[E0261]: use of undeclared lifetime name -- | 7 | struct ConstChunksExact<'rem, T: 'a, const N: usize{} | - ^^ undeclared lifetime | help: consider introducing lifetime here: error[E0046]: not all trait items implemented, missing: -- | 2 | fn constchunks_exact<const N: usize(&self) -ConstChunksExact<'a, T, { N }; |
from trait . 5 | impl<TConstChunksExactTrait<Tfor [T] {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ missing in implementation error[E0392]: lifetime parameter is never used -- | 7 | struct ConstChunksExact<'rem, T: 'a, const N: usize{} | ^^^^ unused lifetime parameter | = help: consider removing , referring to it in a field, or using a marker such as error[E0392]: type parameter is never used -- | 7 | struct ConstChunksExact<'rem, T: 'a, const N: usize{} | ^ unused type parameter | = help: consider removing , referring to it in a field, or using a marker such as error[E0207]: the const parameter is not constrained by the impl trait, self type, or predicates -- | 9 | impl<'a, T,


Question: <ins> // Regression test for https://github.com/rust-lang/rust/issues/122549 // was fixed by https://github.com/rust-lang/rust/pull/122749 trait ConstChunksExactTrait<T> { fn const_chunks_exact<const N: usize>(&self) -> ConstChunksExact<'a, T, { N }>; //~^ ERROR undeclared lifetime } impl<T> ConstChunksExactTrait<T> for [T] {} //~^ ERROR not all trait items implemented, missing: `const_chunks_exact` struct ConstChunksExact<'rem, T: 'a, const N: usize> {} //~^ ERROR use of undeclared lifetime name `'a` //~^^ ERROR lifetime parameter //~^^^ ERROR type parameter impl<'a, T, const N: usize> Iterator for ConstChunksExact<'a, T, {}> { //~^ ERROR the const parameter `N` is not constrained by the impl trait, self type, or predicates //~^^ ERROR mismatched types type Item = &'a [T; N]; } fn main() { let slice = &[1i32, 2, 3, 4, 5, 6, 7, 8, 9, 10]; let mut iter = [[1, 2, 3], [4, 5, 6], [7, 8, 9]].iter(); for a in slice.const_chunks_exact::<3>() { assert_eq!(a, iter.next().unwrap()); } } </ins>

const N: usizeIterator for ConstChunksExact<'a, T, {}{ | ^^^^^^^^^^^^^^ unconstrained const parameter | = note: expressions using a const parameter must map each value to a distinct output value = note: proving the result of expressions other than the parameter are unique is not supported error[E0308]: mismatched types -- | 9 | impl<'a, T, const N: usizeIterator for ConstChunksExact<'a, T, {}{ | ^^ expected , found thread 'rustc' panicked at unexpected inference var std::option::Option<&'?16 [i32;


Question: <ins> // Regression test for https://github.com/rust-lang/rust/issues/122549 // was fixed by https://github.com/rust-lang/rust/pull/122749 trait ConstChunksExactTrait<T> { fn const_chunks_exact<const N: usize>(&self) -> ConstChunksExact<'a, T, { N }>; //~^ ERROR undeclared lifetime } impl<T> ConstChunksExactTrait<T> for [T] {} //~^ ERROR not all trait items implemented, missing: `const_chunks_exact` struct ConstChunksExact<'rem, T: 'a, const N: usize> {} //~^ ERROR use of undeclared lifetime name `'a` //~^^ ERROR lifetime parameter //~^^^ ERROR type parameter impl<'a, T, const N: usize> Iterator for ConstChunksExact<'a, T, {}> { //~^ ERROR the const parameter `N` is not constrained by the impl trait, self type, or predicates //~^^ ERROR mismatched types type Item = &'a [T; N]; } fn main() { let slice = &[1i32, 2, 3, 4, 5, 6, 7, 8, 9, 10]; let mut iter = [[1, 2, 3], [4, 5, 6], [7, 8, 9]].iter(); for a in slice.const_chunks_exact::<3>() { assert_eq!(a, iter.next().unwrap()); } } </ins>

?0c: usize]stack backtrace: 0: 0x7ff8073a4912 - std::backtracers::backtrace::libunwind::trace::h2da6c6ec1776ed1b at 1: 0x7ff8073a4912 - std::backtracers::backtrace::traceunsynchronized::h0cb696e9cf0107ba at 2: 0x7ff8073a4912 - std::syscommon::backtrace::printfmt::hfb11ed7a7d38a028 at 3: 0x7ff8073a4912 - <std::syscommon::backtrace::print::DisplayBacktrace as core::fmt::Display::fmt::h1048d052a888b26c at 4: 0x7ff8073f5c8c - core::fmt::rt::Argument::fmt::hcf8265a03a389e34 at 5: 0x7ff8073f5c8c - core::fmt::write::hd12c3a84e62e1cec at 6: 0x7ff80739980f - std::io::Write::writefmt::h236993be0d5d91de at 7: 0x7ff8073a46e4 - std::syscommon::backtrace::print::he44e9b7b149d34c3 at 8: 0x7ff8073a46e4 - std::syscommon::backtrace::print::h6f8e8e3b9f052551 at 9: 0x7ff8073a73eb - std::panicking::defaulthook::{{closure}}::h321d04c9179dccca 10: 0x7ff8073a7143 - std::panicking::defaulthook::hd949d1362c2e5565 at 11: 0x7ff803fa68ef - std[]::panicking::updatehook::<alloc[]::boxed::Box<rustcdriverimpl[]::installicehook::{closure}::{closure} 12: 0x7ff8073a7b50 - <alloc::boxed::Box<F,


Question: <ins> // Regression test for https://github.com/rust-lang/rust/issues/122549 // was fixed by https://github.com/rust-lang/rust/pull/122749 trait ConstChunksExactTrait<T> { fn const_chunks_exact<const N: usize>(&self) -> ConstChunksExact<'a, T, { N }>; //~^ ERROR undeclared lifetime } impl<T> ConstChunksExactTrait<T> for [T] {} //~^ ERROR not all trait items implemented, missing: `const_chunks_exact` struct ConstChunksExact<'rem, T: 'a, const N: usize> {} //~^ ERROR use of undeclared lifetime name `'a` //~^^ ERROR lifetime parameter //~^^^ ERROR type parameter impl<'a, T, const N: usize> Iterator for ConstChunksExact<'a, T, {}> { //~^ ERROR the const parameter `N` is not constrained by the impl trait, self type, or predicates //~^^ ERROR mismatched types type Item = &'a [T; N]; } fn main() { let slice = &[1i32, 2, 3, 4, 5, 6, 7, 8, 9, 10]; let mut iter = [[1, 2, 3], [4, 5, 6], [7, 8, 9]].iter(); for a in slice.const_chunks_exact::<3>() { assert_eq!(a, iter.next().unwrap()); } } </ins>

Aas core::ops::function::Fn<Args::call::h4f6c988be7bdee68 at 13: 0x7ff8073a7b50 - std::panicking::rustpanicwithhook::hb71de646be3b3469 at 14: 0x7ff8073a7892 - std::panicking::beginpanichandler::{{closure}}::hbca15a8a0a3dee72 at 15: 0x7ff8073a4de6 - std::syscommon::backtrace::rustendshortbacktrace::h885125d06f4d13f0 at 16: 0x7ff8073a75c4 - rustbeginunwind at 17: 0x7ff8073f21a5 - core::panicking::panicfmt::ha3facef8c988a935 at 18: 0x7ff80529d0a8 - <rustcborrowck[]::typecheck::relatetys::NllTypeRelating as rustcmiddle[]::ty::relate::TypeRelation::tys 19: 0x7ff80608d936 - <rustcborrowck[]::typecheck::TypeChecker::typeckmir 20: 0x7ff802afa5fa - rustcborrowck[]::typecheck::typecheck 21: 0x7ff802b34257 - rustcborrowck[]::nll::computeregions 22: 0x7ff80601edc1 - rustcborrowck[]::domirborrowck 23: 0x7ff806011128 - rustcborrowck[]::mirborrowck 24: 0x7ff806010c17 - rustcqueryimpl[]::plumbing::rustbeginshortbacktrace::<rustcqueryimpl[]::queryimpl::mirborrowck::dynamicquery::{closure}::{closure}, rustcmiddle[]::query::erase::Erased<[u8; 8usize]25: 0x7ff80540ff2e - rustcquerysystem[]::query::plumbing::tryexecutequery::<rustcqueryimpl[]::DynamicConfig<rustcquerysystem[]::query::caches::VecCache<rustcspan[]::defid::LocalDefId,


Question: <ins> // Regression test for https://github.com/rust-lang/rust/issues/122549 // was fixed by https://github.com/rust-lang/rust/pull/122749 trait ConstChunksExactTrait<T> { fn const_chunks_exact<const N: usize>(&self) -> ConstChunksExact<'a, T, { N }>; //~^ ERROR undeclared lifetime } impl<T> ConstChunksExactTrait<T> for [T] {} //~^ ERROR not all trait items implemented, missing: `const_chunks_exact` struct ConstChunksExact<'rem, T: 'a, const N: usize> {} //~^ ERROR use of undeclared lifetime name `'a` //~^^ ERROR lifetime parameter //~^^^ ERROR type parameter impl<'a, T, const N: usize> Iterator for ConstChunksExact<'a, T, {}> { //~^ ERROR the const parameter `N` is not constrained by the impl trait, self type, or predicates //~^^ ERROR mismatched types type Item = &'a [T; N]; } fn main() { let slice = &[1i32, 2, 3, 4, 5, 6, 7, 8, 9, 10]; let mut iter = [[1, 2, 3], [4, 5, 6], [7, 8, 9]].iter(); for a in slice.const_chunks_exact::<3>() { assert_eq!(a, iter.next().unwrap()); } } </ins>

rustcmiddle[]::query::erase::Erased<[u8; 8usize], false, false, false, rustcqueryimpl[]::plumbing::QueryCtxt, false26: 0x7ff80540fa4c - rustcqueryimpl[]::queryimpl::mirborrowck::getquerynonincr::rustendshortbacktrace 27: 0x7ff80599919e - rustcinterface[]::passes::analysis 28: 0x7ff805998425 - rustcqueryimpl[]::plumbing::rustbeginshortbacktrace::<rustcqueryimpl[]::queryimpl::analysis::dynamicquery::{closure}::{closure}, rustcmiddle[]::query::erase::Erased<[u8; 1usize]29: 0x7ff806006165 - rustcquerysystem[]::query::plumbing::tryexecutequery::<rustcqueryimpl[]::DynamicConfig<rustcquerysystem[]::query::caches::SingleCache<rustcmiddle[]::query::erase::Erased<[u8; 1usize], false, false, false, rustcqueryimpl[]::plumbing::QueryCtxt, false30: 0x7ff806005ec9 - rustcqueryimpl[]::queryimpl::analysis::getquerynonincr::rustendshortbacktrace 31: 0x7ff805d5e284 - rustcinterface[]::interface::runcompiler::<core[]::result::Result<(), rustcspan[]::ErrorGuaranteed, rustcdriverimpl[]::runcompiler::{closure}::{closure} 32: 0x7ff806223805 - std[]::syscommon::backtrace::rustbeginshortbacktrace::<rustcinterface[]::util::runinthreadwithglobals<rustcinterface[]::util::runinthreadpoolwithglobals<rustcinterface[]::interface::runcompiler<core[]::result::Result<(), rustcspan[]::ErrorGuaranteed, rustcdriverimpl[]::runcompiler::{closure}::{closure}, core[]::result::Result<(), rustcspan[]::ErrorGuaranteed::{closure}, core[]::result::Result<(), rustcspan[]::ErrorGuaranteed::{closure}::{closure}, core[]::result::Result<(),


Question: <ins> // Regression test for https://github.com/rust-lang/rust/issues/122549 // was fixed by https://github.com/rust-lang/rust/pull/122749 trait ConstChunksExactTrait<T> { fn const_chunks_exact<const N: usize>(&self) -> ConstChunksExact<'a, T, { N }>; //~^ ERROR undeclared lifetime } impl<T> ConstChunksExactTrait<T> for [T] {} //~^ ERROR not all trait items implemented, missing: `const_chunks_exact` struct ConstChunksExact<'rem, T: 'a, const N: usize> {} //~^ ERROR use of undeclared lifetime name `'a` //~^^ ERROR lifetime parameter //~^^^ ERROR type parameter impl<'a, T, const N: usize> Iterator for ConstChunksExact<'a, T, {}> { //~^ ERROR the const parameter `N` is not constrained by the impl trait, self type, or predicates //~^^ ERROR mismatched types type Item = &'a [T; N]; } fn main() { let slice = &[1i32, 2, 3, 4, 5, 6, 7, 8, 9, 10]; let mut iter = [[1, 2, 3], [4, 5, 6], [7, 8, 9]].iter(); for a in slice.const_chunks_exact::<3>() { assert_eq!(a, iter.next().unwrap()); } } </ins>

rustcspan[]::ErrorGuaranteed33: 0x7ff806223632 - <<std[]::thread::Builder::spawnunchecked<rustcinterface[]::util::runinthreadwithglobals<rustcinterface[]::util::runinthreadpoolwithglobals<rustcinterface[]::interface::runcompiler<core[]::result::Result<(), rustcspan[]::ErrorGuaranteed, rustcdriverimpl[]::runcompiler::{closure}::{closure}, core[]::result::Result<(), rustcspan[]::ErrorGuaranteed::{closure}, core[]::result::Result<(), rustcspan[]::ErrorGuaranteed::{closure}::{closure}, core[]::result::Result<(), rustcspan[]::ErrorGuaranteed::{closure} as core[]::ops::function::FnOnce<()::callonce::{shim:vtable} 34: 0x7ff8073b11e5 - <alloc::boxed::Box<F,Aas core::ops::function::FnOnce<Args::callonce::hab5d072bb143d8fe at 35: 0x7ff8073b11e5 - <alloc::boxed::Box<F,Aas core::ops::function::FnOnce<Args::callonce::he1f566ad483a8fda at 36: 0x7ff8073b11e5 - std::sys::pal::unix::thread::Thread::new::threadstart::h23d47a8da771b95c at 37: 0x7ff800ea955a - <unknown38: 0x7ff800f26a3c - <unknown39: 0x0 - <unknownerror: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: rustc 1.78.0-nightly ( 2024-03-15) running on x8664-unknown-linux-gnu query stack during panic: [mirborrowck] borrow-checking [analysis] running analysis passes on this crate end of query stack error: aborting due to 7 previous errors Some errors have detailed explanations: E0046, E0207, E0261, E0308, E0392. For more information about an error, try .


Question: <ins> // Regression test for https://github.com/rust-lang/rust/issues/122549 // was fixed by https://github.com/rust-lang/rust/pull/122749 trait ConstChunksExactTrait<T> { fn const_chunks_exact<const N: usize>(&self) -> ConstChunksExact<'a, T, { N }>; //~^ ERROR undeclared lifetime } impl<T> ConstChunksExactTrait<T> for [T] {} //~^ ERROR not all trait items implemented, missing: `const_chunks_exact` struct ConstChunksExact<'rem, T: 'a, const N: usize> {} //~^ ERROR use of undeclared lifetime name `'a` //~^^ ERROR lifetime parameter //~^^^ ERROR type parameter impl<'a, T, const N: usize> Iterator for ConstChunksExact<'a, T, {}> { //~^ ERROR the const parameter `N` is not constrained by the impl trait, self type, or predicates //~^^ ERROR mismatched types type Item = &'a [T; N]; } fn main() { let slice = &[1i32, 2, 3, 4, 5, 6, 7, 8, 9, 10]; let mut iter = [[1, 2, 3], [4, 5, 6], [7, 8, 9]].iter(); for a in slice.const_chunks_exact::<3>() { assert_eq!(a, iter.next().unwrap()); } } </ins>

</p</details<!-- query stack: 5 | impl<TConstChunksExactTrait<Tfor [T] {} [mirborrowck] borrow-checking [analysis] running analysis passes on this crate --
cc


Question: // Parse the arguments, starting out with `self` being allowed... let (mut params, _) = self.parse_paren_comma_seq(|p| { p.recover_diff_marker(); <ins> let snapshot = p.create_snapshot_for_diagnostic(); </ins> let param = p.parse_param_general(req_name, first_param).or_else(|mut e| { e.emit(); let lo = p.prev_token.span; <ins> p.restore_snapshot(snapshot); </ins> // Skip every token until next possible arg or end. p.eat_to_tokens(&[&token::Comma, &token::CloseDelim(Delimiter::Parenthesis)]); // Create a placeholder argument for proper arg count (issue #34264).

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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regression in nightly-2021-04-12 finding bors merge commits found 9 bors merge commits in the specified range commit[0] 2021-04-10: Auto merge of - Aaron1011:new-preexp-tests, r=petrochenkov commit[1] 2021-04-10: Auto merge of - Aaron1011:derive-invoc-order, r=petrochenkov commit[2] 2021-04-11: Auto merge of - RalfJung:liballoc-miri, r=Manishearth commit[3] 2021-04-11: Auto merge of - nagisa:nixos-patching-fix, r=Mark-Simulacrum commit[4] 2021-04-11: Auto merge of - JohnTitor:issue-, r=estebank commit[5] 2021-04-11: Auto merge of - Aaron1011:feature/final-preexp-tts, r=petrochenkov commit[6] 2021-04-11: Auto merge of - LingMan:patch-1, r=nagisa commit[7] 2021-04-11: Auto merge of - tweksteen:androidsetmessage, r=m-ou-se commit[8] 2021-04-11: Auto merge of - hyd-dev:uwtable, r=nagisa
claim
Reduced reproduction:
claim


Question: #[serde(rename_all = "snake_case")] #[serde(tag = "variant_kind", content = "variant_inner")] pub enum Variant { <ins> /// A variant with no parentheses, and possible discriminant. /// /// ```rust /// enum Demo { ///     PlainVariant, ///     PlainWithDiscriminant = 1, /// } /// ``` </ins> Plain(Option<Discriminant>), <del> Tuple(Vec<Type>), Struct(Vec<Id>), </del> <ins> /// A variant with unnamed fields. /// /// Unlike most of json, `#[doc(hidden)]` fields will be given as `None` /// instead of being ommited, because order matters. /// /// ```rust /// enum Demo { ///     TupleVariant(i32), ///     EmptyTupleVariant(), /// } /// ``` Tuple(Vec<Option<Id>>), /// A variant with named fields. /// /// ```rust /// enum Demo { ///     StructVariant { x: i32 }, ///     EmptyStructVariant {}, /// } /// ``` Struct { fields: Vec<Id>, fields_stripped: bool }, </ins> } #[derive(Clone, Debug, PartialEq, Eq, Hash, Serialize, Deserialize)]

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


Question: iter.map(|e| t!(e)).collect::<Vec<_>>().into_iter() } <del> fn symlink_file<P: AsRef<Path>, Q: AsRef<Path>>(&self, src: P, link: Q) -> io::Result<()> { #[cfg(unix)] use std::os::unix::fs::symlink as symlink_file; #[cfg(windows)] use std::os::windows::fs::symlink_file; if !self.config.dry_run() { symlink_file(src.as_ref(), link.as_ref()) } else { Ok(()) } } </del> /// Returns if config.ninja is enabled, and checks for ninja existence, /// exiting with a nicer error message if not. fn ninja(&self) -> bool {

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: iter.map(|e| t!(e)).collect::<Vec<_>>().into_iter() } <del> fn symlink_file<P: AsRef<Path>, Q: AsRef<Path>>(&self, src: P, link: Q) -> io::Result<()> { #[cfg(unix)] use std::os::unix::fs::symlink as symlink_file; #[cfg(windows)] use std::os::windows::fs::symlink_file; if !self.config.dry_run() { symlink_file(src.as_ref(), link.as_ref()) } else { Ok(()) } } </del> /// Returns if config.ninja is enabled, and checks for ninja existence, /// exiting with a nicer error message if not. fn ninja(&self) -> bool {

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: let mut_substs = self.tcx.mk_substs_trait(mut_borrowed_found_ty, &[]); // Try to apply the original trait binding obligation by borrowing. <del> let mut try_borrowing = |new_imm_trait_ref: ty::TraitRef<'tcx>, new_mut_trait_ref: ty::TraitRef<'tcx>, expected_trait_ref: ty::TraitRef<'tcx>, </del> <ins> let mut try_borrowing = |new_imm_trait_ref: ty::Binder<'tcx, ty::TraitRef<'tcx>>, new_mut_trait_ref: ty::Binder<'tcx, ty::TraitRef<'tcx>>, expected_trait_ref: ty::Binder<'tcx, ty::TraitRef<'tcx>>, </ins> blacklist: &[DefId]| -> bool { <del> if blacklist.contains(&expected_trait_ref.def_id) { </del> <ins> if blacklist.contains(&expected_trait_ref.def_id()) { </ins> return false; } let imm_result = self.predicate_must_hold_modulo_regions(&Obligation::new( ObligationCause::dummy(), param_env, <del> ty::Binder::dummy(new_imm_trait_ref).without_const().to_predicate(self.tcx), </del> <ins> new_imm_trait_ref.without_const().to_predicate(self.tcx), </ins> )); let mut_result = self.predicate_must_hold_modulo_regions(&Obligation::new( ObligationCause::dummy(), param_env, <del> ty::Binder::dummy(new_mut_trait_ref).without_const().to_predicate(self.tcx), </del> <ins> new_mut_trait_ref.without_const().to_predicate(self.tcx), </ins> )); if imm_result || mut_result {

<!-- 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. --When creating this I found that it did not error if the function was not called and it also seemed to require it to be a function not just an argument of type T or (from what I tested) a different impl Trait although it could be any Fn* trait <!-- 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. --: This appears to only happen on nightly while stable and beta generate useful error reports <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label regression-from-stable-to-nightly
does not ICE but errors correctly while does ICE
glacier ""
searched nightlies: from nightly-2021-09-17 to nightly-2021-09-18 regressed nightly: nightly-2021-09-18 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-apple-darwin Reproduce with: </detailsThat's , so cc
I've got this. claim Interestingly, this is precisely the kind of thing that is hopefully going to help harden against: "hidden" s when calling and such
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium


Question: <ins> include ../tools.mk # only-windows-msvc all: # Test that we don't have the full path to the PDB file in the binary $(RUSTC) main.rs -g --crate-name my_crate_name --crate-type bin -Cforce-frame-pointers $(CGREP) "my_crate_name.pdb" < $(TMPDIR)/my_crate_name.exe $(CGREP) -v "my_crate_name.pdb" < $(TMPDIR)/my_crate_name.exe # Test that backtraces still can find debuginfo by checking that they contain symbol names and # source locations. $(TMPDIR)/my_crate_name.exe &> $(TMPDIR)/backtrace.txt $(CGREP) "my_crate_name::fn_in_backtrace" < $(TMPDIR)/backtrace.txt $(CGREP) "main.rs:15" < $(TMPDIR)/backtrace.txt # Test that explicitly passed `-Clink-arg=/PDBALTPATH:...` is respected $(RUSTC) main.rs -g --crate-name my_crate_name --crate-type bin -Clink-arg=/PDBALTPATH:abcdefg.pdb -Cforce-frame-pointers $(CGREP) "abcdefg.pdb" < $(TMPDIR)/my_crate_name.exe $(CGREP) -v "my_crate_name.pdb" < $(TMPDIR)/my_crate_name.exe </ins>

Spawned off of When passing to rustc I would expect all paths that start with to be replaced with , instead a is still present. Note that this happens even in release mode, because rustc always tells the msvc linker to generate files. This can be "fixed" by passing either , or to rustc, but doing so will break backtraces with ( already prints almost nothing in release mode). As a sidenote, do we really need backtraces in release mode, and by consequence files? They will break anyway if only the is distributed or the directory is deleted. Moreover this shouldn't be needed in the first place since promises to "remap source names in all output (compiler messages and output files)" (from the output of ), "including ). Also note that neither nor the rustc book mention the need to pass one of those arguments to rustc to remap/remove the path to the file, which makes it harder for non-experts to know how to remove them. :
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Perhaps this should be amended to say compiler output but not linker outputs. PDB files are generated at the linking step, which is probably why sees non-determinism for --crate-type=bin (linked) and not for --crate-type=rlib (not linked). Passing to the linker to put a relative path to the PDB files is probably the best choice, as it is the least destructive, and the debugger will look for PDB files next to the executables, so it will be able to find it. Chromium uses this for its Windows linking step as well: ;drc=;l=2358 Doing this with could work if you can figure out which "to-be-remapped" path is going to be the path being written by the linker, and then pass the resulting path to . I must confess I am not sure how linking is being done, but I assume the binary is being linked by a dedicated linker, not by rustc itself? If so that is not too reliable. rustc could provide a switch to remove the absolute path to PDB files, which would just map to . The value proposition there seems low, since you can pass that as the user anyway.


Question: <ins> include ../tools.mk # only-windows-msvc all: # Test that we don't have the full path to the PDB file in the binary $(RUSTC) main.rs -g --crate-name my_crate_name --crate-type bin -Cforce-frame-pointers $(CGREP) "my_crate_name.pdb" < $(TMPDIR)/my_crate_name.exe $(CGREP) -v "my_crate_name.pdb" < $(TMPDIR)/my_crate_name.exe # Test that backtraces still can find debuginfo by checking that they contain symbol names and # source locations. $(TMPDIR)/my_crate_name.exe &> $(TMPDIR)/backtrace.txt $(CGREP) "my_crate_name::fn_in_backtrace" < $(TMPDIR)/backtrace.txt $(CGREP) "main.rs:15" < $(TMPDIR)/backtrace.txt # Test that explicitly passed `-Clink-arg=/PDBALTPATH:...` is respected $(RUSTC) main.rs -g --crate-name my_crate_name --crate-type bin -Clink-arg=/PDBALTPATH:abcdefg.pdb -Cforce-frame-pointers $(CGREP) "abcdefg.pdb" < $(TMPDIR)/my_crate_name.exe $(CGREP) -v "my_crate_name.pdb" < $(TMPDIR)/my_crate_name.exe </ins>

Determinism is important for both release and debug builds, so I don't believe there is anything release-mode specific here or that a solution should be chosen that doesn't deal with debug mode? Could you say what is breaking about backtraces with ?
Without that flag I get something like: <details<summaryBacktrace</summary<p</p</detailsBut with it it just prints: <details<summaryBacktrace</summary<p</p</detailsThis seems to happen because the pdb file is searched relative to the current working directory, and when running that's often not the directory with the executable and pdb files. appears to work, but only as long as you execute it from the crate root, which is definitely not ideal.
Can move to the crate root before executing the target executable? Then cargo could pass (or debug) while other build systems pass or whatever works for them?
Wouldn't that break any workflow that relies on the current working directory always being where is executed from?
I think this meant the crate root instead of the cwd? I had no idea that would be a common thing, but you're right. It would change any use of . I would expect to be more commonly used for relative paths, as it doesn't depend on running from a cargo source tree, but maybe I am wrong. Regardless, I can see why changing behaviour isn't ideal. The MSVC linker doesn't present a whole lot of options though, as the path relative to where you plan to run the binary has to be encoded into the pdb files if you want a deterministic output. It seems the options are: -determinisic output, backtraces always work, debuggers work: PDB absolute paths. This is the default behaviour. output, , and backtraces work from the exe's directory: output, backtraces work from the crate root, but debuggers won't work: Have I missed an option? There's no option that I can see with both deterministic output and backtraces working from arbitrary working directories. AIUI, this github issue is about --remap-path-prefix not adding a flag, essentially. It would be nice if deterministic builds were easier to get!


Question: <ins> include ../tools.mk # only-windows-msvc all: # Test that we don't have the full path to the PDB file in the binary $(RUSTC) main.rs -g --crate-name my_crate_name --crate-type bin -Cforce-frame-pointers $(CGREP) "my_crate_name.pdb" < $(TMPDIR)/my_crate_name.exe $(CGREP) -v "my_crate_name.pdb" < $(TMPDIR)/my_crate_name.exe # Test that backtraces still can find debuginfo by checking that they contain symbol names and # source locations. $(TMPDIR)/my_crate_name.exe &> $(TMPDIR)/backtrace.txt $(CGREP) "my_crate_name::fn_in_backtrace" < $(TMPDIR)/backtrace.txt $(CGREP) "main.rs:15" < $(TMPDIR)/backtrace.txt # Test that explicitly passed `-Clink-arg=/PDBALTPATH:...` is respected $(RUSTC) main.rs -g --crate-name my_crate_name --crate-type bin -Clink-arg=/PDBALTPATH:abcdefg.pdb -Cforce-frame-pointers $(CGREP) "abcdefg.pdb" < $(TMPDIR)/my_crate_name.exe $(CGREP) -v "my_crate_name.pdb" < $(TMPDIR)/my_crate_name.exe </ins>

But based on all of the above, it seems to me that is better solved through Cargo than through rustc's , perhaps behind a Cargo flag in As a convenience, maybe could provide an option to move to the exe's directory to run it, instead of users doing , which would let option 2 be more ergonomic while also supporting debuggers.
Would it be possible to have create a symbolic link to the file or the directory when it's not already present in the current working directory? This would partially solve the ergonomic problems of approaches 2 and 3
It'd probably be easier to have set , which effect the default search path for the used for
Any update on this? :)
I've just opened which solves the problem by making always pass to the linker. This seems like the best solution to me. The PR is currently blocked on backtrace-rs not handling this properly, but I've opened , which will hopefully fix that.


Question: //! Types/fns concerning URLs (see RFC 3986) #![crate_name = "url"] <del> #![experimental] </del> <ins> #![deprecated="This is being removed. Use rust-url instead. http://servo.github.io/rust-url/"] </ins> #![crate_type = "rlib"] #![crate_type = "dylib"] #![license = "MIT/ASL2"]

The common fix for , , and is to rewrite the module based on the spec at and the tests at (Note: the tests assume the API, designed for JavaScript in web browsers. We do not necessarily want the same API for Rust outside of testing code.)
I'm interested in this
I have a work-in-progress implementation. I’ll publish it later today so you can pick it up if you want.
Here it is: Note that I’m targeting Rust , the version used in Servo. (Though there is an upgrade being worked on.) IDNA and the actual URL parser are not there yet, but everything else (host/domain/ipv6, , percent encoding, test harness) is there. This should start being useful as soon as the URL parser is . The host parser returns an error on non-ASCII domains. This is good enough for now, IDNA support can be later. also made an in-progress implementation: It has some known bugs ( is incorrect with non-ASCII input, at least) but the parser code can probably be reused.
Also, be aware that the URL spec itself is still moving and has a number of open bugs:
I Punycode encoding and decoding (with tests) to but not Nameprep, which is the other big part of IDNA.
is now (IMHO) ready to replace . It is not "done" yet (some bugs remain, including in the spec!), but at this point it has more than feature-parity and is probably correct in more corner cases. Given the current tendency to move things out of , rust-url probably shouldn’t move in. It could be distributed with rustc like the rest of the modules moving out of extra, but this has the downside of tying rust-url upgrades to compiler upgrades, and only weak advantages IMO. So, whenever the Rust team decides it’s appropriate, I suggest removing and recommending rust-url as a replacement.
I would generally be in favor of a in the distribution for now. This would certainly not be a package in long-term, but for now putting everything in this repo is the ad-hoc solution we have until we get a real package manager.
In that case, I’d like to iterate a bit on rust-url (port rust-http and Servo to it, …) before it moves into the distribution. Also, rust-url depends on rust-encoding, which I guess would have to move as well.


Question: //! Types/fns concerning URLs (see RFC 3986) #![crate_name = "url"] <del> #![experimental] </del> <ins> #![deprecated="This is being removed. Use rust-url instead. http://servo.github.io/rust-url/"] </ins> #![crate_type = "rlib"] #![crate_type = "dylib"] #![license = "MIT/ASL2"]

I’d say rust-url is now in "beta" state. I have branches of rust-http and Servo using it: It builds with Cargo. It depends on rust-encoding (which also builds with Cargo), but for something non-essential that could be deactivated if avoiding the additional dependency helps. I’d like people to start using it and give feedback. I think the best way to do that is to get rid of the old liburl. I’ll go through the RFC process, but before that, what would you prefer? Replace liburl with snapshots[] of rust-url. You were in favor of this in February, but Cargo has reached alpha since then. Just remove liburl, and tell people to use rust-url through Cargo. Something else? [] In any case, I’d like to keep a separate rust-url repository that I can update in Servo independently of language upgrades.
+1 on removing liburl. Thanks
Perhaps we can deprecate all of liburl for one release cycle.
This seems like a great place to let cargo shine.
Deprecating sounds reasonable. That means emitting warnings by default, right?
awesome work! I agree with and that I think this is where cargo shines, and we can probably just remove liburl entirely without re-adding rust-url. We can also try to grow more official support for it in terms of documentation and automation (not present currently). We can mark liburl as with a message to use instead which should ferry everyone along quickly.


Question: <ins> error[E0599]: no method named `get_a` found for type `&Self` in the current scope --> $DIR/constrain-trait.rs:15:31 | LL |         println!("{:?}", self.get_a()); |                               ^^^^^ method not found in `&Self` | = help: items from traits can only be used if the type parameter is bounded by the trait help: the following trait defines an item `get_a`, perhaps you need to add another supertrait for it: | LL | trait UseString: std::fmt::Debug + GetString { |                                  ^^^^^^^^^^^ error[E0599]: no method named `get_a` found for type `&Self` in the current scope --> $DIR/constrain-trait.rs:21:31 | LL |         println!("{:?}", self.get_a()); |                               ^^^^^ method not found in `&Self` | = help: items from traits can only be used if the type parameter is bounded by the trait help: the following trait defines an item `get_a`, perhaps you need to add a supertrait for it: | LL | trait UseString2: GetString { |                 ^^^^^^^^^^^ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0599`. </ins>

The following example code yields an error: It's unclear from this error message how to proceed - I'm not sure of the syntax, location, or where I should be putting the "GetString" trait bound. It should be shown with a better example or link when this error is presented, as the current message is not sufficient for a resolution to be arrived at.
cc
Fixing in . To fix your code write:
Thanks!


Question: //~^ ERROR doesn't implement } <del> pub fn main() { } </del> <ins> trait Foo<T>: Sized { 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 + Sized { const SIZE: usize = core::mem::size_of::<Self>(); //~^ ERROR the size for values of type `Self` cannot be known at compilation time } trait Baz: Sized 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>: Sized 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 + Sized { 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?)