Question: <ins> // ignore-emscripten no asm! support #![feature(asm)] fn main() { unsafe { asm! {"mov $0,$1"::"0"("bx"),"1"(0x00)} //~^ ERROR: invalid value for constraint in inline assembly } } </ins>

Binder(<[type error] as ToBytes) This only happens if there are two erroneous functions, if I take out it works fine. It seems like I was trying to do this wrong in the first place since the first function gives an error . Not sure what the right way to do this is. <details<summaryTraceback</summary</details
Tried to reduce it and found a similar case with the same ICE:
Compiler triage: Seems likely to be caused by the need for lazy norm. Marking as p-medium for now.
The ICE doesn't appear on the latest nightly, marked as E-needstest


Question: let span = self.mark_span_with_reason(DesugaringKind::Await, dot_await_span, None); let gen_future_span = self.mark_span_with_reason( DesugaringKind::Await, <del> await_span, </del> <ins> full_span, </ins> self.allow_gen_future.clone(), ); let expr = self.lower_expr_mut(expr);

This code: produces: Which is invalid. Looks like the span of the desugaring of uses only the part, instead of the span of the entire expression. This results in invalid suggestions when used by the code in .
I'm not entirely sure if this means that desugaring should use a bigger span, or if the suggestion diagnostic needs to be interpreted differently.
hmm.. is the only case where the desugared expr's span doesn't cover the whole piece of code it comes from? That doesn't sound right. If wonder if the expr should have the bigger span by default, and then async-specific code could grab the tighter span for diagnostics that need to point at the operator.
Some of the desugaring only uses the span, but the parts relevant for diagnostics like this do use the full span. Not sure if there's a problem there too.
I thought I might have accidentally introduced this bug in , but right after that PR was merged, the output was correct: So something changed in the last two months in what spans are used for await desugarings, it seems.
actually I think it was introduced in in , cc Do you need someone to fix this? I'm happy to put up a quick PR.
Yeah, looks like it: I just finished bisecting, which pointed at a rollup involving .
this was introduced in the PR linked earlier to try and improve other errors. It is tricky because reducing the span to only incurs these kind of bugs. On the other hand, the errors that got improved there became much less noisy, so I wouldn't want to revert the whole change. My fix above will solve this issue, but I'm sure there will be others in the future :-/


Question: pub fn output(cmd: &mut Command) -> String { let output = match cmd.stderr(Stdio::inherit()).output() { Ok(status) => status, <del> Err(e) => fail(&format!("failed to execute command: {}", e)), </del> <ins> Err(e) => fail(&format!("failed to execute command: {:?}nerror: {}", cmd, e)), </ins> }; if !output.status.success() { panic!("command did not execute successfully: {:?}n

Rustbuild now prints which is very not helpful.
I've hit this one too: When there's a stale in Rust's root directory, bootstrap reads paths from there and tries to convert them into windows format using (which it, of course, can't find since we are not running in msys shell). The error message comes from in buildhelper (called from ).


Question: return; }; <del> let doc = item.doc_value(); if doc.is_empty() { return; } if let Some(item_id) = item.def_id() { check_redundant_explicit_link_for_did(cx, item, item_id, hir_id, &doc); } if let Some(item_id) = item.inline_stmt_id { check_redundant_explicit_link_for_did(cx, item, item_id, hir_id, &doc); </del> <ins> let hunks = prepare_to_doc_link_resolution(&item.attrs.doc_strings); for (item_id, doc) in hunks { if let Some(item_id) = item_id.or(item.def_id()) && !doc.is_empty() { check_redundant_explicit_link_for_did(cx, item, item_id, hir_id, &doc); } </ins> } }

We've recently begun testing Bevy against the beta toolchain, where it has incorrectly raised an lint against . is not imported in this file, yet rustdoc believes that it is. (See the imports .) As a temporary workaround, I've created to ignore the error. Here is that first failed. In case it expires, here's . Look at . I can reproduce it on using by running the following command: The is optional, but it makes the command finish quicker. I'll continue testing to see if I can create a minimum reproducible example. :
I've created a minimal reproduction in my -repro branch of my fork. Go to the  folder and run . I've managed to squish it down to this:
I've created a reproduction that removes the dependency on Bevy . I've simplified it down to this:
I bisected it, and this bug appears to first be introduced in . I could not reproduce it in .


Question: <ins> // check-pass trait Factory { type Product; } impl Factory for () { type Product = (); } trait ProductConsumer<P> { fn consume(self, product: P); } impl<P> ProductConsumer<P> for () { fn consume(self, _: P) {} } fn make_product_consumer<F: Factory>(_: F) -> impl ProductConsumer<F::Product> { () } fn main() { let consumer = make_product_consumer(()); consumer.consume(()); } </ins>

The compiler seems unable to determine that two types are equal. I tried this code: I expected the program to compile and run without issue, because is , so the call should be fine. Instead, I got this error message: The problem exists on stable 1.42 and nightly 1.44
It somehow compiles if you replace the associated type with a type parameter:
cc /
Possibly relevant rustc log entries: Seems like the will resolve the inference variable to yield , but for some reason is unable to normalize that further.
It seems like the opaque type has a substs with only in it; on first glance I'd have expected the projection there, but the docs on do explain this: So it seems like the is what was inserted for the type parameter, making . I'm not sure why this is represented like it is, but it seems like we need more info to be able to look at the real substs of the opaque type.
Duh, I forgot how opaque types work. Not sure where would be stored (? It's empty at this point according to log), but it's definitely not in the type, so this output makes sense.
This is fixed on nightly.


Question: check_expr_with_expectation_and_lvalue_pref( fcx, &**oprnd, expected_inner, lvalue_pref); let mut oprnd_t = fcx.expr_ty(&**oprnd); <del> if !ty::type_is_error(oprnd_t) && !ty::type_is_bot(oprnd_t) { </del> <ins> if !ty::type_is_error(oprnd_t) { </ins> match unop { ast::UnBox => { <del> oprnd_t = ty::mk_box(tcx, oprnd_t) </del> <ins> if !ty::type_is_bot(oprnd_t) { oprnd_t = ty::mk_box(tcx, oprnd_t) } </ins> } ast::UnUniq => { <del> oprnd_t = ty::mk_uniq(tcx, oprnd_t); </del> <ins> if !ty::type_is_bot(oprnd_t) { oprnd_t = ty::mk_uniq(tcx, oprnd_t); } </ins> } ast::UnDeref => { oprnd_t = structurally_resolved_type(fcx, expr.span, oprnd_t);

Taking a look.
Probably the best fix for now is to disallow deref of outright. I'll work up a PR that fixes this and a few other ICEs surrounding .
This is fixed with a test, closing.


Question: #![allow(rustc::untranslatable_diagnostic)] use either::Either; <del> use hir::ClosureKind; </del> <ins> use hir::{ClosureKind, Path}; </ins> use rustc_data_structures::captures::Captures; use rustc_data_structures::fx::FxIndexSet; use rustc_errors::{codes::*, struct_span_code_err, Applicability, Diag, MultiSpan};

No response No response No response
I thought the intent with was to use it in a passthrough style, so you can insert it into existing expressions ie. becomes . In which case, maybe the lint should be for not using the value resulting from evaluating .
Not sure about the majority of users but for me is a convenience over . I use it without using the return value almost all of the time.
Probably a common thing to do, sure, but if we're talking about adding a lint, why not nudge the user in the direction of the intended and documented usage? You could at least do both: "insert into an existing expression or pass it a borrow" etc.
The fix in will only report a hint when there is already a happened. For example this code: before this fix the error is: with the fix, since there is already a error, the lint will try to find out the original macro, and suggest a borrow: The suggestion is not 100% right, since if we change it to , we need one more extra fix now(the return type is not expecting a reference), but there is a different issue, at least we have already moved one step on. If the original code is: Then suggest a borrow is a great and correct hint.
Similar in the scenario of function argument: original error is: new errors from the fix:
Would not also be a good hint? The suggestion wouldn't compile anyway right? Because would need to change to take ? Without involved, the compiler does indeed suggest that: Once that's addressed (whichever way it's done), once again becomes transparent, and eg. or works. does not, however, and I see why a "consider borrowing" hint would be good there. However, if you make the change first and leave as-is, the resulting error does not include the suggestion to change , which is unhelpful. (I agree that the message is even less helpful though, I'm not disputing that.)
Yes, it's a good hint, but from the implementation view of a hint, it's much harder to analyze the following code from the error point and then construct a new expression. Even it seems an easy thing for humans. You are right, the suggestion is not 100% right, we may need an extra follow-up fix after applying the hint, which is also a common thing in rustc diagnostics.


Question: <del> error[E0658]: `#[thread_local]` is an experimental feature, and does not currently handle destructors. There is no corresponding `#[task_local]` mapping to the task model (see issue #29594) </del> <ins> error[E0658]: `#[thread_local]` is an experimental feature, and does not currently handle destructors. (see issue #29594) </ins> --> $DIR/feature-gate-thread_local.rs:18:1 | 18 | #[thread_local] //~ ERROR `#[thread_local]` is an experimental feature

I will like to fix this. What should be the better warning message here? Or I just need to remove the last sentence?
It seems fine to just remove the sentence.
Fixed by


Question: /// let num_trailing = unsafe { cttz_nonzero(x) }; /// assert_eq!(num_trailing, 3); /// ``` <del> #[rustc_const_unstable(feature = "const_cttz", issue = "none")] </del> <ins> #[rustc_const_stable(feature = "const_cttz", since = "1.53.0")] </ins> pub fn cttz_nonzero<T: Copy>(x: T) -> T; /// Reverses the bytes in an integer type `T`.

Tracking issue for trailingzeros and leadingzeros for non zero types as introduced by . The feature gate for the issue is . On many architectures, this functions can perform better than trailingzeros/leading_zeros on the underlying integer type, as special handling of zero can be avoided.
It seems on my (common) architecture it doesn't give an advantage: : : So the question is: is this NonZero method worth keeping? Are the architectures where it gives a performance advantage common enough?
but as you show in your example if you want to make a distributable binary and due to this not set the target-cpu there is a big difference
The architecture I'm using is quite standard. A distributable binary could probably use it as "universal target". I don't know much common is going to be an instruction like tzcnt in the future. If you think a similar instruction will be sufficiently uncommon then please ignore my comments here :-)
merge cc
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [ ] [x] [x] [x] [x] [x] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
started to make the stabilization PR but hit a problem I think that constcttz needs to be stabilized for this to be stabilized from //! If an intrinsic is supposed to be used from a with a attribute, //! the intrinsic's attribute must be , too. Such a change should not be done //! without T-lang consulation, because it bakes a feature into the language that cannot be //! replicated in user code without compiler support.


Question: <ins> error[E0668]: malformed inline assembly --> $DIR/issue-62046.rs:8:9 | LL |         asm!("nop" : "+r"("r15")); |         ^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to previous error For more information about this error, try `rustc --explain E0668`. </ins>

Was working on bug and tried to compile the program below. The inline assembly may be bogus: I make no guarantees of its correctness. crashed with this output: : (but also happened on a nightly from late May)
The inline assembly is in fact bogus. Here's a minimal example that crashes the compiler. The problem is likely using the string operand (by mistake, because I'm dumb).
<details<summarybacktrace</summary</details
modify labels: I-ICE T-compiler A-inline-assembly C-bug
Thank you!


Question: - [wasm32-wasip1](platform-support/wasm32-wasip1.md) - [wasm32-wasip1-threads](platform-support/wasm32-wasip1-threads.md) - [wasm32-wasip2](platform-support/wasm32-wasip2.md) <ins> - [wasm32-unknown-unknown](platform-support/wasm32-unknown-unknown.md) </ins> - [wasm64-unknown-unknown](platform-support/wasm64-unknown-unknown.md) - [*-win7-windows-msvc](platform-support/win7-windows-msvc.md) - [x86_64-fortanix-unknown-sgx](platform-support/x86_64-fortanix-unknown-sgx.md)

This can be replicated with a minimal : Compile it to WASM with Then, check if the generated WASM uses reference types: <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: (and previous stable rust versions) On those versions, compiling the above and then running with doesn't fail. <!-- Provide the version you are using that has the regression. --: <!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged -- modify labels: +regression-from-stable-to-nightly -regression-untriaged This seems to have been caused by The compatibility note there says: However, the generated code seems to be indeed affected by default. Interestingly, reference types seem to be used unnecessarily, as using to turn the generated into wat and then to turn it back into wasm removes the reference types. As-is, this breaks compatibility with the WebAssembly 1.0 spec.
cc Looks like this causes issues in practice and we might want to do after all?
WG-prioritization assigning priority (). label -I-prioritize +P-high
I was unable to confirm the presence of any reference type instructions in the generated Wasm, even though I got the same error pointing towards a that looks perfectly valid to me. Interestingly enough, doing the back and forth conversion with and remove the issue, even though the output of both files is exactly the same, apart from the missing debug information. I'm assuming that this is another example of a tool making use of the , so this was already anticipated. Unfortunately (?) this isn't the first time LLVM has enabled features by default, in the past they even did affect code generation. From what I've read in the various WebAssembly specification groups, this was always intended. In conclusion, I agree this is a form of breakage, it seems to be intended, I believe if Rust wants to do anything about it the solution needs to a bit more comprehensive. E.g. actually disable all target features by default (I don't know if this is feasible with LLVM, would need research). See and .
I just spend some time digging into this error message that spits out.


Question: - [wasm32-wasip1](platform-support/wasm32-wasip1.md) - [wasm32-wasip1-threads](platform-support/wasm32-wasip1-threads.md) - [wasm32-wasip2](platform-support/wasm32-wasip2.md) <ins> - [wasm32-unknown-unknown](platform-support/wasm32-unknown-unknown.md) </ins> - [wasm64-unknown-unknown](platform-support/wasm64-unknown-unknown.md) - [*-win7-windows-msvc](platform-support/win7-windows-msvc.md) - [x86_64-fortanix-unknown-sgx](platform-support/x86_64-fortanix-unknown-sgx.md)

Locally I've produced exactly the same message, but it really doesn't make any sense to me. The location pointed out by the error message does indeed contain a call to , but the reserved value is , so I don't know what the issue is. Further, after using the -trick, it doesn't produce this error anymore, but the code location contains the exact same bytes. I also checked if reads the target feature section. While I confirmed it does, I don't believe it validates it from what I can see in the code. So maybe there is some sort of codegen difference, but I am unable to actually find it.
Could it be the encoding difference discussed in the description of this PR?
Yes, I just confirmed that's the issue. So it does affect codegen, even if in a minor way!
Yes the problem is the LEB-encoding of the table index immediate. Using on the output of rustc I see: which shows that 's type and table index are both using a 5-byte encoding of a zero value. This is not valid in MVP WebAssembly which required the table index to be a literal zero byte, not a LEB. Given I doubt LLVM will do anything here so it sounds like yes, we'll have to solve this in Rust. I believe this is due to the the binary encoding of the LEB. This isn't reflected in the text format and most other tools don't handle this well, so it's a subtle error. That's also why convert-to-text-and-back produces a working binary. To clarify, I don't believe that this is the case. I believe modifications to the target feature section are unrelated. Ok so the question now is what to do. I see a few possible routes: this change. That would entail updating the release notes for the LLVM upgrade PR to indicate that wasm targets are indeed affected. This would probably also detail the workaround of . Note that may not be enough given in . 't accept this change. That would require something along the lines of , perhaps modified to use then adding on features afterwards. "Fix" this change. This would require coordinating with upstream LLVM to change how this works. My guess is that given the existence of this seems unlikely to happen.


Question: - [wasm32-wasip1](platform-support/wasm32-wasip1.md) - [wasm32-wasip1-threads](platform-support/wasm32-wasip1-threads.md) - [wasm32-wasip2](platform-support/wasm32-wasip2.md) <ins> - [wasm32-unknown-unknown](platform-support/wasm32-unknown-unknown.md) </ins> - [wasm64-unknown-unknown](platform-support/wasm64-unknown-unknown.md) - [*-win7-windows-msvc](platform-support/win7-windows-msvc.md) - [x86_64-fortanix-unknown-sgx](platform-support/x86_64-fortanix-unknown-sgx.md)

There's not really a governing body per se around the Rust WebAssembly targets so there's not really a group of people we can point to and say "ok please tell us what to do". In lieu of that I would personally be tempted to go with route (1) because that keeps LLVM/C/C++ aligned with Rust and prevents divergence in the wasm ecosystem. Given the age of the proposal and the general intention for enabling more features by default over time as popular engines implement them this will also continue to change. So, concretely, I would propose: Do not change code as a result of this issue, leave it as-is. Update the release notes for LLVM 19 to indicate that WebAssembly targets are affected Update the WebAssembly documentation to explicitly document how to achieve and "MVP binary" by using and .
in the compiler team triage meeting. We think plan is reasonable at present but if there are additional issues or complications (such as it being more difficult to create an MVP binary than just using ), then option 2 (use by default) seems to be the way to go.
Looks like there may be complications. I am endeavouring to add a test to CI which asserts that a particular compiler invocation will generate MVP features. So far roadblocks are: Using is not sufficient. The attribute is not rewritten for IR of dependent libraries, like the standard library. That means that is only applied to the local crate and the standard library still codegens newer features. One can fix the above issue to additionally use but you'd have to pass for all active features. Not great. Even with there are still bulk-memory instructions in at least for example. These are coming from wasi-libc for the target which is what rustc tests in CI. This is not applicable to this issue as users typically use for this but would make adding a test difficult. Trying out the target locally I can't even get something to work it seems. LLVM is producing an invalid binary with alone when there's a memcpy in the binary. There's... a lot going on here apparently. Given the above I don't think that (2) I described above is a silver bullet by any means, even that seems doubtful to work. I need to investigate more what's going on here with all these features slinging all over the place.
Testing shows that plus Cargo's is sufficient.


Question: - [wasm32-wasip1](platform-support/wasm32-wasip1.md) - [wasm32-wasip1-threads](platform-support/wasm32-wasip1-threads.md) - [wasm32-wasip2](platform-support/wasm32-wasip2.md) <ins> - [wasm32-unknown-unknown](platform-support/wasm32-unknown-unknown.md) </ins> - [wasm64-unknown-unknown](platform-support/wasm64-unknown-unknown.md) - [*-win7-windows-msvc](platform-support/win7-windows-msvc.md) - [x86_64-fortanix-unknown-sgx](platform-support/x86_64-fortanix-unknown-sgx.md)

That's more-or-less the same as (1) so I'll take it on myself to document this and get it all written down. Unfortunately that doesn't lend itself well to a test in-repo but that's not necessarily worse than where we are at today.
I've proposed to close this issue as "this change is expected".


Question: - [wasm32-wasip1](platform-support/wasm32-wasip1.md) - [wasm32-wasip1-threads](platform-support/wasm32-wasip1-threads.md) - [wasm32-wasip2](platform-support/wasm32-wasip2.md) <ins> - [wasm32-unknown-unknown](platform-support/wasm32-unknown-unknown.md) </ins> - [wasm64-unknown-unknown](platform-support/wasm64-unknown-unknown.md) - [*-win7-windows-msvc](platform-support/win7-windows-msvc.md) - [x86_64-fortanix-unknown-sgx](platform-support/x86_64-fortanix-unknown-sgx.md)

and WebAssembly book () In Rust some requirements for WebAssembly targets. This makes Wasm binaries compiled with Rust (at least with default options/out of the box std) incompatible with older runtime environments, in particular not-so-old iOS safari (). Here is for example the support for Safari iOS 15.5 simulator: ! I searched but did not find any place where these requirements are written down. I think that this is a problem.
In principle Rust can produce binaries that only target the core subset of wasm 1.0 just fine. You do need to set some additional options with and build your own standard libraries though. But point taken, is missing dedicated pages on the wasm target that could contain this information.
The 2nd sentence right after the one you quoted outlines exactly what you need to do to take advantage of rustc’s capability to emit outputs to the wasm 1.0 spec (or any superset of it:) Make sure to do this and report back if you're still seeing the unexpected instructions/types/other entities after rustc is told to produce wasm binaries the way you need them to be. AFAIK, not for WASM.
Sorry, I realized I misunderstood your answer and deleted my post while you were answering it. Do you know how to show which features are enabled by default for a given target? I searched and did not find. I'm trying to discover whether is enabled by default on nowadays. As it seems to be because I am seeing types in the emitted wasm, even though I disabled the feature by "" in an environment variable RUSTFLAGS. It would be surprising to me that is built with that feature by default on wasm32, but maybe it is.
Hm, I'm actually not sure why you might be seeing simd128 in your modules. As far as I can tell it is not enabled by default for any wasm target. In order to print out features used you should look for lines in: For what it is worth I’ve been using this exact target at my $DAYJOB with a pretty primitive runtime and it has been working largely OOB if my memory serves me right. So it indeed could have something to do with your dependencies possibly using something like ? Not sure!


Question: - [wasm32-wasip1](platform-support/wasm32-wasip1.md) - [wasm32-wasip1-threads](platform-support/wasm32-wasip1-threads.md) - [wasm32-wasip2](platform-support/wasm32-wasip2.md) <ins> - [wasm32-unknown-unknown](platform-support/wasm32-unknown-unknown.md) </ins> - [wasm64-unknown-unknown](platform-support/wasm64-unknown-unknown.md) - [*-win7-windows-msvc](platform-support/win7-windows-msvc.md) - [x86_64-fortanix-unknown-sgx](platform-support/x86_64-fortanix-unknown-sgx.md)

It seems that the was built with as I see this WASM function: What I am not sure is whether 1. this was integrated with the standard library and then imported indirectly to my project, or 2. somehow one of the dependency managed to enable it by itself. I tend to favor 1 but I'm not sure. That is why it would be great for such things to be documented :-)
For reference, I asked on the about how the std lib is built.
I confirm that as of version 1.75, the standard library is not using any WebAssembly SIMD instructions. Here is my test: which shows nothing, so they get pulled in by the memchr package through some of my dependencies.
You yourself pointed out which crate produces the v128 types: . It uses to enable emission of these types, regardless of the global configuration it looks like. This is usually fine for other architectures, but rarely for wasm, so it might make sense to file an issue over there.
I fully agree and I just opened an issue there: BurntSushi/memchr
As a heads up I've proposed that close this issue with documentation of how to target MVP wasm.


Question: - [wasm32-wasip1](platform-support/wasm32-wasip1.md) - [wasm32-wasip1-threads](platform-support/wasm32-wasip1-threads.md) - [wasm32-wasip2](platform-support/wasm32-wasip2.md) <ins> - [wasm32-unknown-unknown](platform-support/wasm32-unknown-unknown.md) </ins> - [wasm64-unknown-unknown](platform-support/wasm64-unknown-unknown.md) - [*-win7-windows-msvc](platform-support/win7-windows-msvc.md) - [x86_64-fortanix-unknown-sgx](platform-support/x86_64-fortanix-unknown-sgx.md)

<!-- 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 to build a wasm binary with MVP opcode only, so I disabled the features: I expected to see no in the wasm binary. Instead, this happened: <!-- 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
You can not deactivate default features, because std is prebuilt. You need to build std yourself. Also these features are considered the default by LLVM ever since the recent upgrade to LLVM 16: This should possibly be mentioned in the Rust 1.70 release notes though?
cc to confirm that we're fine with inheriting this change to default target features in Rust.
More context for this change can be found in these locations: - discussion about enabling new features in both Emscripten and LLVM. - the original LLVM patch for this - more follow-up discussion on LLVM In that sense this is an expected change, but at the same time the change was made with the expectation that most users are running on an engine that implements sign-extension. could you expand a bit more on your motivation for excluding these sign-extension instructions? I do agree, though, that this should be mentioned in the detailed release notes. It's unfortunately a bit opaque since not all users of wasm are intimately familiar with proposals and whether or not engines support them, but it's a change nonetheless worth mentioning.
I have tried to use , still not work: Our blockchain platform has used Wasm as a virtual machine running smart contracts and has been running steadily for many years. The MVP opcodes is fully sufficient for our use case. I hope there are ways to turn off these default extension features to avoid frequent upgrades every time a new feature is introduced.
Could you share the code used to reproduce this? These upgrades will not be frequent. This is the first time it's changed in 5 years.


Question: - [wasm32-wasip1](platform-support/wasm32-wasip1.md) - [wasm32-wasip1-threads](platform-support/wasm32-wasip1-threads.md) - [wasm32-wasip2](platform-support/wasm32-wasip2.md) <ins> - [wasm32-unknown-unknown](platform-support/wasm32-unknown-unknown.md) </ins> - [wasm64-unknown-unknown](platform-support/wasm64-unknown-unknown.md) - [*-win7-windows-msvc](platform-support/win7-windows-msvc.md) - [x86_64-fortanix-unknown-sgx](platform-support/x86_64-fortanix-unknown-sgx.md)

The use case I have for wanting to build without these extensions isn't critical (servers for a game which don't support the extensions in the old version of nodejs they're running), but a way to successfully disable them to be able to build for such environments would be appreciated!
It would be helpful to have a reproduction of this to run to test out fixes. I tested something locally and was sufficient to disable sign extension instructions. I don't know why isn't working and that may be an LLVM bug. I can't confirm whether this works for others though without a means of reproduction.
I just tried the following: compiled with: to make sure std being precompiled isn't causing problems, and it totally still contains the sign-ext instructions: So you are right, this is some sort of LLVM bug.
Confirming that results in a file without the sign-ext opcodes, while does not, in my testing as well.
would you perhaps know more about ? I would expect that with on the function then even without sign-extension instructions wouldn't get generated, but I'm not sure.
I wonder if this is a consequence of It looks like that might be unioning the module-level features along with the per-function features to form the effective feature set to use.
It can also be reproduced with:
FWIW, the above flags did not work for me with - the resulting binary still had sign-extension opcodes (namely ) - but this served as a workaround (): Command: ^ With the wasm-opt pass, sign-extension ops were gone; without the pass, still there. From the thread above, it sounds like those flags work for some people but not for others. My use case is (was) supporting old Apple devices stuck on iOS 12 and thus Safari 12. Now past this, the binary can load, but performance is enough of a problem to suggest dropping support anyway.
A slightly related issue is that the WebAssembly extensions used by default by the Rust compiler are not documented (besides in the change log, but new users won't look at it), I opened a specific issue for that () and just want to link it here.
As a heads up I've documentation about features to which I've currently got as flagged to close this issue. The documented solution for targetting MVP wasm is: which should solve the original OP of this issue.


Question: - [wasm32-wasip1](platform-support/wasm32-wasip1.md) - [wasm32-wasip1-threads](platform-support/wasm32-wasip1-threads.md) - [wasm32-wasip2](platform-support/wasm32-wasip2.md) <ins> - [wasm32-unknown-unknown](platform-support/wasm32-unknown-unknown.md) </ins> - [wasm64-unknown-unknown](platform-support/wasm64-unknown-unknown.md) - [*-win7-windows-msvc](platform-support/win7-windows-msvc.md) - [x86_64-fortanix-unknown-sgx](platform-support/x86_64-fortanix-unknown-sgx.md)

Other solutions in this issue such as using or that in conjunction with or others don't work for one reason or another. Using the target-cpu, however, plus recompiling the standard library with , does work.


Question: <ins> // check-fail // See issue #91899. If we treat unnormalized args as WF, `Self` can also be a // source of unsoundness. pub trait Yokeable<'a>: 'static { type Output: 'a; } impl<'a, T: 'static + ?Sized> Yokeable<'a> for &'static T { type Output = &'a T; } pub trait ZeroCopyFrom<C: ?Sized>: for<'a> Yokeable<'a> { /// Clone the cart `C` into a [`Yokeable`] struct, which may retain references into `C`. fn zero_copy_from<'b>(cart: &'b C) -> <Self as Yokeable<'b>>::Output; } impl<T> ZeroCopyFrom<[T]> for &'static [T] { fn zero_copy_from<'b>(cart: &'b [T]) -> &'b [T] { //~^ the parameter cart } } fn main() {} </ins>

Note: The regression is valid/"allowed" (there's a hole in the typesystem being patched), I'm just filing this issue now so we can make sure that this regression is tracked in case it got "fixed" by accident. Feel free to close if it's a known quantity; I'm just worried that this got "accidentally" fixed in some other change. My crate is being fixed to not face this problem, but in general there's a chance other crates are falling afoul of this as well; we should perhaps assess the impact and start off with it being a future incompatibility warning if necessary. I tried this code: () I expected to see this happen: It compiles, like it does on stable, or at least throws a future incompatibility warning. Instead, this happened: It errors: It most recently worked on: Rust 1.56.0
This regressed in , which was a rollup. Further testing shows this resulted from . It's marked as being a partial revert, so I'm not entirely sure what the chronology is here. CC Note that we think this "regression" probably isn't actually a problem, per the note at the top.
What the....
Okay so reverting fully also errors. Stable 1.55.0 fails. Checking (a couple commits before ) now, but I'm assuming it's going to error. So, this was actually a bug in 1.56.0 - prior to that, this didn't compile, rightfully. My guess is because of treating unnormalized function args & output as WF, we saw , replaced it with , assumed that was WF, so we didn't actually check that . I'm going to go ahead and make a PR to add a test that closes this issue. This was a bug in 1.56.0, not a regression since.
Good to know, thanks! (And good that this was just a one-version regression; less chance of there being in-the-wild breakage)
I should figure out an excuse to make yoke a dependency of rustc, it seems really good at finding typesystem corner cases and maybe we should just have it be a test
Isn't it failing on the wrong line?


Question: <ins> // check-fail // See issue #91899. If we treat unnormalized args as WF, `Self` can also be a // source of unsoundness. pub trait Yokeable<'a>: 'static { type Output: 'a; } impl<'a, T: 'static + ?Sized> Yokeable<'a> for &'static T { type Output = &'a T; } pub trait ZeroCopyFrom<C: ?Sized>: for<'a> Yokeable<'a> { /// Clone the cart `C` into a [`Yokeable`] struct, which may retain references into `C`. fn zero_copy_from<'b>(cart: &'b C) -> <Self as Yokeable<'b>>::Output; } impl<T> ZeroCopyFrom<[T]> for &'static [T] { fn zero_copy_from<'b>(cart: &'b [T]) -> &'b [T] { //~^ the parameter cart } } fn main() {} </ins>

I would have expected it to fail on the because is the thing that needs to match
Haha yeah, it's a thorn in my side So, it's interesting. The check is , which is true. What I might expect here is it to fail because you haven't written (which is required for to be well-formed. But I think this is implied bounds, since this is fine:
In my experience WFness of has always been a bit variable where sometimes you can assume it and sometimes it requires you to spell it out, so maybe this is another instance of that.
Thanks!


Question: // option. This file may not be copied, modified, or distributed // except according to those terms. <ins> #![feature(associated_consts)] </ins> use Trait::foo; //~^ ERROR `foo` is not directly importable <ins> use Trait::Assoc; //~^ ERROR `Assoc` is not directly importable use Trait::C; //~^ ERROR `C` is not directly importable </ins> use Foo::new; //~^ ERROR unresolved import `Foo::new`. Not a module `Foo` <ins> use Foo::C2; //~^ ERROR unresolved import `Foo::C2`. Not a module `Foo` </ins> pub trait Trait { fn foo(); <ins> type Assoc; const C: u32; </ins> } struct Foo; impl Foo { fn new() {} <ins> const C2: u32 = 0; </ins> } fn main() {}

with rustc 1.0.0-nightly ( 2015-03-01) (built 2015-03-01)
This is still an issue
Still an issue in 1.0.0.
This is still an issue in 1.3.0-nightly: $ rustc error: internal compiler error: unexpected panic thread 'rustc' panicked at 'assertion failed: <= ()', stack backtrace: 1: 0x7fd6c19bd5ee - sys::backtrace::write::h04a6ced565b26815Lqs 2: 0x7fd6c19c5214 - panicking::onpanic::h521f84b604e22dfel8w 3: 0x7fd6c198804e - rt::unwind::beginunwindinner::hd3dee614a0e1c16cZNw 4: 0x7fd6c1988d7c - rt::unwind::beginunwindfmt::ha4ce6704c81423045Mw 5: 0x7fd6c19c4dd6 - rustbeginunwind 6: 0x7fd6c1a15bb4 - panicking::panicfmt::he89ea3094b3178e919B 7: 0x7fd6c1a0f9dd - panicking::panic::h9e565ee21070221by8B 8: 0x7fd6c11f8271 - astconv::finishresolvingdeftoty::h03670159ac2fefe7aTv 9: 0x7fd6c11b6340 - astconv::asttytoty::hb2c49d2cf31c029bYUv 10: 0x7fd6c1189eed - check::closure::checkexprclosure::hbce85e7beaf0ebd52zl 11: 0x7fd6c11d360b - check::checkexprwithunifier::h16314096699859592584 12: 0x7fd6c11f998b - check::checkdeclinitializer::h491ede37e45bce9e84r 13:


Question: // option. This file may not be copied, modified, or distributed // except according to those terms. <ins> #![feature(associated_consts)] </ins> use Trait::foo; //~^ ERROR `foo` is not directly importable <ins> use Trait::Assoc; //~^ ERROR `Assoc` is not directly importable use Trait::C; //~^ ERROR `C` is not directly importable </ins> use Foo::new; //~^ ERROR unresolved import `Foo::new`. Not a module `Foo` <ins> use Foo::C2; //~^ ERROR unresolved import `Foo::C2`. Not a module `Foo` </ins> pub trait Trait { fn foo(); <ins> type Assoc; const C: u32; </ins> } struct Foo; impl Foo { fn new() {} <ins> const C2: u32 = 0; </ins> } fn main() {}

0x7fd6c11f9a4d - check::checkdecllocal::h1c782249285c9ae3m6r 14: 0x7fd6c11f9c79 - check::checkstmt::h48bf6ea3f412b86bf8r 15: 0x7fd6c11a91b3 - check::checkblockwithexpected::h072b2c4702c43b1cjcs 16: 0x7fd6c118bef4 - check::checkfn::h8218f9adb3734183iQn 17: 0x7fd6c11a35ca - check::checkbarefn::h3c567a2d1339f838RFn 18: 0x7fd6c11a1523 - check::checkitembody::h8e17e6521c30131ay6n 19: 0x7fd6c11a31e4 - check::checkitemtypes::h62e908b1d9f74b39oDn 20: 0x7fd6c12609b8 - checkcrate::h594ee0148d251222uZC 21: 0x7fd6c1f1dc69 - driver::phase3runanalysispasses::closure.


Question: // option. This file may not be copied, modified, or distributed // except according to those terms. <ins> #![feature(associated_consts)] </ins> use Trait::foo; //~^ ERROR `foo` is not directly importable <ins> use Trait::Assoc; //~^ ERROR `Assoc` is not directly importable use Trait::C; //~^ ERROR `C` is not directly importable </ins> use Foo::new; //~^ ERROR unresolved import `Foo::new`. Not a module `Foo` <ins> use Foo::C2; //~^ ERROR unresolved import `Foo::C2`. Not a module `Foo` </ins> pub trait Trait { fn foo(); <ins> type Assoc; const C: u32; </ins> } struct Foo; impl Foo { fn new() {} <ins> const C2: u32 = 0; </ins> } fn main() {}

22: 0x7fd6c1f1c633 - middle::ty::ctxt<'tcx::createandenter::h349256048753845929 23: 0x7fd6c1f17a17 - driver::phase3runanalysispasses::h15521018079403107052 24: 0x7fd6c1efa266 - driver::compileinput::hbf698b02349f7ce3Tba 25: 0x7fd6c1fd3ed3 - runcompiler::hd724b5fef3441688y7b 26: 0x7fd6c1fd18ae - boxed::F.FnBox<A::callbox::h6609070342514802751 27: 0x7fd6c1fd10f9 - rt::unwind::try::tryfn::h10774555836369096370 28: 0x7fd6c1a3ed48 - rusttryinner 29: 0x7fd6c1a3ed35 - rusttry 30: 0x7fd6c19b08a7 - rt::unwind::try::innertry::hb0d7a3eb324339ceSJw 31: 0x7fd6c1fd130b - boxed::F.FnBox<A::callbox::h18179817771297192954 32: 0x7fd6c19c3e71 - sys::thread::Thread::new::threadstart::hf8c7448e27294ed0PTv 33: 0x7fd6bb60f353 - startthread 34: 0x7fd6c161ebfc - _clone 35: 0x0 - <unknown
$ rustc --version rustc 1.3.0-nightly ( 2015-06-30)
This problem has gone away for me now. It may have been from mixing versions? It may have gone away after a .
It is still an issue on nightly according to the playpen:
You're right. I must have been in the wrong project.
I just ran into the same assertion (with both stable 1.1 and nightly 1.3), but with different code.


Question: // option. This file may not be copied, modified, or distributed // except according to those terms. <ins> #![feature(associated_consts)] </ins> use Trait::foo; //~^ ERROR `foo` is not directly importable <ins> use Trait::Assoc; //~^ ERROR `Assoc` is not directly importable use Trait::C; //~^ ERROR `C` is not directly importable </ins> use Foo::new; //~^ ERROR unresolved import `Foo::new`. Not a module `Foo` <ins> use Foo::C2; //~^ ERROR unresolved import `Foo::C2`. Not a module `Foo` </ins> pub trait Trait { fn foo(); <ins> type Assoc; const C: u32; </ins> } struct Foo; impl Foo { fn new() {} <ins> const C2: u32 = 0; </ins> } fn main() {}

Would it help if I try to create another minimal working example and post it here or a new bug report? This is my backtrace: didn't help.
Okay here it is: Unfortunately it has something to do with glium, so I guess this doesn't help much :/
May be related, not sure: (rustc 1.2.0 ( 2015-08-03))
minimized:


Question: <ins> error[E0425]: cannot find value `a_variable_longer_name` in this scope --> $DIR/issue-66968-suggest-sorted-words.rs:3:20 | LL |     println!("{}", a_variable_longer_name); |                    ^^^^^^^^^^^^^^^^^^^^^^ help: a local variable with a similar name exists: `a_longer_variable_name` error: aborting due to previous error For more information about this error, try `rustc --explain E0425`. </ins>

On identifiers that have more than one word, it is relatively common to write them in the wrong order ( → ). These are normally not found by Levenshtein distance checks, but we could do a basic "split on ``, sort and join before comparison" so that we could suggest the right identifier. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I'd like to try to work on this. As is short enough to be caught by the Levenstein distance, I wrote for testing: claim
I'm thinking about the priority of the different possible matches. I tend to think that a match found by levenstein distance should have a greater priority, but what do you think?
it's tricky. I feel that your instinct might be right but we'd only know when looking at real world usage. The nice thing is that the lev distance check by its very nature it is limited, so doing the swapped words check as a fallback should work out ok in practice.
Releasing my assignment, as I am not sure to be able to commit. In case someone want to take on this, here is the function that should be modified. release-assignment
(I think this is appropriate, please tell me if it isn't) modify labels to +E-Easy
I can take a stab at this, seems reasonable with previous comments. claim


Question: let archive = ArchiveRO::open(&path).expect("wanted an rlib"); debug!("reading {}", name); <del> let bc = time(sess.time_passes(), format!("read {}.bc", name), (), |_| archive.read(format!("{}.bc", name))); let bc = bc.expect("missing bytecode in archive!"); </del> <ins> let bc = time(sess.time_passes(), format!("read {}.bc.deflate", name), (), |_| archive.read(format!("{}.bc.deflate", name))); let bc = bc.expect("missing compressed bytecode in archive!"); </ins> let bc = time(sess.time_passes(), format!("inflate {}.bc", name), (), |_| flate::inflate_bytes(bc)); let ptr = bc.as_slice().as_ptr();

Passing rustc the flag and passing may produce different files (that is, outputs). This is true of rust-core (see below), though was not the case for a simpler ("Hello, world!") test file. Test script: Diff output indicates binary files differ. Tested with , rust-core on . rustc compiled from master on Arch Linux. If this is, in fact, expected behavior- sorry for the trouble, unexpected to me.
Can you provide a diff between the outputs? This is likely a known issue, but I would like to be sure.
.bc is a binary format, so just gives "Binary files and differ" as its output. On my machine, is 19K and is 62K. I'm not familiar enough with the format to extract much more data.
I note the difference persists when the second line is (two separate flags), though both produce both artifacts.
Can you pass and diff those outputs?
With emit flags as and respectively, there is no difference in and (according to diff.)
It seems that every bytecode is invalid only when a rlib is produced. It stopped working between rust-git-0.9.1301 and 1362 (shortly before 2014-02-23 15:37:05 -0800). Going back thorugh the log, I found I believe that creates deflated bytecode. Perhaps should be stored with extension or .


Question: } fn main() { <del> unsafe { printf(); } //~ ERROR E0060 </del> <ins> unsafe { printf(); } //~^ ERROR E0060 //~| NOTE expected at least 1 parameter //~| NOTE the following parameter type was expected </ins> }

From: src/test/compile- Error E0061 needs a span_label, updating it from: To: Bonus: the types could be incorporated into the label rather than a note (though we may want to avoid types with long names in the label)
Planning on tackling the bonus here. Is there a prefered max length for output on the console. In the case it would exceed this should i truncate the typename or just not include?
- great point. If you want to work on truncation, feel free to add it, too. I'm not sure if the term crate will tell you the current terminal size, but it may.
I'm fixing and I noticed that it and this issue currently share the same code for generating this error, and adding code to add a to the message in would fix both.
Did you do the bonus as well? I can tackle that if you haven't.
I haven't yet - I can fix the issue (currently testing/fixing unit tests) and you can take on the bonus part of the issue.
Sounds great to me! Thanks.
- I opened up issue to track the bonus portion of the work for you.


Question: tcx: TyCtxt<'tcx>, fn_sig: ty::PolyFnSig<'tcx>, ) -> Result<bool, &'tcx LayoutError<'tcx>> { <del> let mut ret_ty = fn_sig.output().skip_binder(); </del> <ins> // this type is only used for layout computation, which does not rely on regions let fn_sig = tcx.instantiate_bound_regions_with_erased(fn_sig); let mut ret_ty = fn_sig.output(); </ins> let layout = tcx.layout_of(ParamEnv::reveal_all().and(ret_ty))?; let size = layout.layout.size().bytes();

<!-- ICE: Rustc '' 'thread 'rustc' panicked at ' has escaping bound vars, so it cannot be wrapped in a dummy binder.'', 'thread 'rustc' panicked at ' has escaping bound vars, so it cannot be wrapped in a dummy binder.'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [issizedraw] computing whether is [layoutof] computing layout of -- label +F-impltraitinassoctype +F-inherentassociated_types
ah lol this regressed in cc


Question: <ins> // Regression test for #61315 // // `dyn T:` is lowered to `dyn T: ReEmpty` - check that we don't ICE in NLL for // the unexpected region. // compile-pass trait T {} fn f() where dyn T: {} fn main() {} </ins>

Found as a byproduct of work on backtrace: Compiles on stable 1.35.0.
triage: Looks like matthewjasper is on top of this. Marking P-high just so I don't have to think about it further right now. Removing nomination tag.


Question: <ins> // Regression test for #61315 // // `dyn T:` is lowered to `dyn T: ReEmpty` - check that we don't ICE in NLL for // the unexpected region. // compile-pass trait T {} fn f() where dyn T: {} fn main() {} </ins>

Happens on stable 1.34.2, 1.35.0 and current nightly (2019-05-28). . Results in:
Reduced:
Compiles fine on 1.34.0; haven't tested 1.34.1.
both my repro and your reduced one do ICE on (and ) for me, can you verify that again?
Happens all the way back to 1.30.0 (with ) for me, as long as is passed to rustc.
Ah of course! is needed for NLL on older versions... :) I forgot that godbolt doesn't have that by default.


Question: } else if attr.check_name(sym::thread_local) { codegen_fn_attrs.flags |= CodegenFnAttrFlags::THREAD_LOCAL; } else if attr.check_name(sym::track_caller) { <del> if tcx.fn_sig(id).abi() != abi::Abi::Rust { </del> <ins> if tcx.is_closure(id) || tcx.fn_sig(id).abi() != abi::Abi::Rust { </ins> struct_span_err!(tcx.sess, attr.span, E0737, "`#[track_caller]` requires Rust ABI") .emit(); }

This code () Produces ICE on any channel
This is the same issue as , attributes on expressions are not converted into HIR properly.
I checked on latest nightly - isn't produced anymore while this one still throws ICE.
could you reopen this issue?
triage: P-high. Removing nomination.
Reduced somewhat:


Question:
pub fn create( ) -> Padding00000000000000000000000000000000000000000000000000000000000000000000000000000000
   No newline at end of file
pub fn create() -> Padding00000000000000000000000000000000000000000000000000000000000000000000000000000000
   No newline at end of file

Take a look at the docs for : Rustdoc is making good choices for whether to wrap the declarations ! But when it wraps, it doesn't include a trailing comma on the last parameter. I think it should, because the default style guide wants a comma there. (And rustdoc should continue not putting a trailing comma when the declaration is shown as a single line.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim


Question: <ins> // check-pass trait MyCmp { fn cmp(&self) {} } impl MyCmp for f32 {} fn main() { // Ensure that `impl<F: FnPtr> Ord for F` is never considered for int and float infer vars. 0.0.cmp(); } </ins>

Note: the below reduction originally came from a + in the wild. I haven't found a way to demonstrate this outside of the "float inference vars + method" combo, but: works on stable () and beta (), and errors on nightly with: Even though it doesn't show the source for candidate , I'm almost certain it's this: from (cc On the original PR I left comments like , trying to rectify the issues with the original approach, but they didn't go anywhere and the version that one in the end is the (arguably) more fragile original one, that uses blanket s and works around their unwanted interactions. It's possible in this case all it takes is checking for "float inference vars" and making sure they can never be considered to implement , but I'm worried there might be other edge cases lurking in the shadows. Also, did both of those PRs skip crater? I feel like this shouldn't be that hard to hit in the wild.
WG-prioritization assigning priority (). label -I-prioritize +P-high


Question: "URL": "struct.ZyxwvutMethodDisambiguation.html#method.method_impl_disambiguation-1" }, ENDS_WITH) assert: "section:target" <ins> // Checks that, if a type has two methods with the same name, // and if it has multiple inherent impl blocks, that the numeric // impl block's disambiguator is also acted upon. go-to: "file://" + |DOC_PATH| + "/lib2/index.html?search=MultiImplBlockStruct->bool" wait-for: "#search-tabs" assert-count: ("a.result-method", 1) assert-attribute: ("a.result-method", { "href": "../lib2/another_mod/struct.MultiImplBlockStruct.html#impl-MultiImplBlockStruct/method.second_fn" }) click: "a.result-method" wait-for: "details:has(summary > #impl-MultiImplBlockStruct-1) > div section[id='method.second_fn']:target" go-to: "file://" + |DOC_PATH| + "/lib2/index.html?search=MultiImplBlockStruct->u32" wait-for: "#search-tabs" assert-count: ("a.result-method", 1) assert-attribute: ("a.result-method", { "href": "../lib2/another_mod/struct.MultiImplBlockStruct.html#impl-MultiImplBlockTrait-for-MultiImplBlockStruct/method.second_fn" }) click: "a.result-method" wait-for: "details:has(summary > #impl-MultiImplBlockTrait-for-MultiImplBlockStruct) > div section[id='method.second_fn-1']:target" </ins>

I spotted this in : the result links to ' which is not a valid link. Cc
cc -- I think these are supposed to be autoredirected in JS?
Okay... This happens because there's more than one and the one we want is currently named . The URL escaping is fine; the -35 is the problem.


Question: - checkout: self fetchDepth: 2 <ins> # Spawn a background process to collect CPU usage statistics which we'll upload # at the end of the build. See the comments in the script here for more # information. - bash: python src/ci/cpu-usage-over-time.py &> cpu-usage.csv & displayName: "Collect CPU-usage statistics in the background" </ins> - bash: printenv | sort displayName: Show environment variables

One of the easiest ways to make CI faster is to make things parallel and simply use the hardware we have available to us. Unfortunately though we don't have a lot of data about how parallel our build is. Are there steps we think are parallel but actually aren't? Are we pegged to one core for long durations when there's other work we could be doing? The general idea here is that we'd spin up a daemon at the very start of the build which would sample CPU utilization every so often. This daemon would then update a file that's either displayed or uploaded at the end of the build. Hopefully we could then use these logs to get a better view into how the builders are working during the build, diagnose non-parallel portions of the build, and implement fixes to use all the cpus we've got. cc
On Windows this can be done by taking advantage of job objects. If the entire build is wrapped in a job object then we can call with to get a bunch of useful data.
I made script that will print output into the travis log every 30 seconds , . Some findings: Cloning submodules jemalloc, libcompilerbuildtins and liblibc alone takes 30 seconds. While building bootstrap, compiling serdederive, serdejson and bootstrap crates seems to take 30 seconds (total build time: 47 seconds). stage0: Compiling tidy crate seems to take around 30 seconds. Compiling rustcerrors takes at least 2 minutes, only one codegen-unit is used Compiling syntaxext takes 9 minutes, only one CGU used stage0 codegen artifacts: Compiling rustcllvm takes 1,5 minutes, one CGU During stage1, rustcerrors and syntaxext builds are approximately as slow as during stage0, rustc_plugins 2 minutes, one CGU. stage2: rustdoc took 2 minutes to build, one CGU compiletest suite=run-make mode=run-make: It looks like there is a single test that takes around 3 minutes to complete and has no parallelization. Testing alloc stage1: building liballoc takes around a minute Testing syntax stage1: building syntax takes 1.5 minutes, one CGU Notes: When the load average dropped towards 1, I assumed only one codegen unit was active.


Question: - checkout: self fetchDepth: 2 <ins> # Spawn a background process to collect CPU usage statistics which we'll upload # at the end of the build. See the comments in the script here for more # information. - bash: python src/ci/cpu-usage-over-time.py &> cpu-usage.csv & displayName: "Collect CPU-usage statistics in the background" </ins> - bash: printenv | sort displayName: Show environment variables

The script was only applied to the default pullrequest travis-ci configuration.
As shown in , the CPUs assigned to each job may have some performance difference: Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz The clock-rate 2.4 GHz vs 2.5 GHz shouldn't make any noticeable difference though (this would at most slow down by 7.2 minutes out of 3 hours if everything is CPU-bound). It is not enough to explain the timeout in .
I was working on recently for this where it periodically prints out the CPU usage as a percentage for the whole system (aka 1 core on a 4 core machine is 25%). I only got Linux/OSX working though and was unable to figure out a good way to do it on Windows. My thinking for how we'd do this is probably download a binary near the beginning of the build (or set up some script). We'd then run just before we run . That way we could correlate the two timestamps of each log (the main log and the to similar moments in time. Initially I was also thinking we'd just at the end of the build and scrape it later if need be.


Question: modified: Option<SystemTime>, } <del> #[derive(Copy, Clone, PartialEq, Eq, Hash, Debug)] </del> <ins> #[derive(Copy, Clone, Eq, Debug)] </ins> pub struct FileType { mode: mode_t, } <ins> impl PartialEq for FileType { fn eq(&self, other: &Self) -> bool { self.masked() == other.masked() } } impl core::hash::Hash for FileType { fn hash<H: core::hash::Hasher>(&self, state: &mut H) { self.masked().hash(state); } } </ins> #[derive(Debug)] pub struct DirBuilder { mode: mode_t,

<!-- 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 this code: This currently fails, even though no symlinks are involved. This is because on Unix are currently compared on the totality of their contained unix , which are bitflags of the form (in octal) where is a Unix permission mode and the actual file type. As of now, depending on how the is built, may be either (from ) or set to the actual file permission mode (if built from ). (This bug was co-investigated with <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
label: +T-libs-api + Libs-Small
Error: Parsing relabel command in failed: ...'libs-api +' ' Libs-Smal'... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
label: +T-libs-api +Libs-Small
Error: Label Libs-Small can only be set by Rust team members Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
label: +T-libs-api


Question: #[no_mangle] fn __rustc_plugin_registrar(reg: &mut Registry) { reg.lint_store.register_lints(&[&TEST_LINT]); <del> reg.lint_store.register_early_pass(|| box Pass); </del> <ins> reg.lint_store.register_early_pass(|| Box::new(Pass)); </ins> } ```

There is no such thing as boxsyntax anymore :D <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
does the same.
It probably makes sense to search across the repository (including submodules) any references to this removed feature and remove them
claim


Question: can_unwind: fn_can_unwind(cx.tcx().sess.panic_strategy(), codegen_fn_attr_flags, conv), }; fn_abi.adjust_for_abi(cx, sig.abi); <ins> debug!("FnAbi::new_internal = {:?}", fn_abi); </ins> fn_abi }

Rust should pass more structs in registers. Consider these examples: ideally, both functions would execute entirely in registers and wouldn't touch memory: Rust, as of a recent 1.2.0-dev nightly, is unable to pass either of these in registers (see LLVM IR and ASM below). It would be pretty safe to pass and return small structs (ones that fit into <=2 registers) in registers, and is likely to improve performance on average. This is what the System V ABI does. It would also be nice to exploit Rust's control over aliasing, and where possible also promote reference arguments to registers, i.e. put the values in registers for the following functions: In the case, this would mean passing two values in registers as function parameters, and returning two values in registers as the return values (ideally we'd arrange for the parameter registers to match the return registers). Uniqueness of makes this optimization valid, although we may have to give up on this optimization in cases such as when there are raw pointers present. Here's a more realistic example where I've wanted Rust to do this: This function is too large to justify inlining. I'd like the begin and end pointers of to be kept in registers across the function call. Probably not surprising to the compiler team, but for completeness here is the LLVM IR of the above snippets, as of today's Rust (1.2.0-dev), compiled in release mode / opt-level=3: and here is the ASM:
For fat pointers this has been fixed in Am 22.06.2015 07:58 schrieb "Reiner Pope"
On etc. this is currently impossible because the address of references is significant (you can e.g. print it with ).
- yes, the ability to take addresses prevents doing this for all functions. But you could see doing this as an optimization: make the compiler check whether a function uses the address of a reference, and if not then change its calling convention. The compiler can use the worker/wrapper technique (as in GHC) to support call sites which aren't aware of this change in calling convention, by splitting the function into two:
Don't do this. You will break FastISel. Fix LLVM if it's not doing the optimizations you want.
what exactly would break FastISel?


Question: can_unwind: fn_can_unwind(cx.tcx().sess.panic_strategy(), codegen_fn_attr_flags, conv), }; fn_abi.adjust_for_abi(cx, sig.abi); <ins> debug!("FnAbi::new_internal = {:?}", fn_abi); </ins> fn_abi }

Pretty sure that since work on niche-filling optimisation, and use a pair of registers for the argument and the return value, respectively. Cc
didn't solve this?
Yes, this appears to be fixed. The following Rust code (): generates and
Ah no, I see that this issue also suggests: We don't do that yet: . FWIW Maybe it is worth to split this issue into two. One part has been closed already AFAICT. The other part (passing as a register containing a ) is... a suggestion at most. This issue does not suggest how to do this. already raised the issue that this breaks if the address is inspected. It probably needs to handle writes through (e.g. due to ) and somehow as well, etc. So I'm skeptic that this can work.
Here's another slightly more complex example, where ABI seems to be more efficient than :
A related thread:
is this fixed? Linked code is still bigger on Rust 1.48.
my example is fixed, the return value is no longer via stack: The difference is that rust abi version now uses a vectorized add, which seems like a win?
Hi all. I've traced back the cause of 'P-high' issue to two pulls that relate to this issue, namely and . Basically, these commits break auto-vectorization post Rust version 1.48 in a way that is not easily worked around. In short, if we take: 47 yields an efficient: 48 yields an awkward: 50 yields an even more awkward cascade effect: There are other examples in . My overly simplistic analysis, I'm no expert, is . In summary, if I rebuild Rust with the above pulls neutered, auto-vectorization appears to return to normal, as per 1.47.


Question: LinkerFlavor::Gcc, vec!["-m64".to_string(), "-arch".to_string(), "x86_64".to_string()], ); <del> base.link_env.extend(super::apple_base::macos_link_env("x86_64")); </del> base.link_env_remove.extend(super::apple_base::macos_link_env_remove()); // don't use probe-stack=inline-asm until rust#83139 and rust#84667 are resolved base.stack_probes = StackProbeType::Call;

<!-- 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. --This used to work on Rust : is present in the framework (on macOS +10.13; on lower versions, in the framework). The framework uses internally, so the symbol is available through that (I think). Linking like this worked previously, but since Rust it started failing. This is . <!-- 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. --OS: macOS Mojave 10.14.6. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Sorry if the issue is not very well explained, I'm very inexperienced with how linking works
This is affecting  as well from what I can tell.
This appears to have regressed via , cc As a temporary workaround, you can try setting the environment variable to something like .
With Rust sets to 10.7 for the linker, if not set, to match what we are passing to LLVM. Setting it to 10.8 or above get rids of the linker failure. I will look into this more.
Can you elaborate on that? Building it locally with worked fine for me on an M1.
I can confirm that using gets rid of the linker failure in . For , is required. You need to build a binary, so that the linker is actually invoked. Try building an example (e.g. ).
I can clarify this a little more: If you were building a Rust program for an Apple platform that linked to APIs with availability somewhere between 10.7+ and 12.0+, and you weren't setting your own deployment target, has revealed a bug in your build process. Your binaries were only ever going to run on recent OS releases, but you would have been unaware without testing.


Question: LinkerFlavor::Gcc, vec!["-m64".to_string(), "-arch".to_string(), "x86_64".to_string()], ); <del> base.link_env.extend(super::apple_base::macos_link_env("x86_64")); </del> base.link_env_remove.extend(super::apple_base::macos_link_env_remove()); // don't use probe-stack=inline-asm until rust#83139 and rust#84667 are resolved base.stack_probes = StackProbeType::Call;

For coreaudio, if it really requires APIs from 11.0+, that seems a bit recent/limiting for a library that's existed since forever on macOS. If the authors were unaware of this, has revealed that they need to do more work to attain backwards compatibility. There will be more breakage like it, but it is the good kind, because anyone using newer Apple APIs should be aware of their minimum platform requirement, just as Xcode forces you to be.
Hmm, this change had more impact than I thought. to determine which minimum Macos version to pass as part of the target triple to LLVM and to ld via by looking at the various command line options and environment variables that have accumulated over the years. If nothing is specified, it apparently defaults to the minimum of the specified in the SDKROOTs and the host Macos version . I think ideally we should probably try to mimic this behavior somewhat so we don't confront users with having to set , while they don't have to do it using clang. Not sure how we can easily accomplish this though.
Actually, that makes a lot of sense, thanks! I fully agree that it's better to catch these issues when developing (instead of later, when users complain that the application doesn't work on their older system)! I've opened to fix the linking in , and would fix the linking in .
Note that this is a breaking change for macOS users, before, they didn't have to specify , now they do. Furthermore, they have no easy way to find out that they need to (they just get a confusing linker error)! Additionally, the affected crates (that we know about) are quite widely used (at least half of all Rust games depend on and/or ), and have not yet fixed the issue, nor yet released updated versions which includes these fixes. And even when this has been done, it will take time before users have run and received working versions (can probably be helped along by yanking the affected versions). I don't really know the procedure for this, but I would like to propose reverting (at least from the current beta) to give the affected crates more time to update. Again, I really do agree with the change, I just also want to minimize the breakage macOS users will experience from upgrading Rust.


Question: LinkerFlavor::Gcc, vec!["-m64".to_string(), "-arch".to_string(), "x86_64".to_string()], ); <del> base.link_env.extend(super::apple_base::macos_link_env("x86_64")); </del> base.link_env_remove.extend(super::apple_base::macos_link_env_remove()); // don't use probe-stack=inline-asm until rust#83139 and rust#84667 are resolved base.stack_probes = StackProbeType::Call;

Like I wrote I think ideally we should match clang's behavior and thus fall back to the default of the currently configured Macos SDK. That would mean looking at the property of the in the currently configured SDK. Unfortunately I don't really see a reliable way to do get the path to that without running .
I think we should revert the change until you find a way to do this - it seems to be causing a lot of breakage and my understanding is the goal was just to turn a runtime error into a link time error.
Oh sure. I am not against a revert until that is sorted out. I will open a PR. claim
reopening as this is a beta-regression, and we keep those open until beta fix lands (or we explicitly decline to fix).
Backport merged.
Just for reference, the linking in the noted crates have since been fixed: , ,
I root-caused this a little bit more today, sharing my findings: The problem can be reproduced with and the following file: Weirdly enough, if you remove the linking to , everything links fine. I think this is actually a bug in , it seems like: The linker is reading the symbol tables from and to try to figure out where comes from. When reading , it sees that it has a few "", which includes , which is where the symbol actually comes from (well, nowadays from , but that is re-exported from ). But when reading , it finds the symbol , which is intended to indicate that "when linking on older platforms, use instead" But instead, it ends up making it seem like is actually the real , and does not expose , so the linking fails. Again, I believe this to be a linker bug because the problem does not happen with (try passing ).


Question: ty::ReErased => { flags = flags | TypeFlags::HAS_RE_ERASED; } <del> ty::ReError(_) => {} </del> <ins> ty::ReError(_) => { flags = flags | TypeFlags::HAS_FREE_REGIONS; } </ins> } debug!("type_flags({:?}) = {:?}", self, flags);

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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<summary<strongBacktrace</strong</summary<p</p</details
Another regression of cc
Before I create a fix: is an expected/reasonable value in this ? I.e. is the right fix here just to allow ?
I don't think so. Actually just looked, think it's because we're not erasing properly. Let me put up a quick fix.


Question: #[rustc_main] fn main() -> std::process::ExitCode {{ const TESTS: [test::TestDescAndFn; {nb_tests}] = [{ids}]; <del> let bin_marker = std::ffi::OsStr::new(__doctest_mod::BIN_OPTION); </del> let test_marker = std::ffi::OsStr::new(__doctest_mod::RUN_OPTION); let test_args = &[{test_args}]; <ins> const ENV_BIN: &'static str = "RUSTDOC_DOCTEST_BIN_PATH"; </ins> <del> let mut args = std::env::args_os().skip(1); while let Some(arg) = args.next() {{ if arg == bin_marker {{ let Some(binary) = args.next() else {{ panic!("missing argument after `{{}}`", __doctest_mod::BIN_OPTION); }}; if crate::__doctest_mod::BINARY_PATH.set(binary.into()).is_err() {{ panic!("`{{}}` option was used more than once", bin_marker.to_string_lossy()); }} return std::process::Termination::report(test::test_main(test_args, Vec::from(TESTS), None)); }} else if arg == test_marker {{ let Some(nb_test) = args.next() else {{ panic!("missing argument after `{{}}`", __doctest_mod::RUN_OPTION); }}; if let Some(nb_test) = nb_test.to_str().and_then(|nb| nb.parse::<usize>().ok()) {{ if let Some(test) = TESTS.get(nb_test) {{ if let test::StaticTestFn(f) = test.testfn {{ return std::process::Termination::report(f()); }} </del> <ins> if let Ok(binary) = std::env::var(ENV_BIN) {{ let _ = crate::__doctest_mod::BINARY_PATH.set(binary.into()); unsafe {{ std::env::remove_var(ENV_BIN); }} return std::process::Termination::report(test::test_main(test_args, Vec::from(TESTS), None)); }} else if let Ok(nb_test) = std::env::var(__doctest_mod::RUN_OPTION) {{ if let Ok(nb_test) = nb_test.parse::<usize>() {{ if let Some(test) = TESTS.get(nb_test) {{ if let test::StaticTestFn(f) = test.testfn {{ return std::process::Termination::report(f()); </ins> }} }} <del> panic!("Unexpected value after `{{}}`", __doctest_mod::RUN_OPTION); </del> }} <ins> panic!("Unexpected value for `{{}}`", __doctest_mod::RUN_OPTION); </ins> }} <del> eprintln!("WARNING: No argument provided so doctests will be run in the same process"); </del> <ins> eprintln!("WARNING: No rustdoc doctest environment variable provided so doctests will be run in  the same process"); </ins> std::process::Termination::report(test::test_main(test_args, Vec::from(TESTS), None)) }}", nb_tests = self.nb_tests,

The crater run for merged doctests () detected a large number of regressions due to tests examining the process arguments. (I don't have an exact number, but let's say ~50 projects.) Previously, there were no arguments, but now it gets arguments like which the user's CLI parsing code isn't expecting. For example, using something like  will now fail. It seems to be fairly common to have objects whose default constructor will parse the arguments from the command line. I'm not sure if or how we should resolve that. One idea is to use a different mechanism for passing in the test information (like via an environment variable).
I vaguely remember that using environment variables was discussed but can't find anything except mentioning it . Maybe it'd be a better approach indeed. Let me send a PR so we can make a crater run on it.


Question: ItemsInTraitsAreNotImportable, }; use crate::Determinacy::{self, *}; <del> use crate::Namespace::*; </del> use crate::{module_to_string, names_to_string, ImportSuggestion}; <ins> use crate::{AmbiguityError, Namespace::*}; </ins> use crate::{AmbiguityKind, BindingKey, ResolutionError, Resolver, Segment}; use crate::{Finalize, Module, ModuleOrUniformRoot, ParentScope, PerNS, ScopeSet}; use crate::{NameBinding, NameBindingData, NameBindingKind, PathResult, Used};

<!-- ICE: Rustc '' 'error: internal compiler error: no resolution for an import', 'error: internal compiler error: no resolution for an import' File: --auto-reduced (treereduce-rust): <details<summary<strongoriginal code</strong</summary<poriginal: </p</detailsVersion information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
regression in cc
I believe the root cause of this issue stems from the changes I made, so claim


Question: <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. // To work around #46855 // compile-flags: -Z mir-opt-level=0 // Regression test for the inhabitedness of unions with uninhabited variants, issue #46845 use std::mem; #[derive(Copy, Clone)] enum Never { } // A single uninhabited variant shouldn't make the whole union uninhabited. union Foo { a: u64, _b: Never } // If all the variants are uninhabited, however, the union should be uninhabited. union Bar { _a: (Never, u64), _b: (u64, Never) } fn main() { assert_eq!(mem::size_of::<Foo>(), 8); assert_eq!(mem::size_of::<Bar>(), 0); let f = [Foo { a: 42 }, Foo { a: 10 }]; println!("{}", unsafe { f[0].a }); assert_eq!(unsafe { f[1].a }, 10); } </ins>

Uninhabited variants should ideally be irrelevant to the representation, just like in enums. As a test, this prints out 0 instead of 8: This happens because rustc considers unions more like structs than enums, and the sees a single variant with two fields, one of which is uninhabited. I have a fix for this, but it's slightly easier to bundle it with some other changes I'm working on.
This becomes a problem when making an array of unions: The above code represents a regression (prints 42 on stable, garbage on beta/nightly).
I didn't realize it was a regression to beta - in that case I'll put up an independent fix so that it can be backported if desired.
Although I can't trigger it on the playground, you code is actually triggering an ICE for me: EDIT: I bisected the ICE to somewhere between "rust 1.23.0-nightly ( 2017-11-25)" and "rust 1.23.0-nightly ( 2017-11-26)".
cc
I put up a PR to fix this, but I'm still confused about the ICE (which I moved to ).


Question: <ins> #![feature(specialization)] #![allow(incomplete_features)] pub trait ReflectDrop { const REFLECT_DROP: bool = false; } impl<T> ReflectDrop for T where T: Clone {} pub trait PinDropInternal { fn is_valid() where Self: ReflectDrop; } struct Bears<T>(T); default impl<T> ReflectDrop for Bears<T> {} impl<T: Sized> PinDropInternal for Bears<T> { fn is_valid() where Self: ReflectDrop, { let _ = [(); 0 - !!(<Bears<T> as ReflectDrop>::REFLECT_DROP) as usize]; //~ ERROR constant expression depends on a generic parameter } } fn main() {} </ins>

Testcase: I was mostly fooling around trying to see if there was any way I could get rustc to believe that it would always know whether Bears<Twas Drop regardless of T; for the test case, I changed it to Clone and got rid of actually setting the constant to true in the default case, as well as some unsafe keywords, to avoid muddying the waters with Drop's semantics. Note that the array trick for turning a constant into a compile time error comes from , so it's not as contrived as it initially appears. Stacktrace:
The test case overflows on ` <details</details
The code doesn't produce ICE anymore (tested on ), instead, the following error is produced: ()
this no longer crashes , marking as needs-test modify labels: E-needs-test


Question: <ins> // aux-build:issue-119463-extern.rs extern crate issue_119463_extern; struct S; impl issue_119463_extern::PrivateTrait for S { //~^ ERROR: trait `PrivateTrait` is private const FOO: usize = 1; fn nonexistent() {} //~^ ERROR: method `nonexistent` is not a member of trait } fn main() {} </ins>

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --the minimal triggering case seems to impl a trait that isn't visible from the location it ends up. edit: this turns out not to require macros at all. <!-- 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. --: This also occurs in nightly (), but not in stable (which provides the correct complaint that is not publicly re-exported) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2023-11-11 to nightly-2023-12-28 regressed nightly: nightly-2023-12-19 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
0x7f6adfe7f645 - core::panicking::panic fmt::hcc at /rustc/ /library/core 72:14 180 x - <rustc resolve[]::late ::LateResolutionVisitor as rustcast[]::visit::Visitor::visititem 19: 0x7f6adee2d7ff - <rustcresolve[]::Resolver::resolvecrate ::{closure} 20: 0x7f6adee2ad1a - <rustcresolve[]::Resolver::resolvecrate 21: 0x7f6adeeb6d72 - rustcinterface[]::passes::resolverforlowering 22: 0x7f6adeeb5e2b - rustcqueryimpl[]::plumbing::rustbeginshortbacktrace::<rustcqueryimpl[]::queryimpl::resolverforlowering::dynamicquery::{closure}::{closure},


Question: <ins> // aux-build:issue-119463-extern.rs extern crate issue_119463_extern; struct S; impl issue_119463_extern::PrivateTrait for S { //~^ ERROR: trait `PrivateTrait` is private const FOO: usize = 1; fn nonexistent() {} //~^ ERROR: method `nonexistent` is not a member of trait } fn main() {} </ins>

rustcmiddle[]::query::erase::Erased<[u8; 8usize]23: 0x7f6adef1f8ec - rustcquerysystem[]: :query::plumbing::tryexecutequery::<rustcquery impl[]::DynamicConfig<rustcquerysystem[]::query::caches::SingleCache<rustcmiddle[]::query::erase::Erased<[u8; 8usize], false, false, false, rustcqueryimpl[]::plumbing::QueryCtxt, true24: 0x7f6adef1eff3 - rustcqueryimpl[]::queryimpl::resolverforlowering::getqueryincr::rustendshortbacktrace 25: 0x7f6aded0bab3 - rustcinterface[]::interface::runcompiler::<core[]::result::Result<(), rustcspan[]::ErrorGuaranteed, rustcdriverimpl[]::runcompiler::{closure}::{closure} 26: 0x7f6adee3b25b - std[]::syscommon::backtrace::rustbeginshortbacktrace::<rustcinterface[]::util::runinthreadwithglobals<rustcinterface[]::interface::runcompiler<core[]::result::Result<(), rustcspan[]::ErrorGuaranteed, rustcdriverimpl[]::runcompiler::{closure}::{closure}, core[]::result::Result<(), rustcspan[]::ErrorGuaranteed::{closure}::{closure}, core[]::result::Result<(), rustcspan[]::ErrorGuaranteed27: 0x7f6adee3b0b9 - <<std[]::thread::Builder::spawnunchecked<rustcinterface[]::util::runinthreadwithglobals<rustcinterface[]::interface::runcompiler<core[]::result::Result<(), rustcspan[]::ErrorGuaranteed, rustcdriverimpl[]::runcompiler::{closure}::{closure}, core[]::result::Result<(), rustcspan[]::ErrorGuaranteed::{closure}::{closure}, core[]::result::Result<(), rustcspan[]::ErrorGuaranteed::{closure} as core[]::ops::function::FnOnce<()::callonce::{shim:vtable} 28: 0x7f6adfe3d8e5 - <alloc::boxed::Box<F,


Question: <ins> // aux-build:issue-119463-extern.rs extern crate issue_119463_extern; struct S; impl issue_119463_extern::PrivateTrait for S { //~^ ERROR: trait `PrivateTrait` is private const FOO: usize = 1; fn nonexistent() {} //~^ ERROR: method `nonexistent` is not a member of trait } fn main() {} </ins>

Aas core::ops::function::FnOnce<Args::callonce::h5d7c8f150ab9c84c at 29: 0x7f6adfe3d8e5 - <alloc::boxed::Box<F,Aas core::ops::function::FnOnce<Args::callonce::h570d5b005c242c15 at 30: 0x7f6adfe3d8e5 - std::sys::unix::thread::Thread::new::threadstart::h36b0a20c0b2361ad at 31: 0x7f6ad9e97ada - <unknown32: 0x7f6ad9f2847c - <unknown33: 0x0 - <unknownerror: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: rustc 1.76.0-beta.1 ( 2023-12-21) running on x8664-unknown-linux-gnu note: compiler flags: --crate-type bin -C embed-bitcode=no -C debuginfo=2 -C incremental=[REDACTED] note: some of the compiler flags provided by cargo are hidden query stack during panic: [resolverfor_lowering] getting the resolver for lowering end of query stack
That is line 18 to 33
WG-prioritization assigning priority (). label -I-prioritize +P-medium
An interesting issue, claim
interesting that the crash also doesn't happen if we qualify the trait with instead of the crate's name.
The is interpreted as referring to an external crate, whereas not
right; i'm assuming it hits a different resolver codepath, despite both working the same if the referred ident is public. thanks for the quick fix!


Question: cmd.env("MIRI_BE_RUSTC", "target"); // we better remember to *unset* this in the other phases! // Set rustdoc to us as well, so we can run doctests. <ins> if let Some(orig_rustdoc) = env::var_os("RUSTDOC") { cmd.env("MIRI_ORIG_RUSTDOC", orig_rustdoc); } </ins> cmd.env("RUSTDOC", &cargo_miri_path); cmd.env("MIRI_LOCAL_CRATES", local_crates(&metadata));

Currently we do ensure on CI that works, but doctests are enabled as I couldn't figure out how to get this to work within bootstrap. However, that has let slip through. So ideally we can figure out these bootstrap issues and test rustdoc inside on rustc CI.
Here's what currently happens: shows a similar error. So... probably we're using the wrong rustdoc? I assume it's the bootstrap rustdoc, if that's a thing? I can't even see a rustdoc being built in the build log. We want the rustdoc that is produced by stage 0 here, since we are testing the Miri produced by stage 0. How do we get that? Cc
looks to be the reason we're running a random rustdoc here. I suspect we'll need to thread through a custom bootstrap env variable, since IIRC there's no RUSTDOC_WRAPPER that miri can use to thread state. Alternatively it might work to adjust miri such that it remembers which toolchain is running earlier, but I suspect that'll be harder. As-is though it's almost certainly semi-broken for any Rust user doing something like presumably, where their default toolchain isn't nightly?
It seems to be working, AFAIK rustup ensures that nested calls use the -specified toolchain. Or maybe we are just lucky... But yes we should in the outermost wrapper, determine which rustdoc cargo would invoke using the same logic as cargo store that in a miri-private env var invoke that in I assume however we'll also need further changes in how bootstrap invokes cargo-miri to tell it where the right rustdoc lives? Currently we're not even building rustdoc so something surely needs to change in bootstrap. I see this snippet a few times, is that all we need?
Yeah, I'd expect that to be enough to start with at least. Also potentially relevant: If we're already using somewhere in there (we should be, probably?) then that should already get mostly setup, see here: ,
We do that already: Unless you are trying stage 0, you should be able to see rustdoc compilation in the build logs.
This is stage 0. It should still have to build rustdoc, stage 0 Miri needs stage 0 rustdoc (not bootstrap rustdoc) for its doctests.


Question: cmd.env("MIRI_BE_RUSTC", "target"); // we better remember to *unset* this in the other phases! // Set rustdoc to us as well, so we can run doctests. <ins> if let Some(orig_rustdoc) = env::var_os("RUSTDOC") { cmd.env("MIRI_ORIG_RUSTDOC", orig_rustdoc); } </ins> cmd.env("RUSTDOC", &cargo_miri_path); cmd.env("MIRI_LOCAL_CRATES", local_crates(&metadata));

(...) ah fun, so if we invoke RUSTDOC we'll actually invoke bootstrap's rustdoc wrapper. We'll have to see if having both Miri and that wrapper around will work.^^
Never mind, that was for a build. For stage 0 this doesn't happen. I don't think this can work though... The staging with Miri is a bit weird; we need a stage 1 std as well for our stage 0 tests. Specifically we need a host sysroot that was built with a compiler that "is the same as" Miri, i.e. that is fully compatible. (The is wrong, it's not the compiler that built Miri.) This was needed to make build scripts and proc macros work in .
Yes, and if you want to use the actual rustdoc without wrapper, you can invoke . I tried using env instead of plain "rustdoc" and this is the output:
I had to manually pass from the cargo miri test caller; it turns out we are not passing it by default (or it somehow gets removed later?). Anyway, this is how I tested it:
Yeah currently this does not work due to But you have already come closer than I did. :) Was that with or stage 1? Maybe is ?
I guess that needs to be resolved first before we enable doctests on cargo miri test ? It was stage 1. Yeah, it seems like.
Yes. must continue working. I don't want to always build rustc twice when working on Miri in the tree.^^ But if necessary we could enable doc-tests only for higher stages... that would still be better than the status quo.


Question: parse_async_move_order_incorrect = the order of `move` and `async` is incorrect .suggestion = try switching the order <ins> parse_at_dot_dot_in_struct_pattern = `@ ..` is not supported in struct patterns .suggestion = bind to each field separately or, if you don't need them, just remove `{$ident} @` parse_at_in_struct_pattern = Unexpected `@` in struct pattern .note = struct patterns use `field: pattern` syntax to bind to fields .help = consider replacing `new_name @ field_name` with `field_name: new_name` if that is what you intended </ins> parse_attr_after_generic = trailing attribute after generic parameter .label = attributes must go before parameters

This erroneous code: Produces this error message It would be better if instead it produced an error message like this: Tried the code in these Rust versions and they all produced the same error message: 1.37.0 stable1.45.0 stable1.46.0-beta.1 (2020-07-15 )1.47.0-nightly (2020-07-22 ) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This shouldn't be too hard. This comes from the parser, specifically the code that parses a pattern, which is one of functions. Somewhere there is the code to parse a struct pattern. I assume the error above happens when it successfully parses a struct field and then expects a comma or closing brace. To fix it you'd have to check for and report a better error message.
claim


Question: use crate::generated_code; <del> use rustc_ast::token::{self, TokenKind}; use rustc_parse::lexer::{self, StringReader}; </del> <ins> use rustc_data_structures::sync::Lrc; use rustc_lexer::{tokenize, TokenKind}; </ins> use rustc_session::Session; use rustc_span::*;

contains a function, which allows to to, well, retokenize existing span: There's only caller of this function: And there's only one caller of that caller: In other words, the only reason why we need is to get the span of hir::Usewhich happens to be a glob import. ( rls needs to know the span of use foo:: with explicit list of imported items" code action. This was the first demoed code action and is still that is implemented ) I'd like to remove the function, as it is one of the few remaining things that requires to be public, and as it is very much a hack anyway. Additionally, I believe I've broken this function accidently a while ago: Rather than retokenizing a span, it retokenized file from the begining until the end of the span (whcih, as uses are usually on top, worked correctly most of the times by accident). What would be the best way to fix this? Add hir::Use-- this seem to be the "proper" solution here Move hack's implementation to where it belongs: in , just fetch the text of the file and look for ('') Remove the deglog functionlity from RLS? I don't like this option as it handicaps the RLS before we formally decided to deprecated it. But I don't completely disregard it either, as, as a whole, it seems to be a full-stack one off hack penetrating every layer of abstraction. WDYT?
I'd suggest the second alternative (move hack's implementation to in librutcsaveanalysis), save analysis is a home of many hacks already and one more until save analysis is deprecated in its entirety won't hurt. Adding span for would be ok if it were useful for anything else at least.


Question: if let Some(positional_arg_to_replace) = position_sp_to_replace { let name = if is_formatting_arg { named_arg_name + "$" } else { named_arg_name }; <ins> let span_to_replace = if let Ok(positional_arg_content) = self.sess().source_map().span_to_snippet(positional_arg_to_replace) && positional_arg_content.starts_with(":") { positional_arg_to_replace.shrink_to_lo() } else { positional_arg_to_replace }; </ins> db.span_suggestion_verbose( <del> positional_arg_to_replace, </del> <ins> span_to_replace, </ins> "use the named argument by name to avoid ambiguity", name, Applicability::MaybeIncorrect,

The suggestion that rustc gives is incorrect and seems to not take into account what characters are in the format argument. I tried this code: I expected to see this happen: Instead, this happened: Using beta.2/nightly : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label -C-bug +A-diagnostics +T-compiler
claim


Question: pub item_name: Ident, pub action_or_ty: String, } <ins> #[derive(Diagnostic)] #[diag(hir_typeck_ctor_is_private, code = "E0603")] pub struct CtorIsPrivate { #[primary_span] pub span: Span, pub def: String, } </ins>

I tried this code: I expected to see this happen: compilation should fail because the trait impl is defined outside of the module for the type but refers to its private field. Instead, this happened: this compiled successfully This reproduces on the playground for stable Rust, version 1.69.0:
Adding a main function and attempting to call the (playground link: ) raises the compilation error: !
This can be reproduced with cross-crate (e.i., any other crate can access the private field). This means that all encapsulations that take advantage of the field being private can be bypassed. (For example, if we change Vec to a tuple struct, the same thing as setlen could be done in safe code by abusing this bug.) label +I-unsound Also, this can be reproduced in all versions where is stable (e.i., 1.32+). It's a matter of how you initialize Foo. If you provide a constructor for Foo, you won't get a compile error:
Just for completeness, turning this into a segfault without external crates/just std:
label A-visibility
this has been unsound ever since in version 1.32
WG-prioritization assigning priority (). label -I-prioritize +P-high


Question: <ins> error: expected `fn`, found `PUT_ANYTHING_YOU_WANT_HERE` --> $DIR/issue-68062-const-extern-fns-dont-need-fn-specifier.rs:5:25 | LL |     const extern "Rust" PUT_ANYTHING_YOU_WANT_HERE bug() -> usize { 1 } |                         ^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `fn` error[E0658]: `const extern fn` definitions are unstable --> $DIR/issue-68062-const-extern-fns-dont-need-fn-specifier.rs:5:5 | LL |     const extern "Rust" PUT_ANYTHING_YOU_WANT_HERE bug() -> usize { 1 } |     ^^^^^^^^^^^^ | = note: for more information, see https://github.com/rust-lang/rust/issues/64926 = help: add `#![feature(const_extern_fn)]` to the crate attributes to enable error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0658`. </ins>

The following program compiles, and prints :
As pointed out by on discord , this also works on stable:
Regression introduced in 1.40.0, specifically this line:
I have a fix in


Question: trace!("Running RemoveUnneededDrops on {:?}", body.source); let did = body.source.def_id(); <del> let param_env = tcx.param_env(did); </del> <ins> let param_env = tcx.param_env_reveal_all_normalized(did); </ins> let mut should_simplify = false; let (basic_blocks, local_decls) = body.basic_blocks_and_local_decls_mut();

Previously: Now: <!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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<summary<strongBacktrace</strong</summary<p</p</details
Inlining exposes a use of unnormalized local in a call terminator (not sure if this is more of an issue with inlining or a validator): Note: revision annotation doesn't work in an auxiliary file (so it isn't tested on CI with mir-opt-level=2). modify labels: +A-mir-opt-inlining
This ICEs again because the fix was reverted Can someone reopen please?
Due to this new requires to trigger. <details<summaryICE:</summary</details
(FWIW can also trigger this: )
fixes this for and , but it still ICEs with on its own or with mir-opt-level 1/2 cc


Question: <ins> // Copyright 2012-2014 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. // Regression test for #27042. Test that a loop's label is included in its span. fn main() { let _: i32 = 'a: //~ ERROR mismatched types loop { break }; let _: i32 = 'b: //~ ERROR mismatched types while true { break }; let _: i32 = 'c: //~ ERROR mismatched types for _ in None { break }; let _: i32 = 'd: //~ ERROR mismatched types while let Some(_) = None { break }; } </ins>

Rustc's parser does not include a loop's label in its span. So the span associated to the expression will contain only cc


Question: <ins> warning: the feature `generic_const_exprs` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/double-opaque-parent-predicates.rs:3:12 | LL | #![feature(generic_const_exprs)] |            ^^^^^^^^^^^^^^^^^^^ | = note: see issue #76560 <https://github.com/rust-lang/rust/issues/76560> for more information = note: `#[warn(incomplete_features)]` on by default warning: 1 warning emitted </ins>

<!-- ICE: Rustc '' 'error: internal compiler error: cannot convert to a region vid', 'error: internal compiler error: cannot convert to a region vid' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [mirborrowck] borrow-checking [analysis] running analysis passes on this crate --
cc