jiebi/CodeConvo huggingface dataset:
Change:
The following causes an ICE: Backtrace: With: I can confirm that this bug has been around since 1.0.0-alpha (though with a slightly different assertion violation; I accidentally posted that version originally).
Removing either constraint in the clause, or changing the lifetimes used in the clause to be the same causes the ICE to go away.
I guess we should change that error message to be different from "coherence failed to report ambiguity" to "trait selection failed". Your use-case isn't currently supported (). Not sure which error message to give, through.
A couple more examples of this (including a nightly regression) can be found in
With rustc 1.7.0, 1.8.0 and 1.9.0, the example fails to compile, but don't generate an ICE.
Added a regression test in
It's been awhile since I reported this and I'm woefully out of the loop on Rust development at this point, but I'm not fully understanding the fix. The current error message is that additional type annotations are required, but my understanding of the original problem is that this is a fundamental limitation of the typechecker. Is there a way to add in more type annotations here to make this compile? I tried playing around with this a bit, but I wasn't able to come up with anything concrete.
you're not wrong, the error message is poor.
it's a limitation of the existing solver, anyway. (also, sorry for the like 2+ year gap here :) just happened to be looking at this issue)
thanks for the clarification, hello, and no problem! :)

Discussion:
<ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. trait Trait1<'l0, T0> {} trait Trait0<'l0>  {} impl <'l0, 'l1, T0> Trait1<'l0, T0> for bool where T0 : Trait0<'l0>, T0 : Trait0<'l1> {} //~^ ERROR type annotations required: cannot resolve `T0: Trait0<'l0>` //~^^ NOTE required by `Trait0` fn main() {} </ins>
Change:
I've come across quite a few broken links just while browsing the online documentation generated by rustdoc (particularly when clicking on links from search results). There are already issues relating to specific cases, but perhaps there should be a catch-all test on the output of rustdoc to check that all generated hyperlinks are valid?
The problem with things like this is that services that go down then break your build. We did this for Rust By Example, but then a bad deploy caused the whole site to 404, and we couldn't bring it back up because the site was 404'ing :wink: Specific cases should be looked into, and bugs should get filed, for sure, but running checks like this takes about an hour and a half, I've done it with linkchecker.
I was thinking more of something which ran on the files offline - it can ignore external urls, but just check that internal urls point to a file that was actually generated. That wouldn't be affected by anything outside the current build.
Also, rather than using , which – as is saying – usually is not an expedient process, we could have record all the URLs produced when generating the HTML and then validate them against the directory structure.
One example: From Link is broken.
That's due to a Rustdoc... Mis-feature, for which we already have a bug open.
Another instance of a broken link is found in It says where 'this paper' is a dead link to
So, I'm going to give this bug a close. If there are specific things that are causing to generate invalid links, they should be filed as bugs, and if there are specific, manually linked links that are wrong, they should have a bug, but I don't see under what conditions this bug will ever get closed.

Discussion:
If you’d like to dive into this topic in greater detail, [this paper][wilson] is a great introduction. <del> [wilson]: http://www.cs.northwestern.edu/~pdinda/icsclass/doc/dsa.pdf </del> <ins> [wilson]: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.143.4688 </ins> ## Semantic impact
Change:
I feel like it would be really helpful if the different kinds of tests were explained nicely somewhere, since there are a lot of different kinds, and it's a little hard to guess which kind I'll need to write, so I have to look at a lot of examples each time. In particular, the semantics of the lines such as: are clear enough when reading, but I'm not really sure how it works in detail. For example, in has on line 14 but the actual error message is With the extra at the end, so is it some sort of fuzzy match, or just prefix or what? Also when do you chose between and , is that only for placing the comment and are these the same: Or is there more going on? It'd also be quite nice to have a one line summary of the different test types, clarifying how is different from , etc. I know I can figure it out given long enough, but it'd save a lot of time. Thanks!
Perhaps it would be sufficient to link to from for the moment?
Yes! That's exactly what I was looking for and couldn't find. , jooert wrote:

Discussion:
[merge-queue]: http://buildbot.rust-lang.org/homu/queue/rust <ins> Speaking of tests, Rust has a comprehensive test suite. More information about it can be found [here](https://github.com/rust-lang/rust-wiki-backup/blob/master/Note-testsuite.md). </ins> ## Writing Documentation Documentation improvements are very welcome. The source of `doc.rust-lang.org`
Change:
We should add some sort of special comment like . Here is the hashcode of the current snapshot. The build system can then issue warnings if such a comment exists and is not still the current snapshot.
do you still feel that this would be useful?
Still seems useful to me.
Still very useful.
(bug triage) This would be nice, but is not a blocker.

Discussion:
#[test] #[should_fail] fn test_ascii_fail_char_slice() { 'λ'.to_ascii(); } <ins> #[test] </ins> fn test_opt() { assert_eq!(65u8.to_ascii_opt(), Some(Ascii { chr: 65u8 })); assert_eq!(255u8.to_ascii_opt(), None);

#[cfg(test)] mod test { use super::*; <del> use io::net::ip::{Ipv4Addr, SocketAddr}; </del> <ins> use io::net::ip::{SocketAddr}; </ins> use io::*; <del> use io::test::*; </del> use prelude::*; iotest!(fn bind_error() {

use unstable::run_in_bare_thread; use super::*; use rt::task::Task; <del> use rt::local_ptr; </del> #[test] fn thread_local_task_smoke_test() {

fn visit_estr_uniq(&mut self) -> bool { true } fn visit_estr_slice(&mut self) -> bool { true } fn visit_estr_fixed(&mut self, <del> _sz: uint, _sz: uint, </del> <ins> _sz: uint, _sz2: uint, </ins> _align: uint) -> bool { true } fn visit_box(&mut self, _mtbl: uint, _inner: *TyDesc) -> bool { true }
Change:
rustc just crashes with no useful errors. I guess you're not supposed to be able to do this anyway and it works if either are const instead of static but it shouldn't crash. Tested with latest nightly and 1.0.0-beta.2 on windows 64-bit.
No longer crashes:
E-needstest.
Triage: not aware of any tests being .
It seems that the E0394 error was removed in and the tests were moved from compile-fail and ui/error-codes to run-pass.

Discussion:
<ins> // check-pass // ignore-emscripten no llvm_asm! support #![feature(llvm_asm)] pub fn boot(addr: Option<u32>) { unsafe { llvm_asm!("mov sp, $0"::"r" (addr)); } } fn main() {} </ins>

<ins> // edition:2018 use std::sync::{Arc, Mutex}; pub async fn f(_: ()) {} pub async fn run() { let x: Arc<Mutex<()>> = unimplemented!(); f(*x.lock().unwrap()).await; } </ins>

<ins> // aux-build: issue_67893.rs // edition:2018 // dont-check-compiler-stderr // FIXME(#71222): Add above flag because of the difference of stderrs on some env. extern crate issue_67893; fn g(_: impl Send) {} fn main() { g(issue_67893::run()) //~^ ERROR: `std::sync::MutexGuard<'_, ()>` cannot be sent between threads safely } </ins>

<ins> #![feature(intrinsics)] extern "C" { pub static FOO: extern "rust-intrinsic" fn(); } fn main() { FOO() //~ ERROR: use of extern static is unsafe } </ins>

<ins> error[E0133]: use of extern static is unsafe and requires unsafe function or block --> $DIR/issue-28575.rs:8:5 | LL |     FOO() |     ^^^ use of extern static | = note: extern statics are not controlled by the Rust type system: invalid data, aliasing violations or data races will cause undefined behavior error: aborting due to previous error For more information about this error, try `rustc --explain E0133`. </ins>

<ins> pub static TEST_STR: &'static str = "Hello world"; </ins>

<ins> // aux-build: issue_24843.rs // check-pass extern crate issue_24843; static _TEST_STR_2: &'static str = &issue_24843::TEST_STR; fn main() {} </ins>
Change:
I just saw , a rustdoc page with an image. On small screens, the image doesn't resize and is just cut off. I know images are probably quite rare in documentation, but adding to the rustdoc main css file is a trivial thing.

Discussion:
padding: 20px; } <ins> img { max-width: 100%; } </ins> .content.source { margin-top: 50px; max-width: none;
Change:
Triggers an LLVM assertion when targeting Android:
Something that works on any host (i.e. you needn’t compile libstd for android to repro):
As the error says, isn't a supported calling convention for the ARM target in LLVM. Not really much we can do from the rustc side unless we want to error early based on cc/target combinations. In any case, it should not crash.
I'm hitting this when I tried to run tests for 1.10.0 on arm64 (aarch64-unknown-linux-gnu). The build succeeds otherwise. I'm just adding and to for the time being.
Neither example crashes today. Closing, since I don't see any good opportunity for a test here (it'd have to be something like and that's probably not worth it). With (original example): Updated example:

Discussion:
// option. This file may not be copied, modified, or distributed // except according to those terms. <del> // ignore-android: FIXME(#10381) </del> // min-lldb-version: 310 // compile-flags:-g

#![omit_gdb_pretty_printer_section] <del> // ignore-android: FIXME(#10381) </del> // min-lldb-version: 310 // aux-build:cross_crate_spans.rs

// ignore-tidy-linelength // ignore-lldb <del> // ignore-android: FIXME(#10381) </del> <ins> // ignore-android: FIXME(#24958) </ins> // compile-flags:-g

// option. This file may not be copied, modified, or distributed // except according to those terms. <del> // ignore-android: FIXME(#10381) </del> // ignore-windows // min-lldb-version: 310

// option. This file may not be copied, modified, or distributed // except according to those terms. <del> // ignore-android: FIXME(#9116) Bus error </del> use std::mem; #[repr(packed)]
Change:
Triggers an LLVM assertion when targeting Android:
Something that works on any host (i.e. you needn’t compile libstd for android to repro):
As the error says, isn't a supported calling convention for the ARM target in LLVM. Not really much we can do from the rustc side unless we want to error early based on cc/target combinations. In any case, it should not crash.
I'm hitting this when I tried to run tests for 1.10.0 on arm64 (aarch64-unknown-linux-gnu). The build succeeds otherwise. I'm just adding and to for the time being.
Neither example crashes today. Closing, since I don't see any good opportunity for a test here (it'd have to be something like and that's probably not worth it). With (original example): Updated example:

Discussion:
: "eax" ); # } } <ins> # #[cfg(not(any(target_arch = "x86", target_arch = "x86_64")))] # fn main() {} </ins> ``` Whitespace also doesn't matter:

# fn main() { unsafe { asm!("xor %eax, %eax" ::: "eax"); # } } <ins> # #[cfg(not(any(target_arch = "x86", target_arch = "x86_64")))] # fn main() {} </ins> ``` ## Operands

// Put the value 0x200 in eax asm!("mov $$0x200, %eax" : /* no outputs */ : /* no inputs */ : "eax"); # } } <ins> # #[cfg(not(any(target_arch = "x86", target_arch = "x86_64")))] # fn main() {} </ins> ``` Input and output registers need not be listed since that information

} println!("eax is currently {}", result); # } <ins> # #[cfg(not(any(target_arch = "x86", target_arch = "x86_64")))] # fn main() {} </ins> ``` ## More Information

// ignore-tidy-linelength // ignore-lldb // ignore-android: FIXME(#24958) <ins> // ignore-arm: FIXME(#24958) // ignore-aarch64: FIXME(#24958) </ins> // compile-flags:-g
Change:
is a keyword, this error message indicates that it can be used to define type, which is misleading.
There is a similar issue: file.
No, that's a different issue. At the time that issue was filed, was not a keyword, just a confusing type. That said, at the time that issue was reported, it's fine to say the compiler was implemented properly. But my issue is about wrong error message, not bad(confusing) error message.
Do you mean is not a special ident now? I found the example code can be compiled, and there is excluding self type code
My point is that we are in different situation now. See and notice that it happened after the time the issue we discuss was filed.
Actually, IIRC we're moving towards a direction where can be used everywhere in a trait or impl context. I'm not sure though. any idea?
Yes we can use it in traits or impls. is totally legal for instance. But inside global functions can not be explained if I understand correctly.
Oh, sorry, this was a global fn. Makes sense.

Discussion:
"type name" }; <del> let msg = format!("use of undeclared {} `{}`", kind, path_names_to_string(path, 0)); </del> <ins> let self_type_name = special_idents::type_self.name; let is_invalid_self_type_name = path.segments.len() > 0 && maybe_qself.is_none() && path.segments[0].identifier.name == self_type_name; let msg = if is_invalid_self_type_name { "use of `Self` outside of an impl or trait".to_string() } else { format!("use of undeclared {} `{}`", kind, path_names_to_string(path, 0)) }; </ins> self.resolve_error(ty.span, &msg[..]); } }

fn outer(self) { fn inner(_: Self) { //~^ ERROR can't use type parameters from outer function <del> //~^^ ERROR use of undeclared type name `Self` </del> <ins> //~^^ ERROR use of `Self` outside of an impl or trait </ins> } } }

<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 foo(_: Self) { //~^ ERROR use of `Self` outside of an impl or trait } fn main() {} </ins>
Change:
Hello folks, I'm dutifully reporting this as the compiler told me to so. The bug is the same reported already by and , although it appeared on a different circumstance. I have this simple program (I'm a Rust newbie so It's very likely I'm doing things terribly wrong): Expected outcome: The compile to tell me how wrong I am Actual outcome: Meta Shows up with latest beta as well:
cc me
Minified: We do write tyerr to node 11 (). Apparently we somehow don't report an error.
triage: P-medium
Whoops. There is indeed an error, which is indeed gets to reportselectionerror, but when we do (), we get an error, and think this one was a duplicate.
no_std version:
You don't even need the trait:

Discussion:
{ let predicate = infcx.resolve_type_vars_if_possible(&obligation.predicate); <del> if !predicate.references_error() { </del> <ins> // The ty_err created by normalize_to_error can end up being unified // into all obligations: for example, if our obligation is something // like `$X = <() as Foo<$X>>::Out` and () does not implement Foo<_>, // then $X will be unified with ty_err, but the error still needs to be // reported. if !infcx.tcx.sess.has_errors() || !predicate.references_error() { </ins> span_err!(infcx.tcx.sess, obligation.cause.span, E0271, "type mismatch resolving `{}`: {}", predicate.user_string(infcx.tcx),

let trait_predicate = infcx.resolve_type_vars_if_possible(trait_predicate); <del> if !trait_predicate.references_error() { </del> <ins> if !infcx.tcx.sess.has_errors() || !trait_predicate.references_error() { </ins> let trait_ref = trait_predicate.to_poly_trait_ref(); span_err!(infcx.tcx.sess, obligation.cause.span, E0277, "the trait `{}` is not implemented for the type `{}`",

} /// in various error cases, we just set ty_err and return an obligation <del> /// that, when fulfilled, will lead to an error </del> <ins> /// that, when fulfilled, will lead to an error. /// /// FIXME: the ty_err created here can enter the obligation we create, /// leading to error messages involving ty_err. </ins> fn normalize_to_error<'a,'tcx>(selcx: &mut SelectionContext<'a,'tcx>, projection_ty: ty::ProjectionTy<'tcx>, cause: ObligationCause<'tcx>,

// except according to those terms. fn main() { <del> "".chars().fold(|_, _| (), ()); //~^ ERROR cannot determine a type for this expression: unconstrained type </del> <ins> "".chars().fold(|_, _| (), ()); //~ ERROR is not implemented for the type `()` </ins> }

<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. struct S; trait InOut<T> { type Out; } fn do_fold<B, F: InOut<B, Out=B>>(init: B, f: F) {} fn bot<T>() -> T { loop {} } fn main() { do_fold(bot(), ()); //~ ERROR is not implemented for the type `()` } </ins>
Change:
Just found the Learn chapter has appeared in nightlies. While working through it the very first bit of code it gets me to run has a bug! It is note the last line we are printing which is there return value of read_line (appears to be number of bytes read) and not the actual string which is what the chapter text implies. Trivial fix... Took me a while to find, but I figured out where the book source is and will submit PR despite it being one word change so far ;).
I guess I made my pull request from that commit badly, but it's I guess this should be closed if that is accepted.

Discussion:
.ok() .expect("Failed to read line"); <del> println!("You guessed: {}", input); </del> <ins> println!("You guessed: {}", guess); </ins> } ```

There’s just one line of this first example left: ```rust,ignore <del> println!("You guessed: {}", input); </del> <ins> println!("You guessed: {}", guess); </ins> } ``` This prints out the string we saved our input in. The `{}`s are a placeholder, <del> and so we pass it `input` as an argument. If we had multiple `{}`s, we would </del> <ins> and so we pass it `guess` as an argument. If we had multiple `{}`s, we would </ins> pass multiple arguments: ```rust
Change:
Image says it all really, running rustdoc on files with windows style line-endings inserts (or doesn't strip?) additional newline characters, screwing up alignment with the line numbers: ! This only seems to affect regular comments, doc comments are fine. Edit: since it's not really obvious from the image due to the nature of the bug, it should look like this:

Discussion:
Some('/') => { self.bump(); self.bump(); // line comments starting with "///" or "//!" are doc-comments <del> if self.curr_is('/') || self.curr_is('!') { let start_bpos = self.pos - BytePos(3); while !self.is_eof() { match self.curr.unwrap() { 'n' => break, 'r' => { if self.nextch_is('n') { // CRLF break } else { self.err_span_(self.last_pos, self.pos, "bare CR not allowed in doc-comment"); } </del> <ins> let doc_comment = self.curr_is('/') || self.curr_is('!'); let start_bpos = if doc_comment { self.pos - BytePos(3) } else { self.last_pos - BytePos(2) }; while !self.is_eof() { match self.curr.unwrap() { 'n' => break, 'r' => { if self.nextch_is('n') { // CRLF break } else if doc_comment { self.err_span_(self.last_pos, self.pos, "bare CR not allowed in doc-comment"); </ins> } <del> _ => () </del> } <del> self.bump(); </del> <ins> _ => () </ins> } <del> return self.with_str_from(start_bpos, |string| { // but comments with only more "/"s are not </del> <ins> self.bump(); } return if doc_comment { self.with_str_from(start_bpos, |string| { // comments with only more "/"s are not doc comments </ins> let tok = if is_doc_comment(string) { token::DocComment(token::intern(string)) } else { token::Comment }; <del> return Some(TokenAndSpan{ </del> <ins> Some(TokenAndSpan { </ins> tok: tok, sp: codemap::mk_sp(start_bpos, self.last_pos) <del> }); }); </del> <ins> }) }) </ins> } else { <del> let start_bpos = self.last_pos - BytePos(2); while !self.curr_is('n') && !self.is_eof() { self.bump(); } return Some(TokenAndSpan { </del> <ins> Some(TokenAndSpan { </ins> tok: token::Comment, sp: codemap::mk_sp(start_bpos, self.last_pos) <del> }); </del> <ins> }) </ins> } } Some('*') => {

assert_eq!(lexer.next_token().tok, token::Literal(token::Char(token::intern("a")), None)); } <ins> #[test] fn crlf_comments() { let sh = mk_sh(); let mut lexer = setup(&sh, "// testrn/// testrn".to_string()); let comment = lexer.next_token(); assert_eq!(comment.tok, token::Comment); assert_eq!(comment.sp, ::codemap::mk_sp(BytePos(0), BytePos(7))); assert_eq!(lexer.next_token().tok, token::Whitespace); assert_eq!(lexer.next_token().tok, token::DocComment(token::intern("/// test"))); } </ins> }
Change:
check- uses Unix-only module , runs and therefore fails on Windows Workaround: use instead of cc
Oof, sorry! Having a look now
What version of python and windows are you on? I was fairly sure that I confirmed this did something reasonable on not-posix, but I do not in fact have a windows box to test on. I'm kinda confused about how the builders are working right now.
msys2 x64 on Windows 7 Python 2.7.9

Discussion:
import os import sys import functools <del> import resource </del> STATUS = 0

@only_on(('linux', 'darwin', 'freebsd', 'openbsd')) def check_rlimit_core(): <ins> import resource </ins> soft, hard = resource.getrlimit(resource.RLIMIT_CORE) if soft > 0: error_unless_permitted('ALLOW_NONZERO_RLIMIT_CORE', """
Change:
time: 58.110 LLVM passes vs time: 785.935 LLVM passes running on hyper Full output at
cc (There's a slight suspicion that this may be caused by , since that's touching trans/codegen.)
ran with , got
cc
Could you provide files for before and after? Hopefully should work now.
Looks like this is caused by -- the assume intrinsics no longer get simplified into nonnull metadata on load instructions and cause massive slowdowns.

Discussion:
#[inline] fn next(&mut self) -> Option<$elem> { // could be implemented with slices, but this avoids bounds checks <del> if self.ptr == self.end { None } else { unsafe { if mem::size_of::<T>() != 0 { ::intrinsics::assume(!self.ptr.is_null()); ::intrinsics::assume(!self.end.is_null()); } </del> <ins> unsafe { if mem::size_of::<T>() != 0 { assume(!self.ptr.is_null()); assume(!self.end.is_null()); } if self.ptr == self.end { None } else { </ins> let old = self.ptr; self.ptr = slice_offset!(self.ptr, 1); Some(slice_ref!(old))

#[inline] fn next_back(&mut self) -> Option<$elem> { // could be implemented with slices, but this avoids bounds checks <del> if self.end == self.ptr { None } else { unsafe { </del> <ins> unsafe { if mem::size_of::<T>() != 0 { assume(!self.ptr.is_null()); assume(!self.end.is_null()); } if self.end == self.ptr { None } else { </ins> self.end = slice_offset!(self.end, -1); <del> if mem::size_of::<T>() != 0 { ::intrinsics::assume(!self.ptr.is_null()); ::intrinsics::assume(!self.end.is_null()); } </del> Some(slice_ref!(self.end)) } }