Question: ulimit -c unlimited fi <ins> # There was a bad interaction between "old" 32-bit binaries on current 64-bit # kernels with selinux enabled, where ASLR mmap would sometimes choose a low # address and then block it for being below `vm.mmap_min_addr` -> `EACCES`. # This is probably a kernel bug, but setting `ulimit -Hs` works around it. # See also `dist-i686-linux` where this setting is enabled. if [ "$SET_HARD_RLIMIT_STACK" = "1" ]; then rlimit_stack=$(ulimit -Ss) if [ "$rlimit_stack" != "" ]; then ulimit -Hs "$rlimit_stack" fi fi </ins> ci_dir=`cd $(dirname $0) && pwd` source "$ci_dir/shared.sh"

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: ulimit -c unlimited fi <ins> # There was a bad interaction between "old" 32-bit binaries on current 64-bit # kernels with selinux enabled, where ASLR mmap would sometimes choose a low # address and then block it for being below `vm.mmap_min_addr` -> `EACCES`. # This is probably a kernel bug, but setting `ulimit -Hs` works around it. # See also `dist-i686-linux` where this setting is enabled. if [ "$SET_HARD_RLIMIT_STACK" = "1" ]; then rlimit_stack=$(ulimit -Ss) if [ "$rlimit_stack" != "" ]; then ulimit -Hs "$rlimit_stack" fi fi </ins> ci_dir=`cd $(dirname $0) && pwd` source "$ci_dir/shared.sh"

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: ulimit -c unlimited fi <ins> # There was a bad interaction between "old" 32-bit binaries on current 64-bit # kernels with selinux enabled, where ASLR mmap would sometimes choose a low # address and then block it for being below `vm.mmap_min_addr` -> `EACCES`. # This is probably a kernel bug, but setting `ulimit -Hs` works around it. # See also `dist-i686-linux` where this setting is enabled. if [ "$SET_HARD_RLIMIT_STACK" = "1" ]; then rlimit_stack=$(ulimit -Ss) if [ "$rlimit_stack" != "" ]; then ulimit -Hs "$rlimit_stack" fi fi </ins> ci_dir=`cd $(dirname $0) && pwd` source "$ci_dir/shared.sh"

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: ulimit -c unlimited fi <ins> # There was a bad interaction between "old" 32-bit binaries on current 64-bit # kernels with selinux enabled, where ASLR mmap would sometimes choose a low # address and then block it for being below `vm.mmap_min_addr` -> `EACCES`. # This is probably a kernel bug, but setting `ulimit -Hs` works around it. # See also `dist-i686-linux` where this setting is enabled. if [ "$SET_HARD_RLIMIT_STACK" = "1" ]; then rlimit_stack=$(ulimit -Ss) if [ "$rlimit_stack" != "" ]; then ulimit -Hs "$rlimit_stack" fi fi </ins> ci_dir=`cd $(dirname $0) && pwd` source "$ci_dir/shared.sh"

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: checksum = "d29ab0c6d3fc0ee92fe66e2d99f700eab17a8d57d1c1d3b748380fb20baa78cd" [[package]] <ins> name = "semver" version = "1.0.17" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "bebd363326d05ec3e2f532ab7660680f3b02130d780c299bca73469d521bc0ed" [[package]] </ins> name = "serde" version = "1.0.137" source = "registry+https://github.com/rust-lang/crates.io-index"

I'm trying to build Rust on a Tier 3 platform (; actually it's that's listed in Tier 3, but I don't think that affects the problem). Since there are no snapshots for this platform, I installed rustc from the distro's package manager (apk) and created a file to force using the pre-installed rustc rather than downloading snapshots: And the output of : I ran ; when it got as far as building the core library, I got a series of errors that were very hard to make sense of until I realized that it's because core library code depends on unstable features and I was using a stable rustc to compile it: There were many more errors, but I think they all relate to unstable features. It took me ages to figure out that (for example) the first error is due to the feature being disabled in stable. I understand that the stable compiler won't allow using unstable features even with , but is it possible for the parser to recognize this code even so and reject it with something like "feature is not enabled" instead of the much more generic "expected identifier" error?
Huh, usually Rust gets around this by setting , and usually when we bootstrap it's with a beta compiler, which does need that set by , and that would allow all the features. I wonder if wasn't set?
It's set, but the command that's actually failing (it took some effort to figure out which executable was actually failing) is: And what's installed for me in is a stable compiler. I realized after the fact that I can't use it to bootstrap, but with a different error message I might have noticed that sooner.
Forwards compatibility in diagnostics seems extremely hard. I think a much simpler and more helpful fix is to check the output of in bootstrap and give a hard error if it's not either the current version or N-1.
Note that the problem here is that you were trying to use 1.68 to build 1.70; it's unrelated to stable vs beta, the problem is that it was two versions behind instead of only one.
Mentoring instructions: in , if is set, run that process with . Compare that output to the contents of using the crate; if the minor versions aren't either the same or 1 apart, give a hard error. Note that this should also disallow e.g.


Question: checksum = "d29ab0c6d3fc0ee92fe66e2d99f700eab17a8d57d1c1d3b748380fb20baa78cd" [[package]] <ins> name = "semver" version = "1.0.17" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "bebd363326d05ec3e2f532ab7660680f3b02130d780c299bca73469d521bc0ed" [[package]] </ins> name = "serde" version = "1.0.137" source = "registry+https://github.com/rust-lang/crates.io-index"

building 1.68 with 1.69; we use deny-warnings in most cases and have no guarantees that unstable features will be the same between releases. Only building 1.68 with 1.67 or 1.68 should be allowed.
btw I've noticed you running into a few different bootstrap bugs the past few days — reading through https://rustc-dev- may or may not make it easier to diagnose these issues without having to spend ages interpreting the diagnostics. I'm also happy to chat about "how should this work" sorts of things .
Yes, I've read that. Thanks!
The error message could be improved though. Maybe one could make the to put into libcore/bootstrap's
I don't think rust-version is a good way to solve this, no - that won't give a warning or error if you use a future version to compile an older version. Also it won't be able to catch local-rebuild issues where the nightly version of the bootstrap compiler is too old. See my suggestion in
Hmm, I'm afraid I might have said something unclear. I'm not asking for forward compatibility in diagnostics. The feature was in version 1.68.0, according to , and I was using rustc version 1.68.2. So it should "know" about that feature, but my understanding is that when I was invoking rustc it was with flags that prevent unstable features from being used.
hmm, in that case something strange is going on because playground gives a much more reasonable error than the one you saw:
what commit of rustc were you trying to build when you got this error? I'm going to see if I can replicate it locally.
I was trying to build .
Ah ok, it was related to the context of the closure: If you look at the same gist with beta, the error message is much better: So I think this particular diagnostic issue has already been fixed. I still want to keep this issue open to track checking the version of the bootstrap compiler, though.


Question: <ins> error[E0026]: variant `A::A` does not have a field named `fob` --> $DIR/issue-52717.rs:19:12 | LL |     A::A { fob } => { println!("{}", fob); } |            ^^^ |            | |            variant `A::A` does not have this field |            help: did you mean: `foo` error: aborting due to previous error For more information about this error, try `rustc --explain E0026`. </ins>

With a single typo in a match arm, we generate three separate errors: We should collect all these errors into a single diagnostic:
could you share sample code to exactly reproduce above diagnostic?
I will raise another PR to address the case where we are unnecessarily throwing .


Question: } }; <del> let yielded = opt_expr.as_ref().map(|x| self.lower_expr(x)).unwrap_or_else(|| self.expr_unit(span)); </del> if is_async_gen { // `yield $expr` is transformed into `task_context = yield async_gen_ready($expr)`. // This ensures that we store our resumed `ResumeContext` correctly, and also that

<!-- ICE: Rustc '--edition=2021 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'no entry found for key'', 'thread 'rustc' panicked at 'no entry found for key'' 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: [hirownerparent] getting HIR parent of [checkunused_traits] checking unused trait imports in crate [analysis] running analysis passes on this crate --
cc
Minimal:


Question: ty::Dynamic(ref data, ..) if data.principal_def_id().is_some() => { self.check_def_id(item, data.principal_def_id().unwrap()); } <ins> ty::Dynamic(..) => { struct_span_err!( self.tcx.sess, ty.span, E0785, "cannot define inherent `impl` for a dyn auto trait" ) .span_label(ty.span, "impl requires at least one non-auto trait") .note("define and implement a new trait or type instead") .emit(); } </ins> ty::Bool => { self.check_primitive_impl( item.def_id,

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


Question: Some((destination, success)) }, from_hir_call, <del> fn_span </del> <ins> fn_span, </ins> }, ); success.unit()

<!-- 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. --The code fails to pass <!-- 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. --Repo is at <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Oh that is interesting: is that expected? The other way around would make sense (assigning a into anything, really), but with a on the left, that seems odd? Or maybe the message just gets the sides wrong.
Yeah, that MIR looks really broken: Cc
This is probably due to this line: , and shouldn't have this, since they have type , not .
This is a super old issue going back all the way to the initial MIR implementation and I’m somewhat confident is documented somewhere, though I cannot find an issue for this. IIRC these invalid assignments only happen in unreachable basic blocks, so however wrong it looks in isolation, it is dead code and I think it never was a priority to fix either generation or the MIR validation we had back then for exactly that reason. Looks like is a new take on validation? Perhaps the easy fix would be to not validate unreachable blocks.


Question: /// # Example /// /// ```rust <ins> /// # #![allow(deprecated)] </ins> /// use url::encode; /// /// let url = encode("https://example.com/Rust (programming language)");

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: /// # Example /// /// ```rust <ins> /// # #![allow(deprecated)] </ins> /// use url::encode; /// /// let url = encode("https://example.com/Rust (programming language)");

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> fn int_ty_bits(int_ty: ast::IntTy) -> u64 { match int_ty { ast::TyI =>    int::BITS as u64, ast::TyI8 =>   i8::BITS  as u64, ast::TyI16 =>  i16::BITS as u64, ast::TyI32 =>  i32::BITS as u64, ast::TyI64 =>  i64::BITS as u64 } } fn uint_ty_bits(uint_ty: ast::UintTy) -> u64 { match uint_ty { ast::TyU =>    uint::BITS as u64, ast::TyU8 =>   u8::BITS  as u64, ast::TyU16 =>  u16::BITS as u64, ast::TyU32 =>  u32::BITS as u64, ast::TyU64 =>  u64::BITS as u64 } } </ins> fn check_limits(tcx: &ty::ctxt, binop: ast::BinOp, l: &ast::Expr, r: &ast::Expr) -> bool { let (lit, expr, swap) = match (&l.node, &r.node) {

Currently overlong bit shifts are undefined behavior because that's how llvm rolls--. But even when they aren't, we should warn on something like where happens to be , since it's a useless operation that couldn't possibly return anything interesting. There's a and I imagine it'd be a common gotcha since other languages tend to read unadorned integral literals as 32bit s and then promote the in before doing the actual shift.
I think this can be closed, resolved in
Hooray!


Question: /// # Example /// /// ```rust <ins> /// # #![allow(deprecated)] </ins> /// let query = vec![("title".to_string(), "The Village".to_string()), ///                  ("north".to_string(), "52.91".to_string()), ///                  ("west".to_string(), "4.10".to_string())];


Question: /// # Example /// /// ```rust <ins> /// # #![allow(deprecated)] </ins> /// let query = vec![("title".to_string(), "The Village".to_string()), ///                  ("north".to_string(), "52.91".to_string()), ///                  ("west".to_string(), "4.10".to_string())];


Question: synth_provided, } } else { <del> let num_missing_args = expected_max - provided; </del> <ins> // Check if associated type bounds are incorrectly written in impl block header like: // ``` // trait Foo<T> {} // impl Foo<T: Default> for u8 {} // ``` let parent_is_impl_block = cx .tcx() .hir() .parent_owner_iter(seg.hir_id) .next() .is_some_and(|(_, owner_node)| owner_node.is_impl_block()); if parent_is_impl_block { let constraint_names: Vec<_> = gen_args.constraints.iter().map(|b| b.ident.name).collect(); let param_names: Vec<_> = gen_params .own_params .iter() .filter(|param| !has_self || param.index != 0) // Assumes `Self` will always be the first parameter .map(|param| param.name) .collect(); if constraint_names == param_names { // We set this to true and delay emitting `WrongNumberOfGenericArgs` // to provide a succinct error for cases like issue #113073 all_params_are_binded = true; }; } </ins> <del> let constraint_names: Vec<_> = gen_args.constraints.iter().map(|b| b.ident.name).collect(); let param_names: Vec<_> = gen_params .own_params .iter() .filter(|param| !has_self || param.index != 0) // Assumes `Self` will always be the first parameter .map(|param| param.name) .collect(); if constraint_names == param_names { // We set this to true and delay emitting `WrongNumberOfGenericArgs` // to provide a succinct error for cases like issue #113073 all_params_are_binded = true; }; </del> <ins> let num_missing_args = expected_max - provided; </ins> GenericArgsInfo::MissingTypesOrConsts { num_missing_args,

<!-- ICE: Rustc '--crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error[E0107]: trait takes 1 generic argument but 0 generic arguments were supplied', 'error: internal compiler error[E0107]: trait takes 1 generic argument but 0 generic arguments were supplied' 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: --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc :thinking:
claim


Question: //@aux-build:proc_macro_attr.rs:proc-macro <ins> // Flaky test, see https://github.com/rust-lang/rust/issues/113585. //@ignore-32bit //@ignore-64bit </ins> #![warn(clippy::needless_arbitrary_self_type)]

In , clippy CI , and I don't think that can be caused by my PR: <details</detailsCc
Seems same with my PR Did you try to rebase master for you branch? I resolved it in this way.
your problem was different. the problem Ralf is running into is
The error message and failed test case are both same with my failed CI in my new PR
gotcha - in that case the rebase probably didn't do anything except rerun ci - this only fails some of the time. https://rust- has a plausible explanation
See the discussion at https://rust- I believe this is an issue with ui_test.
This is causing lots of problems in CI, so I'm marking it as critical.
I'll leave it up to you on tracking what needs to be done to revert . It looks like you've been working on it in ui_test, but I'm not involved in clippy development, so I probably shouldn't be the one tracking/fixing things. However, if you have questions on the cargo side, let me know.
Thanks! After the next clippy sync (tomorrow) this should be fixed. On the ui_test side, the failure is now protected against being spurious and 100% reproducible. I'll ship that to miri soon to prevent the same thing from happening there.


Question: <ins> error[E0308]: mismatched types --> $DIR/issue-117669.rs:2:20 | LL |     let abs: i32 = 3i32.checked_abs(); |              ---   ^^^^^^^^^^^^^^^^^^ expected `i32`, found `Option<i32>` |              | |              expected due to this | = note: expected type `i32` found enum `Option<i32>` help: consider using `Option::expect` to unwrap the `Option<i32>` value, panicking if the value is an `Option::None` | LL |     let abs: i32 = 3i32.checked_abs().expect("REASON"); |                                      +++++++++++++++++ error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>

in Dec '22 introduced a cool new feature to suggest removing the last method call if it would alleviate a type mismatch error. This is particularly using for people wrestling with issues. in Oct '23 introduced another useful feature to suggest to users that they might consider ing an or type in order to solve a type mismatch. Also very cool, and conveniently by the same author Unfortunately, in cases where a method is called, the previous check takes precedence, and the compiler suggests removing that trailing method to get the code to compile. This isn't generally that useful as the expect suggestion, and I can't think of an example where it's a better one. If you can think of one though, please put it below for me to test! surfaced this with but it's more easily demonstrated with ints. I can see two ways to fix this: the trailing method check first, but ignore and types the checks so the option type is checked first. Note that the method check has to be high in the chain as the motive is to quickly suggest removing a call, before adding a whole load of new ones. This means the check has to be one of the first I am going to work on solving it via method 2, as it feels cleaner that the method check doesn't have to know about the and check. If anyone has strong feelings on this, please let me know! Playground No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I think this suggestion for removing the method call is way too eager, as it can easily be wrong and when it's wrong it's quite confusing. Maybe it should instead say that the type was correct before the method call (which is never wrong), nudging the user towards removing the call if they know that it's not important. Instead of strongly saying that it should be removed. Alternatively, it could be special cased to known "unimportant" functions like or .
I think this brings up two issues: should the method call suggestor should do, and say. There was some discussion of this in where it was decided to keep it generic rather than special-casing, but I don't think it's done badly at the moment. Perhaps the wording could be altered?


Question: <ins> error[E0308]: mismatched types --> $DIR/issue-117669.rs:2:20 | LL |     let abs: i32 = 3i32.checked_abs(); |              ---   ^^^^^^^^^^^^^^^^^^ expected `i32`, found `Option<i32>` |              | |              expected due to this | = note: expected type `i32` found enum `Option<i32>` help: consider using `Option::expect` to unwrap the `Option<i32>` value, panicking if the value is an `Option::None` | LL |     let abs: i32 = 3i32.checked_abs().expect("REASON"); |                                      +++++++++++++++++ error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>

it should run I'll focus on the latter here, but if you have examples where removing the method call doesn't make sense we can aggregate them and see if there is a holistic solution?


Question: /// # Examples /// /// ```no_run <del> /// # #![feature(bufreader_buffer)] </del> /// use std::io::{BufReader, BufRead}; /// use std::fs::File; ///

Update: this is the tracking issue for: is both unstable and deprecated, it should be removed. There is currently no way to tell whether there is any data buffered inside a BufReader. This is unfortunate because it means that an application has no way to know whether calls to read() and fillbuffer() will return instantly or trigger a potentially expensive call to the underlying Reader. I propose adding an is_empty() method to BufReader to fill this gap.
now that has been merged, I'm guessing this should get the label?
What's left for this to stabilize? I'm parsing bytes from a to MsgPack using . The function will stop parsing once a valid MsgPack value has been found. But in my application the parsing should fail if the buffer hasn't been consumed completely. Checking would probably be the cleanest way to do so.
the method proposed in may also be useful for that purpose, though that may take even longer to land.
This is the tracking issue for: Looks good to me to stabilize. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [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.
This seems fine to stabilize, but it seems like it'd be more useful to know how many bytes are buffered, rather than just that there are some number of bytes.
Why not both? Slices have even though it’s somewhat redundant with .
For sure. Would it be reasonable to try to squeeze that into this stabilization?
Sounds ok to me, though we should probably (re)start FCP after the implementation is merged.
Naming wise, I don't think fits since that seems to me like it'd refer to the length of the entire reader rather than just the current buffered data (similarly is a bit confusing). How about and ?
Agreed. Sounds good to me.
Alternatively, we could add to just return the buffer, which is also a thing people want separately from this issue. At that point seems not much worse than so we could have one method instead of three.


Question: /// # Examples /// /// ```no_run <del> /// # #![feature(bufreader_buffer)] </del> /// use std::io::{BufReader, BufRead}; /// use std::fs::File; ///

adds and deprecates .
:bell: This is now entering its final comment period, as per the . :bell:
With alternative (and IMO better) proposal just introduced, should this still be going into its final comment period?
fcp cancel Let’s start again after has landed.
proposal cancelled.
We should likely also add a method to for consistency?
That can't be done backwards compatibly.
why not? It's just a , right? Just like .
Oh derp I somehow read that as .
Haha, no worries. Is there even a trait?
No there isn't _Off of the topic of me needing more caffeine, it definitely seems reasonable to add to , and fold it into the same feature gate as 's.
It has been a while since landed. Is this ready to stabilize?
is implemented, but discussed above is not. (I’ve updated the issue’s description with the current status.)
Wait, we aren't proposing to stabilize the (already deprecated) is_empty method are we?
No, sorry I didn’t clarify. An API marked both unstable and deprecated is to be removed (after something like a couple release cycles of deprecation period, which we’re at in this case).
I'm excited to see that this is so close to landing. Is this still waiting on an implementation of ? Would it be possible to track that feature separately to unblock this one?
Bump. Is there anything else blocking stabilization?
Is there any particular reason not to add to ? It seems like a useful enough general-purpose API ("get me however many bytes you can easily give me"), and I found myself looking for such a method while working on parser tooling. Individual implementations could make stricter guarantees about the lower bounds, of which "at least the unconsumed fraction of the last " would be a common one.
Yeah, this has been a while. is this ready for a vote to stabilize?
This issue seems to have been stuck in a strange limbo state for quite a while now. Pinging more people the rfcbot mentioned...
Sorry we dropped the ball here. This is now one method on the and structs. 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] [x] [ ] No concerns currently listed.


Question: /// # Examples /// /// ```no_run <del> /// # #![feature(bufreader_buffer)] </del> /// use std::io::{BufReader, BufRead}; /// use std::fs::File; ///

Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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.
There is nothing called in std. Did you mean the trait? A downside is that to add it now we would have to make it a default method, which would (at first) have an inconsistent behavior with for existing impls. We can update impls in std at the same time, but that leaves impls in other crates.
:bell: This is now entering its final comment period, as per the . :bell:
Sorry, yes, I meant . For my use cases, not having a lower bound is fine. Anything that does can use a marker subtrait that encompasses that guarantee. I think the only stipulation should be that it not provide more than , but less is fine. For example, an implementation might copy existing data around on to make a larger contiguous segment, but can't/shouldn't do so in (I think it should be a cheap conversion, wouldn't have been an unreasonable name).
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.


Question: traits::RepeatVec => { tcx.sess.span_note( obligation.cause.span, <del> format!( "the `Copy` trait is required because the  repeated element will be copied").as_slice()); </del> <ins> "the `Copy` trait is required because the  repeated element will be copied"); </ins> } traits::VariableType(_) => { tcx.sess.span_note( obligation.cause.span, "all local variables must have a statically known size"); } <ins> traits::ReturnType => { tcx.sess.span_note( obligation.cause.span, "the return type of a function must have a  statically known size"); } </ins> traits::AssignmentLhsSized => { tcx.sess.span_note( obligation.cause.span,

The following code causes an ICE: Removing the parameter or changing it to be a value instead of a reference stops the crash with an error saying I need to specify a lifetime, which makes me think this is a problem related to inferred lifetimes.
It isn't, you just have to specify a lifetime: ICE-s as well. Returning an unsized type should be a typeck error.
happens to work because it implies , i.e. would also work.


Question: let f1: f32 = FromStrRadix::from_str_radix("1p-123", 16).unwrap(); let f2: f32 = FromStrRadix::from_str_radix("1p-111", 16).unwrap(); let f3: f32 = FromStrRadix::from_str_radix("1.Cp-12", 16).unwrap(); <del> assert_eq!(Float::ldexp(1f32, -123), f1); assert_eq!(Float::ldexp(1f32, -111), f2); </del> <ins> assert_eq!(1f32.ldexp(-123), f1); assert_eq!(1f32.ldexp(-111), f2); </ins> assert_eq!(Float::ldexp(1.75f32, -12), f3); assert_eq!(Float::ldexp(0f32, -123), 0f32);

has an unusual format: it takes as it's first parameter where everything else in the trait takes . It should take as it's first parameter for consistency with everything else. It is located in
+1. There are a few different things to consider here, though: does not operate on any FP number per se like most other operations do, but rather constructs a new FP number from two arguments one of which happens to be FP number. This function’s signature is consistent with most other methods that construct some kind of FP number (e.g. ). We might want to consider whether methods such as shouldn’t just go ahead and take instead. can’t currently be chained, but I see literally 0 cases where anybody would chain this function. cc
Okay, but from a consistency standpoint, it's like 1/80 for vs . It it keeps the same format, it and it's similar functions would probably be better to go at the end or beginning of the function list where they won't be so unusual.
Nominating for 1.0-beta P-backcompat-libs
One should be able to call this thing as a method, one way or another. We need to make sure that is resolved.
0 beta, P-backcompat-libs
I started to fix this.


Question: <ins> error: an inner attribute is not permitted in this context --> $DIR/issue-89971-outer-attr-following-inner-attr-ice.rs:11:1 | LL | #![deny(missing_docs)] | ^^^^^^^^^^^^^^^^^^^^^^ ... LL | struct Mew(); | ------------- the inner attribute doesn't annotate this struct | = note: inner attributes, like `#![no_std]`, annotate the item enclosing them, and are usually found at the beginning of source files help: to annotate the struct, change the attribute from inner to outer style | LL - #![deny(missing_docs)] LL + #[deny(missing_docs)] | error: aborting due to previous error </ins>

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --I encountered an ICE while incorrectly inserting a outer attribute above deriving or inside of a proc-macro. This did not happen with any other derive I tried. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
can you please also provide the configuration to reproduce an for your issue? thanks
Sure, sorry for forgetting, here is the mcve: But incase you dont want to see the entire project the for the macro was just: And the of the project to use the macro (and trigger the ICE) was:
Cool, thank you! Here's the result of a bisection: seems to point to PR cc searched nightlies: from nightly-2021-01-01 to nightly-2021-08-11 regressed nightly: nightly-2021-04-12 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium


Question: <ins> // run-rustfix // Regression test for changes introduced while fixing #54505 // This test uses non-literals for Ranges // (expecting no parens with borrow suggestion) use std::ops::RangeBounds; // take a reference to any built-in range fn take_range(_r: &impl RangeBounds<i8>) {} fn main() { take_range(&std::ops::Range { start: 0, end: 1 }); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &std::ops::Range { start: 0, end: 1 } take_range(&::std::ops::Range { start: 0, end: 1 }); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &::std::ops::Range { start: 0, end: 1 } take_range(&std::ops::RangeFrom { start: 1 }); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &std::ops::RangeFrom { start: 1 } take_range(&::std::ops::RangeFrom { start: 1 }); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &::std::ops::RangeFrom { start: 1 } take_range(&std::ops::RangeFull {}); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &std::ops::RangeFull {} take_range(&::std::ops::RangeFull {}); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &::std::ops::RangeFull {} take_range(&std::ops::RangeInclusive::new(0, 1)); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &std::ops::RangeInclusive::new(0, 1) take_range(&::std::ops::RangeInclusive::new(0, 1)); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &::std::ops::RangeInclusive::new(0, 1) take_range(&std::ops::RangeTo { end: 5 }); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &std::ops::RangeTo { end: 5 } take_range(&::std::ops::RangeTo { end: 5 }); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &::std::ops::RangeTo { end: 5 } take_range(&std::ops::RangeToInclusive { end: 5 }); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &std::ops::RangeToInclusive { end: 5 } take_range(&::std::ops::RangeToInclusive { end: 5 }); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &::std::ops::RangeToInclusive { end: 5 } } </ins>

is an incorrect suggestion because has higher precedence than . It should suggest .
If someone wants to tackle this issue, it should be straightforward to fix. In: there should be another branch for , where the path of the call is . This code is a good reference: This issue affects the other range syntaxes too, so those should also be fixed (although these are not — look at for clues).
Hi I'd like to tackle this and take the plunge into the Rust compiler code :)
great! Let me know if you hit any snags or need any more tips. You'll want to add tests for these (in ). The is a good place for general information about the compiler. When you're done, include in the pull request and I'll review it!
you've anticipated most of my newbie questions already :) Thanks for that info, very useful! I'm now in the process of stressing my PC with lots of compiling to actually get started. Skimming the test code I'm really impressed by how easy it is to add "UI" tests for these sorts of things (compile this, expect this error on this line). Snazzy! That's all great, but do you anticipate I should also add "deeper" tests? I guess I'm trying to understand if the scope of this is just pure UI or do I need to touch some syntax parsing/immediate representations, since you mentioned code in . Because the compiler is emitting a syntax suggestion, we might want to assert that the suggestion is correct syntax in the first place. I don't know if that's how deep the rabbit hole goes and if there's a facility to help out, but my hunch is that since we have all of the compiler at hand, why not use it to validate the suggestion syntax? EDIT: OK, reading up on adding new tests to the compiler I encountered mention of , and it seems to be sort-of what I was after.
The issue here is just a diagnostic issue, so checking that we're getting the updated hint is enough. The code in is just helpful to see what ranges like and are desugared into, so you can catch them in — you shouldn't need to modify anything (apart from the test) outside of . It would technically be possible to do something like this, but it would probably be more trouble than it's worth.


Question: <ins> // run-rustfix // Regression test for changes introduced while fixing #54505 // This test uses non-literals for Ranges // (expecting no parens with borrow suggestion) use std::ops::RangeBounds; // take a reference to any built-in range fn take_range(_r: &impl RangeBounds<i8>) {} fn main() { take_range(&std::ops::Range { start: 0, end: 1 }); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &std::ops::Range { start: 0, end: 1 } take_range(&::std::ops::Range { start: 0, end: 1 }); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &::std::ops::Range { start: 0, end: 1 } take_range(&std::ops::RangeFrom { start: 1 }); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &std::ops::RangeFrom { start: 1 } take_range(&::std::ops::RangeFrom { start: 1 }); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &::std::ops::RangeFrom { start: 1 } take_range(&std::ops::RangeFull {}); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &std::ops::RangeFull {} take_range(&::std::ops::RangeFull {}); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &::std::ops::RangeFull {} take_range(&std::ops::RangeInclusive::new(0, 1)); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &std::ops::RangeInclusive::new(0, 1) take_range(&::std::ops::RangeInclusive::new(0, 1)); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &::std::ops::RangeInclusive::new(0, 1) take_range(&std::ops::RangeTo { end: 5 }); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &std::ops::RangeTo { end: 5 } take_range(&::std::ops::RangeTo { end: 5 }); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &::std::ops::RangeTo { end: 5 } take_range(&std::ops::RangeToInclusive { end: 5 }); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &std::ops::RangeToInclusive { end: 5 } take_range(&::std::ops::RangeToInclusive { end: 5 }); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &::std::ops::RangeToInclusive { end: 5 } } </ins>

(I'm not aware of a facility to do this easily already.) I think manually going through the possible s and checking that the parenthesisation behaviour is correct in each case would be a lot simpler: if we handle the different s in an exhaustive now (it's likely that if the ranges were handled incorrectly, there could be some others that are also missed at the moment), then this should be a one-time fix and the tests should prevent it regressing. A simple UI test should be sufficient here: will generate the output files, which will include all the relevant notes.
There was a similar problem with the suggestions, and it was fixed in . Further use of the operator precedence list can be seen in (which introduced the error fixed in the other PR).
Thanks for your guidance and much appreciated. I have dug into HIR and built-in ranges a bit more. Decided to check all the built-in range types and concluded they are all indeed affected by this problem. The following test I came up with demonstrates my intended fix (fails with nightly as well as stage 1 compiled from master): None of the fix suggestions, when applied, constitute valid syntax. My test checks for syntax I believe should be suggested by the compiler. I'm keen to tackle all of the range types at once in the scope of this issue. The problem I see though is just how wildly different each of the range types is represented in HIR. Adding a call just above this line: Revealed the following: for isfor isfor isfor isfor isfor is I'm quite bewildered by this non-uniformity and I guess I need some help unifying all of these into a elegant condition to tell "is this a built-in range?". I could probably brute-force it in a with explicit checks for , but maybe we can do better. Thanks in advance! EDIT realized that this non-uniformity was actually mentioned in the second comment from , but my plea still stands. Thanks for your patience.
I think you can match on all of these with something along the lines of (pseudocode):
Right, that's what I had in mind, but was also wondering if something like a check for  trait would work better. I guess we want to match against built-in range literals though, and explicitly.


Question: <ins> // run-rustfix // Regression test for changes introduced while fixing #54505 // This test uses non-literals for Ranges // (expecting no parens with borrow suggestion) use std::ops::RangeBounds; // take a reference to any built-in range fn take_range(_r: &impl RangeBounds<i8>) {} fn main() { take_range(&std::ops::Range { start: 0, end: 1 }); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &std::ops::Range { start: 0, end: 1 } take_range(&::std::ops::Range { start: 0, end: 1 }); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &::std::ops::Range { start: 0, end: 1 } take_range(&std::ops::RangeFrom { start: 1 }); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &std::ops::RangeFrom { start: 1 } take_range(&::std::ops::RangeFrom { start: 1 }); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &::std::ops::RangeFrom { start: 1 } take_range(&std::ops::RangeFull {}); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &std::ops::RangeFull {} take_range(&::std::ops::RangeFull {}); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &::std::ops::RangeFull {} take_range(&std::ops::RangeInclusive::new(0, 1)); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &std::ops::RangeInclusive::new(0, 1) take_range(&::std::ops::RangeInclusive::new(0, 1)); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &::std::ops::RangeInclusive::new(0, 1) take_range(&std::ops::RangeTo { end: 5 }); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &std::ops::RangeTo { end: 5 } take_range(&::std::ops::RangeTo { end: 5 }); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &::std::ops::RangeTo { end: 5 } take_range(&std::ops::RangeToInclusive { end: 5 }); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &std::ops::RangeToInclusive { end: 5 } take_range(&::std::ops::RangeToInclusive { end: 5 }); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &::std::ops::RangeToInclusive { end: 5 } } </ins>

Here's how I rationalize it: because they are parsed and desugared by the compiler, the check needs to be explicit and hardcode all paths to builtin ranges. Handle a special case with a special case.
Yes, this is where the lowering code comes in handy, because you can see exactly how the different syntax is desugared differently, to make sure you really are catching all the cases. Yes, I agree. It'd be nice if there was a more uniform way to handle them, but it's not convenient at the moment. You could include a reference back to in a comment to where the desugaring takes place, which will provide some motivation for matching in .
All clear now, thanks. I have succeeded in matching all range types and getting the test to pass. Needs some cleanups, but hopefully should be ready for PR soon. I have a few more questions before that though :smile: I have noticed that most of my code would actually be irrelevant if I re-used functions and constants defined in , e.g.: Can't deny that I have used these as inspiration / guideline (albeit I did not do a stupid copy-paste). What's the policy on using clippy code (clippy is a submodule of main repo)? This is purely in the interest of pursuing . The diff is not that big (52 new lines to , fairly specific to matching paths) -- but still, my clean code sense tingles because of possible DRY violation. Another conundrum I have is whether we should address and paths (and if so, how to work out we're not using at compile time)?
Unfortunately, there's not much sharing from clippy to rustc. I wouldn't worry about it. If you can encapsulate it easily, it's possible that clippy could make use of the code in rustc instead. The function in picks the correct path for / — you should be able to use that.
Thanks for the suggestion for , unfortunately I can't really make the association of and . It seems to me they are disjoint -- in : lowering happens in , whereas typechecking happens in . in takes : The it uses needs an awful lot of things to be instantiated. Not sure if I can get the hold of it all in .


Question: <ins> // run-rustfix // Regression test for changes introduced while fixing #54505 // This test uses non-literals for Ranges // (expecting no parens with borrow suggestion) use std::ops::RangeBounds; // take a reference to any built-in range fn take_range(_r: &impl RangeBounds<i8>) {} fn main() { take_range(&std::ops::Range { start: 0, end: 1 }); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &std::ops::Range { start: 0, end: 1 } take_range(&::std::ops::Range { start: 0, end: 1 }); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &::std::ops::Range { start: 0, end: 1 } take_range(&std::ops::RangeFrom { start: 1 }); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &std::ops::RangeFrom { start: 1 } take_range(&::std::ops::RangeFrom { start: 1 }); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &::std::ops::RangeFrom { start: 1 } take_range(&std::ops::RangeFull {}); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &std::ops::RangeFull {} take_range(&::std::ops::RangeFull {}); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &::std::ops::RangeFull {} take_range(&std::ops::RangeInclusive::new(0, 1)); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &std::ops::RangeInclusive::new(0, 1) take_range(&::std::ops::RangeInclusive::new(0, 1)); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &::std::ops::RangeInclusive::new(0, 1) take_range(&std::ops::RangeTo { end: 5 }); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &std::ops::RangeTo { end: 5 } take_range(&::std::ops::RangeTo { end: 5 }); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &::std::ops::RangeTo { end: 5 } take_range(&std::ops::RangeToInclusive { end: 5 }); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &std::ops::RangeToInclusive { end: 5 } take_range(&::std::ops::RangeToInclusive { end: 5 }); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &::std::ops::RangeToInclusive { end: 5 } } </ins>

Another problem I encountered while writing tests is that the changes I have made will affect suggestions for code like this: With my changes, the suggestion would be . I believe the correct suggestion would not involve the needless parentheses. This is due to not differentiating between "de-sugared" form coming from and between these de-sugared forms being supplied explicitly as input source code. With this in mind, I think current code is not PR worthy just yet. If of interest, here's the branch:
Left a couple of comments on possible approaches on that commit. The code looks fine.


Question: <ins> error[E0107]: trait takes 1 generic argument but 0 generic arguments were supplied --> $DIR/name-same-as-generic-type-issue-128249.rs:4:30 | LL |     fn one(&self, val:  impl Trait<Type: Default>); |                              ^^^^^ expected 1 generic argument | note: trait defined here, with 1 generic parameter: `Type` --> $DIR/name-same-as-generic-type-issue-128249.rs:1:7 | LL | trait Trait<Type> { |       ^^^^^ ---- help: add missing generic argument | LL |     fn one(&self, val:  impl Trait<Type, Type: Default>); |                                    +++++ error[E0107]: trait takes 1 generic argument but 0 generic arguments were supplied --> $DIR/name-same-as-generic-type-issue-128249.rs:7:15 | LL |     fn two<T: Trait<Type: Default>>(&self) -> T; |               ^^^^^ expected 1 generic argument | note: trait defined here, with 1 generic parameter: `Type` --> $DIR/name-same-as-generic-type-issue-128249.rs:1:7 | LL | trait Trait<Type> { |       ^^^^^ ---- help: add missing generic argument | LL |     fn two<T: Trait<Type, Type: Default>>(&self) -> T; |                     +++++ error[E0107]: trait takes 1 generic argument but 0 generic arguments were supplied --> $DIR/name-same-as-generic-type-issue-128249.rs:11:12 | LL |         T: Trait<Type: Default>,; |            ^^^^^ expected 1 generic argument | note: trait defined here, with 1 generic parameter: `Type` --> $DIR/name-same-as-generic-type-issue-128249.rs:1:7 | LL | trait Trait<Type> { |       ^^^^^ ---- help: add missing generic argument | LL |         T: Trait<Type, Type: Default>,; |                  +++++ error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0107`. </ins>


Question: .emit(); } EscapeError::MoreThanOneChar => { <ins> let msg = if mode.is_bytes() { "if you meant to write a byte string literal, use double quotes" } else { "if you meant to write a `str` literal, use double quotes" }; </ins> handler .struct_span_err( span_with_quotes,

When creating a byte literal with single quotes, like , The error message says: But following the directions would not give us a literal, it would give a literal.
This should be easy to fix, by replacing the message with: when the literal is prefixed by . You may need to see work out which call is originating from (in ) to pass information about the nature of the literal.
Can I work on this?
go ahead! :) Let me know if you have any questions.
Hi, I have been doing some work in this issue, cause this is the first time I'm sending PR to rust, can you give me some feedback. Thanks!


Question: #[stable(feature = "ip_u32", since = "1.1.0")] impl From<Ipv4Addr> for u32 { <ins> /// It performs the conversion in network order (big-endian). </ins> fn from(ip: Ipv4Addr) -> u32 { let ip = ip.octets(); ((ip[0] as u32) << 24) + ((ip[1] as u32) << 16) + ((ip[2] as u32) << 8) + (ip[3] as u32)

The conversion traits are implemented for conversion between and , but it is not clear what byte order is used.
It is network order, but that should be documented on the impl.
doc team triage: this would make a great first PR. I am happy to mentor anyone who wants to tackle this issue.
I'd like to, is someone else working on this?
nope, please do! Ping me if you need any help


Question: // it.  We do not write to `self` nor reborrow to a mutable reference. // Hence the raw pointer we created above, for `deque`, remains valid. let ring = self.buffer_as_slice(); <del> let iter = Iter::new(ring, drain_tail, drain_head); Drain::new(drain_head, head, iter, deque) </del> <ins> Drain::new(drain_head, head, ring, drain_tail, drain_head, deque) </ins> } }

liballoc's fails when run in Miri. The error occurs in the call: is called with a as argument. contains contains a shared reference to a slice; that slice is thus marked as "must not be mutated for the entire duration of this function call". calls calls calls calls , which eventually drops the . calls to re-arrange stuff (I have not fully understood this yet), and in some cases this will end up writing to memory that the slice in points to. I am not sure what the best way to fix this is. We have to fix holding (indirectly) a shared reference to something that it'll mutate during its . The mutation is likely there for a reason, so I guess the shared reference has to go. (FWIW, this shared reference already caused other trouble, but that was fixed by ) Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
yeah I guess just change it to and toss in a PhantomData for the borrow. shrug
You mean, change this in as well? Sure, that should work. In principle this reduces the precision of compiler analyses on .
ahh misread. maybe would just not use Iter then. depends on what the impl looks like now
But the first thing it does is which should exhaust the such that its is an empty slice. I suppose its pointer will still be somewhere in the deque's memory, but with length 0 it can't actually read anything. Is that not good enough to appease Miri?
No. This code still matches the pattern There is no notion of "exhausting" or "consuming" a shared reference. When you create a shared reference with a certain lifetime, you promise that until that lifetime ends, no mutation happens. here is mutable so you can change what the slice points to, but that has no effect at all on the guarantees that have been made about the value that was initially passed to . Now, lifetimes are an entirely static concept, so for Stacked Borrows a "lifetime" generally is "until the pointer is used for the last time".


Question: // it.  We do not write to `self` nor reborrow to a mutable reference. // Hence the raw pointer we created above, for `deque`, remains valid. let ring = self.buffer_as_slice(); <del> let iter = Iter::new(ring, drain_tail, drain_head); Drain::new(drain_head, head, iter, deque) </del> <ins> Drain::new(drain_head, head, ring, drain_tail, drain_head, deque) </ins> } }

However, for the special case of a reference being passed to a function, Stacked Borrows asserts that the "lifetime" will last at least as long as the function the reference is pointed to. (This is enforced by the "barriers" explained .) This is extremely useful for optimizations.
forward to . I wouldn't want to copy those.
Oh, I also didn't realize that doesn't actually shrink down to an empty slice -- it only updates its indexes. It would otherwise have to use two slices for the wrapped head and tail. So that full shared reference does still exist after the iterator is exhausted. (This also raises the validity question of having references to uninitialized data.) Could we base on instead? We could arrange to work through that mutable reference too, so there's no question of mutable aliasing.
That might work. However, must not access in that case -- that would be in conflict with the unique reference in .
Hmm, does need to be covariant over ? I guess would break that.
Actually this idea of "consuming a shared ref" is far from unique to ... the following code also errors in Miri:
As I understand it, Miri and stacked borrows should be "more powerful" than the Rust borrow checker, right? So, is this an example where Miri does not match what Rust allows or is this a bug in Rust that could lead to undefined behaviour in safe code? ()
-- I believe is admitting that example as something that should be allowed. But this issue with involves raw pointers, which rustc doesn't check at all, so miri is in uncharted waters here.
This is up for us all to decide. I can't tell you. ;) Not necessary. I have argued that / are problematic long before Stacked Borrows. The lifetimes there are, strictly speaking, wrong. I think it would be reasonable to rule that they have to use raw pointers.
FWIW here is a stand-alone version of the testcase to reproduce this with Miri (but it needs access to some private internals):
See for the issue about whether Stacked Borrows should allow such code or not. For now, with , Miri accepts this code again. So I am going to close the issue here. It still represents an interesting data point to inform what Stacked Borrows rules should be.


Question: // it.  We do not write to `self` nor reborrow to a mutable reference. // Hence the raw pointer we created above, for `deque`, remains valid. let ring = self.buffer_as_slice(); <del> let iter = Iter::new(ring, drain_tail, drain_head); Drain::new(drain_head, head, iter, deque) </del> <ins> Drain::new(drain_head, head, ring, drain_tail, drain_head, deque) </ins> } }

nods wisely just gotta stand still long enough for the spec to bend around you
;-) I don't think the decision is made either way, but for now with several counterexamples in libstd, it is not helpful for Miri to complain about this. Plus, this matches what we formalized in Coq; the basic optimizations that we considered so far are all fine with this change.
See there actually is a bug here right now, because we do emit for passed to a function. So what Miri found is actually UB in the LLVM IR that we are generating right now. Reopening for now, but maybe it makes more sense to treat this as a duplicate of
Smaller reproduction that I found in (a now closed dupe of this issue) that doesn't rely on VecDeque internals, that fails now with
re-enables the part of Stacked Borrows that got disabled (in parts) to work around the issue, before I knew that we actually have here and are risking real miscompilations.
claim


Question: .map(|v| v.parse().expect("failed to parse rust.llvm-libunwind")); if let Some(ref backends) = rust.codegen_backends { <del> config.rust_codegen_backends = backends.iter().map(|s| INTERNER.intern_str(s)).collect(); </del> <ins> let available_backends = vec!["llvm", "cranelift", "gcc"]; config.rust_codegen_backends = backends.iter().map(|s| { if let Some(backend) = s.strip_prefix(CODEGEN_BACKEND_PREFIX) { if available_backends.contains(&backend) { panic!("Invalid value '{s}' for 'rust.codegen-backends'. Instead, please use '{backend}'."); } else { println!("help: '{s}' for 'rust.codegen-backends' might fail.  Codegen backends are mostly defined without the '{CODEGEN_BACKEND_PREFIX}' prefix.  In this case, it would be referred to as '{backend}'."); } } INTERNER.intern_str(s) }).collect(); </ins> } config.rust_codegen_units = rust.codegen_units.map(threads_from_config);

I tried this code: I expected to see this happen: An error saying that is invalid and should be instead. Instead, this happened: <!-- 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. --HEAD is branched from <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim


Question: [[package]] name = "backtrace" <del> version = "0.3.25" </del> <ins> version = "0.3.29" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "autocfg 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)",

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


Question: [[package]] name = "backtrace" <del> version = "0.3.25" </del> <ins> version = "0.3.29" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "autocfg 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)",

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


Question: // Private support modules mod panicking; <del> #[unstable(feature = "ice_to_disk", issue = "none")] pub use panicking::panic_hook_with_disk_dump; </del> #[path = "../../backtrace/src/lib.rs"] #[allow(dead_code, unused_attributes, fuzzy_provenance_casts)] mod backtrace_rs;

slightly increased default binary size (checked on x8664-pc-windows-msvc), the reason is now code unconditionally includes File::open (~ 2kb out of 130) and friends. can be tracked back by new imports of , for where is Originally posted by in
cc
cc -- I'm surprised that didn't include any libs review in the first place, having modified the default panic hook. Maybe ought to be registering its own panic hook instead?
Size changed back to 123kb.


Question: b, index: 0, // unused len: 0,   // unused <ins> a_len: 0, // unused </ins> } }

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


Question: let codegen_options = CodegenOptions::build(early_dcx, matches); let unstable_opts = UnstableOptions::build(early_dcx, matches); <del> let force_unstable_if_unmarked = unstable_opts.force_unstable_if_unmarked; </del> let dcx = new_dcx(error_format, None, diagnostic_width, &unstable_opts);

for example lists implementations of in , which aren't visible anyway and the links are also broken.
Not present in the docs for 1.77.2, regression?
cc getting multiple reports of this:
I believe this regressed in (
This was closed but it's still happening on current stable docs, in various traits, Debug being the one that seems the worst: ! !
What page are you looking at? I do not see those implementations on
stable docs, not nightly I understand this was reported the day 1.78.0 was released and 1.79.0 isn't due for a few weeks more, but I feel it should be possible to apply the fix to the current stable docs at least as published on rust- in the meantime
The stable docs are tied to the release, so we would have to make a new release to update them. The fix for this is in 1.80, and will reach stable on July 25.
There's no way to backport it internally? That's unfortunate. I was hoping it would land for 1.79.0 at least
Closing then.
This can in fact be beta backported.
And it was in
Good to know, thank you


Question: // This zip may have several times the same lifetime in `substs` paired with a different // lifetime from `id_substs`.  Simply `collect`ing the iterator is the correct behaviour: // it will pick the last one, which is the one we introduced in the impl-trait desugaring. <del> let map = substs.iter().zip(id_substs); let map: FxHashMap<GenericArg<'tcx>, GenericArg<'tcx>> = match origin { // HACK: The HIR lowering for async fn does not generate // any `+ Captures<'x>` bounds for the `impl Future<...>`, so all async fns with lifetimes // would now fail to compile. We should probably just make hir lowering fill this in properly. OpaqueTyOrigin::AsyncFn(_) => map.collect(), OpaqueTyOrigin::FnReturn(_) | OpaqueTyOrigin::TyAlias => { // Opaque types may only use regions that are bound. So for // ```rust // type Foo<'a, 'b, 'c> = impl Trait<'a> + 'b; // ``` // we may not use `'c` in the hidden type. let variances = tcx.variances_of(def_id); debug!(?variances); map.filter(|(_, v)| { let ty::GenericArgKind::Lifetime(lt) = v.unpack() else { return true }; let ty::ReEarlyBound(ebr) = lt.kind() else { bug!() }; variances[ebr.index as usize] == ty::Variance::Invariant }) .collect() } }; </del> <ins> let map = substs.iter().zip(id_substs).collect(); </ins> debug!("map = {:#?}", map); // Convert the type from the function into a type valid outside

Here is an example which uses a RPIT on a borrowed type in three different ways: IMO this is perfectly reasonable code and (EDIT: see below). On stable () we have the following: And on beta () and nightly () we get some additional errors: EDIT: On second thought, I guess the first error (on stable) is reasonable, since we are actually returning a in that case. If you either use in the body or in the return type then the error goes away. But the second error is still a regression. It most recently worked on: rustc 1.66.0 ( 2022-12-12) : modify labels: +regression-from-stable-to-beta -regression-untriaged
This is . Cc It is related to the invariance: Another case that doesn't rely on member constraints in the second function and yields a different error message: I also found a distantly related regression that doesn't require invariance. It looks like a missed subtyping opportunity:
Another version using TAIT: At this point there are two classes of regression: The first is related to the fact that and the the second requires more subtyping relations. label I-types-nominated T-types T-compiler
WG-prioritization assigning priority (). label -I-prioritize +P-critical
From beta crater: https://crater- https://crater- https://crater- https://crater- https://crater-
unnominating as it will get fixed by which is approved again. Have to try to get this into beta though, only have 1 more day for that


Question: } #[test] <ins> fn test_line_buffer_fail_flush() { // Issue #32085 struct FailFlushWriter<'a>(&'a mut Vec<u8>); impl<'a> Write for FailFlushWriter<'a> { fn write(&mut self, buf: &[u8]) -> io::Result<usize> { self.0.extend_from_slice(buf); Ok(buf.len()) } fn flush(&mut self) -> io::Result<()> { Err(io::Error::new(io::ErrorKind::Other, "flush failed")) } } let mut buf = Vec::new(); { let mut writer = LineWriter::new(FailFlushWriter(&mut buf)); let to_write = b"abcndef"; if let Ok(written) = writer.write(to_write) { assert!(written < to_write.len(), "didn't flush on new line"); // PASS return; } } assert!(buf.is_empty(), "write returned an error but wrote data"); } #[test] </ins> fn test_line_buffer() { let mut writer = LineWriter::new(Vec::new()); writer.write(&[0]).unwrap();

can return an error after a partial write if flushing the inner fails (). It should instead return , ignoring the error. I originally thought this problem was systematic so I audited stdlib. Apparently it isn't... See below. The write trait guarantees: However, this is violated all over stdlib. For example, if is written to a , the could write , try to flush, and then return an error due to a failed flush. However, has been written violating the spec. IMO, the solution is to return for partial writes and drop the error (if any). This should be safe because of write's write-xor-error guarantee. If the error was transient, the caller never needs to know. Otherwise, they will will learn of it on the next write. Here's everything in the stdlib that implements write (and should be audited): [x] in [x] in [x] in [x] in [x] in [x] in [x] in [x] in [x] in [x] in [x] in [x] in [x] in [x] in [x] in [x] in [x] in [ ] in (buggy) [x] in (buggy but unfixable and deprecated). [x] in [x] in [x] in [ ] in (panics on partial write) [x] in [x] in [x] in
Note: this could, e.g., theoretically cause to write on interrupt.
Ok. Actually, it turns out that only and are really problematic. on windows is bad but at least it's acknowledged in the code with a ...
So, is actually correct (I misread some of the code). This is just a bug in , nothing more.
Nice effort to audit it all!


Question: } #[test] <ins> #[allow(deprecated)] </ins> fn stream_smoke_test_ip4() { let server_ip = next_test_ip4(); let client_ip = next_test_ip4(); <ins> let dummy_ip = next_test_ip4(); </ins> let (tx1, rx1) = channel(); let (tx2, rx2) = channel(); spawn(proc() { <del> match UdpSocket::bind(client_ip) { Ok(client) => { let client = box client; let mut stream = client.connect(server_ip); rx1.recv(); stream.write([99]).unwrap(); </del> <ins> let send_as = |ip, val: &[u8]| { match UdpSocket::bind(ip) { Ok(client) => { let client = box client; let mut stream = client.connect(server_ip); stream.write(val).unwrap(); } Err(..) => fail!() </ins> } <del> Err(..) => fail!() } </del> <ins> }; rx1.recv(); send_as(dummy_ip, [98]); send_as(client_ip, [99]); </ins> tx2.send(()); });

change this to something more appropriate. This was introduced in commit when still returned . This should either block until a message from the correct sender arrives or return an error.


Question: } } <ins> // This is only used by a test which asserts that the initialization-tracking is correct. #[cfg(test)] impl<R> BufReader<R> { pub fn initialized(&self) -> usize { self.buf.initialized() } } </ins> impl<R: Seek> BufReader<R> { /// Seeks relative to the current position. If the new position lies within the buffer, /// the buffer will not be flushed, allowing for more efficient seeks.

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


Question: } } <ins> // This is only used by a test which asserts that the initialization-tracking is correct. #[cfg(test)] impl<R> BufReader<R> { pub fn initialized(&self) -> usize { self.buf.initialized() } } </ins> impl<R: Seek> BufReader<R> { /// Seeks relative to the current position. If the new position lies within the buffer, /// the buffer will not be flushed, allowing for more efficient seeks.

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


Question: <ins> //@ run-rustfix #![allow(unused_mut)] use std::borrow::{Borrow, BorrowMut}; use std::convert::{AsMut, AsRef}; struct Bar; impl AsRef<Bar> for Bar { fn as_ref(&self) -> &Bar { self } } impl AsMut<Bar> for Bar { fn as_mut(&mut self) -> &mut Bar { self } } fn foo<T: AsRef<Bar>>(_: T) {} fn qux<T: AsMut<Bar>>(_: T) {} fn bat<T: Borrow<T>>(_: T) {} fn baz<T: BorrowMut<T>>(_: T) {} pub fn main() { let bar = Bar; foo(bar); let _baa = bar; //~ ERROR use of moved value let mut bar = Bar; qux(bar); let _baa = bar; //~ ERROR use of moved value let bar = Bar; bat(bar); let _baa = bar; //~ ERROR use of moved value let mut bar = Bar; baz(bar); let _baa = bar; //~ ERROR use of moved value } </ins>

... 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: /// consolidate multiple unresolved import errors into a single diagnostic. fn finalize_import(&mut self, import: &'b Import<'b>) -> Option<UnresolvedImportError> { let orig_vis = import.vis.replace(ty::Visibility::Invisible); <del> let orig_unusable_binding = match &import.kind { ImportKind::Single { target_bindings, .. } => { Some(mem::replace(&mut self.r.unusable_binding, target_bindings[TypeNS].get())) } _ => None, }; </del> let prev_ambiguity_errors_len = self.r.ambiguity_errors.len(); let path_res = self.r.resolve_path( &import.module_path,

I tried this code: I expected to see this happen: Compilation error. This shadows one (glob-imported) with another . As far as I know, this should be forbidden. Instead, this happened: this code successfully compiled. : c.c. c.c.
Shadowing a glob import with a specific item is allowed and will unambiguously resolve to the specific one. This is also how the prelude works. The following compiles fine as well: .
To clarify, the problem is not shadowing, but time travel. We shadow identifier which have been already used to resolve another import, so we end up with meaning two things at the same time in the same scope.
This is a change from Rust 1.44, in Rust 1.43 this is an ICE "inconsistent resolution for an import". Possibly a consequence of
I'm not sure this is a bug. When resolving we are looking at all names in scope except for the names introduced by itself. Otherwise we'd have cycles even in trivial cases like where is a name from extern prelude. If you take this detail into consideration, then all paths seem to be resolved correctly.
cc (somewhat related)
I think, the difference with is that doesn't replace one resolution with another. We already have a name in the scope that is resolved to a particular extern crate. In my example, uses name from the scope, and then rebinds this name to another item. I can complicate my example a bit. What this program prints, "111" or "222"? It'd say, it depends on imports resolution order, but looks like it always prints "111".
It'd say, it depends on imports resolution order The intent for the resolution results is to never depend on internal resolution order. (cc , order-dependence can probably happen in practice due to the current not very principled implementation, but hopefully still can be eliminated in backward-compatible-in-practice way by rewriting the main resolution/expansion loop more carefully.) but looks like it always prints "111" That's what I'd expect. resolves to in resolves to (because non-globs shadow globs) first in resolves to (which the only in scope after excluding itself)
I'd still be ok with replacing the former ICE with an error though, since that's a more conservative choice.


Question: /// consolidate multiple unresolved import errors into a single diagnostic. fn finalize_import(&mut self, import: &'b Import<'b>) -> Option<UnresolvedImportError> { let orig_vis = import.vis.replace(ty::Visibility::Invisible); <del> let orig_unusable_binding = match &import.kind { ImportKind::Single { target_bindings, .. } => { Some(mem::replace(&mut self.r.unusable_binding, target_bindings[TypeNS].get())) } _ => None, }; </del> let prev_ambiguity_errors_len = self.r.ambiguity_errors.len(); let path_res = self.r.resolve_path( &import.module_path,

Actually enabling the property "name resolve to the same thing whether some items were excluded during its resolution to avoid cycles or not" may be useful for using something like "inference variables" for unresolved imports and making import resolution more like unification in type inference. That's an idea I had for quite some, but I hadn't realized that merging went against it.
Sigh, the issue already affects three stable releases - from 1.44 to 1.46. I'll try to prioritize it.
Addressed in
Assigning so this isn't lost. See the .
The fix caused some regressions -
The code in the issue produce no errors using Rust 1.67.1. Should we re-open the issue or is it not considered a bug now?
The fix was reverted due to breakage () and the current behavior is considered by design since then.
(Also it's not exactly a time travel - )


Question: <ins> #![allow(unused)] </ins> fn main() { <del> let arr = &[0,1,2,3]; for _i in 0..arr.len().rev() { //~ERROR not an iterator // The above error used to say “the method `rev` exists for type `usize`”. // This regression test ensures it doesn't say that any more. } </del> <ins> let arr = &[0, 1, 2, 3]; for _i in 0..arr.len().rev() { //~^ ERROR can't call method //~| surround the range in parentheses // The above error used to say “the method `rev` exists for type `usize`”. // This regression test ensures it doesn't say that any more. } // Test for #102396 for i in 1..11.rev() { //~^ ERROR can't call method //~| HELP surround the range in parentheses } let end: usize = 10; for i in 1..end.rev() { //~^ ERROR can't call method //~| HELP surround the range in parentheses } for i in 1..(end + 1).rev() { //~^ ERROR can't call method //~| HELP surround the range in parentheses } if 1..(end + 1).is_empty() { //~^ ERROR can't call method //~| ERROR mismatched types [E0308] //~| HELP surround the range in parentheses } if 1..(end + 1).is_sorted() { //~^ ERROR mismatched types [E0308] //~| ERROR can't call method //~| HELP surround the range in parentheses } let _res: i32 = 3..6.take(2).sum(); //~^ ERROR can't call method //~| ERROR mismatched types [E0308] //~| HELP surround the range in parentheses let _sum: i32 = 3..6.sum(); //~^ ERROR can't call method //~| ERROR mismatched types [E0308] //~| HELP surround the range in parentheses let a = 1 as usize; let b = 10 as usize; for _a in a..=b.rev() { //~^ ERROR can't call method //~| HELP surround the range in parentheses } let _res = ..10.contains(3); //~^ ERROR can't call method //~| HELP surround the range in parentheses if 1..end.error_method() { //~^ ERROR no method named `error_method` //~| ERROR mismatched types [E0308] // Won't suggest } let _res = b.take(1)..a; //~^ ERROR `usize` is not an iterator let _res: i32 = ..6.take(2).sum(); //~^ can't call method `take` on ambiguous numeric type //~| ERROR mismatched types [E0308] //~| HELP you must specify a concrete type for this numeric value // Won't suggest because `RangeTo` dest not implemented `take` </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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should something like this: label +D-confusing +D-invalid-suggestion <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim


Question: crate emit: Vec<EmitType>, /// If `true`, HTML source pages will generate links for items to their definition. crate generate_link_to_definition: bool, <ins> /// Set of function-call locations to include as examples </ins> crate call_locations: AllCallLocations, <ins> /// If `true`, Context::init will not emit shared files. crate no_emit_shared: bool, </ins> } #[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 rendering docs for a crate with: That puts this in the sidebar: ! In this case, and are dependencies (which I don't want to document). And is the name of one of the examples, this is a dead link.
cc - running on dependencies seems like a cargo bug, but showing them in the sidebar seems like it's an issue in rustdoc.
Thanks for the report I will take a look this week.
Ok, I have fixed the issue where examples show up in the crates list. However, I wasn't able to reproduce the issue with non-examples appearing in the crates list. Specifically, my setup was: I could not get to appear in the sidebar when using .
Thanks I tried some more things, and I think what happened is that I used it without at first, and then without clearing the folder, did it with , which apparently doesn't remove the dependencies from the sidebar. So I guess that part of the issue is about not working quite right when these artefacts already exist, and unrelated to .