jiebi/CodeConvo huggingface dataset:
Change:
} } <del> #[derive(PartialEq, Eq)] </del> <ins> #[derive(Debug, PartialEq, Eq)] </ins> pub enum StringPart { Normal(String), Highlighted(String),

Discussion:
On E0308 type mismatch errors we already perform a basic check to type arguments in order to only highlight differences between the expected and found type. I recently came across a case where the two types had identifiers of the same length with no type arguments, but that were not local so the path was quite long. It took me some time to realize that the two types were actually different and not caused by different crate versions. It'd be nice if for the following, only the parts of the path that differ were highlighted/bolded in the CLI output: CC
Hello, I'd like to implement this feature.
Hi Will you be needing a hand? To begin with, I would recommend searching for in order to find how it works today. Particularly, shows how the highlighting for specific type arguments is currently handled. It is extremely verbose, but the comments should help somewhat. Also, the is a good primer on how to develop in the compiler's codebase. If you need a hand, don't hesitate to reach out.
Thanks, I'd found that struct and file, but I'd overlooked that method due to how complicated it seemed at a glance.
Should I add a test for this? If so, how would I implement that? The standard UI testing method doesn't seem to track highlights.
sadly, we do not have any way to test correct application of colors in the test suite. Attach screenshots to the PR so that we can see the changes, but we have to rely on being extra careful when touching this part of the codebase.
Change:
<ins> error[E0277]: `Cell<i32>` cannot be shared between threads safely --> $DIR/reentrantlockguard-sync.rs:13:15 | LL |     test_sync(guard); |     --------- ^^^^^ `Cell<i32>` cannot be shared between threads safely |     | |     required by a bound introduced by this call | = help: the trait `Sync` is not implemented for `Cell<i32>`, which is required by `ReentrantLockGuard<'_, Cell<i32>>: Sync` = note: if you want to do aliasing and mutation between multiple threads, use `std::sync::RwLock` or `std::sync::atomic::AtomicI32` instead = note: required for `ReentrantLockGuard<'_, Cell<i32>>` to implement `Sync` note: required by a bound in `test_sync` --> $DIR/reentrantlockguard-sync.rs:7:17 | LL | fn test_sync<T: Sync>(_t: T) {} |                 ^^^^ required by this bound in `test_sync` error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
I tried running this code in miri: I expected to see this happen: compile error Instead, this happened: compiled successfully and miri reported a data race this is because the automatic is incorrect: 'a,+T%3E ReentrantLock's tracking issue:
label I-unsound
label requires-nightly
Change:
self.parent_map.get(&id).cloned().map(|(p, _)| p) } <del> /// Returns the lifetime of the local variable `var_id` pub fn var_scope(&self, var_id: hir::ItemLocalId) -> Scope { self.var_map .get(&var_id) .cloned() .unwrap_or_else(|| bug!("no enclosing scope for id {:?}", var_id)) </del> <ins> /// Returns the lifetime of the local variable `var_id`, if any. pub fn var_scope(&self, var_id: hir::ItemLocalId) -> Option<Scope> { self.var_map.get(&var_id).cloned() </ins> } /// Returns the scope when the temp created by `expr_id` will be cleaned up.

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. --<!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I was just looking at the parsing code for const generic exprs.. claim
actually, so this isn't related to incorrectly parsing , since we're parsing in expr position to allow if-let chains.. -- this is due to const eval lowering to MIR and the fact that const generic parameters have no enclosing scope. Adding around the generic args works, but I don't know where exactly to hack in a scope for these params. release-assignment label A-const-eval A-mir
Maybe fixing this also fixes :slightlysmilingface:
This gives an error without ICE in 1.55
It was unclear to me - I think meant that changing to gives a compile error instead of an ICE. So the proper fix here is probably to add somewhere instead of panicking.
Then this should be easy. claim
Change:
# Note that the LLVM installer is an NSIS installer # # Original downloaded here came from <del> # http://releases.llvm.org/7.0.0/LLVM-7.0.0-win64.exe - if NOT defined MINGW_URL appveyor-retry appveyor DownloadFile https://s3-us-west-1.amazonaws.com/rust-lang-ci2/rust-ci-mirror/LLVM-7.0.0-win64.exe - if NOT defined MINGW_URL .LLVM-7.0.0-win64.exe /S /NCRC /D=C:clang-rust </del> <ins> # http://releases.llvm.org/8.0.0/LLVM-8.0.0-win64.exe - if NOT defined MINGW_URL appveyor-retry appveyor DownloadFile https://s3-us-west-1.amazonaws.com/rust-lang-ci2/rust-ci-mirror/LLVM-8.0.0-win64.exe - if NOT defined MINGW_URL .LLVM-8.0.0-win64.exe /S /NCRC /D=C:clang-rust </ins> - if NOT defined MINGW_URL set RUST_CONFIGURE_ARGS=%RUST_CONFIGURE_ARGS% --set llvm.clang-cl=C:clang-rustbinclang-cl.exe # Here we do a pretty heinous thing which is to mangle the MinGW installation

Discussion:
For example and are not being set. Would it be possible to use (i.e. compiler-rt's regular build system) to find out which flags to set? cc
I wonder if I can somehow use for detecting whether to set the flags. I guess that executing this in the build script would only tell me about the host platform, right? Is there a way to query 's target platform spec?
If you execute Cargo will use that to set env vars for the build script. When a build script is executed the env vars match the target we're executing the script for, so Cargo should set (IIRC). Either that should be fine or just simply enabling it via a whitelist of platforms would be fine by me personally
Indeed: :heart:
Change:
emit_table(f, "to_uppercase_table", sorted(to_upper.iteritems(), key=operator.itemgetter(0)), is_pub=False, t_type = t_type, pfun=pfun) <del> emit_table(f, "to_titlecase_table", sorted(to_title.iteritems(), key=operator.itemgetter(0)), is_pub=False, t_type = t_type, pfun=pfun) </del> f.write("}nn") def emit_grapheme_module(f, grapheme_table, grapheme_cats):

Discussion:
Converting a string to titlecase requires a word-breaking algorithm, which std does not provide. We do have the method for converting a single char to titlecase, if one can identify the first char of a word. This method requires a few kb of lookup tables. We might want to consider whether its wise to ship one without the other. This is marked for stabilization in 1.2 so we need to decide soon. cc
so I'm fine just deleting it, I don't think it's marked to be stable.
Change:
See also `--test`. <ins> ## `--test-run-directory`: run code examples in a specific directory Using this flag looks like this: ```bash $ rustdoc src/lib.rs --test --test-run-directory=/path/to/working/directory ``` This flag will run your code examples in the specified working directory. For more, see [the chapter on documentation tests](write-documentation/documentation-tests.md). See also `--test`. </ins> ## `--target`: generate documentation for the specified target triple Using this flag looks like this:

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:
let asm_ty = match *ty.kind() { // `!` is allowed for input but not for output (issue #87802) ty::Never if is_input => return None, <del> ty::Error(_) => return None, </del> <ins> _ if ty.references_error() => return None, </ins> ty::Int(IntTy::I8) | ty::Uint(UintTy::U8) => Some(InlineAsmType::I8), ty::Int(IntTy::I16) | ty::Uint(UintTy::U16) => Some(InlineAsmType::I16), ty::Int(IntTy::I32) | ty::Uint(UintTy::U32) => Some(InlineAsmType::I32),

Discussion:
No response No response Happens on , as well as several earlier versions. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Just needs someone to this error if the type , I think.
assign
Error: Parsing assign command in failed: ...' assign' ''... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
claim
claim
Hi! I have given a brief introduction of myself in the . With that said, I have potentially setup the necessary pre-requisites and compiler infrastructure in my local machine, also re confirmed by using the and other build commands which seem to work. As per the , I have the all the toolchains command executed (for [0-2]). Like any other contribution, I figured that in repo, are tagged as for new-comers, and to start, I have chosen this issue. Until now, I have found the following which I presume is targeting the output: Would be great if one could point out any points I may have missed out! A head start would be great!
claim
Change:
= note: each usage of a `const` item creates a new temporary = note: the mutable reference will refer to this temporary, not the original `const` item note: mutable reference created due to call to this method <del> --> $DIR/lint-const-item-mutation.rs:8:5 </del> <ins> --> $DIR/lint-const-item-mutation.rs:9:5 </ins> | LL |     fn use_mut(&mut self) {} |     ^^^^^^^^^^^^^^^^^^^^^ note: `const` item defined here <del> --> $DIR/lint-const-item-mutation.rs:12:1 </del> <ins> --> $DIR/lint-const-item-mutation.rs:13:1 </ins> | <del> LL | const MY_STRUCT: MyStruct = MyStruct { field: true, inner_array: ['a'] }; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ </del> <ins> LL | const MY_STRUCT: MyStruct = MyStruct { field: true, inner_array: ['a'], raw_ptr: 2 as *mut u8 }; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ </ins> warning: taking a mutable reference to a `const` item <del> --> $DIR/lint-const-item-mutation.rs:19:5 </del> <ins> --> $DIR/lint-const-item-mutation.rs:21:5 </ins> | LL |     &mut MY_STRUCT; |     ^^^^^^^^^^^^^^

Discussion:
<!-- 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 have quite a lot of MMIO in an embedded project, defined and used like this: (see a ) When I , I'm getting a whole host of warnings of the type: I expect no warnings, because I'm not assigning to a , I'm assigning to a dereferenced , aka a mutable u32. I couldn't figure out a playground example that would show the value actually mutating, but by hitting hardware registers I can prove that the value does get mutated, and it makes sense that it would: The pointer is , but it's pointing to a able . Dereferencing shouldn't care whether the pointer variable is . <!-- 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. --: No backtrace for this bug; it's a warning.
There's a... fine, I guess, workaround of in my case, since all the MMIO code is bundled into a module away from the rest.
cc
This will be fixed by
Awesome, thanks so much!
Change:
let param = self.param_at(param.index as usize, tcx); match param.kind { GenericParamDefKind::Type { .. } => param, <del> _ => bug!("expected type parameter, but found another generic parameter"), </del> <ins> _ => bug!("expected type parameter, but found another generic parameter: {param:#?}"), </ins> } }

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: expected lifetime parameter, but found another generic parameter', 'error: internal compiler error: expected lifetime parameter, but found another generic parameter' 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: [collectreturnpositionimpltraitintraittys] comparing an impl and trait method signature, inferring any hidden types in the process [typeof] computing type of --
cc
Change:
Ok(true) } <del> fn range_covered_by_constructor(tcx: TyCtxt, span: Span, </del> <ins> fn constructor_covered_by_range(tcx: TyCtxt, span: Span, </ins> ctor: &Constructor, from: &ConstVal, to: &ConstVal, end: RangeEnd)

Discussion:
With rust nightly compiler, the result on the screen is even though the compiler warning that 11 case is unreachable. Link to rust playground:
Change:
use sys_common::condvar as sys; use sys_common::mutex as sys_mutex; use sys_common::poison::{self, LockResult}; <del> use time::Duration; </del> <ins> use time::{Duration, Instant}; </ins> /// A type indicating whether a timed wait on a condition variable returned /// due to a time out or not.

Discussion:
Yes, another incarnation of . and also have this issue. Note that is an error and has a test for it. cc
Does this also date back to 1.0, like did?
Yes. The fix would be technically a breaking change.
Change:
|                     ^^---- |                     | |                     expected `{` <del> |                     help: try placing this code inside a block: `{ 'b: { } }` </del> <ins> |                     help: try placing this code inside a block: `{ 'b: {} }` </ins> error: expected one of `.`, `?`, `{`, or an operator, found `'b` --> $DIR/label_break_value_illegal_uses.rs:18:17

Discussion:
I'm seeing the following error on the channel, but not on or : Found with the help of .
triage: P-medium. Leaving nominated so that team double-checks that priority assignment.
This is triggered here It should be possible to use the span snippet instead. I believe it was introduced in
Change:
--host-rustcflags "$(RUSTC_FLAGS_$(3)) $$(CTEST_RUSTC_FLAGS) -L $$(RT_OUTPUT_DIR_$(3))"  --lldb-python-dir=$(CFG_LLDB_PYTHON_DIR)  --target-rustcflags "$(RUSTC_FLAGS_$(2)) $$(CTEST_RUSTC_FLAGS) -L $$(RT_OUTPUT_DIR_$(2))"  <del> --cc '$$(CC_$(2))'  --cxx '$$(CXX_$(2))'  </del> <ins> --cc '$$(call FIND_COMPILER,$$(CC_$(2)))'  --cxx '$$(call FIND_COMPILER,$$(CXX_$(2)))'  </ins> --cflags "$$(CFG_GCCISH_CFLAGS_$(2))"  --llvm-components "$$(LLVM_ALL_COMPONENTS_$(2))"  --llvm-cxxflags "$$(LLVM_CXXFLAGS_$(2))" 

Discussion:
I'm building Rust with , it fails at the miniz step:
This is due to , specifically . The problem is that --enable-ccache exports and it's ambiguous whether that's a file name with a space in it or two arguments.
Change:
} else if (!hasClass(document.getElementById("help"), "hidden")) { addClass(document.getElementById("help"), "hidden"); removeClass(document.body, "blur"); <ins> } else { // Making a collapsed element visible on onhashchange seems // too late var a = findParentElement(ev.target, 'A'); if (a && a.hash) { expandSection(a.hash.replace(/^#/, '')); } </ins> } };

Discussion:
Stable documentation (e.g. ): Click on to collapse everything Click on in Page will be scrolled to the . Nightly documentation (e.g. ): Click on to collapse everything Click on in Nothing will happen, because the is inside a collapsed outer section.
Another example: Click the word in the description on the page Nothing happens, making it appear that the link is broken. Since trait impls are collapsed by default, AFAIK there is no way to properly link to them. I'm guessing this would need to be implemented in and , and check if the block is hidden?
Change:
}; search_input.onpaste = search_input.onchange; <del> var selectCrate = document.getElementById('crate-search'); </del> <ins> var selectCrate = document.getElementById("crate-search"); </ins> if (selectCrate) { selectCrate.onchange = function() { <ins> updateLocalStorage("rustdoc-saved-filter-crate", selectCrate.value); </ins> search(undefined, true); }; }

Discussion:
Right now it is allowed to select whether we want to search within all crates or in the specific ones (e.g. core, std, etc). It would be really useful to remember the selected option, because in most cases we want to search in the std crate only. cc
Good idea!
Does not work, neither in stable nor nightly. Go to Choose the "std" option. Type Option, click on it We still see the "All crates" on the , and if we try to search something else, results will be from all sources anyway.
Indeed, will take a look quickly.
Works perfectly now. Thanks!
Change:
// which is sound because we forbid impls like the following // // impl<D: Debug> AlwaysApplicable for D { } <del> let always_applicable_traits = impl1_predicates.iter().copied().filter(|&predicate| { </del> <ins> let always_applicable_traits = impl1_predicates.iter().copied().filter(|&(predicate, _)| { </ins> matches!( trait_predicate_kind(tcx, predicate), Some(TraitSpecializationKind::AlwaysApplicable)

Discussion:
<!-- 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: <!-- Please provide a link to -- The current output is: <!-- The following is not always necessary. --Ideally the output should not reference the debug format of an internal type <!-- 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. -- modify labels +F-specialization +A-specialization +requires-nightly
Change:
clean::ImplItem(..) => {} <del> // tymethods/macros have no control over privacy clean::MacroItem(..) | clean::TyMethodItem(..) => {} </del> <ins> // tymethods have no control over privacy clean::TyMethodItem(..) => {} </ins> // Proc-macros are always public clean::ProcMacroItem(..) => {}

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: is hidden from the documentation. Instead, this happened: is shown in the documentation and has its own page. Private declarative macros are also shown. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: rustc 1.56.0-nightly ( 2021-08-14) <!-- Provide the version you are using that has the regression. --: <!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-nightly-to-nightly -regression-untriaged +A-macros +A-visibility +T-rustdoc --
modify labels +requires-nightly
Thanks for filing this issue! This regression was almost certainly introduced in . I'm looking into it.
Assigning priority as in the prioritization working group. label: +P-high -I-prioritize
Thanks