jiebi/CodeConvo huggingface dataset:
Change:
<ins> include ../tools.mk # Verify that the impl_* symbols are preserved. #108030 # only-x86_64-unknown-linux-gnu # min-llvm-version: 17 all: $(RUSTC) -Cdebuginfo=0 -Copt-level=3 lib.rs $(RUSTC) -Clto=fat -Cdebuginfo=0 -Copt-level=3 main.rs </ins>

Discussion:
This will take quite a while; sorry, I don't have a more minimal reproduction on hand since the issue doesn't reproduce on a toy example and reducing the actual reproduction into a minimal example is tricky when it takes forever to reproduce. The compilation succeeds. Linking fails. rustc 1.69.0-nightly ( 2023-01-23) rustc 1.69.0-nightly ( 2023-02-13) Linux+amd64 The issue also reproduces on macOS+aarch64. I'm not sure whether this is a generic LTO bug, or a bug with . The  crate sets up a bunch of trampolines like this: <details<summaryRelevant code</summary</detailsSo as you can see the symbol that's being unnecessarily stripped out is being passed into the block () and that is being called from assembly (). That symbol is just a normal mangled extern "C" function (). What's also interesting is also that this seems to affect only these two symbols (there are more that are defined, and it seems like those are not being stripped out for some reason), and that it doesn't reproduce on toy examples. There are also two potential workarounds; first workaround is to just mark the function as : The other is to create a dummy variable with a on it: After applying either of those the linking succeeds even when LTO is enabled. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Might or might not be related:
This is a minimal reproduction that works on macOS and Linux (x86_64). I think the fixes this issue.
label +A-llvm
claim
Change:
const mobileTitle = document.createElement("h2"); mobileTitle.className = "location"; if (hasClass(document.querySelector(".rustdoc"), "crate")) { <del> mobileTitle.innerText = `Crate ${window.currentCrate}`; </del> <ins> mobileTitle.innerHTML = `Crate <a href="#">${window.currentCrate}</a>`; </ins> } else if (locationTitle) { mobileTitle.innerHTML = locationTitle.innerHTML; }

Discussion:
On mobile using both firefox and Brave. !
This is presumably a rustdoc issue, unless our css somehow affects it, but I doubt it.
Taking a look.
Change:
<del> // check-pass </del> <ins> // build-pass </ins> // edition:2018 type BoxFuture<T> = std::pin::Pin<Box<dyn std::future::Future<Output=T>>>;

Discussion:
<!-- 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. --code from <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: This crashes nightly, beta and stable <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Looks like this is happens during codegen which is why this didn't show up in the test (note the ´check-pass`) ...?
Hmm... this should be normalized somewhere above codegen I think? Curious to investigate though. claim
I suspect that this is caused by a bug in how we handle higher-ranked region variables (possibly during trait selection caching).
Change:
<ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![feature(advanced_slice_patterns, slice_patterns)] fn check(list: &[u8]) { match list { &[] => {}, &[_u1, _u2, ref _next..] => {}, &[_u1] => {}, } } fn main() {} </ins>

Discussion:
Hello, According to this , I have writted this example: But after the rustc 1.14.0-nightly version from 2016-10-25 --, I expected to see this happen:
Minimal example Fails with
regression introduced in .
How can this be a stable-nightly regression when this affects a gated feature?
Not sure what's the policy about it. It's a regression.
Yeah, I totally agree that this is a regression, although the label is inaccurate. I have wanted a label in the past (for eg. ), and think that once upon a time there even was such a label.
Change:
let v = CString::new(v.as_bytes())?; unsafe { <del> let _guard = ENV_LOCK.write_with_guard(); </del> <ins> let _guard = env_lock(); </ins> cvt(libc::setenv(k.as_ptr(), v.as_ptr(), 1)).map(drop) } }

Discussion:
For example: i686-gnu, i686-gnu, i686-gnu-nopt, i686-gnu-nopt, i686-gnu, i686-gnu-nopt, i686-gnu, i686-gnu-nopt i686-gnu, i686-gnu, i686-gnu, x8664-gnu-distcheck, i686-gnu-nopt, x8664-gnu-tools, i686-gnu, i686-gnu-nopt, i686-gnu-nopt,
Posted a fix at .
Change:
/// Adds the compiler's directory of dynamic libraries to `cmd`'s dynamic /// library lookup path. <del> pub fn add_rustc_lib_path(&self, compiler: Compiler, cmd: &mut Cargo) { </del> <ins> pub fn add_rustc_lib_path(&self, compiler: Compiler, cmd: &mut Command) { </ins> // Windows doesn't need dylib path munging because the dlls for the // compiler live next to the compiler and the system will find them // automatically.

Discussion:
I tried to build rust right after got merged and caught error:
cc
What command did you run?
Change:
if abi == abi::RustIntrinsic { encode_inlined_item(ecx, rbml_w, IIForeignRef(nitem)); } <ins> encode_attributes(rbml_w, &*nitem.attrs); let stab = stability::lookup(ecx.tcx, ast_util::local_def(nitem.id)); encode_stability(rbml_w, stab); </ins> encode_symbol(ecx, rbml_w, nitem.id); } ast::ForeignItemStatic(_, mutbl) => {

Discussion:
This may be a duplicate, but can't find the original if it exists. See for the problem. Most of the intrinsics are doc'd with stability markers, but none of that shows up. Docs also consequently don't show up in re-exports.
Uh, are you sure? The doesn't seem to have stability markers at all. Reexports would be a different story though.
The copy_memory ones do.
Ah, you are right. It seems that any extern fns (and not only ) with stability markers are missing them.
To clarify: functions declared inside an block are missing stability markers. Extern functions have them. That is:
There is a FIXME related to this issue, Now that the issue is closed can the FIXME be fix, or made more specific?
Change:
return true; } // Normalize projections and things like that. <del> // FIXME: We need to reveal_all, as some optimizations change types in ways // that require unfolding opaque types. let param_env = self.param_env.with_reveal_all_normalized(self.tcx); let src = self.tcx.normalize_erasing_regions(param_env, src); let dest = self.tcx.normalize_erasing_regions(param_env, dest); </del> <ins> let src = self.tcx.normalize_erasing_regions(self.param_env, src); let dest = self.tcx.normalize_erasing_regions(self.param_env, dest); </ins> // Type-changing assignments can happen when subtyping is used. While // all normal lifetimes are erased, higher-ranked types with their // late-bound lifetimes are still around and can lead to type // differences. So we compare ignoring lifetimes. <del> equal_up_to_regions(self.tcx, param_env, src, dest) </del> <ins> equal_up_to_regions(self.tcx, self.param_env, src, dest) </ins> } }

Discussion:
Previously: Now: <!-- 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
Inlining exposes a use of unnormalized local in a call terminator (not sure if this is more of an issue with inlining or a validator): Note: revision annotation doesn't work in an auxiliary file (so it isn't tested on CI with mir-opt-level=2). modify labels: +A-mir-opt-inlining
This ICEs again because the fix was reverted Can someone reopen please?
Due to this new requires to trigger. <details<summaryICE:</summary</details
(FWIW can also trigger this: )
fixes this for and , but it still ICEs with on its own or with mir-opt-level 1/2 cc
Change:
This flag will run your code examples as tests. For more, see [the chapter on documentation tests](write-documentation/documentation-tests.md). <del> See also `--test-args`. </del> <ins> See also `--test-args` and `--test-run-directory`. </ins> ## `--test-args`: pass options to test runner

Discussion:
This is a tracking issue for the flag in rustdoc. This flag changes the directory where doctests are run. This was to support changing the directory used while running in a Cargo workspace. See for more information. None at this time. — Initial PR. Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not* meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label. cc
I opened with the aim to stabilize this rustdoc flag, primarily to facilitate the cargo flag, and to eventually making it the default. The flag in combination with allows specifying an explicit directory in which rustdoc will run the compiled doctests. The default, without this explicit flag, is to run the resulting doctest binaries in the same current working directory as rustdoc itself. This flag is primarily the building block for the cargo flag (See ). With that flag, doctests are handled consistently to unit- and integration tests: They will be compiled relative to the cargo workspace root, but they are run in the crate directory. The flag is currently not documented as part of the . -- highlights usage with cwd-sensitive functions inside doctests. -- shows indirect usage via the cargo flag.Similar flags that allow hooking into or observing the side effects of rustdoc test compilation, such as are not stable yet, and there does not seem to be a push to stabilization either. The usefulness of this flag when invoking manually might be limited. But it is a requirement for the cargo flag. Is there maybe a better alternative to solve the compile/run directory inconsistency that exists in cargo workspaces today?
over in expressed agreement to make the cargo flag the default, considering it rather a bugfix for the current inconsistent behavior. However, stabilizing is a requirement for that, and there does not seem to be a better alternative to it. is there anything I can do to move stabilization () forward?
Next step is the FCP. I'll start on the PR.
cargo test runs doc tests by default and doesn't allow to specify . My project uses sqlx which tries to create directory. But if fails because I run the build inside a container against immutable source. Instead I expect that the test should stay in the workspace directory and use which is mounted as a build cache volume.
Change:
// option. This file may not be copied, modified, or distributed // except according to those terms. <ins> // As documented in Issue #45983, this test is evaluating the quality // of our diagnostics on erroneous code using higher-ranked closures. // // However, as documented on Issue #53026, this test also became a // prime example of our need to test the NLL migration mode // *separately* from the existing test suites that focus solely on // AST-borrwock and NLL. // revisions: ast migrate nll // Since we are testing nll (and migration) explicitly as a separate // revisions, dont worry about the --compare-mode=nll on this test. // ignore-compare-mode-nll //[ast]compile-flags: -Z borrowck=ast //[migrate]compile-flags: -Z borrowck=migrate -Z two-phase-borrows //[nll]compile-flags: -Z borrowck=mir -Z two-phase-borrows </ins> fn give_any<F: for<'r> FnOnce(&'r ())>(f: F) { f(&()); }

Discussion:
D'oh: while investigating , I found a case where we are downgrading the NLL errors to warnings (due to the migration mode in ), but AST-borrowck issues an error for the test! (This may explain , at least in part...) Namely, . Here is the test: Here is the AST-borrowck output (a hard error): And here is the NLL output (another hard error): But here is the output from : ui/borrowck/issue- is one particular instance of this, but now that I've found one, I'm certain there are more. This is pretty bad. Very high priority to fix.
This code looks suspicious:
Ha I should have just left this to to fix, since we seem to have independently identified the culprit.
I think I've already assigned myself to enough issues.
Change:
pub type TargetResult = Result<Target, String>; macro_rules! supported_targets { <del> ( $(($triple:expr, $module:ident),)+ ) => ( $(mod $module;)* </del> <ins> ( $(($( $triple:literal, )+ $module:ident ),)+ ) => { $(mod $module;)+ </ins> /// List of supported targets <del> const TARGETS: &[&str] = &[$($triple),*]; </del> <ins> const TARGETS: &[&str] = &[$($($triple),+),+]; </ins> fn load_specific(target: &str) -> Result<Target, LoadTargetError> { match target { $( <del> $triple => { </del> <ins> $($triple)|+ => { </ins> let mut t = $module::target() .map_err(LoadTargetError::Other)?; t.options.is_builtin = true;

Discussion:
There are actually two different generally expected encodings of the host tuple and they're subtly different than what some might expect. For example, 'x8664-sun-solaris' should probably be x8664-pc-solaris. The reason for that is that the encoding schemes are actually: So while 'sparcv9-sun-solaris' is correct because Sun is the (historical) manufacturer of sparc CPUs, 'x8664-sun-solaris' is not, because the MANUFACTURER here is the manufacturer of the CPU not the operating system. There are special cases for this, for example 'x8664-apple-darwin', even though Apple doesn't make x8664 CPUs, but following gcc/clang conventions leads us to x8664-pc-solaris. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
/cc /cc
An interesting discrepancy here is that our target and the LLVM target currently don't match. I'm not sure whether we can/should change anything here for backwards compatibility reasons, though an alias seems fine.
Hi, can I take this issue up? Can someone give a hint on how to fix this? I am a rust beginner, interested in compilers. This would be my first contribution.
as far as I can tell, you should just be able to add a new line under: containing , and then add a new line under: containing: (Sorry for the delay: I only just saw your message.)
claim
I wonder how it's supposed to work? Only x86_64-sun-solaris continues work for me: This change make it harder for Mozilla Firefox to decide which target to use...
I think we may have to introduce some changes in to make rustc try to use the alias. I.e. should try to use the target . I haven't had time to look into what else needs to be changed.
Closing as a duplicate of
Change:
/// # Examples /// /// ``` <del> /// #![feature(cmp_min_max_by)] /// </del> /// use std::cmp; /// /// assert_eq!(cmp::max_by(-2, 1, |x: &i32, y: &i32| x.abs().cmp(&y.abs())), -2);

Discussion:
Tracking issue for the feature, which adds the / / / functions to . PR:
Is there anything blocking this from stabilizing?
Doesn't look like it! If somebody would like to open a stabilization PR then we can start a FCP
Stabilization PR up at
Change:
} } <del> for (name, &item) in WEAK_ITEMS_REFS.iter() { </del> <ins> for (name, item) in WEAK_ITEMS_REFS.clone().into_sorted_vector().into_iter() { </ins> if missing.contains(&item) && required(tcx, item) && items.require(item).is_err() { if item == LangItem::PanicImpl { tcx.sess.err("`#[panic_handler]` function required, but not found");

Discussion:
Since a few weeks we are getting an unrelated failure in a ui test where the order of two diagnostics changes. It is not entirely random, since it only changes if there are compiler changes, but we should still find and fix it <details<summary<iClick to see the possible cause of the failure (guessed by this bot)</i</summary</detailsOriginally posted by in
The first time I've seen it was in The second time in
This happened to me in too.
This could be happening because , declared here: is being traversed here: and thus we get non-determinism in the output... Two obvious solutions: change to a sorted map structure in the declaration, or normalize the order before traversing in the loop in
cc
Change:
bump(rdr); } return with_str_from(rdr, start, |lifetime_name| { <del> token::LIFETIME(str_to_ident(lifetime_name)) </del> <ins> let ident = str_to_ident(lifetime_name); let tok = &token::IDENT(ident, false); if token::is_any_keyword(tok) && !token::is_keyword(token::keywords::Static, tok) && !token::is_keyword(token::keywords::Self, tok) { fatal_span(rdr, start, rdr.last_pos, ~"invalid lifetime name"); } token::LIFETIME(ident) </ins> }) }

Discussion:
e.g. is currently valid, but shouldn't be. (Note that is, and should remain, a valid lifetime.)
Note that this will only be possible after a snapshot, since the snapshot compiler currently requires lifetimes called . (Tagged easy although asking for some guidance in IRC may be useful since the parser isn't exactly easy to navigate.)
Why do we need to disallow this?
Consistency, maybe? ( suggested it.)
motivation was both consistency and to allow for possible future special uses. In particular I think could possibly be put to better use in the future.
Change:
assert!(layout.fields.count() > 0); trace!("DST layout: {:?}", layout); <del> let sized_size = layout.fields.offset(layout.fields.count() - 1); </del> <ins> let unsized_offset_unadjusted = layout.fields.offset(layout.fields.count() - 1); </ins> let sized_align = layout.align.abi; <del> trace!( "DST {} statically sized prefix size: {:?} align: {:?}", layout.ty, sized_size, sized_align ); </del> // Recurse to get the size of the dynamically sized field (must be // the last field). Can't have foreign types here, how would we

Discussion:
Execute with Miri: The problem is that and do not take the reduced field alignment into account and calculate the offset as-if the standard alignment was in place.
The labels are incorrect. Neither does this require nightly, nor is it related to const-eval. This is I-unsound on stable.
label I-prioritize (Looks like can't set .)
Error: Label can only be set by Rust team members Please let know if you're having trouble with this bot.
Error: Parsing relabel command in failed: ...'const-eval' ' "I-unsoun'... Please let know if you're having trouble with this bot.
Assigning as discussed as part of the and removing .
label -I-prioritize +P-medium
labels -T-types Discussed in types team on-site -- we think this is a MIR building bug, in any case, not part of T-types. Throwing hot back to compiler team.
It was actually a bug in the codegen backend, introduced when support for was -- the existing code has logic that assumed "if it is packed then alignment is 1", and that was never re-visited.
Ah, scratch that -- there was a different related bug (the sizeofval / alignofval computation for packed structs with tail was wrong), caused by what I said above. This here was caused by the codegen backend just never considering packed types when computing the offset of the unsized field. Almost always this happened to work since the unsized field is a slice/str and so its alignment (and therefore its offset) is dynamically known, but when dyn trait tails are involved this starts to go wrong. This got fixed by ; will add a test.
Change:
LL +     _a += 1; | <del> error: aborting due to 22 previous errors </del> <ins> error: unnecessary parentheses around pattern --> $DIR/lint-unnecessary-parens.rs:87:8 | LL |     let(mut _a) = 3; |        ^      ^ | help: remove these parentheses | LL -     let(mut _a) = 3; LL +     let mut _a = 3; | error: unnecessary parentheses around pattern --> $DIR/lint-unnecessary-parens.rs:88:9 | LL |     let (mut _a) = 3; |         ^      ^ | help: remove these parentheses | LL -     let (mut _a) = 3; LL +     let mut _a = 3; | error: unnecessary parentheses around pattern --> $DIR/lint-unnecessary-parens.rs:89:8 | LL |     let( mut _a) = 3; |        ^^      ^ | help: remove these parentheses | LL -     let( mut _a) = 3; LL +     let mut _a = 3; | error: unnecessary parentheses around pattern --> $DIR/lint-unnecessary-parens.rs:91:8 | LL |     let(_a) = 3; |        ^  ^ | help: remove these parentheses | LL -     let(_a) = 3; LL +     let _a = 3; | error: unnecessary parentheses around pattern --> $DIR/lint-unnecessary-parens.rs:92:9 | LL |     let (_a) = 3; |         ^  ^ | help: remove these parentheses | LL -     let (_a) = 3; LL +     let _a = 3; | error: unnecessary parentheses around pattern --> $DIR/lint-unnecessary-parens.rs:93:8 | LL |     let( _a) = 3; |        ^^  ^ | help: remove these parentheses | LL -     let( _a) = 3; LL +     let _a = 3; | error: aborting due to 28 previous errors </ins>

Discussion:
Rustc suggests incorrect fixes for #[warn(unusedparens)] for these patterns. No response Rustc version: (the same issue with the stable 1.73.0 rustc). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim