jiebi/CodeConvo huggingface dataset:
Change:
&self, constant: &mir::Constant<'tcx>, ) -> Result<Option<ty::ValTree<'tcx>>, ErrorHandled> { <del> let uv = match constant.literal { </del> <ins> let uv = match self.monomorphize(constant.literal) { </ins> mir::ConstantKind::Unevaluated(uv, _) => uv.shrink(), <ins> mir::ConstantKind::Ty(c) => match c.kind() { // A constant that came from a const generic but was then used as an argument to old-style // simd_shuffle (passing as argument instead of as a generic param). rustc_type_ir::ConstKind::Value(valtree) => return Ok(Some(valtree)), other => span_bug!(constant.span, "{other:#?}"), }, // We should never encounter `ConstantKind::Val` unless MIR opts (like const prop) evaluate // a constant and write that value back into `Operand`s. This could happen, but is unlikely. // Also: all users of `simd_shuffle` are on unstable and already need to take a lot of care // around intrinsics. For an issue to happen here, it would require a macro expanding to a // `simd_shuffle` call without wrapping the constant argument in a `const {}` block, but // the user pass through arbitrary expressions. // FIXME(oli-obk): replace the magic const generic argument of `simd_shuffle` with a real // const generic. </ins> other => span_bug!(constant.span, "{other:#?}"), }; let uv = self.monomorphize(uv);

Discussion:
: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This might be related to cc
Reverting from to (before was merged) fixes the issue for me.
Change:
<ins> // Copyright 2017 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. #![feature(conservative_impl_trait)] use std::iter::once; struct Foo { x: i32, } impl Foo { fn inside(&self) -> impl Iterator<Item = &i32> { once(&self.x) } } fn main() { println!("hi"); } </ins>

Discussion:
My code is about 500 lines long. I'm running up against an assignment deadline, so I don't have time right now to make a minimal demonstration. But if needed I can do so after Thursday, if someone hasn't gotten to it already. Sorry to dump and run. I normally try to be better about bug reports. :/ I expect this to be related to my copy paste error with repeated if clause: EDIT: Removed code, as there is a minimal example below.
Minimal example: Gives output:
I like to check back in on my issues from time to time to ensure that they haven't become invalid. I found that this issue still exists in the 2017/12/11 nightly ().

The following code ICEs on x8664 linux Suspect that it's this line (expecting that a struct with size 8 has 1 field) ICE message: cc
This isn't fixed, example should have had a or a attribute to make sure that the function is exported.
. CC
These "components" are not exactly struct fields, but rather hardware registers. The alignment padding probably triggers an edge case, I'll have to look deeper.

I found out that doesn't work, so I got a bit creative and tried this (reduced example): Which lead to this: It just prints an error on stable (1.17.0): And of course:
I ran into this with declarative macros on
Panics with the same error on 1.18.0 stable now:
Now this works, but it breaks proc-macro derives on the same item (parsing fails). Should I report that bug to a different location? It sort of feels like it's rustc's fault, as it's passing the proc-macro invalid syntax. I think it's odd that a macro can legally expand to invalid syntax...
That sounds a rust-lang/rust problem, yes. Have you filed an issue? I'd love to see a short example of the failure.
I've opened another issue for it:

$ RUST_BACKTRACE=1 rustc $ cat $ rustc --version --verbose
Looks like this was fixed. Output with current nightly as per playground:
Yeah, this was fixed. Marking as E-needstest.
Change:
pub const PROGRESS_CONTINUE: DWORD = 0; <ins> // List of Windows system error codes with descriptions: // https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes#system-error-codes </ins> pub const ERROR_FILE_NOT_FOUND: DWORD = 2; pub const ERROR_PATH_NOT_FOUND: DWORD = 3; pub const ERROR_ACCESS_DENIED: DWORD = 5;

Discussion:
On Windows an io::Error created via with the Windows system error code (1460) is not of the kind , but . This is counter-intuitive considering both (system error code and kind) have (almost) the same symbolic name. I've tested this with Rust 1.42 on x8664-pc-windows-gnu, but this behavior is obviously still present in . Unless I'm overlooking sth., this should be fairly easy to fix by defining the constant and adding the following after : If you'd like me to, I can prepare a merge request implementing the suggested fix. I tried this code: I expected to see this happen: Assertion passes because (should be): Instead, this happened: Assertion fails because: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
This issue is not limited to the system error code , as Windows appears to use various error codes for what would all be on POSIX. For example, I'm getting an () if a write operation on a COM port times out (on Windows 10 version 1809). Looking at the list of , I found the following that contain TIME and appear to be timeouts: () () () () () () Thanks to for pointing out that this error code indicates an invalid timeout and not that a timeout occurred. () () () () () () () () () ()
One concern with merging these all into is that the caller would no longer know which of the timeout occurred -- are there cases where that's important?
I don't think that's the case, but please correct me if I'm wrong. The following example will produce this on Windows: Currently, only will yield an of . All other timeout errors will be of , which is counter-intuitive, because matching an error's kind against will not catch all timeout errors. I would suggest to only change the kind of the errors listed above to . The original OS error code can still be accessed via if the programmer is interested in the OS-specific timeout reason. Therefore, this should not break backwards-compatibility, unless someone expects these errors to be , which should be discouraged.
Ah, okay, right.

I would in that case not be personally opposed to making this change, I think a PR that does so would be the best way to do so (and that can be FCP'd to libs team).
All right. Thanks for the quick response. I'll prepare a pull request.
Note that does not indicate the operation timed out, but rather that the timeout you specified was invalid.
Thanks for checking that. I'll revise the list of errors before submitting the PR, but I'm afraid I have very close to zero experience with the Windows API. I just stumbled over this issue while porting POSIX software to Windows.
Change:
<ins> // Make sure that we escape the arguments of the GAT projection even if we fail to compute // the href of the corresponding trait (in this case it is private). // Further, test that we also linkify the GAT arguments. // @has 'issue_109488/type.A.html' // @has - '//pre[@class="rust item-decl"]' '<S as Tr>::P<Option<i32>>' // @has - '//pre[@class="rust item-decl"]//a[@class="enum"]/@href' '{{channel}}/core/option/enum.Option.html' pub type A = <S as Tr>::P<Option<i32>>; /*private*/ trait Tr { type P<T>; } pub struct S; impl Tr for S { type P<T> = (); } </ins>

Discussion:
Given Rustdoc does not escape the ASCII angle brackets for the generic argument list of the generic associated type projection leading to the following butchered HTML output: I've noticed this while working on rustdoc integration for in . It's possible that the refactoring PR will fix this (need to check) or at least make it more pleasant to fix. Assigning myself for now since I'm gonna fix this otherwise. claim label T-rustdoc A-rustdoc-ui F-genericassociatedtypes <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Copying my comment from : is requesting alternate formatting (i.e. plaintext), but in this branch of things, alternate formatting hasn't been requested by the caller. So this is likely emitting into an HTML context. If you change it to in your branch I'm guessing that will fix things.
Here's a live example: As it turns out, this bug does appear to be what's crashing rustdoc in . So I will wind up fixing it. But feel free to investigate and fix if you prefer not to wait.
This wound up being the fix:
On at least I cannot reproduce your fix that involves adding in branch (maybe that only works on your branch). In any case, the lines in are definitely the culprit. I've already fixed it that way in but I've now also opened a separate PR. Thanks for the live example!
Change:
err.span_label(arm_span, msg); } } <del> hir::MatchSource::TryDesugar => { // Issue #51632 if let Ok(try_snippet) = self.tcx.sess.source_map().span_to_snippet(arm_span) { err.span_suggestion_with_applicability( arm_span, "try wrapping with a success variant", format!("Ok({})", try_snippet), Applicability::MachineApplicable, ); } } </del> <ins> hir::MatchSource::TryDesugar => {} </ins> _ => { let msg = "match arm with an incompatible type"; if self.tcx.sess.source_map().is_multiline(arm_span) {

Discussion:
Reproduced on versions: - Isolated example to reproduce: Actual error: Mentioned suggestion about "wrap into " is incorrect at all. There we should deref the value from the . - - Expected error: (something like this)
Here's where the suggestion gets issued: The motivation was to solve (where a -expression appears in tail position, which seemed likely to be a common mistake), but it turns out that there are other situations where we run into a type mismatch between match arms of a desugared expression. We regret the error.
Here's another case of this:
I see what's happening, we're only checking wether the error came from a desugaring, disregarding the types involved. It should be possible to check that information as well, even if the suggestion is only provided when it's a where everything but the error type matches. (I think it's ok if the supplied error cannot be converted to the expected error, as this suggestion exposes newcomers to a non-obvious construct at least.)
Clippy to detect this that we might want to uplift ...
(But for now I'm just going to remove the suggestion.)
Change:
} pub fn set_nodelay(&self, nodelay: bool) -> io::Result<()> { <del> net::setsockopt(self, c::IPPROTO_TCP, c::TCP_NODELAY, nodelay as c::BYTE) </del> <ins> net::setsockopt(self, c::IPPROTO_TCP, c::TCP_NODELAY, nodelay as c::BOOL) </ins> } pub fn nodelay(&self) -> io::Result<bool> { <del> let raw: c::BYTE = net::getsockopt(self, c::IPPROTO_TCP, c::TCP_NODELAY)?; </del> <ins> let raw: c::BOOL = net::getsockopt(self, c::IPPROTO_TCP, c::TCP_NODELAY)?; </ins> Ok(raw != 0) }

Discussion:
This bug was found and mitigated by the Wine project here: The types for each setsockopt are documented here: As the Wine commit explains, Windows itself is more liberal in what values of optlen it will accept for boolean arguments, which is why this has not affected Windows proper, but it would still be better to pass the expected type and length, so that the Rust bindings will also work on more strict implementations of winsock, such as Wine's prior to this fix. I confirmed that this is the case using Wine 7.0, which is the current stable branch available from Wine 5.0.3, which is the version that Debian/Ubuntu distribute themselves, is not affected by this problem. I tried this code: I set up a listening peer with , built with , and ran with . I expected to see this happen: all the socket operations succeed, and prints "hello" and exits. Instead, this happened: setnodelay returns an Err: If I run with , which shows the Linux system calls that wine makes on behalf of the program, I can see: I tested this using rust 1.58.1, but I confirmed that the code in question is still doing the same thing on the branch of rust. Here is a commit which should fix the issue: I was able to test it myself and confirmed that the error goes away: That this error isn't formatted correctly is probably another bug, but I haven't looked into it.
Thanks for reporting this! Would you mind creating a pull request with your changes? The rustc dev guide has information on the .
Sure thing:
Change:
<ins> // Check that borrowck ensures that `static mut` items have the expected type. static FOO: u8 = 42; static mut BAR: &'static u8 = &FOO; static mut BAR_ELIDED: &u8 = &FOO; fn main() { unsafe { println!("{} {}", BAR, BAR_ELIDED); set_bar(); set_bar_elided(); println!("{} {}", BAR, BAR_ELIDED); } } fn set_bar() { let n = 42; unsafe { BAR = &n; //~^ ERROR does not live long enough } } fn set_bar_elided() { let n = 42; unsafe { BAR_ELIDED = &n; //~^ ERROR does not live long enough } } </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried : I expected to see this: Instead, happens undefined behavior. Program successfully compiles in the Rust but fails to compile in (thats what I want).
Regressed in , likely cc
Visited in the compiler team triage meeting. It would be good to look into closing this ASAP. do you think you'll have time to investigate? If not, I'd want to find someone else.
We've assigned this speculatively to -- if you think you won't be able to investigate promptly, though, feel free to unassign and ping t-compiler for reassignment,
I expected the behavior to match that of this example (which still errors): I wonder if the gets erased somehow. Maybe an "user type annotation" is required on the from a , to give it a lifetime'd type?
Change:
<ins> error[E0432]: unresolved import `single_err::something` --> $DIR/issue-57015.rs:10:5 | LL | use single_err::something; //~ ERROR unresolved import `single_err::something` |     ^^^^^^^^^^^^^^^^^^^^^ no `something` in `single_err` error: aborting due to previous error For more information about this error, try `rustc --explain E0432`. </ins>

Discussion:
the code i tried: noticed there was a typo, fixed it, still getting an ICE i expected: cargo-generate/pull/135, to not compile and give an error about typo cargo-generate/pull/136, to compile (and no longer display 2018 warnings about path clarity) instead, what happened: system info:
i also get this on stable and earlier nightlies, if that is at all useful.
(also please feel free to let me know if i can provide any more info- this is my first time filing a compiler bug! thanks for all your hardwork and help <3)
Nominating -- we should keep focus on Rust 2018-related bugs like this, I think.
Did you? I mean, there is a typo, right? Do you mean, you expected a controller error? Specifically I see this in the diff: and I think it should be ?
I guess you are saying you get the same ICE from , which has a fix... did you try a cargo clean? (I'm wondering if it is related to incremental compilation.)
yeah, so i noticed the typo, and then fixed it (hence the 2 PRs- i included both on the offchance that there were 2 issues.) i expected the 2nd one to compile, and the first one (after i noticed the typo, to not compile but give an error re: the typo). i will run a cargo clean and see if it helps!
OK, thanks for the clarification.
just ran and then and have the same error message.
Fixed in
Change:
} } <ins> #[derive(Debug, Clone, PartialEq, Eq, Hash)] pub struct CrateRunMakeSupport { host: TargetSelection, } impl Step for CrateRunMakeSupport { type Output = (); const ONLY_HOSTS: bool = true; fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.path("src/tools/run-make-support") } fn make_run(run: RunConfig<'_>) { run.builder.ensure(CrateRunMakeSupport { host: run.target }); } /// Runs `cargo test` for run-make-support. fn run(self, builder: &Builder<'_>) { let host = self.host; let compiler = builder.compiler(builder.top_stage, host); builder.ensure(compile::Std::new(compiler, host)); let mut cargo = tool::prepare_tool_cargo( builder, compiler, Mode::ToolStd, host, "test", "src/tools/run-make-support", SourceType::InTree, &[], ); cargo.allow_features("test"); run_cargo_test( cargo, &[], &[], "run-make-support", "run-make-support self test", compiler, host, builder, ); } } </ins> default_test!(Ui { path: "tests/ui", mode: "ui", suite: "ui" }); default_test!(Crashes { path: "tests/crashes", mode: "crashes", suite: "crashes" });

Discussion:
The library is currently not registered/configured in bootstrap to be able to run its unit tests via . See for an example on how compiletest unit tests are ran. I plan to get to this eventually (busy ATM), but if someone wants to try implementing this feel free to claim it. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Thanks, I'm doing this. claim
Change:
let r = match f(self) { Ok(val) => Some(val), Err(err) => { <del> let (frames, span) = self.ecx.generate_stacktrace(None); let err = ConstEvalErr { span, error: err, stacktrace: frames, }; err.report_as_lint( self.ecx.tcx, "this expression will panic at runtime", lint_root, ); </del> <ins> match err.kind { // don't report these, they make no sense in a const prop context EvalErrorKind::MachineError(_) => {}, _ => { let (frames, span) = self.ecx.generate_stacktrace(None); let err = ConstEvalErr { span, error: err, stacktrace: frames, }; err.report_as_lint( self.ecx.tcx, "this expression will panic at runtime", lint_root, ); } } </ins> None }, };

Discussion:
inlined inside a , I get a warning: however, when I involve a variable there is no warning at all but looking at the generated code it is quite clear that this panics:
It warns on current stable, but not on beta and nightly. Might be miri fallout? cc Curiously, when you take a reference (to trigger promotion to static) you get a hard error on beta and nightly (stable is still a warning). Isn't that a regression?
triage: P-medium Still want to get those warnings, but no longer P-high
Hm, what is the status of this? The PR was merged, but with , I don't get a compiler warning for the first example. For the second one I get two though? :confused:
The PR was just for the compilation error. The missing warnings just need an impl for this branch: The warning duplication is unfortunate, but if we deduplicate it, we loose warnings in other edge cases. We could deduplicate it similar to the way the notes about where the lint level was set are deduplicated (note how the second warning has no message). That would probably be the cleanest solution.
Change:
extern "C" { static mut environ: *const *const c_char; } <del> ptr::addr_of_mut!(environ) </del> <ins> &mut environ </ins> } <del> static ENV_LOCK: StaticRWLock = StaticRWLock::new(); pub fn env_read_lock() -> RWLockReadGuard { ENV_LOCK.read_with_guard() </del> <ins> pub unsafe fn env_lock() -> StaticMutexGuard { // It is UB to attempt to acquire this mutex reentrantly! static ENV_LOCK: StaticMutex = StaticMutex::new(); ENV_LOCK.lock() </ins> } /// Returns a vector of (variable, value) byte-vector pairs for all the /// environment variables of the current process. pub fn env() -> Env { unsafe { <del> let _guard = env_read_lock(); </del> <ins> let _guard = env_lock(); </ins> let mut environ = *environ(); let mut result = Vec::new(); if !environ.is_null() {

Discussion:
For example: i686-gnu, i686-gnu, i686-gnu-nopt, i686-gnu-nopt, i686-gnu, i686-gnu-nopt, i686-gnu, i686-gnu-nopt i686-gnu, i686-gnu, i686-gnu, x8664-gnu-distcheck, i686-gnu-nopt, x8664-gnu-tools, i686-gnu, i686-gnu-nopt, i686-gnu-nopt,
Posted a fix at .
Change:
= note: see issue #37854 <https://github.com/rust-lang/rust/issues/37854> for more information = help: add `#![feature(exclusive_range_pattern)]` to the crate attributes to enable = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date <ins> = help: use an inclusive range pattern, like N..=M </ins> error[E0658]: exclusive range pattern syntax is experimental --> $DIR/slice_pattern_syntax_problem1.rs:4:32

Discussion:
Came across this when a beginner was very confused about what was wrong with their ; the words "is experimental" and the link to the issue was not sufficient for their discovering what the problem/solution was. The suggested inclusive range pattern doesn't need to contain the actual matching value if producing it is hard or impossible, printing something like is still better than nothing. This issue may of course be ignored/closed if this nightly feature is just about ready to be stabilized or something. No response label +D-terse +C-enhancement +F-exclusiverangepattern <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<ins> // Copyright 2017 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. macro_rules! a { () => { "a" } } macro_rules! b { ($doc:expr) => { #[doc = $doc] pub struct B; } } b!(a!()); fn main() {} </ins>

Discussion:
This issue probably needs a better title, perhaps someone more familiar with the compiler's handling of macros can suggest a better one. Some kind of error message, at least. panic with exit code :
Simplified: Same ICE will happen if is changed to ///. Update: Panic happens at this line: has keys and , but the is .
Change:
}, ccx.tcx.map.krate()); // Cross-crate: <ins> let mut external_mods = FnvHashSet(); </ins> fn handle_external_def(traits: &mut AllTraitsVec, <ins> external_mods: &mut FnvHashSet<DefId>, </ins> ccx: &CrateCtxt, cstore: &cstore::CStore, dl: decoder::DefLike) {

Discussion:
Updated 10/21: is currently valid Rust. I don't know if it should be, but it causes the compiler to blow its stack when recursively traversing a crate which contains it. To reproduce: Create a lib crate with this body: (compiles fine)Link to this crate, then include code that results in a method missing error, such as: This will cause the stack to overflow in while it looks up traits in linked crates that define a method . There are probably other functions which overflow like this in the case of this text. I would think either should be smart enough to not recursively include the self module or should be an error.
It would be easier to debug this problem if we would have source code that causes it (e.g. for ).
I did some debugging, found the issue, and have updated the title and top comment to explain it clearly, including steps to reproduce. Fortunately, the practical fix is easy (don't use ).
Change:
self.print_where_clause(&exist.generics.where_clause)?; self.s.space()?; <del> self.word_space(":")?; </del> let mut real_bounds = Vec::with_capacity(exist.bounds.len()); for b in exist.bounds.iter() { if let GenericBound::Trait(ref ptr, hir::TraitBoundModifier::Maybe) = *b {

Discussion:
expanded with yields we should not print that extra
Hi, I will like to work on this issue.
awesome! Most likely all that is required is to remove you can check if there's a test in that has a comment with in it. If there is, just add the above test line to it and run tests with . If there is no such test, add such a test ;)
I think I fixed this in one of my PRs, but not sure when it will merge, so go for it. :-)
While adding test, I am getting following error message: The existing test can be seen here:
you need to add to the test
Added that, many thanks!