jiebi/CodeConvo huggingface dataset:
Code change:
#[license = "MIT/ASL2"]; #[crate_type = "rlib"]; #[crate_type = "dylib"]; <del> #[doc(html_logo_url = "http://www.rust-lang.org/logos/rust-logo-128x128-blk.png", </del> <ins> #[doc(html_logo_url = "http://www.rust-lang.org/logos/rust-logo-128x128-blk-v2.png", </ins> html_favicon_url = "http://www.rust-lang.org/favicon.ico", html_root_url = "http://static.rust-lang.org/doc/master")]; #[deny(unused_result, unused_must_use)];

Related discussion:
text: It's currently very bright and distracting (IMO). (Sorry :( ) Current scheme, for future triage/comparison purposes: !
I think I should reconsider my career in graphic design.
I'm looking at this.
(The relevant file is , if you're lost. :) )
BTW I was wondering, why not just use for src line numbering? Probably more optimized/idiomatic in the browser.
Also, it's pretty much impossible to have consistency between rustdoc and the old codemirror (tutorial) since both parsers behave very differently. would it be possible to pass the standalone documentation through rustdoc?
Doesn't this mean every line is a new tag? Also, it possibly screws with copy-paste and making the formatting consistent. This bug is specifically about the colour scheme of rustdoc since it's so wild. Also, about using rustdoc for everything.
My preference for the highlighting scheme is bold for keywords, green for macros, red for strings (the current color is fine), gray for comments (would be nice if code within comments were highlighted). I'd also like to hear more suggestions before we change it.
Something I hacked up a few days ago: ! (The macro colour wasn't "optimised" at all.)
No, it would look like this: I think it would be better to use that since that's the browser native numberings. No it doesn't. The identifier of a list aren't inlined with the content. is an example.
Oh, awesome. It does seem like a good idea, if you can get that to work.
Another note: current rustdoc parsing could be improved, i.e. the "ident" class corresponds to variable names, function names, paths, parameters... could be more split if you ask me.
The highlighting is performed by just by the token types the lexer (with a little bit of extra logic for attributes, macros and $ non-terminals in macros) and so does not have that information.
Code change:
let out = p.wait_with_output().unwrap(); assert!(!out.status.success()); let s = str::from_utf8(&out.stderr).unwrap(); <del> assert!(!s.contains("stack backtrace") && !s.contains("foo::h"), </del> <ins> assert!(!s.contains("stack backtrace") && !s.contains(" - foo"), </ins> "bad output2: {}", s); // Make sure a stack trace is printed

Related discussion:
text: Symbol names are not properly supported yet on msvc, so backtraces are generally unhelpful. As a result, is currently disabled. This issue can be closed when it's been reenabled.
Code change:
version = "0.0.0" dependencies = [ "arena 0.0.0", <del> "backtrace 0.3.25 (registry+https://github.com/rust-lang/crates.io-index)", </del> <ins> "backtrace 0.3.29 (registry+https://github.com/rust-lang/crates.io-index)", </ins> "bitflags 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)", "byteorder 1.2.7 (registry+https://github.com/rust-lang/crates.io-index)", "chalk-engine 0.9.0 (registry+https://github.com/rust-lang/crates.io-index)",

Related discussion:
text: Every since a recent nightly update, both distributed nightlies and locally built produce backtraces where every level of the stack is represented only by their memory address and the label : Sadly I don't have a more specific repro case, but I can consistently reproduce locally. Older distributed nightlies do not present this behavior.
This happens consistently for me as well (also macOS).
I've been seeing this on Linux too, though it's been at least a week. (It also may have been fixed in a rustc newer than the one servo uses)
We should have tests for backtraces, so they don't regress again in the future.
this is certainly happening on master, and it's been happening for a while, but I assumed it was my env.
It just occurred to me that this might be related to the new symbol mangling (although I doubt it).
I've been experiencing this for about a week now (also on macOS). It definitely started prior to being merged. I also have the following in my :
has absolutely no changes if you don't use the flag, so it's not from there.
It's definitely , I tried before and after. It works if you enable the "coresymbolication" feature, though that's obviously not an option for distribution. I tried the latest master of , but it didn't help.
To confirm, is everyone only experiencing problems on OSX for rustc itself? Are there problems with other projects on OSX? can you please confirm or deny your experience from Linux? Throwing in a new platform here changes this quite a lot
Ok I believe I've found the issue for OSX, but if other platforms are still an issue that would be good to know
I've only experienced this with rustc itself on OSX. Things it builds seem ok, and linux/windows seem to be ok.
No, it's still happening on Linux as of yesterday (I can try again today). I also assumed it was my env.
I think the Linux issue is separate since it's been happening much longer than the OSX one
Hey, this seems to an issue on nightly for Windows (msvc) as well: This uses backtrace via :
if that's only using the crate and not using libstd, can you open an issue on the repository? The OSX issue should be fixed in , which I'd like to finish testing and then I'll send an update to libstd.
Code change:
version = "0.0.0" dependencies = [ "arena 0.0.0", <del> "backtrace 0.3.25 (registry+https://github.com/rust-lang/crates.io-index)", </del> <ins> "backtrace 0.3.29 (registry+https://github.com/rust-lang/crates.io-index)", </ins> "bitflags 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)", "byteorder 1.2.7 (registry+https://github.com/rust-lang/crates.io-index)", "chalk-engine 0.9.0 (registry+https://github.com/rust-lang/crates.io-index)",

Related discussion:
text: That could affect Linux as well but I doubt it, so if there are persisting Linux/Windows issues please feel free to let me know. If you can create an isolated problem which uses the crate rather than libstd that's even better!
Done: rust-lang/backtrace-rs
Code change:
fi fi <del> # Unless we're using an older version of LLVM, check that all LLVM components # used by tests are available. if [ "$IS_NOT_LATEST_LLVM" = "" ]; then export COMPILETEST_NEEDS_ALL_LLVM_COMPONENTS=1 fi </del> if [ "$ENABLE_GCC_CODEGEN" = "1" ]; then # If `ENABLE_GCC_CODEGEN` is set and not empty, we add the `--enable-new-symbol-mangling` # argument to `RUST_CONFIGURE_ARGS` and set the `GCC_EXEC_PREFIX` environment variable.

Related discussion:
text: In we're trying to test the ABI adjustment logic of all targets. This generally works as the test is nocore and LLVM has backends for all targets available -- except it does not seem possible to test the csky target that way. Trying to add the usual leads to an error from tidy: The test passes just fine locally, so it seems like at least the downloaded LLVM has the component. I don't know why it was not to tidy's list. Cc
cc but also I think this was just an oversight.
FWIW if one just adds this to a test it does pass on CI but of course it may just be silently ignored, hard to say whether the test actually runs... this stuff makes tests quite fragile. :/
Yeah, the tidy check was to reduce the fragility because a lot of people were giving names other than the LLVM component's name, like riscv64 instead of riscv, etc.
The remaining question then is, how sure are we that the components accepted by tidy are all available on some CI runner?
Also, something else must have been going on... I this test before that sanity check was to tidy. Sadly the logs for failure are already gone.
Code change:
[dependencies] toml = "0.5" serde = { version = "1.0", features = ["derive"] } <ins> serde_json = "1.0" </ins>

Related discussion:
text: Looking at https://rust-, it seems like Miri is getting shipped as a rustup component even though the tests fail. Unfortunately, Miri is currently entirely usable, so it'd probably be better if it did not get shipped in this state. Is that something we can do? Cc
maybe we can make the miri toolstate always go to even if it technically is just
what would be the best place to change this? I think I'd prefer Miri not to be shipped at all when the tests fail; I'd rather people stick to an old-but-working Miri than to a new-but-broken one. I found but that does not seem to decide if a component gets built for distribution or not.
seems to suggest that it is supposed to work as you describe that it should be working. Since it obviously doesn't and I can't see how that comment could be true from looking at the source, I'm guessing this is some refactoring fallout. I'll dig a little into git blame
I found it. The comment was for rls in but then the code making the comment true was removed later
See for why this is hard to fix: the builders don't even run the tool tests, so they cannot know if the tests pass. :/ Also, that's probably for the better actually, as the "tools" builder sets --cfg miri to be more Miri-friendly and we don't want that in the release artifacts.
One (crazy?) thing we could so is have the dist builders query the toolstate repo to figure out if the tests are passing...
That will either retrieve an outdated toolstate or will need to block until the toolstate is uploaded ...
Without blocking it would lag behind by 1 merged PR, yes.
would it be possible to add some kind of build assert so Miri fails on builders when Rust internals change too much?
Well builders already know when Miri fails to build because internals change too much. The issue is things that make Miri still compile but break the test suite.
would it be possible to at least change the logic that opens issues such that for Miri, it opens an issue like when the tests fail? I could also try to implement that if you point me to the right place. So far we have had zero cases of Miri tests spuriously failing.
Code change:
[dependencies] toml = "0.5" serde = { version = "1.0", features = ["derive"] } <ins> serde_json = "1.0" </ins>

Related discussion:
text: That should be easy to do:
Gave it a shot at
had an interesting idea: can't we do the "don't ship broken tools" as part of a post-processing step? We anyway do some little amount of work when a commit hits (as opposed to ), such as actually updating the toolstate repo. So maybe that could also either delete the broken components from the S3 bucket, or else generate a file to be put into the S3 bucket that says which of the components are really there so that the broken ones can be considered "not there"? do you think something like that would be possible?
Thinking about this again, probably the most natural place to do this is in the . That could "just" also check the toolstate database for the commit it is promoting, and then (possibly only for certain tools) not add them to the nightly if their toolstate is not green.
This is biting us again right now, where CI knows that Miri is broken but we ship the component anyway, leading to CI failures in downstream projects that have Miri in their CI.
For another case where this issue got quite painful, see
My PR is because I was incorrectly assuming that all commits have their toolstate recorded in the toolstate repo. Reopening.
FTR, for testing , I downloaded some artifacts: then I edited my : and finally I ran This produces stuff in .
So looks like we have logic in that specifically does not commit to the toolstate repo if nothing changed: Unfortunately, this means that we cannot easily fetch the toolstate of the to-be-produced release in build-manifest, which caused my to fail. Would it be okay for you to change this logic to record the toolstate of all commits in the toolstate repo? Or would you prefer if I try to find another approach for solving this issue? Right now I am somewhat out of ideas though if we cannot even use the toolstate repo to communicate this information.
Wouldn't it be simpler to save list of "good" components to something like and upload it alongside tarballs? Running would show what you need.
I guess we could upload the two JSON files from the two tool runners somehow? Not sure which would be the right places to hook for that, though.
Status: blocked on which is blocked on
This seems to be finally fixed!
Code change:
[dependencies] toml = "0.5" serde = { version = "1.0", features = ["derive"] } <ins> serde_json = "1.0" </ins>

Related discussion:
text: Today nightly was shipped with , and everything looks normal :tada:
Miri is "test-fail" now, so with the next nightly we should be able to see if indeed it gets removed from rustup as it should.
Confirmed it's working! On miri is missing.
Code change:
<ins> mod a { use std::marker::PhantomData; enum Bug { V = [PhantomData; { [ () ].len() ].len() as isize, //~^ ERROR mismatched closing delimiter: `]` //~| ERROR mismatched closing delimiter: `]` //~| ERROR mismatched closing delimiter: `]` //~| ERROR mismatched closing delimiter: `]` } } mod b { enum Bug { V = [Vec::new; { [].len()  ].len() as isize, //~^ ERROR mismatched closing delimiter: `]` //~| ERROR mismatched closing delimiter: `]` //~| ERROR mismatched closing delimiter: `]` //~| ERROR mismatched closing delimiter: `]` //~| ERROR type annotations needed } } mod c { enum Bug { V = [Vec::new; { [0].len() ].len() as isize, //~^ ERROR mismatched closing delimiter: `]` //~| ERROR mismatched closing delimiter: `]` //~| ERROR mismatched closing delimiter: `]` //~| ERROR mismatched closing delimiter: `]` //~| ERROR type annotations needed } } fn main() {} </ins>

Related discussion:
text: The following ICE's on stable, beta and nightly: (notice the was NOT closed) <details<summaryBacktrace:</summary</details
Oh, this works with other types as well, except the messages are different ICE's with:
ICE's with:
Its worth nothing explicitly that: these ICE's are happening after we do issue a diagnostic for the parsing error If you address the parsing error (presumably in the same manner that the parser is auto-correcting to make further progress), the ICE goes away
triage: P-medium. Removing nomination.
Triage: The first example still ICEs in MIR building The second and third examples don't ICE anymore and need tests (without closing this issue!).
cc
Code change:
linker_error.emit(); if sess.target.target.options.is_like_msvc && linker_not_found { <del> sess.note_without_error("the msvc targets depend on the msvc linker  but `link.exe` was not found"); sess.note_without_error("please ensure that VS 2013, VS 2015 or VS 2017  was installed with the Visual C++ option"); </del> <ins> sess.note_without_error( "the msvc targets depend on the msvc linker  but `link.exe` was not found", ); sess.note_without_error( "please ensure that VS 2013, VS 2015, VS 2017 or VS 2019  was installed with the Visual C++ option", ); </ins> } sess.abort_if_errors(); }

Related discussion:
text: A localized (e.g. German) MSVC can produce non-UTF-8 output, which can become almost unreadable in the way it's currently forwarded to the user. This can be seen in an (otherwise unrelated) issue comment: Note especially this line: That output might be a lot longer for multiple LNK errors (one line per error, but the lines are not properly separated in the output, because they are converted to ) and become really hard to read. If possible, the output should be converted to Unicode in this case. (previously reported as ) NOTE from Please install Visual Studio English Language Pack side by side with your favorite language pack for UI
I’m surprised we try to interpret any output in Windows as UTF-8 as opposed to UTF-16, like we should.
I suspect that the MSVC compiler's raw output is encoded as Windows-1252 or Windows-1250 (for German) depending on the current console code page and not as UTF-16. Does solve the encoding problem?
No, neither in nor in (usually I'm working with the latter). It prints but the encoding problems persist.
Is it just MSVC which is localized, or is your system codepage itself different? If we know that a certain program's output is the system codepage we could use with to convert it. Perhaps we could check whether the output is UTF-8, and attempt to do the codepage conversion if it isn't.
I am using a German localized Windows. How can I find out the system codepage? The default CP for console windows is "850 (OEM - Multilingual Lateinisch I)".
You can call  with or .
That returns codepage numbers 1252 for and 850 for .
In which case the output from the linker appears to be , so now someone just has to add code to rustc which detects when the linker output isn't utf-8 on windows and use with instead.
I ran into this problem as well (also on a German Windows 10). As a workaround it helps if you go to in Win 10 to Settings -Region and Language -Language and add English as a language and make it default ( you may have to log out and back in again). After that, programs like should output using a locale that works with rust as it is right now.
Code change:
linker_error.emit(); if sess.target.target.options.is_like_msvc && linker_not_found { <del> sess.note_without_error("the msvc targets depend on the msvc linker  but `link.exe` was not found"); sess.note_without_error("please ensure that VS 2013, VS 2015 or VS 2017  was installed with the Visual C++ option"); </del> <ins> sess.note_without_error( "the msvc targets depend on the msvc linker  but `link.exe` was not found", ); sess.note_without_error( "please ensure that VS 2013, VS 2015, VS 2017 or VS 2019  was installed with the Visual C++ option", ); </ins> } sess.abort_if_errors(); }

Related discussion:
text: It would still be great if this could be fixed in rust :)
Just saw another instance of this in , except with ) (a common encoding in China), where got printed instead of the desired .
Using nightly 2019-07-04, we can confirm that this issue is fixed. (I'm using Chinese version of Visual Studio).
For me, it still does not work even with nightly build (1.38 x86_64-pc-windows-msvc, Russian version of VS). I try to compile a Hello world project in Intellij Idea but always get the exception:
Could you execute and see what that outputs?
That's a little strange. Could you open "x64 Native Tools Command Prompt for Visual Studio 2019" from start menu, and execute the following command: And see whether the output is English? If the output's still not in English, would you mind open "Visual Studio Installer" from start menu, choose "Modify" for the corresponding Visual Studio edition, and in the Language packs tab, install the English language pack. And try the instructions above again?
thanks! The hint about installing the English language pack has made the previous error disappear. But now I have another message while running in Idea: I haven't changed the path to the std library, it's looks like
Yes, this is the same error as before, it's because you didn't install windows sdk. Choose the newest one in the visual studio installer too.
thank you again. Now it's compiling and running. I'm happy ;) Just out of curiosity: was I supposed to know in advance that I would need an English lang pack and a Windows SDK when installing Visual Studio?
Please feel free to point out places where Rust tells you to install Visual Studio but does not tell you to install the Windows SDK, so that we can fix those places. It might still be worth implementing the text encoding version of the fix for people who don't have the English language pack, though I really wish we could just get unicode output out of VS without having to specify a language.
sorry, seems I was a bit inattentive. Now I double-checked: after starting rustup- the screen info says, I should assure that I have Windows SDK installed. So my fault, nothing to fix there :) Thanks.
This is not a fix anymore.
Code change:
linker_error.emit(); if sess.target.target.options.is_like_msvc && linker_not_found { <del> sess.note_without_error("the msvc targets depend on the msvc linker  but `link.exe` was not found"); sess.note_without_error("please ensure that VS 2013, VS 2015 or VS 2017  was installed with the Visual C++ option"); </del> <ins> sess.note_without_error( "the msvc targets depend on the msvc linker  but `link.exe` was not found", ); sess.note_without_error( "please ensure that VS 2013, VS 2015, VS 2017 or VS 2019  was installed with the Visual C++ option", ); </ins> } sess.abort_if_errors(); }

Related discussion:
text: refer to
Please make sure you have installed Visual Studio English Language Pack side by side with your favorite language pack for UI for this to work.
I'm not sure this problem is really fixed. The PR that closed this kinda works around the issue because English is usually ASCII which is the same in UTF-8. However, as noted above, this relies on the Visual Studio English language pack being installed which it isn't always. And that there's no non-ascii output (e.g. file paths, etc). The suggestion to use with seems like a better fix, imho.
Code change:
use std::ffi::CString; <del> use rustc::hir::CodegenFnAttrFlags; </del> <ins> use rustc::hir::{CodegenFnAttrFlags, CodegenFnAttrs}; </ins> use rustc::hir::def_id::{DefId, LOCAL_CRATE}; use rustc::session::Session; use rustc::session::config::Sanitizer;

Related discussion:
text: and are both broken on s390x since Rust 1.28. When is built without debuginfo, the tests hang with their backtracing processes stuck in a loop. With debuginfo, it fails with output like: I believe the problem is this part of : where doesn't identify that is a 64-bit platform. See also alexcrichton/backtrace-rs. I plan to update that here when it's published, and make a similar fix in .
fixes the backtrace when is built with debuginfo, but I'm still getting a hang without. In GDB, it looks like the unwinder gets to the that catches panics, then loops unwinding that same PC forever. This part of the regression is older -- happens on 1.27.2 as well, but 1.26.2 is fine. Binaries from the older version don't appear to have a distinct symbol at all, but maybe that's just inlined differently. I'm bisecting for that hang now.
Bisecting pointed me at (cc which attributes to all functions. For s390x the base features actually include a removal, . But it doesn't look like the features are applied to the synthesized (), and as a result it doesn't get inlined anymore since it has more features (w/ ) than the callee. We probably should apply target-features to as well. I don't know why the non-inlined can't be unwound -- maybe we need to force ? By default GDB backtrace stops at crate , but tries to go further: Maybe Rust's could have a similar defensive check, at least.
Nice find Definitely makes sense to me, and this should be fixed up (at least the business) in
With , , and , I believe we have this fixed.