jiebi/CodeConvo huggingface dataset:
Change:
Yuck.
Nominating for the feature complete milestone.
rustdoc_ng doesn't look into extern blocks. Should it?
cc
Renaming bug with a more appropriate title now that rustdocng is generating docs. The old title was: "rustdoc thinks that extern blocks are modules named foreignmod"

Discussion:
use syntax; use syntax::ast; use syntax::ast_util; <ins> use syntax::attr; </ins> use syntax::attr::AttributeMethods; use std;

} } <ins> // This is a rough approximation that gets us what we want. impl<'self> attr::AttrMetaMethods for &'self Attribute { fn name(&self) -> @str { match **self { Word(ref n) | List(ref n, _) | NameValue(ref n, _) => n.to_managed() } } fn value_str(&self) -> Option<@str> { match **self { NameValue(_, ref v) => Some(v.to_managed()), _ => None, } } fn meta_item_list<'a>(&'a self) -> Option<&'a [@ast::MetaItem]> { None } fn name_str_pair(&self) -> Option<(@str, @str)> { None } } </ins> #[deriving(Clone, Encodable, Decodable)] pub struct TyParam { name: ~str,

use extra::sort; use syntax::ast; <ins> use syntax::attr; </ins> use clean; use doctree;

impl<'self> fmt::Default for Item<'self> { fn fmt(it: &Item<'self>, fmt: &mut fmt::Formatter) { <ins> match attr::find_stability(it.item.attrs.iter()) { Some(stability) => { write!(fmt.buf, "<a class='stability {lvl}' title='{reason}'>{lvl}</a>", lvl = stability.level.to_str(), reason = match stability.text { Some(s) => s, None => @"", }); } None => {} } </ins> // Write the breadcrumb trail header for the top write!(fmt.buf, "<h1 class='fqn'>"); match it.item.inner {

float: left; padding: 20px; } <ins> .stability { border-left: 5px solid #000; border-radius: 3px; padding: 0 3px; float: right; background: #fff; text-transform: lowercase; } .stability.Deprecated { border-color: #D60027; color: #880017; } .stability.Experimental { border-color: #EC5315; color: #a53c0e; } .stability.Unstable { border-color: #FFD700; color: #b39800; } .stability.Stable { border-color: #AEC516; color: #7c8b10; } .stability.Frozen { border-color: #009431; color: #007726; } .stability.Locked { border-color: #0084B6; color: #00668c; } </ins>

} /// The available stability levels. <del> #[deriving(Eq,Ord,Clone)] </del> <ins> #[deriving(Eq,Ord,Clone,ToStr)] </ins> pub enum StabilityLevel { Deprecated, Experimental,
Change:
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:

Discussion:
# 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

cfg.define("COMPILER_RT_HAS_UNAME", Some("1")); } <ins> // Assume that the Unixes we are building this for have fnctl() available if env::var_os("CARGO_CFG_UNIX").is_some() { cfg.define("COMPILER_RT_HAS_FCNTL_LCK", Some("1")); } // This should be a pretty good heuristic for when to set // COMPILER_RT_HAS_ATOMICS if env::var_os("CARGO_CFG_TARGET_HAS_ATOMIC").map(|features| { features.to_string_lossy().to_lowercase().contains("cas") }).unwrap_or(false) { cfg.define("COMPILER_RT_HAS_ATOMICS", Some("1")); } </ins> // The source for `compiler-rt` comes from the `compiler-builtins` crate, so // load our env var set by cargo to find the source code. let root = env::var_os("DEP_COMPILER_RT_COMPILER_RT").unwrap();
Change:
Reading both and there's no specification that the type for the iterator is . To me it seemed ambiguous what an "iterator that splits an environment variable into paths" or "an iterator over the paths" returns since it could be the string representing the paths -- which is -- or an actual object. I'm happy to submit a PR if this is makes sense enough to fix (since according it used to specify this detail and now it doesn't with a quick perusal of not turning up anything obvious as to why the change).
If you unfold at the Trait Implementation section in you can see that . Did you mean that this should be more clearly mentioned in the description of (or maybe as well)? I do think it would be nice if some extra text on would be that clarifies the item type of the iterator!
since I didn't even think of expanding for the info (which in hindsight makes sense), my answer is "yes" , mentioning it explicitly as part of the main summary would be handy". As I said, if this is deemed reasonable I'm happy to do the PR to add the change.
That would be great! Let us know what you come up with!
Looks like someone snagged fixing this before I had a chance to get to it, so I'll let and its author handle fixing this.
Nice :) Let's wait for that then :)

Discussion:
/// An iterator that splits an environment variable into paths according to /// platform-specific conventions. /// <ins> /// The iterator element type is [`PathBuf`]. /// </ins> /// This structure is created by the [`std::env::split_paths`] function. See its /// documentation for more. /// <ins> /// [`PathBuf`]: ../../std/path/struct.PathBuf.html </ins> /// [`std::env::split_paths`]: fn.split_paths.html #[stable(feature = "env", since = "1.0.0")] pub struct SplitPaths<'a> { inner: os_imp::SplitPaths<'a> }

/// Parses input according to platform conventions for the `PATH` /// environment variable. /// <del> /// Returns an iterator over the paths contained in `unparsed`. </del> <ins> /// Returns an iterator over the paths contained in `unparsed`. The iterator /// element type is [`PathBuf`]. </ins> /// /// # Examples ///

///     None => println!("{} is not defined in the environment.", key) /// } /// ``` <ins> /// /// [`PathBuf`]: ../../std/path/struct.PathBuf.html </ins> #[stable(feature = "env", since = "1.0.0")] pub fn split_paths<T: AsRef<OsStr> + ?Sized>(unparsed: &T) -> SplitPaths<'_> { SplitPaths { inner: os_imp::split_paths(unparsed.as_ref()) }
Change:
The documentation for  mentions two ways that it can affect a program: can enable the compiler to make optimizations based on the assumption that the function will never be executed. the function actually is executed, its behavior is undefined. It then goes on to mention the macro, saying This statement could be read as addressing the 2nd effect, but not the 1st. In other words, it could be interpreted as saying "the compiler will assume that will never be executed, but in the event that it is it will cause a panic." It might be worth rewording this statement to make it clear that neither (1) nor (2) applies to the safe version.
Would you like to rephrase this yourself, or would you like me to take an attempt?

Discussion:
/// difficult-to-debug problems. /// /// Use this function only when you can prove that the code will never call it. <ins> /// Otherwise, consider using the [`unreachable!`] macro, which does not allow /// optimizations but will panic when executed. </ins> /// <del> /// The [`unreachable!()`] macro is the safe counterpart of this function, which /// will panic instead when executed. /// /// [`unreachable!()`]: ../macro.unreachable.html </del> <ins> /// [`unreachable!`]: ../macro.unreachable.html </ins> /// /// # Example ///
Change:
I've got a Rust minimal repro code (a.rs), its mir output (a.mir), its x86 codegen output () and its gnu-x32 codegen output () All these files are in this this . Currently, fails, saying "llvm error cannot emit physreg copy instruction". I don't understand llvm ir at all myself, but i tried commenting out L309, L311 & L314 out (all accessing a special 'variable?' called 'unsizedtmp') and it passes, then i uncomment L309 and llc fails again. This issue is blocking . Maybe or someone else who's familiar with could have a look or give me a hint about this?
Forgot to mention: I generated these files with to make the files shorter, but that's unimportant detail, i guess.
If you haven't yet, you might try using  to minimize the ll to a smaller reproducer.
Using bugpoint, i got this(I used llvm-dis to convert it to text):
Looks like it can't deal with the "probe-stack" attribute: removing that makes it work. My guess is the probe stack code doesn't do well with gnux32 targets which is 64bit but has 32bit pointers. The LLVM debug log re: why it fails:
Speaking of stack probing, I guess might know more about this?
To unblock things, I think it is reasonable to delete line in file while we investigate the issue. Stack probes are x86-only feature that is disabled on other architectures anyway.
I guess LLVM needs a upstream fix for stack probing on x32 (it probably emits code using 64-bit registers). We may also want a x32 specific stack probe function in
I've pushed as the temporary workaround.
Filed: LLVM: compiler-builtins:
Fixed upstream by I believe a separate stack probing function for x32 is not necessary, the one for x86_64 should work fine.
The LLVM fix is now in nightly, so we can try re-enabling this again.

Discussion:
base.cpu = "x86-64".to_string(); base.max_atomic_width = Some(64); base.pre_link_args.get_mut(&LinkerFlavor::Gcc).unwrap().push("-mx32".to_string()); <del> // BUG: temporarily workaround #59674 base.stack_probes = false; </del> <ins> base.stack_probes = true; </ins> base.has_elf_tls = false; // BUG(GabrielMajeri): disabling the PLT on x86_64 Linux with x32 ABI // breaks code gen. See LLVM bug 36743
Change:
After a simple , I tried to generate the crate documentation. I really don't know why I get this error. The problem seems to be here but what's wrong? ^^' The source is on glitch: !/nom- Feel free to ping me if you need to ask me more!
Is this a fluke or is your drive actually full? Is it a regular drive or a network share?
Oops! I didn't see the error message. My fork is stored on Glitch, it's a virtual drive I guess. I must have reached the storage limit authorized by Glitch. edit: ahah, that's it! !
That's not very nice as output... I'll write something a bit better.
As you requested here's the backtrace:
This ICE was changed into a proper error message by . This issue can be closed as a duplicate of .
Ok, thanks! I'll close it!

Discussion:
/// static HTML tree. Each component in the cleaned path will be passed as an /// argument to `f`. The very last component of the path (ie the file name) will /// be passed to `f` if `keep_filename` is true, and ignored otherwise. <del> fn clean_srcpath<F>(src_root: &Path, p: &Path, keep_filename: bool, mut f: F) where </del> <ins> fn clean_srcpath<F>(src_root: &Path, p: &Path, keep_filename: bool, mut f: F) where </ins> F: FnMut(&OsStr), { // make it relative, if possible

let mut href = String::new(); clean_srcpath(&self.scx.src_root, &p, false, |component| { cur.push(component); <del> fs::create_dir_all(&cur).unwrap(); </del> root_path.push_str("../"); href.push_str(&component.to_string_lossy()); href.push('/'); }); <ins> fs::create_dir_all(&cur)?; </ins> let mut fname = p.file_name() .expect("source has no filename") .to_os_string();

href.push_str(&fname.to_string_lossy()); let mut w = BufWriter::new(File::create(&cur)?); <del> let title = format!("{} -- source", cur.file_name().unwrap() </del> <ins> let title = format!("{} -- source", cur.file_name().expect("failed to get file name") </ins> .to_string_lossy()); let desc = format!("Source to the Rust file `{}`.", filename); let page = layout::Page {
Change:
It would be nice if the compiler suggested the intended form: as this seems like a reasonable mistake. This is specific to a particular macro, though, so I'm not sure how flexible we can be with diagnostics here.
Or we could just make the macro accept ...

Discussion:
/// You can also use `dbg!()` without a value to just print the /// file and line whenever it's reached. /// <ins> /// Finally, if you want to `dbg!(..)` multiple values, it will treat them as /// a tuple (and return it, too): /// /// ``` /// assert_eq!(dbg!(1usize, 2u32), (1, 2)); /// ``` /// /// However, a single argument with a trailing comma will still not be treated /// as a tuple, following the convention of ignoring trailing commas in macro /// invocations. You can use a 1-tuple directly if you need one: /// /// ``` /// assert_eq!(1, dbg!(1u32,)); // trailing comma ignored /// assert_eq!((1,), dbg!((1u32,))); // 1-tuple /// ``` /// </ins> /// [stderr]: https://en.wikipedia.org/wiki/Standard_streams#Standard_error_(stderr) /// [`debug!`]: https://docs.rs/log/*/log/macro.debug.html /// [`log`]: https://crates.io/crates/log

tmp } } <del> } </del> <ins> }; // Trailing comma with single argument is ignored ($val:expr,) => { dbg!($val) }; ($($val:expr),+ $(,)?) => { ($(dbg!($val)),+,) }; </ins> } /// Awaits the completion of an async call.

7331 })); assert_eq!(foo, 42); <ins> // Test trailing comma: assert_eq!(("Yeah",), dbg!(("Yeah",))); // Test multiple arguments: assert_eq!((1u8, 2u32), dbg!(1, 2)); // Test multiple arguments + trailing comma: assert_eq!((1u8, 2u32, "Yeah"), dbg!(1u8, 2u32, "Yeah",)); </ins> } fn validate_stderr(stderr: Vec<String>) {

"before", ":51] { foo += 1; eprintln!("before"); 7331 } = 7331", <ins> ":59] ("Yeah",) = (", "    "Yeah",", ")", ":62] 1 = 1", ":62] 2 = 2", ":66] 1u8 = 1", ":66] 2u32 = 2", ":66] "Yeah" = "Yeah"", </ins> ]); }
Change:
(which is equivalent to GCC's mcmodel=medany). I believe that this means that it is now possible to cherry pick the relevant commits and expose support from Rust. See also: rust-embedded/wg/issues/218
great ! would be useful for me as well: Kendryte K210 expects code to run from fixed address , so medlow relocations get truncated
Greetings from Oxidize! It'd be great if someone could bump LLVM, so we can start adding support for Linux/RV64 targets. It was suggested might be the person to ping about this. Is there a specific LLVM version you would recommend? I assume we want at least , but I imagine there may be other upstream fixes that are needed. Thanks! CCing
Rust can already target bare metal Rv64 (with the riscv64imac-unknown-none-elf target). What is missing is the ability to place the code/symbols at locations outside the range [-2GB, 2GB]. That isn't too much of an issue for writing supervisor mode code which can just configure the MMU to map those addresses to point to RAM, but machine mode can't pick the memory layout of the board it runs on. You actually can get away with having code outside this range as long as there aren't any indirect jumps or static variables there. It is very restrictive and inconvenient, but you might be able to get away with it for a small amount of code.
I also really want these patches to be merged. I've already tried to merge upstream branch as well as to deduce a cherry-pick-able set of commits but failed in both cases. Because of that, I can't tell whether these patches will fix the issue or not. At the moment I'm stuck waiting for help. I'm ready to give it another try, but I need some guidance. Maybe or could help me?
There's instructions/rationale about updating LLVM hosted at https://rust- Instructions are slightly out of date but I'll send a PR to fix them.
(Current status) This patch arrived in LLVM: Now LLVM is able to generate pc-relative address load instructions for global variables and functions.

Discussion:
executables: true, panic_strategy: PanicStrategy::Abort, relocation_model: "static".to_string(), <ins> code_model: Some("medium".to_string()), </ins> emit_debug_gdb_scripts: false, abi_blacklist: super::riscv_base::abi_blacklist(), eliminate_frame_pointer: false,

<del> Subproject commit 1bbe0b3e1d756116cbf1fcf049555066ef929008 </del> <ins> Subproject commit 8538d56b2dd450063547a7690f7ffa2ac37c9c65 </ins>
Change:
If a function takes it would be nice to pass it a (say, from pattern matching) without additional friction. implements this.
that could hide unnecessary clone
This is functionally identical to the existing impl. The clone would be necessary - if the receiving function needs to own the , and all you have is a , then someone has to do a clone. If it didn't need to own it then it could take (or ). And if you had a to pass in, then it would hit the no-op blanket impl.
Do you have an example why this is useful? coerces to so there is no need to implement this (also )
coerces to No it doesn't, but it to it. The specific case I had was: Currently the nicest way to handle this is , since there's a .
Okay, that's true. But you will have the same issue with , and . What about that?
To quote me:

Discussion:
} } <ins> #[stable(feature = "from_ref_string", since = "1.35.0")] impl From<&String> for String { #[inline] fn from(s: &String) -> String { s.clone() } } </ins> // note: test pulls in libstd, which causes errors here #[cfg(not(test))] #[stable(feature = "string_from_box", since = "1.18.0")]
Change:
The signed variants are not re-exported in here: We should duplicate that line and re-export them. cc -- this will likely slip into 1.34, but we will backport the fix into 1.35

Discussion:
#[stable(feature = "nonzero", since = "1.28.0")] pub use core::num::{NonZeroU8, NonZeroU16, NonZeroU32, NonZeroU64, NonZeroU128, NonZeroUsize}; <ins> #[stable(feature = "signed_nonzero", since = "1.34.0")] pub use core::num::{NonZeroI8, NonZeroI16, NonZeroI32, NonZeroI64, NonZeroI128, NonZeroIsize}; </ins> #[cfg(test)] use crate::fmt; #[cfg(test)] use crate::ops::{Add, Sub, Mul, Div, Rem};

| = help: the following implementations were found: <i32 as std::convert::From<bool>> <del> <i32 as std::convert::From<core::num::NonZeroI32>> </del> <i32 as std::convert::From<i16>> <i32 as std::convert::From<i8>> <ins> <i32 as std::convert::From<std::num::NonZeroI32>> </ins> and 2 others = note: required by `std::convert::From::from`
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri 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 prioritization.
Miri fix: I'd like to see landing before updating the submodule, as that will break Miri again.
This was automatically nominated by rust-highfive. Based on past discussion with about miri-prioritization, tagging as P-medium.

Discussion:
"compiletest_rs 0.3.21 (registry+https://github.com/rust-lang/crates.io-index)", "directories 1.0.2 (registry+https://github.com/rust-lang/crates.io-index)", "env_logger 0.6.0 (registry+https://github.com/rust-lang/crates.io-index)", <ins> "hex 0.3.2 (registry+https://github.com/rust-lang/crates.io-index)", </ins> "log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)", <ins> "rand 0.6.1 (registry+https://github.com/rust-lang/crates.io-index)", </ins> "rustc-workspace-hack 1.0.0", "rustc_version 0.2.3 (registry+https://github.com/rust-lang/crates.io-index)", "shell-escape 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)",

<del> Subproject commit 28f2e5b17a9a4c33a810dffda8eaaf55a1b8b70d </del> <ins> Subproject commit 7c06679f93df53f83bbf61b197f2e5c39f5d7633 </ins>
Change:
crashes with an illegal instruction, presumably because all the code after is considered unreachable: It seems the root cause is that the struct representing the future contains a field of type as it is preserved across the (unreachable) yield point and thus is considered uninhabited itself, despite being perfectly constructible.
This sounds like it is caused by the fact that generators have an "incorrect" layout (claiming to have fields with certain types when really these might not be initialized), and some code not taking that special case into account properly. Cc
cc
This is actually already fixed in (currently a WIP), . I'll make sure to add this as a test to that PR!
does that mean that generators will no longer "cheat" in their layout, and can be removed? That'd be cool :D I'd also have to adjust -- can that be treated like any other type then because the variants have all the right information?
I don't think it's that simple, we'd likely still need to keep uninitialized variables for now. Although... I suppose the state variants, for yields across which they're not live, could just omit those variables, despite not using that space for anything else.
We could do that, yes, with some further changes to my PR. I would like to get there, and then we can have UB checking for our generators as well :)
triage: P-high. removing nominated tag.
Reopening for the test that didn't add (as far as I can tell; cc &

Discussion:
<ins> // compile-flags: --edition=2018 #![feature(async_await, await_macro)] pub enum Uninhabited { } fn uninhabited_async() -> Uninhabited { unreachable!() } async fn noop() { } #[allow(unused)] async fn contains_never() { let error = uninhabited_async(); await!(noop()); let error2 = error; } #[allow(unused_must_use)] fn main() { contains_never(); } </ins>
Change:
When a trait alias to a trait with a method with the same name as a method on a struct is in scope, rustc is suddenly unable to disambiguate the trait method from the struct method.
cc
cc and -- Is importing the trait with higher priority than inherent items?
Is importing the trait with higher priority than inherent items? It shouldn't do that, looks like a bug. A method introduced into scope via trait alias (import) should behave identically to methods introduced with a trait (import), that means lower priority than inherent items.

Discussion:
fn assemble_inherent_candidates_from_param(&mut self, param_ty: ty::ParamTy) { // FIXME: do we want to commit to this behavior for param bounds? <ins> debug!("assemble_inherent_candidates_from_param(param_ty={:?})", param_ty); </ins> let bounds = self.param_env.caller_bounds.iter().filter_map(|predicate| match *predicate { ty::Predicate::Trait(ref trait_predicate, _) => {

import_ids: import_ids.clone(), kind: TraitCandidate(new_trait_ref), }, <del> true, </del> <ins> false, </ins> ); }); } else {

<ins> // check-pass #![feature(trait_alias)] trait SomeTrait { fn map(&self) {} } impl<T> SomeTrait for Option<T> {} trait SomeAlias = SomeTrait; fn main() { let x = Some(123); // This should resolve to the trait impl for Option Option::map(x, |z| z); // This should resolve to the trait impl for SomeTrait SomeTrait::map(&x); } </ins>

<ins> // check-pass #![feature(trait_alias)] trait Bounded { const MAX: Self; } impl Bounded for u32 { // This should correctly resolve to the associated const in the inherent impl of u32. const MAX: Self = u32::MAX; } trait Num = Bounded + Copy; fn main() {} </ins>
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri 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 prioritization.
Broken by
Miri fix:
triage: miri breakage gets P-medium.

Discussion:
<del> Subproject commit 7c06679f93df53f83bbf61b197f2e5c39f5d7633 </del> <ins> Subproject commit ae9e9cb47c7b79d8bb29fab90929bd9b3606348a </ins>