jiebi/CodeConvo huggingface dataset:
Code change:
(config.mode == common::Pretty && parse_name_directive(ln, "ignore-pretty")) || (config.target != config.host && parse_name_directive(ln, "ignore-cross-compile")) || <del> ignore_gdb(config, ln) || ignore_lldb(config, ln); </del> <ins> ignore_gdb(config, ln) || ignore_lldb(config, ln) || ignore_llvm(config, ln); </ins> props.should_fail = props.should_fail || parse_name_directive(ln, "should-fail"); });

Related discussion:
text: I believe this is due to travis using system llvm which misses the fix backported in . cc
Can we do anything about this?
Our best bet is to add a for tests, I think (alternative is to drop support for LLVM pre 3.9, which would be a shame, even if its buggy in certain cases). Implementation of such directive could be implemented by injecting an environment variable or some such (done ) and checking for that in
There's no need to set an extra environment variable, just check if is set (or if you're boring :wink: )
but… but… what if people have on their own systems too?
cc
no we do not have existing infrastructure for this. I'd prefer to avoid as that's not the relevant piece here, but rather something like or . Distros or anyone else building with an older LLVM are likely to hit this and we'd need a solution for them as well. That being said I think it's fine to temporarily disable the test until we get that. There's basically a 0% chance of us regressing that test as it's just an LLVM bug, and they already have a regression test upstream as well.
Another option would be to create a base Docker image (publishing it to Docker Hub) that is just and the appropriate steps to build whatever version of LLVM we want.
We currently advertise ourselves as supporting LLVM 3.7+, and Travis is kinda our test for that, so I'd prefer to not pull that forward just yet (but instead just fix this)
For the record, I downgraded our LLVM version in a botched rebase and only this test stopped it at bors. Hopefully, someone would have noticed the absence of a fix, but you can't count of that.
touche!
Code change:
|      ^^^ type aliases cannot be used as traits | help: you might have meant to use `#![feature(trait_alias)]` instead of a `type` alias <del> --> $DIR/issue-3907.rs:5:1 </del> | <del> LL | type Foo = dyn issue_3907::Foo; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ </del> <ins> LL | trait Foo = dyn issue_3907::Foo; | </ins> help: consider importing this trait instead | LL | use issue_3907::Foo;

Related discussion:
text: I managed to reproduce the problem with this snippet: The compiler yells E0404 at me, but fair enough I always ask it to a bit more about it :) However this time, it only says this: This is confusing because the snippet above doesn't involve the keyword so I didn't understand initially what I was doing wrong, then I read the error message again: I first tried this, and it worked, but having to repeat the whole syntax everywhere wasn't too compelling, hence the alias: The compiler error message makes it very clear that I can't alias a trait, but the E0404 explanation doesn't mention it at all. I hope the description could also include this use case as I've seen sometimes EXXXX explanations go over several facets of the same problem. That won't help me, but maybe others that may trip on the same problem. I would have submitted a pull request for the docs myself, but I have no idea why you can't use type aliases for traits so I can't it ;) I'm using stable Rust 1.19.0 (on Fedora).
One more thing, even though the compiler lets me create an alias for a trait, I don't know when I can use such an alias. Maybe this should be explained too.
Current output (in nightly):
Current output: No structured suggestion for the nightly feature (should be and the feature flag).
Code change:
// `public_items` map, so we can skip inserting into the // paths map if there was already an entry present and we're // not a public item. <del> if !self.cache.paths.contains_key(&item.item_id.expect_def_id()) </del> <ins> let item_def_id = item.item_id.expect_def_id(); if !self.cache.paths.contains_key(&item_def_id) </ins> || self .cache .effective_visibilities <del> .is_directly_public(self.tcx, item.item_id.expect_def_id()) </del> <ins> .is_directly_public(self.tcx, item_def_id) </ins> { <del> self.cache.paths.insert( item.item_id.expect_def_id(), (self.cache.stack.clone(), item.type_()), ); </del> <ins> self.cache .paths .insert(item_def_id, (self.cache.stack.clone(), item.type_())); </ins> } } }

Related discussion:
text: Generated rustdoc JSON for every one of dozens of crates I've looked at seems to contain unexpected inlined items that look like an block and its contents. I expected to see this happen: rustdoc JSON file contains only the items defined or re-exported by the corresponding crate. Instead, this happened: the rustdoc JSON file contains items like this: In this example, is and here are the names of the items contained in that impl (also part of the rustdoc JSON): Similarly, you can find items from : Invocation for generating rustdoc JSON: : You can find a variety of pre-generated rustdoc JSON files with this issue here: Briefly discussed in Zulip: https://rust- I'll have to work around this behavior to shield , which uses the same codebase as the playground link above. I can hold off on updating the playground for, say, another week, but at some point I'll need to upgrade it to include my workaround which means those items will cease being shown. label +T-rustdoc +A-rustdoc-json
Possibly duplicate of
Might be! Definitely at least some overlap, not entirely sure if duplicate. Do you mind if I ship the workaround for this in cargo-semver-checks and the playground, which will hide these items from our lints and from queries in the playground?
Yeah, it's easy enough to reproduce in raw json, I'm not worried about the repro breaking.
Code change:
<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. struct Foo; impl Foo { fn putc(&self, b: u8) { } fn puts(&self, s: &str) { for byte in s.bytes() { self.putc(byte) } } } fn main() {} </ins>

Related discussion:
text: Minimised example: Both the and the fail in the same way, with an ICE: Adding bounds to and on the trait or in the fn’s where clause doesn’t fix it, but changing to does fix it. (In the particular case that I was dealing with, the lifetime could_ be changed to where this was a problem, but it would only have taken a slight variation of it for me to be in a situation where I needed a non- implementation. There were, of course, other arguments which were using the .) The whole thing around there seems a bit fragile and I’m not quite sure what’s supposed to work and what’s not; if we just take an and transmute it to , for example, we get “error: cannot transmute to or from a type that contains type parameters in its interior [E0139]”. Anyway, an ICE is always a bug, so here’s the report!
No longer repros. compiles now. Fails with: But no ICE.
Code change:
<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. struct Foo; impl Foo { fn putc(&self, b: u8) { } fn puts(&self, s: &str) { for byte in s.bytes() { self.putc(byte) } } } fn main() {} </ins>

Related discussion:
text: While trying to learn how to return a closure.... I came across this.. gives....
Commenting-out the body of still results in an ICE.
I can't seem to produce an ICE no matter what I do.
Those closure kinds info are already gone, so I think many related bugs are gone as well. e.g. I cannot reproduce a bug related to closure kinds and macro
Code change:
<ins> // check-pass // aux-build:test-macros.rs // compile-flags: -Z span-debug #![no_std] // Don't load unnecessary hygiene information from std extern crate std; #[macro_use] extern crate test_macros; macro_rules! empty_stmt { ($s:stmt) => { print_bang!($s); // Currently, all attributes are ignored // on an empty statement #[print_attr] #[rustc_dummy(first)] #[rustc_dummy(second)] $s } } fn main() { empty_stmt!(;); } </ins>

Related discussion:
text: This the the of a proc macro crate : And here is the of another crate: When building, this outputs: 49.0, 1.50.0-beta.5 rustc 1.51.0-nightly ( 2021-01-05) binary: rustc commit-hash: commit-date: 2021-01-05 host: x86_64-unknown-linux-gnu release: 1.51.0-nightly
cc
cc
Assigning as discussed as part of the and removing .
assigning to self to confirm if is the cause of the breakage, and if so, revert the PR until it can be revised to handle this case.
This is caused by us not handling properly - I'm working on a fix.
Opened
Code change:
<ins> #!/bin/sh CARGO_TARGET_DIR=$(pwd)/target/ export CARGO_TARGET_DIR echo 'Deprecated! `util/dev` usage is deprecated, please use `cargo dev` instead.' cd clippy_dev && cargo run -- "$@" </ins>

Related discussion:
text: The following sample crashed rustc: Removing the , or unwrapping the (leaving only ), or replacing the predicate (leaving ), solves the crash. Reproduced on Windows 64-bit, Fedora 32-bit, Ubuntu 64-bit. Full crash log (thanks to ) @ Short crash message:
Fixed pending
Fixed in
Code change:
<ins> #!/bin/sh CARGO_TARGET_DIR=$(pwd)/target/ export CARGO_TARGET_DIR echo 'Deprecated! `util/dev` usage is deprecated, please use `cargo dev` instead.' cd clippy_dev && cargo run -- "$@" </ins>

Related discussion:
text: While I was playing with the new rustc 0.6, I encountered an internal compiler error The source code is here: Compiler version is 0.6, built with gcc, on OS X 10.7.5
If you run rustc under gdb and break on , could you paste the backtrace here?
OK. Here is the backtrace:
Looks like stack exhaustion to me. What happens if you remove ?
The code compiles with no problem when I wrap the rest of the code with mod block. Like:
This yields a proper error message now; closing.
Code change:
<ins> #!/bin/sh CARGO_TARGET_DIR=$(pwd)/target/ export CARGO_TARGET_DIR echo 'Deprecated! `util/dev` usage is deprecated, please use `cargo dev` instead.' cd clippy_dev && cargo run -- "$@" </ins>

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

Related discussion:
text: As seen in , LLVM has lots of places where it will insert calls to libm directly, not switching stacks. One of places that I recall seeing this before is the translation of the instruction. Rust has floating point modulus and presumably it is doing it in the red zone.
We can solve this with an lang item.
Is this an issue with calls to compiler-rt too? Or are they compiled in some special way to avoid the issue?
Nominating for milestone 5, production-ready
, , and are also all generated. As far as I can tell, we can't prevent it from generating these by altering the IR we output.
We can possibly be selective about when we emit memcpy/memmov, second guessing LLVM (like, never for big things)
accepted for production-ready milestone
Closing due to segmented stacks being gone (stack switches no longer a thing)
Code change:
<ins> // We used to not lower the extra `b @ ..` into `b @ _` which meant that no type // was registered for the binding `b` although it passed through resolve. // This resulted in an ICE (#69103). fn main() { let [a @ .., b @ ..] = &mut [1, 2]; //~^ ERROR `..` can only be used once per slice pattern b; let [.., c @ ..] = [1, 2]; //~^ ERROR `..` can only be used once per slice pattern c; // This never ICEd, but let's make sure it won't regress either. let (.., d @ ..) = (1, 2); //~^ ERROR `..` patterns are not allowed here d; } </ins>

Related discussion:
text: The ICE only occurs when is used. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Nominating due to impending stabilization, even though stable doesn't ICE yet
Simplified:
Code change:
replace_late_bound_regions(tcx, value, |_, _| ty::ReStatic).0 } <ins> /// Rewrite any late-bound regions so that they are anonymous.  Region numbers are /// assigned starting at 1 and increasing monotonically in the order traversed /// by the fold operation. /// /// The chief purpose of this function is to canonicalize regions so that two /// `FnSig`s or `TraitRef`s which are equivalent up to region naming will become /// structurally identical.  For example, `for<'a, 'b> fn(&'a int, &'b int)` and /// `for<'a, 'b> fn(&'b int, &'a int)` will become identical after anonymization. pub fn anonymize_late_bound_regions<'tcx, HR>(tcx: &ctxt<'tcx>, sig: &HR) -> HR where HR: HigherRankedFoldable<'tcx> { let mut counter = 0; replace_late_bound_regions(tcx, sig, |_, db| { counter += 1; ReLateBound(db, BrAnon(counter)) }).0 } </ins> /// Replaces the late-bound-regions in `value` that are bound by `value`. pub fn replace_late_bound_regions<'tcx, HR, F>( tcx: &ty::ctxt<'tcx>,

Related discussion:
text: Backtrace:
Well, this is interesting. It's broken all the way back to 0.10. I think it's been a bug in the type id implementation since it first landed. Here's a smaller test case:
is there a particular reason explicitly checks that all regions it encounters are ? Trans doesn't seem to go out of its way to erase late-bound regions in fn type signatures, which results in this ICE. I could add a call to in trans to fix this, but it would be cheaper to just ignore regions during hashing.
Ended up catching me
It seems we actually want to take late-bound regions into account when hashing. For example, the following should hold:
Code change:
set -ex source shared.sh <del> curl https://cmake.org/files/v3.6/cmake-3.6.3.tar.gz | tar xzf - </del> <ins> CMAKE=3.13.4 curl -L https://github.com/Kitware/CMake/releases/download/v$CMAKE/cmake-$CMAKE.tar.gz | tar xzf - </ins> mkdir cmake-build cd cmake-build <del> hide_output ../cmake-3.6.3/configure --prefix=/rustroot </del> <ins> hide_output ../cmake-$CMAKE/configure --prefix=/rustroot </ins> hide_output make -j10 hide_output make install cd .. rm -rf cmake-build <del> rm -rf cmake-3.6.3 </del> <ins> rm -rf cmake-$CMAKE </ins>

Related discussion:
text: The docs currently claim that the minimum Linux kernel version for is 2.6.18 (released September 20th, 2006). This is because RHEL 5 used that kernel version. However, RHEL 5 entered ELS on March 31, 2017. Should we continue to support RHEL 5 for , or should we increase the minimum Linux Kernel version to 2.6.27 (2nd LTS) or 2.6.32 (RHEL 6, 3rd LTS)? . Even bumping the min-version to 2.6.27 would allow us to remove most of the Linux-specific hacks in . Example: .
Given that RHEL is the only reason we keep comically old kernel versions around, I would propose that Rust only support RHEL until Maintenance Support ends. This is (essentially) what we already did for RHEL 4. Rust never supported RHEL 4, and back when RHEL 5 still had maintenance support. It would be nice to get someone from Red Hat or a RHEL customer to comment. This policy would allow us to increment the minimum kernel from 2.6.18 to 2.6.32 (and remove a lot of Linux-specific hacks). Note that RHEL has a weird (and very long) support system for RHEL 4, 5, and 6 (sources: and ). It has 5 major steps: Full Support Normal support of the OS Maintenance Support 1 Bug/Security fixes Limited hardware refresh Maintenance Support 2 Bug/Security fixes The end of this phase is considered "Product retirement" Extended Life Cycle Support (ELS) Additional paid product from Red Hat Gives updates for a longer period of time No additional releases/images Extended Life Phase (ELP) No more updates Limited Technical Support End date not given by Red Hat Current status of RHEL versions: RHEL 4 Not supported by Rust Currently in ELP (no end date specified) ELS ended March 31, 2017 RHEL 5 Supported by Rust Currently in ELS Maintenance Support ended March 31, 2017 ELS ends November 30, 2020 RHEL 6 Supported by Rust Currently in Maintenance Support 2 Maintenance Support ends November 30, 2020
cc which I think they could be related.
Code change:
set -ex source shared.sh <del> curl https://cmake.org/files/v3.6/cmake-3.6.3.tar.gz | tar xzf - </del> <ins> CMAKE=3.13.4 curl -L https://github.com/Kitware/CMake/releases/download/v$CMAKE/cmake-$CMAKE.tar.gz | tar xzf - </ins> mkdir cmake-build cd cmake-build <del> hide_output ../cmake-3.6.3/configure --prefix=/rustroot </del> <ins> hide_output ../cmake-$CMAKE/configure --prefix=/rustroot </ins> hide_output make -j10 hide_output make install cd .. rm -rf cmake-build <del> rm -rf cmake-3.6.3 </del> <ins> rm -rf cmake-$CMAKE </ins>

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

Related discussion:
text: 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)?