Question:
The .exe installer tries to install to "C:Program Files (x86)Rust", even though it's the 64-bit version. It then fails to create the destination directory due to a permission error. The .msi installer correctly defaults to "C:Program FilesRust <channel<version", and has no problems with permissions, I would expect the .exe installer to have the same behaviour.
Rust should install to , just like Ant, Python, and many others. is the place for developer tools that have a known folder. is badly named (compare to ), poorly suited for command line tools, and clutters the already hideous PATH more than .
/cc
Neither Ant nor Python install to C:tools by default, and searching I can't find any reference to C:tools even being a thing? Both Python and Ant install to C:Python<Versionand C:ant, which is incredibly annoying, so please don't do that!
I might be mistaken, but installing both through stuck them in for me. I'd recommend anyone with a machine running Vista or later use chocolatey. And there's a trend in chocolatey to have packages extract to when they aren't self-contained enough for .
For an OS without much filesystem hierarchy, is a decent place for developer and command-line packages, similar to on some unices. But I'd much rather see a that actually obeyed chocolatey's conventions and extracted an archive to , with no installer/registry involvement. But Rust only and installers for windows. : And all packages that do this reduce PATH clutter, since chocolatey symlinks their executables into .
The idea was to deprecate the .exe installer once .msi is known to be working satisfactory.
Can we have a zip release too, that contains Rust and Cargo like the others? Linux and OS X have an archive release. Those are preferred in chocolatey because they don't involve the registry or any other Windows components.
We do produce tarballs for windows.
Seems like we should probably just stop producing the .exe's. That fix would go in
I don't see a cargo+rustc nightly tarball for windows, although I do see ones for linux and osx.
triage: We do not link to the .exe installer anymore, but we still produce them. I don't have access to windows at the moment to check if this bug has been resolved, but it's been a long time...
Grabbing the Windows download link from and swapping the for yields a functional link to the , which is nice. Testing on win7-x64, the MSI extracts with lessmsi, but the directory structure is somewhat unusual so there's no one-liner to get the Rust folder out. The best I came up with was: This yields a Rust install rooted at . However now that exists, multiple targets aren't really an issue anymore. Someone should make a Chocolatey package for
Can someone with access to Windows check what happens here today?
The latest version installs to instead, which works, but is a terrible default.
Triage: ! This seems... fine. I'm not sure if this should stay open or not; I'll let the relevant team (infra? compiler?) decide.

<del> // ---------------------------------------------------------------------------- // // Inno Setup Ver:	5.4.2 // Script Version:	1.4.1 // Author:			Jared Breland <jbreland@legroom.net> // Homepage:		http://www.legroom.net/software // License:			GNU Lesser General Public License (LGPL), version 3 //						http://www.gnu.org/licenses/lgpl.html // // Script Function: //	Allow modification of environmental path directly from Inno Setup installers // // Instructions: //	Copy modpath.iss to the same directory as your setup script // //	Add this statement to your [Setup] section //		ChangesEnvironment=true // //	Add this statement to your [Tasks] section //	You can change the Description or Flags //	You can change the Name, but it must match the ModPathName setting below //		Name: modifypath; Description: &Add application directory to your environmental path; Flags: unchecked // //	Add the following to the end of your [Code] section //	ModPathName defines the name of the task defined above //	ModPathType defines whether the 'user' or 'system' path will be modified; //		this will default to user if anything other than system is set //	setArrayLength must specify the total number of dirs to be added //	Result[0] contains first directory, Result[1] contains second, etc. //		const //			ModPathName = 'modifypath'; //			ModPathType = 'user'; // //		function ModPathDir(): TArrayOfString; //		begin //			setArrayLength(Result, 1); //			Result[0] := ExpandConstant('{app}'); //		end; //		#include "modpath.iss" // ---------------------------------------------------------------------------- procedure ModPath(); var oldpath:	String; newpath:	String; updatepath:	Boolean; pathArr:	TArrayOfString; aExecFile:	String; aExecArr:	TArrayOfString; i, d:		Integer; pathdir:	TArrayOfString; regroot:	Integer; regpath:	String; begin // Get constants from main script and adjust behavior accordingly // ModPathType MUST be 'system' or 'user'; force 'user' if invalid if ModPathType = 'system' then begin regroot := HKEY_LOCAL_MACHINE; regpath := 'SYSTEMCurrentControlSetControlSession ManagerEnvironment'; end else begin regroot := HKEY_CURRENT_USER; regpath := 'Environment'; end; // Get array of new directories and act on each individually pathdir := ModPathDir(); for d := 0 to GetArrayLength(pathdir)-1 do begin updatepath := true; // Modify WinNT path if UsingWinNT() = true then begin // Get current path, split into an array RegQueryStringValue(regroot, regpath, 'Path', oldpath); oldpath := oldpath + ';'; i := 0; while (Pos(';', oldpath) > 0) do begin SetArrayLength(pathArr, i+1); pathArr[i] := Copy(oldpath, 0, Pos(';', oldpath)-1); oldpath := Copy(oldpath, Pos(';', oldpath)+1, Length(oldpath)); i := i + 1; // Check if current directory matches app dir if pathdir[d] = pathArr[i-1] then begin // if uninstalling, remove dir from path if IsUninstaller() = true then begin continue; // if installing, flag that dir already exists in path end else begin updatepath := false; end; end; // Add current directory to new path if i = 1 then begin newpath := pathArr[i-1]; end else begin newpath := newpath + ';' + pathArr[i-1]; end; end; // Append app dir to path if not already included if (IsUninstaller() = false) AND (updatepath = true) then newpath := newpath + ';' + pathdir[d]; // Write new path RegWriteStringValue(regroot, regpath, 'Path', newpath); // Modify Win9x path end else begin // Convert to shortened dirname pathdir[d] := GetShortName(pathdir[d]); // If autoexec.bat exists, check if app dir already exists in path aExecFile := 'C:AUTOEXEC.BAT'; if FileExists(aExecFile) then begin LoadStringsFromFile(aExecFile, aExecArr); for i := 0 to GetArrayLength(aExecArr)-1 do begin if IsUninstaller() = false then begin // If app dir already exists while installing, skip add if (Pos(pathdir[d], aExecArr[i]) > 0) then updatepath := false; break; end else begin // If app dir exists and = what we originally set, then delete at uninstall if aExecArr[i] = 'SET PATH=%PATH%;' + pathdir[d] then aExecArr[i] := ''; end; end; end; // If app dir not found, or autoexec.bat didn't exist, then (create and) append to current path if (IsUninstaller() = false) AND (updatepath = true) then begin SaveStringToFile(aExecFile, #13#10 + 'SET PATH=%PATH%;' + pathdir[d], True); // If uninstalling, write the full autoexec out end else begin SaveStringsToFile(aExecFile, aExecArr, False); end; end; end; end; // Split a string into an array using passed delimiter procedure Explode(var Dest: TArrayOfString; Text: String; Separator: String); var i: Integer; begin i := 0; repeat SetArrayLength(Dest, i+1); if Pos(Separator,Text) > 0 then	begin Dest[i] := Copy(Text, 1, Pos(Separator, Text)-1); Text := Copy(Text, Pos(Separator,Text) + Length(Separator), Length(Text)); i := i + 1; end else begin Dest[i] := Text; Text := ''; end; until Length(Text)=0; end; procedure ModPathCurStepChanged(CurStep: TSetupStep); var taskname:	String; begin taskname := ModPathName; if CurStep = ssPostInstall then if IsTaskSelected(taskname) then ModPath(); end; procedure CurUninstallStepChanged(CurUninstallStep: TUninstallStep); var aSelectedTasks:	TArrayOfString; i:				Integer; taskname:		String; regpath:		String; regstring:		String; appid:			String; begin // only run during actual uninstall if CurUninstallStep = usUninstall then begin // get list of selected tasks saved in registry at install time appid := '{#emit SetupSetting("AppId")}'; if appid = '' then appid := '{#emit SetupSetting("AppName")}'; regpath := ExpandConstant('SoftwareMicrosoftWindowsCurrentVersionUninstall'+appid+'_is1'); RegQueryStringValue(HKLM, regpath, 'Inno Setup: Selected Tasks', regstring); if regstring = '' then RegQueryStringValue(HKCU, regpath, 'Inno Setup: Selected Tasks', regstring); // check each task; if matches modpath taskname, trigger patch removal if regstring <> '' then begin taskname := ModPathName; Explode(aSelectedTasks, regstring, ','); if GetArrayLength(aSelectedTasks) > 0 then begin for i := 0 to GetArrayLength(aSelectedTasks)-1 do begin if comparetext(aSelectedTasks[i], taskname) = 0 then ModPath(); end; end; end; end; end; function NeedRestart(): Boolean; var taskname:	String; begin taskname := ModPathName; if IsTaskSelected(taskname) and not UsingWinNT() then begin Result := True; end else begin Result := False; end; end; </del>


Question:
The .exe installer tries to install to "C:Program Files (x86)Rust", even though it's the 64-bit version. It then fails to create the destination directory due to a permission error. The .msi installer correctly defaults to "C:Program FilesRust <channel<version", and has no problems with permissions, I would expect the .exe installer to have the same behaviour.
Rust should install to , just like Ant, Python, and many others. is the place for developer tools that have a known folder. is badly named (compare to ), poorly suited for command line tools, and clutters the already hideous PATH more than .
/cc
Neither Ant nor Python install to C:tools by default, and searching I can't find any reference to C:tools even being a thing? Both Python and Ant install to C:Python<Versionand C:ant, which is incredibly annoying, so please don't do that!
I might be mistaken, but installing both through stuck them in for me. I'd recommend anyone with a machine running Vista or later use chocolatey. And there's a trend in chocolatey to have packages extract to when they aren't self-contained enough for .
For an OS without much filesystem hierarchy, is a decent place for developer and command-line packages, similar to on some unices. But I'd much rather see a that actually obeyed chocolatey's conventions and extracted an archive to , with no installer/registry involvement. But Rust only and installers for windows. : And all packages that do this reduce PATH clutter, since chocolatey symlinks their executables into .
The idea was to deprecate the .exe installer once .msi is known to be working satisfactory.
Can we have a zip release too, that contains Rust and Cargo like the others? Linux and OS X have an archive release. Those are preferred in chocolatey because they don't involve the registry or any other Windows components.
We do produce tarballs for windows.
Seems like we should probably just stop producing the .exe's. That fix would go in
I don't see a cargo+rustc nightly tarball for windows, although I do see ones for linux and osx.
triage: We do not link to the .exe installer anymore, but we still produce them. I don't have access to windows at the moment to check if this bug has been resolved, but it's been a long time...
Grabbing the Windows download link from and swapping the for yields a functional link to the , which is nice. Testing on win7-x64, the MSI extracts with lessmsi, but the directory structure is somewhat unusual so there's no one-liner to get the Rust folder out. The best I came up with was: This yields a Rust install rooted at . However now that exists, multiple targets aren't really an issue anymore. Someone should make a Chocolatey package for
Can someone with access to Windows check what happens here today?
The latest version installs to instead, which works, but is a terrible default.
Triage: ! This seems... fine. I'm not sure if this should stay open or not; I'll let the relevant team (infra? compiler?) decide.

<del> #define CFG_RELEASE_NUM GetEnv("CFG_RELEASE_NUM") #define CFG_RELEASE GetEnv("CFG_RELEASE") #define CFG_PACKAGE_NAME GetEnv("CFG_PACKAGE_NAME") #define CFG_BUILD GetEnv("CFG_BUILD") [Setup] SetupIconFile=rust-logo.ico AppName=Rust AppVersion={#CFG_RELEASE} AppCopyright=Copyright (C) 2006-2014 Mozilla Foundation, MIT license AppPublisher=Mozilla Foundation AppPublisherURL=http://www.rust-lang.org VersionInfoVersion={#CFG_RELEASE_NUM} LicenseFile=LICENSE.txt PrivilegesRequired=lowest DisableWelcomePage=true DisableProgramGroupPage=true DisableReadyPage=true DisableStartupPrompt=true OutputDir=. SourceDir=. OutputBaseFilename={#CFG_PACKAGE_NAME}-{#CFG_BUILD} DefaultDirName={sd}Rust Compression=lzma2/normal InternalCompressLevel=normal SolidCompression=no ChangesEnvironment=true ChangesAssociations=no AllowUNCPath=false AllowNoIcons=true Uninstallable=yes [Tasks] Name: modifypath; Description: &Add {app}bin to your PATH (recommended) [Components] Name: rust; Description: "Rust compiler and standard crates"; Types: full compact custom; Flags: fixed #ifdef MINGW Name: gcc; Description: "Linker and platform libraries"; Types: full #endif Name: docs; Description: "HTML documentation"; Types: full Name: cargo; Description: "Cargo, the Rust package manager"; Types: full Name: std; Description: "The Rust Standard Library"; Types: full // tool-rls-start Name: rls; Description: "RLS, the Rust Language Server" // tool-rls-end [Files] Source: "rustc/*.*"; DestDir: "{app}"; Flags: ignoreversion recursesubdirs; Components: rust #ifdef MINGW Source: "rust-mingw/*.*"; DestDir: "{app}"; Flags: ignoreversion recursesubdirs; Components: gcc #endif Source: "rust-docs/*.*"; DestDir: "{app}"; Flags: ignoreversion recursesubdirs; Components: docs Source: "cargo/*.*"; DestDir: "{app}"; Flags: ignoreversion recursesubdirs; Components: cargo Source: "rust-std/*.*"; DestDir: "{app}"; Flags: ignoreversion recursesubdirs; Components: std // tool-rls-start Source: "rls/*.*"; DestDir: "{app}"; Flags: ignoreversion recursesubdirs; Components: rls Source: "rust-analysis/*.*"; DestDir: "{app}"; Flags: ignoreversion recursesubdirs; Components: rls // tool-rls-end [Code] const ModPathName = 'modifypath'; ModPathType = 'user'; function ModPathDir(): TArrayOfString; begin setArrayLength(Result, 1) Result[0] := ExpandConstant('{app}bin'); end; #include "modpath.iss" #include "upgrade.iss" // Both modpath.iss and upgrade.iss want to overload CurStepChanged. // This version does the overload then delegates to each. procedure CurStepChanged(CurStep: TSetupStep); begin UpgradeCurStepChanged(CurStep); ModPathCurStepChanged(CurStep); end; </del>


Question:
The .exe installer tries to install to "C:Program Files (x86)Rust", even though it's the 64-bit version. It then fails to create the destination directory due to a permission error. The .msi installer correctly defaults to "C:Program FilesRust <channel<version", and has no problems with permissions, I would expect the .exe installer to have the same behaviour.
Rust should install to , just like Ant, Python, and many others. is the place for developer tools that have a known folder. is badly named (compare to ), poorly suited for command line tools, and clutters the already hideous PATH more than .
/cc
Neither Ant nor Python install to C:tools by default, and searching I can't find any reference to C:tools even being a thing? Both Python and Ant install to C:Python<Versionand C:ant, which is incredibly annoying, so please don't do that!
I might be mistaken, but installing both through stuck them in for me. I'd recommend anyone with a machine running Vista or later use chocolatey. And there's a trend in chocolatey to have packages extract to when they aren't self-contained enough for .
For an OS without much filesystem hierarchy, is a decent place for developer and command-line packages, similar to on some unices. But I'd much rather see a that actually obeyed chocolatey's conventions and extracted an archive to , with no installer/registry involvement. But Rust only and installers for windows. : And all packages that do this reduce PATH clutter, since chocolatey symlinks their executables into .
The idea was to deprecate the .exe installer once .msi is known to be working satisfactory.
Can we have a zip release too, that contains Rust and Cargo like the others? Linux and OS X have an archive release. Those are preferred in chocolatey because they don't involve the registry or any other Windows components.
We do produce tarballs for windows.
Seems like we should probably just stop producing the .exe's. That fix would go in
I don't see a cargo+rustc nightly tarball for windows, although I do see ones for linux and osx.
triage: We do not link to the .exe installer anymore, but we still produce them. I don't have access to windows at the moment to check if this bug has been resolved, but it's been a long time...
Grabbing the Windows download link from and swapping the for yields a functional link to the , which is nice. Testing on win7-x64, the MSI extracts with lessmsi, but the directory structure is somewhat unusual so there's no one-liner to get the Rust folder out. The best I came up with was: This yields a Rust install rooted at . However now that exists, multiple targets aren't really an issue anymore. Someone should make a Chocolatey package for
Can someone with access to Windows check what happens here today?
The latest version installs to instead, which works, but is a terrible default.
Triage: ! This seems... fine. I'm not sure if this should stay open or not; I'll let the relevant team (infra? compiler?) decide.

<del> // The following code taken from https://stackoverflow.com/questions/2000296/innosetup-how-to-automatically-uninstall-previous-installed-version // It performs upgrades by running the uninstaller before the install ///////////////////////////////////////////////////////////////////// function GetUninstallString(): String; var sUnInstPath: String; sUnInstallString: String; begin sUnInstPath := ExpandConstant('SoftwareMicrosoftWindowsCurrentVersionUninstallRust_is1'); sUnInstallString := ''; if not RegQueryStringValue(HKLM, sUnInstPath, 'UninstallString', sUnInstallString) then RegQueryStringValue(HKCU, sUnInstPath, 'UninstallString', sUnInstallString); Result := sUnInstallString; end; ///////////////////////////////////////////////////////////////////// function IsUpgrade(): Boolean; begin Result := (GetUninstallString() <> ''); end; ///////////////////////////////////////////////////////////////////// function UnInstallOldVersion(): Integer; var sUnInstallString: String; iResultCode: Integer; begin // Return Values: // 1 - uninstall string is empty // 2 - error executing the UnInstallString // 3 - successfully executed the UnInstallString // default return value Result := 0; // get the uninstall string of the old app sUnInstallString := GetUninstallString(); if sUnInstallString <> '' then begin sUnInstallString := RemoveQuotes(sUnInstallString); if Exec(sUnInstallString, '/SILENT /NORESTART /SUPPRESSMSGBOXES','', SW_HIDE, ewWaitUntilTerminated, iResultCode) then Result := 3 else Result := 2; end else Result := 1; end; ///////////////////////////////////////////////////////////////////// procedure UpgradeCurStepChanged(CurStep: TSetupStep); begin if (CurStep=ssInstall) then begin if (IsUpgrade()) then begin UnInstallOldVersion(); end; end; end; </del>


Question:
cc
Are you OK with just a PR?
Sure!
Is it worth writing tests for this? I'm not really sure how it could break, but better safe than sorry I suppose...
Yeah but just some simple tests would be fine to have
ping?
Working on it right now. , Steven Allen wrote:
Thanks. I had some free time so I thought I'd check.

Repeat{element: elt} } <ins> /// An iterator that yields nothing. #[unstable(feature="iter_empty", reason = "new addition")] pub struct Empty<T>(marker::PhantomData<T>); #[unstable(feature="iter_empty", reason = "new addition")] impl<T> Iterator for Empty<T> { type Item = T; fn next(&mut self) -> Option<T> { None } fn size_hint(&self) -> (usize, Option<usize>){ (0, Some(0)) } } #[unstable(feature="iter_empty", reason = "new addition")] impl<T> DoubleEndedIterator for Empty<T> { fn next_back(&mut self) -> Option<T> { None } } #[unstable(feature="iter_empty", reason = "new addition")] impl<T> ExactSizeIterator for Empty<T> { fn len(&self) -> usize { 0 } } // not #[derive] because that adds a Clone bound on T, // which isn't necessary. #[unstable(feature="iter_empty", reason = "new addition")] impl<T> Clone for Empty<T> { fn clone(&self) -> Empty<T> { Empty(marker::PhantomData) } } // not #[derive] because that adds a Default bound on T, // which isn't necessary. #[unstable(feature="iter_empty", reason = "new addition")] impl<T> Default for Empty<T> { fn default() -> Empty<T> { Empty(marker::PhantomData) } } /// Creates an iterator that yields nothing. #[unstable(feature="iter_empty", reason = "new addition")] pub fn empty<T>() -> Empty<T> { Empty(marker::PhantomData) } /// An iterator that yields an element exactly once. #[unstable(feature="iter_once", reason = "new addition")] pub struct Once<T> { inner: ::option::IntoIter<T> } #[unstable(feature="iter_once", reason = "new addition")] impl<T> Iterator for Once<T> { type Item = T; fn next(&mut self) -> Option<T> { self.inner.next() } fn size_hint(&self) -> (usize, Option<usize>) { self.inner.size_hint() } } #[unstable(feature="iter_once", reason = "new addition")] impl<T> DoubleEndedIterator for Once<T> { fn next_back(&mut self) -> Option<T> { self.inner.next_back() } } #[unstable(feature="iter_once", reason = "new addition")] impl<T> ExactSizeIterator for Once<T> { fn len(&self) -> usize { self.inner.len() } } /// Creates an iterator that yields an element exactly once. #[unstable(feature="iter_once", reason = "new addition")] pub fn once<T>(value: T) -> Once<T> { Once { inner: Some(value).into_iter() } } </ins> /// Functions for lexicographical ordering of sequences. /// /// Lexicographical ordering through `<`, `<=`, `>=`, `>` requires


Question:
cc
Are you OK with just a PR?
Sure!
Is it worth writing tests for this? I'm not really sure how it could break, but better safe than sorry I suppose...
Yeah but just some simple tests would be fine to have
ping?
Working on it right now. , Steven Allen wrote:
Thanks. I had some free time so I thought I'd check.

// Can't check len now because count consumes. } <ins> #[test] fn test_once() { let mut it = once(42); assert_eq!(it.next(), Some(42)); assert_eq!(it.next(), None); } #[test] fn test_empty() { let mut it = empty::<i32>(); assert_eq!(it.next(), None); } </ins> #[bench] fn bench_rposition(b: &mut Bencher) { let it: Vec<usize> = (0..300).collect();


Question:
cc
Are you OK with just a PR?
Sure!
Is it worth writing tests for this? I'm not really sure how it could break, but better safe than sorry I suppose...
Yeah but just some simple tests would be fine to have
ping?
Working on it right now. , Steven Allen wrote:
Thanks. I had some free time so I thought I'd check.

#![feature(slice_patterns)] #![feature(float_from_str_radix)] #![feature(cell_extras)] <ins> #![feature(iter_empty)] #![feature(iter_once)] </ins> extern crate core; extern crate test;


Question:
This value has not changed in a long time, but to support sxs installation in a single dir it needs to. It should just be hashed from the value of .
So should we pipe the value through e.g. md5sum? That could be awkward on BSDs, where the hash programs have a . I think we can patch over the differences by adding a check to the configure script. Something like this: then in the Makefile we have: But if there's a simpler way then I'm all ears.

T=$(command -v $P 2>&1) if [ $? -eq 0 ] then <del> VER0=$($P --version 2>/dev/null | head -1  |  sed -e 's/[^0-9]*([vV]?[0-9.]+[^ ]*).*/1/' ) </del> <ins> VER0=$($P --version 2>/dev/null  |  grep -o '[vV]?[0-9][0-9.][a-z0-9.-]*' | head -1 ) </ins> if [ $? -eq 0 -a "x${VER0}" != "x" ] then VER="($VER0)"


Question:
This value has not changed in a long time, but to support sxs installation in a single dir it needs to. It should just be hashed from the value of .
So should we pipe the value through e.g. md5sum? That could be awkward on BSDs, where the hash programs have a . I think we can patch over the differences by adding a check to the configure script. Something like this: then in the Makefile we have: But if there's a simpler way then I'm all ears.

probe_need CFG_GIT     git fi <ins> # Use `md5sum` on GNU platforms, or `md5 -q` on BSD probe CFG_MD5              md5 probe CFG_MD5SUM           md5sum if [ -n "$CFG_MD5" ] then CFG_HASH_COMMAND="$CFG_MD5 -q | head -c 8" elif [ -n "$CFG_MD5SUM" ] then CFG_HASH_COMMAND="$CFG_MD5SUM | head -c 8" else err 'could not find one of: md5 md5sum' fi putvar CFG_HASH_COMMAND </ins> probe CFG_CLANG            clang++ probe CFG_CCACHE           ccache probe CFG_GCC              gcc


Question:
This value has not changed in a long time, but to support sxs installation in a single dir it needs to. It should just be hashed from the value of .
So should we pipe the value through e.g. md5sum? That could be awkward on BSDs, where the hash programs have a . I think we can patch over the differences by adding a check to the configure script. Something like this: then in the Makefile we have: But if there's a simpler way then I'm all ears.

# versions (section 9) CFG_PRERELEASE_VERSION=.1 <del> CFG_FILENAME_EXTRA=4e7c5e5c </del> <ins> # Append a version-dependent hash to each library, so we can install different # versions in the same place CFG_FILENAME_EXTRA=$(shell printf '%s' $(CFG_RELEASE) | $(CFG_HASH_COMMAND)) </ins> ifeq ($(CFG_RELEASE_CHANNEL),stable) # This is the normal semver version string, e.g. "0.12.0", "0.12.0-nightly"


Question:
The failure happens in when the output of the command used in the test contains cyrillic letters. Changing the system locale to English (USA) or replacing with something like makes this error go away. cc
Hm interesting! This probably isn't so much connected to locales so much that something in the environment/output isn't valid UTF-8. Could you get a backtrace of this failure? I would be surprised if this was coming from , but the test looks pretty innocuous, so it may very well be coming from std!
The problem may actually reside in compiletest, it captures the output of the test and then can interpret it incorrectly. If the test is run as a standalone program outside of the test suite then no panic happens and the test works as expected. I'm still investigating. Here's the backtrace, but it's not very helpful:
Aha! It looks like . I suspect it would be fine for to just use

$(Q)$(CFG_PYTHON) $(S)src/etc/check-summary.py tmp/*.log # As above but don't bother running tidy. <del> check-notidy: cleantmptestlogs cleantestlibs all check-stage2 </del> <ins> check-notidy: check-sanitycheck cleantmptestlogs cleantestlibs all check-stage2 </ins> $(Q)$(CFG_PYTHON) $(S)src/etc/check-summary.py tmp/*.log # A slightly smaller set of tests for smoke testing. <del> check-lite: cleantestlibs cleantmptestlogs  </del> <ins> check-lite: check-sanitycheck cleantestlibs cleantmptestlogs  </ins> $(foreach crate,$(TEST_TARGET_CRATES),check-stage2-$(crate))  check-stage2-rpass check-stage2-rpass-valgrind  check-stage2-rfail check-stage2-cfail check-stage2-pfail check-stage2-rmake $(Q)$(CFG_PYTHON) $(S)src/etc/check-summary.py tmp/*.log # Only check the 'reference' tests: rpass/cfail/rfail/rmake. <del> check-ref: cleantestlibs cleantmptestlogs check-stage2-rpass check-stage2-rpass-valgrind  check-stage2-rfail check-stage2-cfail check-stage2-pfail check-stage2-rmake </del> <ins> check-ref: check-sanitycheck cleantestlibs cleantmptestlogs check-stage2-rpass  check-stage2-rpass-valgrind check-stage2-rfail check-stage2-cfail check-stage2-pfail  check-stage2-rmake </ins> $(Q)$(CFG_PYTHON) $(S)src/etc/check-summary.py tmp/*.log # Only check the docs. <del> check-docs: cleantestlibs cleantmptestlogs check-stage2-docs </del> <ins> check-docs: check-sanitycheck cleantestlibs cleantmptestlogs check-stage2-docs </ins> $(Q)$(CFG_PYTHON) $(S)src/etc/check-summary.py tmp/*.log # Some less critical tests that are not prone to breakage.


Question:
The failure happens in when the output of the command used in the test contains cyrillic letters. Changing the system locale to English (USA) or replacing with something like makes this error go away. cc
Hm interesting! This probably isn't so much connected to locales so much that something in the environment/output isn't valid UTF-8. Could you get a backtrace of this failure? I would be surprised if this was coming from , but the test looks pretty innocuous, so it may very well be coming from std!
The problem may actually reside in compiletest, it captures the output of the test and then can interpret it incorrectly. If the test is run as a standalone program outside of the test suite then no panic happens and the test works as expected. I'm still investigating. Here's the backtrace, but it's not very helpful:
Aha! It looks like . I suspect it would be fine for to just use

# except according to those terms. import os <ins> import subprocess </ins> import sys import functools STATUS = 0 def error_unless_permitted(env_var, message): global STATUS if not os.getenv(env_var): sys.stderr.write(message) STATUS = 1 def only_on(platforms): def decorator(func): @functools.wraps(func)


Question:
The failure happens in when the output of the command used in the test contains cyrillic letters. Changing the system locale to English (USA) or replacing with something like makes this error go away. cc
Hm interesting! This probably isn't so much connected to locales so much that something in the environment/output isn't valid UTF-8. Could you get a backtrace of this failure? I would be surprised if this was coming from , but the test looks pretty innocuous, so it may very well be coming from std!
The problem may actually reside in compiletest, it captures the output of the test and then can interpret it incorrectly. If the test is run as a standalone program outside of the test suite then no panic happens and the test works as expected. I'm still investigating. Here's the backtrace, but it's not very helpful:
Aha! It looks like . I suspect it would be fine for to just use

return inner return decorator <del> @only_on(('linux', 'darwin', 'freebsd', 'openbsd')) </del> <ins> @only_on(['linux', 'darwin', 'freebsd', 'openbsd']) </ins> def check_rlimit_core(): import resource soft, hard = resource.getrlimit(resource.RLIMIT_CORE)


Question:
The failure happens in when the output of the command used in the test contains cyrillic letters. Changing the system locale to English (USA) or replacing with something like makes this error go away. cc
Hm interesting! This probably isn't so much connected to locales so much that something in the environment/output isn't valid UTF-8. Could you get a backtrace of this failure? I would be surprised if this was coming from , but the test looks pretty innocuous, so it may very well be coming from std!
The problem may actually reside in compiletest, it captures the output of the test and then can interpret it incorrectly. If the test is run as a standalone program outside of the test suite then no panic happens and the test works as expected. I'm still investigating. Here's the backtrace, but it's not very helpful:
Aha! It looks like . I suspect it would be fine for to just use

set ALLOW_NONZERO_RLIMIT_CORE to ignore this warning """ % (soft)) <ins> @only_on(['win32']) def check_console_code_page(): if '65001' not in subprocess.check_output(['cmd', '/c', 'chcp']): sys.stderr.write('Warning: the console output code page is not UTF-8,  some tests may fail. Use `cmd /c "chcp 65001"` to setup UTF-8 code page.n') </ins> def main(): <ins> check_console_code_page() </ins> check_rlimit_core() if __name__ == '__main__':


Question:
Running on the following code results in a stack overflow: With significantly fewer enum variants, it works. If I remove the use of , it works. This is breaking on one of my PRs (bjz/glfw-rs).
This seems to be fixed.
In my tests, you now need to have around 460+ enum variants in order to get the stack overflow. Can we assume nobody will ever have that many?
should a test still be written for this? Panicking is not correct, better would be that the number of variants is limited explicitly and that this is documented. Better still if there is no limit, of course.
In theory yeah if there's something that overflowed previously and no longer does, we should have a test for that :)
Triage: not aware of a test yet

<ins> // Copyright (c) 2015 Anders Kaseorg <andersk@mit.edu> // Permission is hereby granted, free of charge, to any person obtaining // a copy of this software and associated documentation files (the // “Software”), to deal in the Software without restriction, including // without limitation the rights to use, copy, modify, merge, publish, // distribute, sublicense, and/or sell copies of the Software, and to // permit persons to whom the Software is furnished to do so, subject to // the following conditions: // The above copyright notice and this permission notice shall be // included in all copies or substantial portions of the Software. // THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, // EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF // MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. // IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY // CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, // TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE // SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. //! This crate exports a macro `enum_from_primitive!` that wraps an //! `enum` declaration and automatically adds an implementation of //! `num::FromPrimitive` (reexported here), to allow conversion from //! primitive integers to the enum.  It therefore provides an //! alternative to the built-in `#[derive(FromPrimitive)]`, which //! requires the unstable `std::num::FromPrimitive` and is disabled in //! Rust 1.0. //! //! # Example //! //! ``` //! #[macro_use] extern crate enum_primitive; //! extern crate num_traits; //! use num_traits::FromPrimitive; //! //! enum_from_primitive! { //! #[derive(Debug, PartialEq)] //! enum FooBar { //!     Foo = 17, //!     Bar = 42, //!     Baz, //! } //! } //! //! fn main() { //!     assert_eq!(FooBar::from_i32(17), Some(FooBar::Foo)); //!     assert_eq!(FooBar::from_i32(42), Some(FooBar::Bar)); //!     assert_eq!(FooBar::from_i32(43), Some(FooBar::Baz)); //!     assert_eq!(FooBar::from_i32(91), None); //! } //! ``` pub mod num_traits { pub trait FromPrimitive: Sized { fn from_i64(n: i64) -> Option<Self>; fn from_u64(n: u64) -> Option<Self>; } } pub use std::option::Option; pub use num_traits::FromPrimitive; /// Helper macro for internal use by `enum_from_primitive!`. #[macro_export] macro_rules! enum_from_primitive_impl_ty { ($meth:ident, $ty:ty, $name:ident, $( $variant:ident )*) => { #[allow(non_upper_case_globals, unused)] fn $meth(n: $ty) -> $crate::Option<Self> { $( if n == $name::$variant as $ty { $crate::Option::Some($name::$variant) } else )* { $crate::Option::None } } }; } /// Helper macro for internal use by `enum_from_primitive!`. #[macro_export] #[macro_use(enum_from_primitive_impl_ty)] macro_rules! enum_from_primitive_impl { ($name:ident, $( $variant:ident )*) => { impl $crate::FromPrimitive for $name { enum_from_primitive_impl_ty! { from_i64, i64, $name, $( $variant )* } enum_from_primitive_impl_ty! { from_u64, u64, $name, $( $variant )* } } }; } /// Wrap this macro around an `enum` declaration to get an /// automatically generated implementation of `num::FromPrimitive`. #[macro_export] #[macro_use(enum_from_primitive_impl)] macro_rules! enum_from_primitive { ( $( #[$enum_attr:meta] )* enum $name:ident { $( $( #[$variant_attr:meta] )* $variant:ident ),+ $( = $discriminator:expr, $( $( #[$variant_two_attr:meta] )* $variant_two:ident ),+ )* } ) => { $( #[$enum_attr] )* enum $name { $( $( #[$variant_attr] )* $variant ),+ $( = $discriminator, $( $( #[$variant_two_attr] )* $variant_two ),+ )* } enum_from_primitive_impl! { $name, $( $variant )+ $( $( $variant_two )+ )* } }; ( $( #[$enum_attr:meta] )* enum $name:ident { $( $( $( #[$variant_attr:meta] )* $variant:ident ),+ = $discriminator:expr ),* } ) => { $( #[$enum_attr] )* enum $name { $( $( $( #[$variant_attr] )* $variant ),+ = $discriminator ),* } enum_from_primitive_impl! { $name, $( $( $variant )+ )* } }; ( $( #[$enum_attr:meta] )* enum $name:ident { $( $( #[$variant_attr:meta] )* $variant:ident ),+ $( = $discriminator:expr, $( $( #[$variant_two_attr:meta] )* $variant_two:ident ),+ )*, } ) => { $( #[$enum_attr] )* enum $name { $( $( #[$variant_attr] )* $variant ),+ $( = $discriminator, $( $( #[$variant_two_attr] )* $variant_two ),+ )*, } enum_from_primitive_impl! { $name, $( $variant )+ $( $( $variant_two )+ )* } }; ( $( #[$enum_attr:meta] )* enum $name:ident { $( $( $( #[$variant_attr:meta] )* $variant:ident ),+ = $discriminator:expr ),+, } ) => { $( #[$enum_attr] )* enum $name { $( $( $( #[$variant_attr] )* $variant ),+ = $discriminator ),+, } enum_from_primitive_impl! { $name, $( $( $variant )+ )+ } }; ( $( #[$enum_attr:meta] )* pub enum $name:ident { $( $( #[$variant_attr:meta] )* $variant:ident ),+ $( = $discriminator:expr, $( $( #[$variant_two_attr:meta] )* $variant_two:ident ),+ )* } ) => { $( #[$enum_attr] )* pub enum $name { $( $( #[$variant_attr] )* $variant ),+ $( = $discriminator, $( $( #[$variant_two_attr] )* $variant_two ),+ )* } enum_from_primitive_impl! { $name, $( $variant )+ $( $( $variant_two )+ )* } }; ( $( #[$enum_attr:meta] )* pub enum $name:ident { $( $( $( #[$variant_attr:meta] )* $variant:ident ),+ = $discriminator:expr ),* } ) => { $( #[$enum_attr] )* pub enum $name { $( $( $( #[$variant_attr] )* $variant ),+ = $discriminator ),* } enum_from_primitive_impl! { $name, $( $( $variant )+ )* } }; ( $( #[$enum_attr:meta] )* pub enum $name:ident { $( $( #[$variant_attr:meta] )* $variant:ident ),+ $( = $discriminator:expr, $( $( #[$variant_two_attr:meta] )* $variant_two:ident ),+ )*, } ) => { $( #[$enum_attr] )* pub enum $name { $( $( #[$variant_attr] )* $variant ),+ $( = $discriminator, $( $( #[$variant_two_attr] )* $variant_two ),+ )*, } enum_from_primitive_impl! { $name, $( $variant )+ $( $( $variant_two )+ )* } }; ( $( #[$enum_attr:meta] )* pub enum $name:ident { $( $( $( #[$variant_attr:meta] )* $variant:ident ),+ = $discriminator:expr ),+, } ) => { $( #[$enum_attr] )* pub enum $name { $( $( $( #[$variant_attr] )* $variant ),+ = $discriminator ),+, } enum_from_primitive_impl! { $name, $( $( $variant )+ )+ } }; } </ins>


Question:
Running on the following code results in a stack overflow: With significantly fewer enum variants, it works. If I remove the use of , it works. This is breaking on one of my PRs (bjz/glfw-rs).
This seems to be fixed.
In my tests, you now need to have around 460+ enum variants in order to get the stack overflow. Can we assume nobody will ever have that many?
should a test still be written for this? Panicking is not correct, better would be that the number of variants is limited explicitly and that this is documented. Better still if there is no limit, of course.
In theory yeah if there's something that overflowed previously and no longer does, we should have a test for that :)
Triage: not aware of a test yet

<ins> // Copyright 2018 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. // ensure this code doesn't stack overflow // aux-build:enum_primitive.rs #[macro_use] extern crate enum_primitive; enum_from_primitive! { pub enum Test { A1,A2,A3,A4,A5,A6, B1,B2,B3,B4,B5,B6, C1,C2,C3,C4,C5,C6, D1,D2,D3,D4,D5,D6, E1,E2,E3,E4,E5,E6, F1,F2,F3,F4,F5,F6, G1,G2,G3,G4,G5,G6, H1,H2,H3,H4,H5,H6, I1,I2,I3,I4,I5,I6, J1,J2,J3,J4,J5,J6, K1,K2,K3,K4,K5,K6, L1,L2,L3,L4,L5,L6, M1,M2,M3,M4,M5,M6, N1,N2,N3,N4,N5,N6, O1,O2,O3,O4,O5,O6, P1,P2,P3,P4,P5,P6, Q1,Q2,Q3,Q4,Q5,Q6, R1,R2,R3,R4,R5,R6, S1,S2,S3,S4,S5,S6, T1,T2,T3,T4,T5,T6, U1,U2,U3,U4,U5,U6, V1,V2,V3,V4,V5,V6, W1,W2,W3,W4,W5,W6, X1,X2,X3,X4,X5,X6, Y1,Y2,Y3,Y4,Y5,Y6, Z1,Z2,Z3,Z4,Z5,Z6, } } </ins>


Question:
The rust book currently links to, an old beta version of rust, causing some problems using the tutorial. Example: Dining philosophers will not compile.
What's your rust version?
According to the installer: 1.0.0-beta. On windows x64.
It compiles on 1.0.0-beta.2 and up. You should update your compiler.
I believe is right here, so closing, but thanks for the report!

If you're on Windows, please download either the [32-bit installer][win32] or the [64-bit installer][win64] and run it. <del> [win32]: https://static.rust-lang.org/dist/rust-1.0.0-beta-i686-pc-windows-gnu.msi [win64]: https://static.rust-lang.org/dist/rust-1.0.0-beta-x86_64-pc-windows-gnu.msi </del> <ins> [win32]: https://static.rust-lang.org/dist/rust-1.0.0-i686-pc-windows-gnu.msi [win64]: https://static.rust-lang.org/dist/rust-1.0.0-x86_64-pc-windows-gnu.msi </ins> ## Uninstalling


Question:
The rust book currently links to, an old beta version of rust, causing some problems using the tutorial. Example: Dining philosophers will not compile.
What's your rust version?
According to the installer: 1.0.0-beta. On windows x64.
It compiles on 1.0.0-beta.2 and up. You should update your compiler.
I believe is right here, so closing, but thanks for the report!

You should see the version number, commit hash, commit date and build date: ```bash <del> rustc 1.0.0-beta (9854143cb 2015-04-02) (built 2015-04-02) </del> <ins> rustc 1.0.0 (a59de37e9 2015-05-13) (built 2015-05-14) </ins> ``` If you did, Rust has been installed successfully! Congrats!


Question: Here's the problematic piece: On my machine usually can't delete file with "access denied" error. If I insert something like before then the test consistently passes. Supposedly we are trying to delete it too soon when it's still locked after execution.

str::from_utf8(&child_output.stdout).unwrap(), str::from_utf8(&child_output.stderr).unwrap())); <del> fs::remove_dir_all(&child_dir).unwrap(); </del> <ins> let res = fs::remove_dir_all(&child_dir); if res.is_err() { // On Windows deleting just executed mytest.exe can fail because it's still locked std::thread::sleep_ms(1000); fs::remove_dir_all(&child_dir).unwrap(); } </ins> }


Question:
Discussion carried over from: rust-lang/cargo Test binaries created by rustc should have a option instead of (in addition to?) controlling the thread count with . It's not a consistent user experience to have some functionality controlled via environment variables and some via command line options. CLI options should be preferred since they encourage users to keep configuration local to a single execution of a test binary and not export it globally, making it affect other test runs perhaps accidentally. It would also make the output of more uniform and compact.
Agreed.
The ability to specify this in the somehow might be nice. One of my crates I'm working on needs all the tests run like this.
It is already set table by an env var, no? Cargo just can't specify them. So still not ideal but might work in the meantime. On Apr 16, 2016, 19:05 -0400, Nathan , wrote:
Oh cool thanks, I'll set that in my project.

.TP fBRUST_TEST_THREADSfR The test framework Rust provides executes tests in parallel. This variable sets <del> the maximum number of threads used for this purpose. </del> <ins> the maximum number of threads used for this purpose. This setting is overridden by the --test-threads option. </ins> .TP fBRUST_TEST_NOCAPTUREfR


Question:
Discussion carried over from: rust-lang/cargo Test binaries created by rustc should have a option instead of (in addition to?) controlling the thread count with . It's not a consistent user experience to have some functionality controlled via environment variables and some via command line options. CLI options should be preferred since they encourage users to keep configuration local to a single execution of a test binary and not export it globally, making it affect other test runs perhaps accidentally. It would also make the output of more uniform and compact.
Agreed.
The ability to specify this in the somehow might be nice. One of my crates I'm working on needs all the tests run like this.
It is already set table by an env var, no? Cargo just can't specify them. So still not ideal but might work in the meantime. On Apr 16, 2016, 19:05 -0400, Nathan , wrote:
Oh cool thanks, I'll set that in my project.

pub nocapture: bool, pub color: ColorConfig, pub quiet: bool, <ins> pub test_threads: Option<usize>, </ins> } impl TestOpts {


Question:
Discussion carried over from: rust-lang/cargo Test binaries created by rustc should have a option instead of (in addition to?) controlling the thread count with . It's not a consistent user experience to have some functionality controlled via environment variables and some via command line options. CLI options should be preferred since they encourage users to keep configuration local to a single execution of a test binary and not export it globally, making it affect other test runs perhaps accidentally. It would also make the output of more uniform and compact.
Agreed.
The ability to specify this in the somehow might be nice. One of my crates I'm working on needs all the tests run like this.
It is already set table by an env var, no? Cargo just can't specify them. So still not ideal but might work in the meantime. On Apr 16, 2016, 19:05 -0400, Nathan , wrote:
Oh cool thanks, I'll set that in my project.

nocapture: false, color: AutoColor, quiet: false, <ins> test_threads: None, </ins> } } }


Question:
Discussion carried over from: rust-lang/cargo Test binaries created by rustc should have a option instead of (in addition to?) controlling the thread count with . It's not a consistent user experience to have some functionality controlled via environment variables and some via command line options. CLI options should be preferred since they encourage users to keep configuration local to a single execution of a test binary and not export it globally, making it affect other test runs perhaps accidentally. It would also make the output of more uniform and compact.
Agreed.
The ability to specify this in the somehow might be nice. One of my crates I'm working on needs all the tests run like this.
It is already set table by an env var, no? Cargo just can't specify them. So still not ideal but might work in the meantime. On Apr 16, 2016, 19:05 -0400, Nathan , wrote:
Oh cool thanks, I'll set that in my project.

of stdout", "PATH"), getopts::optflag("", "nocapture", "don't capture stdout/stderr of each  task, allow printing directly"), <ins> getopts::optopt("", "test-threads", "Number of threads used for running tests  in parallel", "n_threads"), </ins> getopts::optflag("q", "quiet", "Display one character per test instead of one line"), getopts::optopt("", "color", "Configure coloring of output: auto   = colorize if stdout is a tty and tests are run on serially (default);


Question:
Discussion carried over from: rust-lang/cargo Test binaries created by rustc should have a option instead of (in addition to?) controlling the thread count with . It's not a consistent user experience to have some functionality controlled via environment variables and some via command line options. CLI options should be preferred since they encourage users to keep configuration local to a single execution of a test binary and not export it globally, making it affect other test runs perhaps accidentally. It would also make the output of more uniform and compact.
Agreed.
The ability to specify this in the somehow might be nice. One of my crates I'm working on needs all the tests run like this.
It is already set table by an env var, no? Cargo just can't specify them. So still not ideal but might work in the meantime. On Apr 16, 2016, 19:05 -0400, Nathan , wrote:
Oh cool thanks, I'll set that in my project.

tests whose names contain the filter are run. By default, all tests are run in parallel. This can be altered with the <del> RUST_TEST_THREADS environment variable when running tests (set it to 1). </del> <ins> --test-threads flag or the RUST_TEST_THREADS environment variable when running tests (set it to 1). </ins> All tests have their standard output and standard error captured by default. This can be overridden with the --nocapture flag or setting RUST_TEST_NOCAPTURE


Question:
Discussion carried over from: rust-lang/cargo Test binaries created by rustc should have a option instead of (in addition to?) controlling the thread count with . It's not a consistent user experience to have some functionality controlled via environment variables and some via command line options. CLI options should be preferred since they encourage users to keep configuration local to a single execution of a test binary and not export it globally, making it affect other test runs perhaps accidentally. It would also make the output of more uniform and compact.
Agreed.
The ability to specify this in the somehow might be nice. One of my crates I'm working on needs all the tests run like this.
It is already set table by an env var, no? Cargo just can't specify them. So still not ideal but might work in the meantime. On Apr 16, 2016, 19:05 -0400, Nathan , wrote:
Oh cool thanks, I'll set that in my project.

}; } <ins> let test_threads = match matches.opt_str("test-threads") { Some(n_str) => match n_str.parse::<usize>() { Ok(n) => Some(n), Err(e) => return Some(Err(format!("argument for --test-threads must be a number > 0  (error: {})", e))) }, None => None, }; </ins> let color = match matches.opt_str("color").as_ref().map(|s| &**s) { Some("auto") | None => AutoColor, Some("always") => AlwaysColor,


Question:
Discussion carried over from: rust-lang/cargo Test binaries created by rustc should have a option instead of (in addition to?) controlling the thread count with . It's not a consistent user experience to have some functionality controlled via environment variables and some via command line options. CLI options should be preferred since they encourage users to keep configuration local to a single execution of a test binary and not export it globally, making it affect other test runs perhaps accidentally. It would also make the output of more uniform and compact.
Agreed.
The ability to specify this in the somehow might be nice. One of my crates I'm working on needs all the tests run like this.
It is already set table by an env var, no? Cargo just can't specify them. So still not ideal but might work in the meantime. On Apr 16, 2016, 19:05 -0400, Nathan , wrote:
Oh cool thanks, I'll set that in my project.

nocapture: nocapture, color: color, quiet: quiet, <ins> test_threads: test_threads, </ins> }; Some(Ok(test_opts))


Question:
Discussion carried over from: rust-lang/cargo Test binaries created by rustc should have a option instead of (in addition to?) controlling the thread count with . It's not a consistent user experience to have some functionality controlled via environment variables and some via command line options. CLI options should be preferred since they encourage users to keep configuration local to a single execution of a test binary and not export it globally, making it affect other test runs perhaps accidentally. It would also make the output of more uniform and compact.
Agreed.
The ability to specify this in the somehow might be nice. One of my crates I'm working on needs all the tests run like this.
It is already set table by an env var, no? Cargo just can't specify them. So still not ideal but might work in the meantime. On Apr 16, 2016, 19:05 -0400, Nathan , wrote:
Oh cool thanks, I'll set that in my project.

} }); <del> // It's tempting to just spawn all the tests at once, but since we have // many tests that run in other processes we would be making a big mess. let concurrency = get_concurrency(); </del> <ins> let concurrency = match opts.test_threads { Some(n) => n, None => get_concurrency(), }; </ins> let mut remaining = filtered_tests; remaining.reverse();


Question:
Discussion carried over from: rust-lang/cargo Test binaries created by rustc should have a option instead of (in addition to?) controlling the thread count with . It's not a consistent user experience to have some functionality controlled via environment variables and some via command line options. CLI options should be preferred since they encourage users to keep configuration local to a single execution of a test binary and not export it globally, making it affect other test runs perhaps accidentally. It would also make the output of more uniform and compact.
Agreed.
The ability to specify this in the somehow might be nice. One of my crates I'm working on needs all the tests run like this.
It is already set table by an env var, no? Cargo just can't specify them. So still not ideal but might work in the meantime. On Apr 16, 2016, 19:05 -0400, Nathan , wrote:
Oh cool thanks, I'll set that in my project.

Err(_) => false }, color: test::AutoColor, <ins> test_threads: None, </ins> } }


Question:
I got the message above,how to fix it?
Urgh. This should never have gotten through the CI bots. Some rules must be being built by the install target that aren't under the normal build.
I will try to look into this today while I'm investigating other nightly breakage.
I assume this is being introduced by the doc comment I wrote here: So the two bugs here are: the above doc comment in dropck. (Presumably just replace the indents with nested bullets.) rules do we need to change to synchronize with the CI bots (to catch this kind of case in the future) -- presumably its happening because attempts to build documentation for rust itself ... which sounds a lot like good old: ; see also
I posted a PR to stop building compiler docs. It does not fix the bug in the docs though.
Fixed.
Er, oh yeah, the underlying problem is not fixed, that the docs have broken examples.
Sigh, actually, I'll call this fixed since the title of the bug is about install failure and that works now. Broken examples in the rustc crate are nbd to me atm.
Just downloaded a fresh install from git and ran on a virgin arch linux box running on AWS and getting this error again cfg: using CC=gcc (CFGCC) cfg: disabling valgrind run-pass tests cfg: including prepare rules cfg: including dist rules cfg: including install rules cleaning destination tmp/dist/rustc-1.5.0-dev-x8664-unknown-linux-gnu-image prepare: tmp/dist/rustc-1.5.0-dev-x8664-unknown-linux-gnu-image/bin prepare: tmp/dist/rustc-1.5.0-dev-x8664-unknown-linux-gnu-image/lib prepare: tmp/dist/rustc-1.5.0-dev-x8664-unknown-linux-gnu-image/lib/rustlib/etc prepare: tmp/dist/rustc-1.5.0-dev-x8664-unknown-linux-gnu-image/share/man/man1 rustc: x8664-unknown-linux-gnu/stage0/lib/rustlib/x8664-unknown-linux-gnu/lib/librustc recipe for target 'x8664-unknown-linux-gnu/stage0/lib/rustlib/x8664-unknown-linux-' failed make[1]:  [x8664-unknown-linux-gnu/stage0/lib/rustlib/x8664-unknown-linux-] Killed make[1]: Leaving directory '/root/Downloads/rust' recipe for target 'install' failed make:  [install] Error 2 any ideas

dist-install-dir-$(1): PREPARE_LIB_CMD=$(DEFAULT_PREPARE_LIB_CMD) dist-install-dir-$(1): PREPARE_MAN_CMD=$(DEFAULT_PREPARE_MAN_CMD) dist-install-dir-$(1): PREPARE_CLEAN=true <del> dist-install-dir-$(1): prepare-base-dir-$(1) docs compiler-docs </del> <ins> dist-install-dir-$(1): prepare-base-dir-$(1) docs </ins> $$(Q)mkdir -p $$(PREPARE_DEST_DIR)/share/doc/rust $$(Q)$$(PREPARE_MAN_CMD) $$(S)COPYRIGHT $$(PREPARE_DEST_DIR)/share/doc/rust $$(Q)$$(PREPARE_MAN_CMD) $$(S)LICENSE-APACHE $$(PREPARE_DEST_DIR)/share/doc/rust


Question:
I got the message above,how to fix it?
Urgh. This should never have gotten through the CI bots. Some rules must be being built by the install target that aren't under the normal build.
I will try to look into this today while I'm investigating other nightly breakage.
I assume this is being introduced by the doc comment I wrote here: So the two bugs here are: the above doc comment in dropck. (Presumably just replace the indents with nested bullets.) rules do we need to change to synchronize with the CI bots (to catch this kind of case in the future) -- presumably its happening because attempts to build documentation for rust itself ... which sounds a lot like good old: ; see also
I posted a PR to stop building compiler docs. It does not fix the bug in the docs though.
Fixed.
Er, oh yeah, the underlying problem is not fixed, that the docs have broken examples.
Sigh, actually, I'll call this fixed since the title of the bug is about install failure and that works now. Broken examples in the rustc crate are nbd to me atm.
Just downloaded a fresh install from git and ran on a virgin arch linux box running on AWS and getting this error again cfg: using CC=gcc (CFGCC) cfg: disabling valgrind run-pass tests cfg: including prepare rules cfg: including dist rules cfg: including install rules cleaning destination tmp/dist/rustc-1.5.0-dev-x8664-unknown-linux-gnu-image prepare: tmp/dist/rustc-1.5.0-dev-x8664-unknown-linux-gnu-image/bin prepare: tmp/dist/rustc-1.5.0-dev-x8664-unknown-linux-gnu-image/lib prepare: tmp/dist/rustc-1.5.0-dev-x8664-unknown-linux-gnu-image/lib/rustlib/etc prepare: tmp/dist/rustc-1.5.0-dev-x8664-unknown-linux-gnu-image/share/man/man1 rustc: x8664-unknown-linux-gnu/stage0/lib/rustlib/x8664-unknown-linux-gnu/lib/librustc recipe for target 'x8664-unknown-linux-gnu/stage0/lib/rustlib/x8664-unknown-linux-' failed make[1]:  [x8664-unknown-linux-gnu/stage0/lib/rustlib/x8664-unknown-linux-] Killed make[1]: Leaving directory '/root/Downloads/rust' recipe for target 'install' failed make:  [install] Error 2 any ideas

--legacy-manifest-dirs=rustlib,cargo $$(Q)rm -R tmp/dist/$$(PKG_NAME)-$(1)-image <del> dist-doc-install-dir-$(1): docs compiler-docs </del> <ins> dist-doc-install-dir-$(1): docs </ins> $$(Q)mkdir -p tmp/dist/$$(DOC_PKG_NAME)-$(1)-image/share/doc/rust $$(Q)cp -r doc tmp/dist/$$(DOC_PKG_NAME)-$(1)-image/share/doc/rust/html


Question:
I got the message above,how to fix it?
Urgh. This should never have gotten through the CI bots. Some rules must be being built by the install target that aren't under the normal build.
I will try to look into this today while I'm investigating other nightly breakage.
I assume this is being introduced by the doc comment I wrote here: So the two bugs here are: the above doc comment in dropck. (Presumably just replace the indents with nested bullets.) rules do we need to change to synchronize with the CI bots (to catch this kind of case in the future) -- presumably its happening because attempts to build documentation for rust itself ... which sounds a lot like good old: ; see also
I posted a PR to stop building compiler docs. It does not fix the bug in the docs though.
Fixed.
Er, oh yeah, the underlying problem is not fixed, that the docs have broken examples.
Sigh, actually, I'll call this fixed since the title of the bug is about install failure and that works now. Broken examples in the rustc crate are nbd to me atm.
Just downloaded a fresh install from git and ran on a virgin arch linux box running on AWS and getting this error again cfg: using CC=gcc (CFGCC) cfg: disabling valgrind run-pass tests cfg: including prepare rules cfg: including dist rules cfg: including install rules cleaning destination tmp/dist/rustc-1.5.0-dev-x8664-unknown-linux-gnu-image prepare: tmp/dist/rustc-1.5.0-dev-x8664-unknown-linux-gnu-image/bin prepare: tmp/dist/rustc-1.5.0-dev-x8664-unknown-linux-gnu-image/lib prepare: tmp/dist/rustc-1.5.0-dev-x8664-unknown-linux-gnu-image/lib/rustlib/etc prepare: tmp/dist/rustc-1.5.0-dev-x8664-unknown-linux-gnu-image/share/man/man1 rustc: x8664-unknown-linux-gnu/stage0/lib/rustlib/x8664-unknown-linux-gnu/lib/librustc recipe for target 'x8664-unknown-linux-gnu/stage0/lib/rustlib/x8664-unknown-linux-' failed make[1]:  [x8664-unknown-linux-gnu/stage0/lib/rustlib/x8664-unknown-linux-] Killed make[1]: Leaving directory '/root/Downloads/rust' recipe for target 'install' failed make:  [install] Error 2 any ideas

# Just copy the docs to a folder under dist with the appropriate name # for uploading to S3 <del> dist-docs: docs compiler-docs </del> <ins> dist-docs: docs </ins> $(Q) rm -Rf dist/doc $(Q) mkdir -p dist/doc/ $(Q) cp -r doc dist/doc/$(CFG_PACKAGE_VERS)


Question:
Currently there isn't documentation explaining how the character works
Are you referring to its usage or implementation. Currently the book provides a very brief description of what _ does, however I could write up something slightly more detailed if desired. (see below):
Hmm, the conversation that starts here might be interesting

[tuples]: primitive-types.html#tuples [enums]: enums.html <ins> # Ignoring bindings You can use `_` in a pattern to disregard the value. For example, here’s a `match` against a `Result<T, E>`: ```rust # let some_value: Result<i32, &'static str> = Err("There was an error"); match some_value { Ok(value) => println!("got a value: {}", value), Err(_) => println!("an error occurred"), } ``` In the first arm, we bind the value inside the `Ok` variant to `value`. But in the `Err` arm, we use `_` to disregard the specific error, and just print a general error message. `_` is valid in any pattern that creates a binding. This can be useful to ignore parts of a larger structure: ```rust fn coordinate() -> (i32, i32, i32) { // generate and return some sort of triple tuple # (1, 2, 3) } let (x, _, z) = coordinate(); ``` Here, we bind the first and last element of the tuple to `x` and `z`, but ignore the middle element. </ins> # Mix and Match Whew! That’s a lot of different ways to match things, and they can all be


Question:
The configure script begins with: This works on machines where bash implements its own version of sh. But fails on Solaris where sh and bash are separated programs. To fix, I changed that first line into: And after that it ran.
cf. .
If the problem here is that we are using bashisms in the configure script, I would rather fix that.
works for me today. Was this issue fixed? I remember some other issues...
works, but the installer has the same issue. For this reason, doesn't work on Solaris.
According to , as one example, gen- is using bashsims or other shell extensions: But in all honesty, I don't think it's worth it. I would encourage you to either rewrite the script in Python (such that it is compatible with Python 2.x and 3.x) or simply change the scripts to use instead. On Solaris, is the traditional bourne shell, not bash, and is not even POSIX compliant. This is for backwards-compatibility reasons, among others. The posix shell is .

use build_helper::output; <ins> #[cfg(not(target_os = "solaris"))] const SH_CMD: &'static str = "sh"; // On Solaris, sh is the historical bourne shell, not a POSIX shell, or bash. #[cfg(target_os = "solaris")] const SH_CMD: &'static str = "bash"; </ins> use {Build, Compiler, Mode}; use util::{cp_r, libdir, is_dylib, cp_filtered, copy};


Question:
The configure script begins with: This works on machines where bash implements its own version of sh. But fails on Solaris where sh and bash are separated programs. To fix, I changed that first line into: And after that it ran.
cf. .
If the problem here is that we are using bashisms in the configure script, I would rather fix that.
works for me today. Was this issue fixed? I remember some other issues...
works, but the installer has the same issue. For this reason, doesn't work on Solaris.
According to , as one example, gen- is using bashsims or other shell extensions: But in all honesty, I don't think it's worth it. I would encourage you to either rewrite the script in Python (such that it is compatible with Python 2.x and 3.x) or simply change the scripts to use instead. On Solaris, is the traditional bourne shell, not bash, and is not even POSIX compliant. This is for backwards-compatibility reasons, among others. The posix shell is .

let src = build.out.join(host).join("doc"); cp_r(&src, &dst); <del> let mut cmd = Command::new("sh"); </del> <ins> let mut cmd = Command::new(SH_CMD); </ins> cmd.arg(sanitize_sh(&build.src.join("src/rust-installer/gen-installer.sh"))) .arg("--product-name=Rust-Documentation") .arg("--rel-manifest-dir=rustlib")


Question:
The configure script begins with: This works on machines where bash implements its own version of sh. But fails on Solaris where sh and bash are separated programs. To fix, I changed that first line into: And after that it ran.
cf. .
If the problem here is that we are using bashisms in the configure script, I would rather fix that.
works for me today. Was this issue fixed? I remember some other issues...
works, but the installer has the same issue. For this reason, doesn't work on Solaris.
According to , as one example, gen- is using bashsims or other shell extensions: But in all honesty, I don't think it's worth it. I would encourage you to either rewrite the script in Python (such that it is compatible with Python 2.x and 3.x) or simply change the scripts to use instead. On Solaris, is the traditional bourne shell, not bash, and is not even POSIX compliant. This is for backwards-compatibility reasons, among others. The posix shell is .

.arg(host); build.run(&mut cmd); <del> let mut cmd = Command::new("sh"); </del> <ins> let mut cmd = Command::new(SH_CMD); </ins> cmd.arg(sanitize_sh(&build.src.join("src/rust-installer/gen-installer.sh"))) .arg("--product-name=Rust-MinGW") .arg("--rel-manifest-dir=rustlib")


Question:
The configure script begins with: This works on machines where bash implements its own version of sh. But fails on Solaris where sh and bash are separated programs. To fix, I changed that first line into: And after that it ran.
cf. .
If the problem here is that we are using bashisms in the configure script, I would rather fix that.
works for me today. Was this issue fixed? I remember some other issues...
works, but the installer has the same issue. For this reason, doesn't work on Solaris.
According to , as one example, gen- is using bashsims or other shell extensions: But in all honesty, I don't think it's worth it. I would encourage you to either rewrite the script in Python (such that it is compatible with Python 2.x and 3.x) or simply change the scripts to use instead. On Solaris, is the traditional bourne shell, not bash, and is not even POSIX compliant. This is for backwards-compatibility reasons, among others. The posix shell is .

} // Finally, wrap everything up in a nice tarball! <del> let mut cmd = Command::new("sh"); </del> <ins> let mut cmd = Command::new(SH_CMD); </ins> cmd.arg(sanitize_sh(&build.src.join("src/rust-installer/gen-installer.sh"))) .arg("--product-name=Rust") .arg("--rel-manifest-dir=rustlib")


Question:
The configure script begins with: This works on machines where bash implements its own version of sh. But fails on Solaris where sh and bash are separated programs. To fix, I changed that first line into: And after that it ran.
cf. .
If the problem here is that we are using bashisms in the configure script, I would rather fix that.
works for me today. Was this issue fixed? I remember some other issues...
works, but the installer has the same issue. For this reason, doesn't work on Solaris.
According to , as one example, gen- is using bashsims or other shell extensions: But in all honesty, I don't think it's worth it. I would encourage you to either rewrite the script in Python (such that it is compatible with Python 2.x and 3.x) or simply change the scripts to use instead. On Solaris, is the traditional bourne shell, not bash, and is not even POSIX compliant. This is for backwards-compatibility reasons, among others. The posix shell is .

let src = build.sysroot(compiler).join("lib/rustlib"); cp_r(&src.join(target), &dst); <del> let mut cmd = Command::new("sh"); </del> <ins> let mut cmd = Command::new(SH_CMD); </ins> cmd.arg(sanitize_sh(&build.src.join("src/rust-installer/gen-installer.sh"))) .arg("--product-name=Rust") .arg("--rel-manifest-dir=rustlib")


Question:
The configure script begins with: This works on machines where bash implements its own version of sh. But fails on Solaris where sh and bash are separated programs. To fix, I changed that first line into: And after that it ran.
cf. .
If the problem here is that we are using bashisms in the configure script, I would rather fix that.
works for me today. Was this issue fixed? I remember some other issues...
works, but the installer has the same issue. For this reason, doesn't work on Solaris.
According to , as one example, gen- is using bashsims or other shell extensions: But in all honesty, I don't think it's worth it. I would encourage you to either rewrite the script in Python (such that it is compatible with Python 2.x and 3.x) or simply change the scripts to use instead. On Solaris, is the traditional bourne shell, not bash, and is not even POSIX compliant. This is for backwards-compatibility reasons, among others. The posix shell is .

let image_src = src.join("save-analysis"); let dst = image.join("lib/rustlib").join(target).join("analysis"); t!(fs::create_dir_all(&dst)); <ins> println!("image_src: {:?}, dst: {:?}", image_src, dst); </ins> cp_r(&image_src, &dst); <del> let mut cmd = Command::new("sh"); </del> <ins> let mut cmd = Command::new(SH_CMD); </ins> cmd.arg(sanitize_sh(&build.src.join("src/rust-installer/gen-installer.sh"))) .arg("--product-name=Rust") .arg("--rel-manifest-dir=rustlib")


Question:
The configure script begins with: This works on machines where bash implements its own version of sh. But fails on Solaris where sh and bash are separated programs. To fix, I changed that first line into: And after that it ran.
cf. .
If the problem here is that we are using bashisms in the configure script, I would rather fix that.
works for me today. Was this issue fixed? I remember some other issues...
works, but the installer has the same issue. For this reason, doesn't work on Solaris.
According to , as one example, gen- is using bashsims or other shell extensions: But in all honesty, I don't think it's worth it. I would encourage you to either rewrite the script in Python (such that it is compatible with Python 2.x and 3.x) or simply change the scripts to use instead. On Solaris, is the traditional bourne shell, not bash, and is not even POSIX compliant. This is for backwards-compatibility reasons, among others. The posix shell is .

build.run(&mut cmd); // Create source tarball in rust-installer format <del> let mut cmd = Command::new("sh"); </del> <ins> let mut cmd = Command::new(SH_CMD); </ins> cmd.arg(sanitize_sh(&build.src.join("src/rust-installer/gen-installer.sh"))) .arg("--product-name=Rust") .arg("--rel-manifest-dir=rustlib")


Question:
The configure script begins with: This works on machines where bash implements its own version of sh. But fails on Solaris where sh and bash are separated programs. To fix, I changed that first line into: And after that it ran.
cf. .
If the problem here is that we are using bashisms in the configure script, I would rather fix that.
works for me today. Was this issue fixed? I remember some other issues...
works, but the installer has the same issue. For this reason, doesn't work on Solaris.
According to , as one example, gen- is using bashsims or other shell extensions: But in all honesty, I don't think it's worth it. I would encourage you to either rewrite the script in Python (such that it is compatible with Python 2.x and 3.x) or simply change the scripts to use instead. On Solaris, is the traditional bourne shell, not bash, and is not even POSIX compliant. This is for backwards-compatibility reasons, among others. The posix shell is .

input_tarballs.push_str(&sanitize_sh(&mingw_installer)); } <del> let mut cmd = Command::new("sh"); </del> <ins> let mut cmd = Command::new(SH_CMD); </ins> cmd.arg(sanitize_sh(&build.src.join("src/rust-installer/combine-installers.sh"))) .arg("--product-name=Rust") .arg("--rel-manifest-dir=rustlib")


Question: In it could be useful to explain the and syntax for getting a substring slice. Looking for a way to get a substring reference one is currently with the str API documentation which is quite a lot to digest and if one manages to find the unstable slice_chars(...) it says "Use slicing syntax if you want to use byte indices rather than codepoint indices", but what "slicing syntax" means will probably not be clear to someone who is new to Rust and not yet familiar with the Index trait.

This emphasizes that we have to go through the whole list of `chars`. <ins> ## Slicing You can get a slice of a string with slicing syntax: ```rust let dog = "hachiko"; let hachi = &dog[0..5]; ``` But note that these are _byte_ offsets, not _character_ offsets. So this will fail at runtime: ```rust,should_panic let dog = "忠犬ハチ公"; let hachi = &dog[0..2]; ``` with this error: ```text thread '<main>' panicked at 'index 0 and/or 2 in `忠犬ハチ公` do not lie on character boundary' ``` </ins> ## Concatenation If you have a `String`, you can concatenate a `&str` to the end of it:


Question:
From , (I assume identical to ) should report nanosecond times as or , not . This reportedly would require fixing in libtest.
I posted a PR for this yesterday. Well I chose to round & use units, but you can opine either way
nice! If you'll just tag that as fixing this then bors will take care of the rest.

} } <ins> // Format a number with thousands separators fn fmt_thousands_sep(mut n: usize, sep: char) -> String { use std::fmt::Write; let mut output = String::new(); let mut first = true; for &pow in &[9, 6, 3, 0] { let base = 10_usize.pow(pow); if pow == 0 || n / base != 0 { if first { output.write_fmt(format_args!("{}", n / base)).unwrap(); } else { output.write_fmt(format_args!("{:03}", n / base)).unwrap(); } if pow != 0 { output.push(sep); } first = false; } n %= base; } output } </ins> pub fn fmt_bench_samples(bs: &BenchSamples) -> String { <ins> use std::fmt::Write; let mut output = String::new(); let median = bs.ns_iter_summ.median as usize; let deviation = (bs.ns_iter_summ.max - bs.ns_iter_summ.min) as usize; output.write_fmt(format_args!("{:>11} ns/iter (+/- {})", fmt_thousands_sep(median, ','), fmt_thousands_sep(deviation, ','))).unwrap(); </ins> if bs.mb_s != 0 { <del> format!("{:>9} ns/iter (+/- {}) = {} MB/s", bs.ns_iter_summ.median as usize, (bs.ns_iter_summ.max - bs.ns_iter_summ.min) as usize, bs.mb_s) } else { format!("{:>9} ns/iter (+/- {})", bs.ns_iter_summ.median as usize, (bs.ns_iter_summ.max - bs.ns_iter_summ.min) as usize) </del> <ins> output.write_fmt(format_args!(" = {} MB/s", bs.mb_s)).unwrap(); </ins> } <ins> output </ins> } // A simple console test runner


Question:
A comment suggests the type should be something richer, perhaps, than just .
Blocked on or something similar
Definitely not backwards incompatible for 1.0 if this depends on Rust 2.0 features. Renominating.
Nominating for "far-future" (does that require nomination?)
FIXME is gone, bug is too vague, closing

branches: - 'master' schedule: <del> - cron: '5 15 * * *' # At 15:05 UTC every day. </del> <ins> - cron: '6 6 * * *' # At 6:06 UTC every day. </ins> env: CARGO_UNSTABLE_SPARSE_REGISTRY: 'true'


Question:
A comment suggests the type should be something richer, perhaps, than just .
Blocked on or something similar
Definitely not backwards incompatible for 1.0 if this depends on Rust 2.0 features. Renominating.
Nominating for "far-future" (does that require nomination?)
FIXME is gone, bug is too vague, closing

strategy: fail-fast: false matrix: <del> build: [linux64, macos, win32] </del> include: <del> - build: linux64 os: ubuntu-latest </del> <ins> - os: ubuntu-latest </ins> host_target: x86_64-unknown-linux-gnu <del> - build: macos os: macos-latest </del> <ins> - os: macos-latest </ins> host_target: x86_64-apple-darwin <del> - build: win32 os: windows-latest </del> <ins> - os: windows-latest </ins> host_target: i686-pc-windows-msvc steps: - uses: actions/checkout@v3


Question:
A comment suggests the type should be something richer, perhaps, than just .
Blocked on or something similar
Definitely not backwards incompatible for 1.0 if this depends on Rust 2.0 features. Renominating.
Nominating for "far-future" (does that require nomination?)
FIXME is gone, bug is too vague, closing

;; i686-pc-windows-msvc) MIRI_TEST_TARGET=x86_64-unknown-linux-gnu run_tests <ins> MIRI_TEST_TARGET=x86_64-pc-windows-gnu run_tests </ins> ;; *) echo "FATAL: unknown OS"


Question:
A comment suggests the type should be something richer, perhaps, than just .
Blocked on or something similar
Definitely not backwards incompatible for 1.0 if this depends on Rust 2.0 features. Renominating.
Nominating for "far-future" (does that require nomination?)
FIXME is gone, bug is too vague, closing

mir, ty::{self, FloatTy, Ty}, }; <del> use rustc_target::abi::Integer; </del> <ins> use rustc_target::abi::{Integer, Size}; </ins> use crate::*; use atomic::EvalContextExt as _;


Question:
A comment suggests the type should be something richer, perhaps, than just .
Blocked on or something similar
Definitely not backwards incompatible for 1.0 if this depends on Rust 2.0 features. Renominating.
Nominating for "far-future" (does that require nomination?)
FIXME is gone, bug is too vague, closing

this.write_bytes_ptr(ptr, iter::repeat(val_byte).take(byte_count.bytes_usize()))?; } <ins> "ptr_mask" => { let [ptr, mask] = check_arg_count(args)?; let ptr = this.read_pointer(ptr)?; let mask = this.read_scalar(mask)?.to_machine_usize(this)?; let masked_addr = Size::from_bytes(ptr.addr().bytes() & mask); this.write_pointer(Pointer::new(ptr.provenance, masked_addr), dest)?; } </ins> // Floating-point operations "fabsf32" => { let [f] = check_arg_count(args)?;


Question:
A comment suggests the type should be something richer, perhaps, than just .
Blocked on or something similar
Definitely not backwards incompatible for 1.0 if this depends on Rust 2.0 features. Renominating.
Nominating for "far-future" (does that require nomination?)
FIXME is gone, bug is too vague, closing

let [name] = this.check_shim(abi, Abi::C { unwind: false }, link_name, args)?; let thread = this.pthread_self()?; let max_len = this.eval_libc("MAXTHREADNAMESIZE")?.to_machine_usize(this)?; <del> this.pthread_setname_np( </del> <ins> let res = this.pthread_setname_np( </ins> thread, this.read_scalar(name)?, max_len.try_into().unwrap(), )?; <ins> // Contrary to the manpage, `pthread_setname_np` on macOS still // returns an integer indicating success. this.write_scalar(res, dest)?; </ins> } "pthread_getname_np" => { let [thread, name, len] =


Question:
A comment suggests the type should be something richer, perhaps, than just .
Blocked on or something similar
Definitely not backwards incompatible for 1.0 if this depends on Rust 2.0 features. Renominating.
Nominating for "far-future" (does that require nomination?)
FIXME is gone, bug is too vague, closing

//@ignore-target-windows: No libc on Windows #![feature(cstr_from_bytes_until_nul)] <del> use std::ffi::CStr; </del> <ins> use std::ffi::{CStr, CString}; </ins> use std::thread; fn main() {


Question:
A comment suggests the type should be something richer, perhaps, than just .
Blocked on or something similar
Definitely not backwards incompatible for 1.0 if this depends on Rust 2.0 features. Renominating.
Nominating for "far-future" (does that require nomination?)
FIXME is gone, bug is too vague, closing

.chain(std::iter::repeat(" yada").take(100)) .collect::<String>(); <ins> fn set_thread_name(name: &CStr) -> i32 { #[cfg(target_os = "linux")] return unsafe { libc::pthread_setname_np(libc::pthread_self(), name.as_ptr().cast()) }; #[cfg(target_os = "macos")] return unsafe { libc::pthread_setname_np(name.as_ptr().cast()) }; } </ins> let result = thread::Builder::new().name(long_name.clone()).spawn(move || { // Rust remembers the full thread name itself. assert_eq!(thread::current().name(), Some(long_name.as_str()));


Question:
A comment suggests the type should be something richer, perhaps, than just .
Blocked on or something similar
Definitely not backwards incompatible for 1.0 if this depends on Rust 2.0 features. Renominating.
Nominating for "far-future" (does that require nomination?)
FIXME is gone, bug is too vague, closing

// But the system is limited -- make sure we successfully set a truncation. let mut buf = vec![0u8; long_name.len() + 1]; unsafe { <del> libc::pthread_getname_np(libc::pthread_self(), buf.as_mut_ptr().cast(), buf.len()); } </del> <ins> libc::pthread_getname_np(libc::pthread_self(), buf.as_mut_ptr().cast(), buf.len()) }; </ins> let cstr = CStr::from_bytes_until_nul(&buf).unwrap(); assert!(cstr.to_bytes().len() >= 15); // POSIX seems to promise at least 15 chars assert!(long_name.as_bytes().starts_with(cstr.to_bytes())); <ins> // Also test directly calling pthread_setname to check its return value. assert_eq!(set_thread_name(&cstr), 0); // But with a too long name it should fail. assert_ne!(set_thread_name(&CString::new(long_name).unwrap()), 0); </ins> }); result.unwrap().join().unwrap(); }


Question:
A comment suggests the type should be something richer, perhaps, than just .
Blocked on or something similar
Definitely not backwards incompatible for 1.0 if this depends on Rust 2.0 features. Renominating.
Nominating for "far-future" (does that require nomination?)
FIXME is gone, bug is too vague, closing

<ins> #![feature(ptr_mask)] #![feature(strict_provenance)] fn main() { let v: u32 = 0xABCDABCD; let ptr: *const u32 = &v; // u32 is 4 aligned, // so the lower `log2(4) = 2` bits of the address are always 0 assert_eq!(ptr.addr() & 0b11, 0); let tagged_ptr = ptr.map_addr(|a| a | 0b11); let tag = tagged_ptr.addr() & 0b11; let masked_ptr = tagged_ptr.mask(!0b11); assert_eq!(tag, 0b11); assert_eq!(unsafe { *masked_ptr }, 0xABCDABCD); } </ins>


Question:
Atomics are a language feature that the compiler (LLVM) has to have a deep understanding of in its optimization passes. Send and Sync are also opt-in-built-in-traits, which makes them a pseudo-language construct.
Does this mean Atomics should be mentioned in the Language Reference? What about Send and Sync? Currently, only Sync is mentioned, and that only in passing.

concurrent code at compile time. Before we talk about the concurrency features that come with Rust, it's important <del> to understand something: Rust is low-level enough that all of this is provided by the standard library, not by the language. This means that if you don't like some aspect of the way Rust handles concurrency, you can implement an alternative way of doing things. [mio](https://github.com/carllerche/mio) is a real-world example of this principle in action. </del> <ins> to understand something: Rust is low-level enough that the vast majority of this is provided by the standard library, not by the language. This means that if you don't like some aspect of the way Rust handles concurrency, you can implement an alternative way of doing things. [mio](https://github.com/carllerche/mio) is a real-world example of this principle in action. </ins> ## Background: `Send` and `Sync`


Question:
yields practically no information, and to even figure out what type of error occurred a user has to go run another rust script to use the Display implementation on an error with that os error code. It's not a good UX.
The Debug impl is used quite often, especially through unwrap.
You can look up the error code via (e.g. ). In fact on Windows the standard way to report an error is via its status.
I appreciate the tip, but still consider this is a serious UX problem since I really shouldn't need python to conveniently find out what kind of error I'm dealing with.

repr: Repr, } <del> #[derive(Debug)] </del> enum Repr { Os(i32), Custom(Box<Custom>),


Question:
yields practically no information, and to even figure out what type of error occurred a user has to go run another rust script to use the Display implementation on an error with that os error code. It's not a good UX.
The Debug impl is used quite often, especially through unwrap.
You can look up the error code via (e.g. ). In fact on Windows the standard way to report an error is via its status.
I appreciate the tip, but still consider this is a serious UX problem since I really shouldn't need python to conveniently find out what kind of error I'm dealing with.

} } <ins> impl fmt::Debug for Repr { fn fmt(&self, fmt: &mut fmt::Formatter) -> fmt::Result { match self { &Repr::Os(ref code) => fmt.debug_struct("Os").field("code", code) .field("message", &sys::os::error_string(*code)).finish(), &Repr::Custom(ref c) => fmt.debug_tuple("Custom").field(c).finish(), } } } </ins> #[stable(feature = "rust1", since = "1.0.0")] impl fmt::Display for Error { fn fmt(&self, fmt: &mut fmt::Formatter) -> fmt::Result {


Question:
yields practically no information, and to even figure out what type of error occurred a user has to go run another rust script to use the Display implementation on an error with that os error code. It's not a good UX.
The Debug impl is used quite often, especially through unwrap.
You can look up the error code via (e.g. ). In fact on Windows the standard way to report an error is via its status.
I appreciate the tip, but still consider this is a serious UX problem since I really shouldn't need python to conveniently find out what kind of error I'm dealing with.

use error; use error::Error as error_Error; use fmt; <ins> use sys::os::error_string; #[test] fn test_debug_error() { let code = 6; let msg = error_string(code); let err = Error { repr: super::Repr::Os(code) }; let expected = format!("Error {{ repr: Os {{ code: {:?}, message: {:?} }} }}", code, msg); assert_eq!(format!("{:?}", err), expected); } </ins> #[test] fn test_downcasting() {


Question: !.html states that the macro will return a , where in reality it returns . Example: This same problem exists for as well: Documentation at: !.html.

/// A macro which expands to the line number on which it was invoked. /// <del> /// The expanded expression has type `usize`, and the returned line is not </del> <ins> /// The expanded expression has type `u32`, and the returned line is not </ins> /// the invocation of the `line!()` macro itself, but rather the first macro /// invocation leading up to the invocation of the `line!()` macro. ///


Question: !.html states that the macro will return a , where in reality it returns . Example: This same problem exists for as well: Documentation at: !.html.

/// A macro which expands to the column number on which it was invoked. /// <del> /// The expanded expression has type `usize`, and the returned column is not </del> <ins> /// The expanded expression has type `u32`, and the returned column is not </ins> /// the invocation of the `column!()` macro itself, but rather the first macro /// invocation leading up to the invocation of the `column!()` macro. ///


Question:
but The order of the fields is important, and this is something that should be clearly documented, as changing the order of the fields of a struct can change program logic.
generates a lexicographic ordering.

/// /// - total and antisymmetric: exactly one of `a < b`, `a == b` or `a > b` is true; and /// - transitive, `a < b` and `b < c` implies `a < c`. The same must hold for both `==` and `>`. <ins> /// /// When this trait is `derive`d, it produces a lexicographic ordering. </ins> #[stable(feature = "rust1", since = "1.0.0")] pub trait Ord: Eq + PartialOrd<Self> { /// This method returns an `Ordering` between `self` and `other`.


Question: This causes a ICE: If the trait is defined in the same crate it compiles without error. Backtrace:

encode_item_sort(rbml_w, 't'); encode_family(rbml_w, 'y'); <ins> if let Some(ty) = associated_type.ty { encode_type(ecx, rbml_w, ty); } </ins> is_nonstatic_method = false; } }


Question: This causes a ICE: If the trait is defined in the same crate it compiles without error. Backtrace:

// ought to be reported by the type checker method // `check_impl_items_against_trait`, so here we // just return TyError. <ins> debug!("confirm_impl_candidate: no associated type {:?} for {:?}", assoc_ty.name, trait_ref); </ins> return (selcx.tcx().types.err, vec!()); } }


Question: This causes a ICE: If the trait is defined in the same crate it compiles without error. Backtrace:

<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. pub trait Foo { type Input = usize; fn bar(&self, _: Self::Input) {} } impl Foo for () {} </ins>


Question: This causes a ICE: If the trait is defined in the same crate it compiles without error. Backtrace:

<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. // aux-build:xcrate_associated_type_defaults.rs extern crate xcrate_associated_type_defaults; use xcrate_associated_type_defaults::Foo; fn main() { ().bar(5); } </ins>


Question:
Actually what happens here is the following: The tuple you create in is moved, because it is not . When you perform the you move out of , into , leaving uninitialized. Your assignment to is basically to uninitialized memory, and doesn't have an effect. When you perform the assertion you see the old value of , because your assignment to had no effect. The whole thing is confusing because Rust does not warn when you perform useless assignments to moved variables, and it probably should. The whole thing becomes obviously when you add a statement that uses in the match arm: Edit: the labels you have assigned to this issue are incorrect.
Don't we see the new value , even though we're accessing , when performing the assertion, which causes it to fail? Doing this without a match statement passes the same assertion sucessfully:
Oops, you are correct, I am mistaken :( , mitaa wrote:
heh, I made the same mistake. Typed out most of a response and then realised that I'd mis-read the code.

match base_cmt.cat { mc::cat_upvar(mc::Upvar { id: ty::UpvarId { var_id: vid, .. }, .. }) | mc::cat_local(vid) => { <del> self.reassigned |= self.node == vid && Some(field) == self.field </del> <ins> self.reassigned |= self.node == vid && (self.field.is_none() || Some(field) == self.field) </ins> }, _ => {} }


Question:
Actually what happens here is the following: The tuple you create in is moved, because it is not . When you perform the you move out of , into , leaving uninitialized. Your assignment to is basically to uninitialized memory, and doesn't have an effect. When you perform the assertion you see the old value of , because your assignment to had no effect. The whole thing is confusing because Rust does not warn when you perform useless assignments to moved variables, and it probably should. The whole thing becomes obviously when you add a statement that uses in the match arm: Edit: the labels you have assigned to this issue are incorrect.
Don't we see the new value , even though we're accessing , when performing the assertion, which causes it to fail? Doing this without a match statement passes the same assertion sucessfully:
Oops, you are correct, I am mistaken :( , mitaa wrote:
heh, I made the same mistake. Typed out most of a response and then realised that I'd mis-read the code.

<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. fn main() { let mut c = (1, "".to_owned()); match c { c2 => { c.0 = 2; assert_eq!(c2.0, 1); } } } </ins>


Question:
This code produces "error: expected one of , , , or , found ":
That code sample probably didn't require linking to a playpen, I've made the description and title more useful.

// FOREIGN STATIC ITEM return Ok(Some(self.parse_item_foreign_static(visibility, lo, attrs)?)); } <del> if self.check_keyword(keywords::Fn) || self.check_keyword(keywords::Unsafe) { </del> <ins> if self.check_keyword(keywords::Fn) { </ins> // FOREIGN FUNCTION ITEM return Ok(Some(self.parse_item_foreign_fn(visibility, lo, attrs)?)); }


Question:
This code produces "error: expected one of , , , or , found ":
That code sample probably didn't require linking to a playpen, I've made the description and title more useful.

// compile-flags: -Z parse-only extern { <del> f(); //~ ERROR expected one of `fn`, `pub`, `static`, `unsafe`, or `}`, found `f` </del> <ins> f(); //~ ERROR expected one of `fn`, `pub`, `static`, or `}`, found `f` </ins> } fn main() {


Question:
This code produces "error: expected one of , , , or , found ":
That code sample probably didn't require linking to a playpen, I've made the description and title more useful.

extern { const i: isize; <del> //~^ ERROR expected one of `fn`, `pub`, `static`, `unsafe`, or `}`, found `const` </del> <ins> //~^ ERROR expected one of `fn`, `pub`, `static`, or `}`, found `const` </ins> }


Question:
This is a tracking issue for the unstable methods in the standard library. cc perhaps you can fill this in some more? The specific methods in question are: -
This is basically a lame version of cursors, which is what we should use instead imo. It's not 1:1 though -- this api lets you have all the elements yielded at once. Classic iterator tradeoff.
Triage: these are still unstable.
There are some ideas for a more complete API in
seems misnamed. Doesn't it do exactly what we call elsewhere?
I'm going to echo thoughts: An iterator conceptually represents a (double-ended) range of elements. The only operation that it supports is popping an element off the end of that range. A cursor on the other hand represents a position in a collection, and can be moved backwards or forwards in the collection. The cursor can be used to insert or remove an element at any given position in the collection. I strongly oppose adding insertion/deleting methods to since they do not fit at all with existing iterator usage patterns ( loops and functional-style methods). As I mentioned in the linked thread, a design based on the types in could be used.
Since we now have cursors, I think these methods should be removed.
Reopening since we only deprecated the methods instead of removing them. I'd say give it about 2 weeks then remove them.

/// Inserts the given element just after the element most recently returned by `.next()`. /// The inserted element does not appear in the iteration. /// <del> /// # Examples /// /// ``` /// #![feature(linked_list_extras)] /// /// use std::collections::LinkedList; /// /// let mut list: LinkedList<_> = vec![1, 3, 4].into_iter().collect(); /// /// { ///     let mut it = list.iter_mut(); ///     assert_eq!(it.next().unwrap(), &1); ///     // insert `2` after `1` ///     it.insert_next(2); /// } /// { ///     let vec: Vec<_> = list.into_iter().collect(); ///     assert_eq!(vec, [1, 2, 3, 4]); /// } /// ``` </del> <ins> /// This method will be removed soon. </ins> #[inline] #[unstable( feature = "linked_list_extras", reason = "this is probably better handled by a cursor type -- we'll see", issue = "27794" )] <ins> #[rustc_deprecated( reason = "Deprecated in favor of CursorMut methods. This method will be removed soon.", since = "1.47.0" )] </ins> pub fn insert_next(&mut self, element: T) { match self.head { // `push_back` is okay with aliasing `element` references


Question:
This is a tracking issue for the unstable methods in the standard library. cc perhaps you can fill this in some more? The specific methods in question are: -
This is basically a lame version of cursors, which is what we should use instead imo. It's not 1:1 though -- this api lets you have all the elements yielded at once. Classic iterator tradeoff.
Triage: these are still unstable.
There are some ideas for a more complete API in
seems misnamed. Doesn't it do exactly what we call elsewhere?
I'm going to echo thoughts: An iterator conceptually represents a (double-ended) range of elements. The only operation that it supports is popping an element off the end of that range. A cursor on the other hand represents a position in a collection, and can be moved backwards or forwards in the collection. The cursor can be used to insert or remove an element at any given position in the collection. I strongly oppose adding insertion/deleting methods to since they do not fit at all with existing iterator usage patterns ( loops and functional-style methods). As I mentioned in the linked thread, a design based on the types in could be used.
Since we now have cursors, I think these methods should be removed.
Reopening since we only deprecated the methods instead of removing them. I'd say give it about 2 weeks then remove them.

/// Provides a reference to the next element, without changing the iterator. /// <del> /// # Examples /// /// ``` /// #![feature(linked_list_extras)] /// /// use std::collections::LinkedList; /// /// let mut list: LinkedList<_> = vec![1, 2, 3].into_iter().collect(); /// /// let mut it = list.iter_mut(); /// assert_eq!(it.next().unwrap(), &1); /// assert_eq!(it.peek_next().unwrap(), &2); /// // We just peeked at 2, so it was not consumed from the iterator. /// assert_eq!(it.next().unwrap(), &2); /// ``` </del> <ins> /// This method will be removed soon. </ins> #[inline] #[unstable( feature = "linked_list_extras", reason = "this is probably better handled by a cursor type -- we'll see", issue = "27794" )] <ins> #[rustc_deprecated( reason = "Deprecated in favor of CursorMut methods. This method will be removed soon.", since = "1.47.0" )] </ins> pub fn peek_next(&mut self) -> Option<&mut T> { if self.len == 0 { None