jiebi/CodeConvo huggingface dataset:
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: 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.
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 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.
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: 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 !
Code change:
// preventing the latter from being formatted. ignore_fmt.add(&format!("!/{}", untracked_path)).expect(&untracked_path); } <ins> if !check && paths.is_empty() { if let Some(files) = get_modified_files(build) { for file in files { println!("formatting modified file {file}"); ignore_fmt.add(&format!("/{file}")).expect(&file); } } } </ins> } else { println!("Not in git tree. Skipping git-aware format checks"); }

Related discussion:
text: Since rustfmt is deterministic and idempotent, running it twice on the same file should always have the same output (if it's not both of those things, it's a bug). So we can avoid running it unless the file has changed, which should make without arguments much faster. Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This will need to be careful to still rerun rustfmt when we bump its version (which happens about every 6 weeks). Maybe we can generate a file and format everything if it doesn't yet exist or has the wrong version.
Hello, I want to work on that. How would the detection of modified files work ?
you can use to see modified files. Make sure to fall back to formatting all files if that command fails for some reason, we support building from source tarballs without git installed.
This means that already-commited files that were not formatted when committed would not be formatted, right ?
Ah, good point. You can use to find where the two diverged and compare all files since then. And should still look at all files unconditionally.
Thanks, I will start working on this ! claim
That assumes that the rust-lang remote is labeled as origin. I call that upstream and my fork origin. Using the local master may also not work if one does on branch.
Yes, has a more general solution.
PR is up at
Code change:
LL |     #[deprecated(since(b), note = "a")] //~ ERROR incorrect meta item |                  ^^^^^^^^ <ins> error[E0565]: literal in `deprecated` value must be a string --> $DIR/deprecation-sanity.rs:19:25 | LL |     #[deprecated(note = b"test")] //~ ERROR literal in `deprecated` value must be a string |                         ^^^^^^^ help: consider removing the prefix: `"test"` error[E0565]: item in `deprecated` must be a key/value pair --> $DIR/deprecation-sanity.rs:22:18 | LL |     #[deprecated("test")] //~ ERROR item in `deprecated` must be a key/value pair |                  ^^^^^^ </ins> error[E0550]: multiple deprecated attributes <del> --> $DIR/deprecation-sanity.rs:22:1 </del> <ins> --> $DIR/deprecation-sanity.rs:28:1 </ins> | LL | fn multiple1() { } //~ ERROR multiple deprecated attributes | ^^^^^^^^^^^^^^^^^^ error[E0538]: multiple 'since' items <del> --> $DIR/deprecation-sanity.rs:24:27 </del> <ins> --> $DIR/deprecation-sanity.rs:30:27 </ins> | LL | #[deprecated(since = "a", since = "b", note = "c")] //~ ERROR multiple 'since' items |                           ^^^^^^^^^^^ <del> error: aborting due to 7 previous errors </del> <ins> error: aborting due to 9 previous errors </ins> <del> Some errors occurred: E0538, E0541, E0550, E0551. </del> <ins> Some errors occurred: E0538, E0541, E0550, E0551, E0565. </ins> For more information about an error, try `rustc --explain E0538`.

Related discussion:
text: Look for example to It is deprecated, and in source code there is hint what should be used instead: but in generated html documentation there is no hint about
isn't the correct syntax for the attribute. It should be . You can see it work: . This isn't a rustdoc issue. It's an issue with rustc that it doesn't reject .
Code change:
// ensure that we issue lints in a repeatable order def_ids.sort_by_cached_key(|&def_id| self.tcx.def_path_hash(def_id)); <del> for def_id in def_ids { </del> <ins> 'lifetimes: for def_id in def_ids { </ins> debug!("check_uses_for_lifetimes_defined_by_scope: def_id = {:?}", def_id); let lifetimeuseset = self.lifetime_uses.remove(&def_id);

Related discussion:
text: I tried this code: I expected to see this happen: the code is correct. Instead, this happened: Just swap the functions, then the code compiles: Update : The examples may be misleading. I forgot that takes effect on a single item. It was a typo. Here is a new example. It should be correct. But the compiler does not accept it. <!-- 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. --: :
Very strange. I'm thinking we have some stateful HIR lowering code that is hanging onto state it shouldn't.
This bug existed as far back as November 2019 (when was stabilized), so it's not a recent regression.
Marking this as P-medium based on the
I did some digging into this. I'm brand new to the compiler so slowly learning the architecture along the way. Below are some thoughts on what I've seen so far. The desugared HIR for both samples is the same: async first async last As expected both resolves the same set of lifetimes (from ) and process them in the same order (since ). Dump from the property at the first iteration: async first async last Interestingly both included the lifetime as used only once in the opaque/desugared async function and both . However, for the second case (async last) the compilation still succeeds - this is really confusing and I'm probably missing something big about the compiler architecture. Need to dig deeper.
The examples may be misleading. I forgot that takes effect on a single item. It was a typo. Here is a new example.
Makes sense. Then the behavior is no longer magical and makes a lot of sense.
Based on what I've seen the desugaring process is working correctly and the object is keeping the correct state. The lifetime linting identifies the lifetime as only used once within the return opaque type generated by the desugaring process. This behavior seems correct since we'd still want to catch this for an opaque type implementation from the user. My suggestion would be to include an exception in the linting specifically for opaque types of async functions that use a lifetime name already declared in the generic params of the parent function. I have validated this simple change (I named the loop ) and propose to include it alongside .
Code change:
// ensure that we issue lints in a repeatable order def_ids.sort_by_cached_key(|&def_id| self.tcx.def_path_hash(def_id)); <del> for def_id in def_ids { </del> <ins> 'lifetimes: for def_id in def_ids { </ins> debug!("check_uses_for_lifetimes_defined_by_scope: def_id = {:?}", def_id); let lifetimeuseset = self.lifetime_uses.remove(&def_id);

Related discussion:
text: One more question for the team ( what would we expect in this case? This compiles successfully, which is counter intuitive by looking at the function signature. It compiles because the desugared generator uses the same lifetime as the async function.
Code change:
"rls-rustc", "rls-span", "rls-vfs", <del> "rustc-serialize", </del> "rustc-workspace-hack", "rustc_tools_util 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)", "rustfmt-nightly",

Related discussion:
text: Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
Code change:
ByteStr(_) | ByteStrRaw(..) => "byte string" } } <ins> // See comments in `interpolated_to_tokenstream` for why we care about // *probably* equal here rather than actual equality fn probably_equal_for_proc_macro(&self, other: &Lit) -> bool { mem::discriminant(self) == mem::discriminant(other) } </ins> } pub(crate) fn ident_can_begin_expr(ident: ast::Ident, is_raw: bool) -> bool {

Related discussion:
text: This is minimized from the dramatic forum thread . The following code is fine in nightly-2018-04-12 but breaks with nightly-2018-04-15. Oddly, lots of minor perturbations make it succeed. For example remove the two characters and it works. Or remove the single quote in the string and it works.
Alrighty-roo. As everything these days with hygiene, there's a couple of bugs here. With this one though I think only two! Everything has to do here with basically. AKA anything that runs through that falls off The usual reasons we think you fall off the "happy path" are due to things like inner attributes, , macro expansion, etc. None of that's present here! It should be the case that above can be losslessly converted to a based on what we've cached. Turns out though had a bug in it (surprise surprise!). There we're using to compare the resulting two token streams which eventually bottoms out in . As it turns out this isn't quite what we want! The implementation is structural, but the token stream we get when stringifying is slightly different than what we parsed. Here in the example you're using the literal string , but rustc stringifies this token as . Similarly if you replaced the string with something like it'll be stringified as . This means that the tokens are not literally byte-for-byte equal, which means we fall off the happy path! tl;dr the token stream of is not equivalent to the token stream . This causes us to fall off the happy path and used a stringified token stream. OK so in the case above we're falling off the happy path when we didn't expect to, but even still there's some weird bad hygiene behavior when we're not on the happy path. There's still something to fix! It turns out that there's also a regression due to (found via bisection). Before that PR this example would compile just fine, afterwards though it's hitting this error. can you help diagnose this and see what's going on? The reduced test case I have right now is: (note the inner attribute on to force using a non-cached token stream)
I've posted a fix for the "happy path" at will actually fix example above.
Code change:
ByteStr(_) | ByteStrRaw(..) => "byte string" } } <ins> // See comments in `interpolated_to_tokenstream` for why we care about // *probably* equal here rather than actual equality fn probably_equal_for_proc_macro(&self, other: &Lit) -> bool { mem::discriminant(self) == mem::discriminant(other) } </ins> } pub(crate) fn ident_can_begin_expr(ident: ast::Ident, is_raw: bool) -> bool {

Related discussion:
text: That PR does not, however, fix the regression from which is still reproducible with the example I gisted.
Any idea why my repro case above is fixed if you remove the tokens? It seems like should fall off the happy path just as much.
If you remove the tokens we're still on the stringification path (aka not the happy path). For whatever reason though the hygiene bug goes away. That's likely caused from a subtelty introduced in (or at least so I'm hoping). I don't know much about , so I'm hoping will be able to look at this and know what's going on!
I don't know much about , so I'm hoping will be able to look at this and know what's going on! I'll investigate.
is the commit causing the regression. Further investigation is in progress.
An issue recently popped up on Rocket () that appears to be identical to this one and is not resolved in any recent nightly. It's possible that the root cause is , however.
Code change:
impl Scalar { pub fn is_bool(&self) -> bool { <del> if let Int(I8, _) = self.value { self.valid_range == (0..=1) } else { false } </del> <ins> matches!(self.value, Int(I8, false)) && self.valid_range == (0..=1) </ins> } /// Returns the valid range as a `x..y` range.

Related discussion:
text: <!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
modify labels: +regression-from-stable-to-stable This happens since rust
More minimal reproducer. Does not occur with just 1 variant. Or if one of the variants has a negative discriminant. Affects most targets if not all of them, despite the failure seemingly occurring inside the target-specific code.
Assigning P-medium as .20enum.20from.20an.20extern.20c.E2.80.A6) and removing I-prioritize.
Code change:
<ins> // check-pass struct Sqlite {} trait HasArguments<'q> { type Arguments; } impl<'q> HasArguments<'q> for Sqlite { type Arguments = std::marker::PhantomData<&'q ()>; } fn foo() { let _ = <Sqlite as HasArguments>::Arguments::default(); } fn main() {} </ins>

Related discussion:
text: This code: compiles on stable but not on nightly. Error: I bisected it to and then refined it; reverting fixes the issue. This is the cause for
ping since you're the author of the commit
WG-prioritization assigning priority (). label -I-prioritize +P-critical
note: there's a fix in ready for review
Code change:
fn get_or_create_type_parameter_def<'a,'tcx>(ccx: &CrateCtxt<'a,'tcx>, ast_generics: &hir::Generics, space: ParamSpace, <del> index: u32) </del> <ins> index: u32, allow_defaults: bool) </ins> -> ty::TypeParameterDef<'tcx> { let param = &ast_generics.ty_params[index as usize];

Related discussion:
text: If I understand correctly, type parameter defaults have no effect in the block . Just like in PR , this should have a warning and then an error. Example cc
Argh, I guess I failed to cover those?
Nominating for triage.
triage: P-high
Code change:
<del> Subproject commit f5532b22b5d741f3ea207b5b07e3e1ca63476f9b </del> <ins> Subproject commit 02b3734a5ba6de984eb5a02c50860cc014e58d56 </ins>

Related discussion:
text: nightly-2017-10-24 contains a libtest with bad DWARF: I can reproduce this if I recompile libtest locally: The problem can be fixed by disabling thinlto (and keeping the codegen units is ok). I noticed this with nightly-2017-10-24 because it is the first nightly compiled with thinlto, but the problem also occurs if I compile libtest with thinlto enabled using earlier compilers (eg nightly-2017-10-17). Inspecting the DWARF, a DIE at that local ref offset does exist in another codegen unit, so the problem seems to be that we should be using a global ref instead.
cc'ing since he's been poking around in LLVM's DWARF generation code recently.
Sorta smells like an LLVM bug -- but hard to say. Who should investigate?
triage: P-medium if you are able to investigate as part of ThinLTO work would be great.
It's likely that this is the cause of , which even if the underlying segfault were fixed would likely prevent backtraces from happening on OSX.
This is unfortunately not "automagically fixed" if we upgrade to LLVM 5
Making progress. First up, minimized Rust source code via creduce to get: Next up let's see if we can reduce it to one object file: Ok looks like only one object file is invalid! Let's take a look the LLVM IR: Ok let's see what's happening by minimizing the LLVM IR: yielding which I . I checked out LLVM trunk, , and looks like the error is still on LLVM trunk.
I'm not sure at this point if this is an LLVM bug, a rustc bug, or a ThinLTO bug. I've managed to extract what I believe is a for this which reproduces the error. I'm hoping fixing that IR will fix all other related issues to this at this point in time. For those of you more familiar with debug information (probably everyone other than me!) mind taking a look at that IR? Does it look "obviously wrong"? If it's "obviously wrong" I can try to work backwards to figure out what piece of the pipeline introduced such a wrong piece, but if it looks correct I can open an LLVM bug saying that we think it may be broken (and maybe they'll say it's "obviously wrong"!)