jiebi/CodeConvo huggingface dataset:
Code change:
return; } <del> if self.in_scope_lifetimes.contains(&ident.modern()) { </del> <ins> if self.in_scope_lifetimes.contains(&ParamName::Plain(ident.modern())) { </ins> return; }

Related discussion:
text: The diagnostics ("use of undeclared lifetime name") are bad, but this indeed must be an error because the inner is an illegal use of the outer rather than an implicitly defined fresh lifetime.
Hm, I don't think that's quite what I'd expect: previously using in that context would be fine because there is no shadowing so to speak, that is, this compiles:
From Similarly, if a fn definition is nested inside another fn definition, it is an error to mention lifetimes from that outer definition (without binding them explicitly). This is again intended for future-proofing and clarity, and is an edge case. (In the second example there's an explicit definition that shadows the previous definition for following uses, in the first example there's no second definition, only use)
I see that this is in the RFC, but I think I more or less disagree with the reasoning given. Disallowing the use of inband lifetimes when nesting function seems arbitrary and not entirely helpful; it also makes a mechanical change from "old" to "new" more difficult because shadowing is visible only based on indent levels.
IMO it should be an error, with a helpful note like the one you get when writing . Let's not make in-band lifetimes any more confusing than they already are.
The distinction is that inband lifetime's selling point is that you don't need to declare lifetimes. If we say that, and then clarify it with "except" then I think the feature feels incomplete. Inband lifetimes confusion does not increase with permitting this, IMO.
The problem is if it's allowed, then has a different meaning than This seems unfortunate and confusing. Even unergonomic if I may say so. There's no way that the distinction between and won't be missed in a quick scan of the second one. But, like, the RFC process did decide that isn't important, so whatever.
Well, somewhat, but not really. Nothing outside of imports/definitions inherits into the inner function, unlike the impl where there is a history and multiple things which inherit (, lifetimes, generics).
Code change:
<ins> mod b { pub struct A(u32); } trait Id { type Assoc; } impl Id for b::A { type Assoc = b::A; } impl Id for u32 { type Assoc = u32; } trait Trait<T> { fn method(&self) where T: Id<Assoc = b::A>; } impl<T: Id> Trait<T> for <T as Id>::Assoc { fn method(&self) where T: Id<Assoc = b::A>, { let Self(a) = self; //~^ ERROR: tuple struct constructor `A` is private println!("{a}"); } } fn main() {} </ins>

Related discussion:
text: 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
Code change:
--set target.x86_64-unknown-linux-gnu.ranlib=/rustroot/bin/llvm-ranlib  --set llvm.thin-lto=true  --set llvm.ninja=false  <del> --set llvm.use-linker=lld  --set rust.use-lld=true  </del> --set rust.jemalloc <del> ENV SCRIPT ../src/ci/pgo.sh python3 ../x.py dist  </del> <ins> ENV SCRIPT ../src/ci/pgo.sh python2.7 ../x.py dist  </ins> --host $HOSTS --target $HOSTS  --include-default-paths  src/tools/build-manifest

Related discussion:
text: When I install the latest master toolchains via and try to build with them, linking fails: I did some bisection, and it looks like the problem started happening with Cc
The error is actually already mentioned in However, I am building Miri with cargo, so I don't know how I'd "use LLD instead".
Hm, we probably need to revert that PR. I did not realize we'd need lld downstream too, I thought that was only on our builder. cc
Yes, a revert seems appropriate. We're going to have to figure out where that's actually coming from. The only change I saw between 10 and 11 by grepping was the removal of llgo, but maybe there's some bad remnant.
Yeah, I thought this issue would be limited to the rustc build, but it makes sense that it can also affect project linking against rustc shared objects. I've looked a bit into what the root cause is, and what I have so far as that the symbol comes from and is present as a weak symbol both when compiling with clang-10 and clang-11. The only difference I see from is this: So apparently was treated as a symbol of the library, while now it's treated as a symbol of -- I'm not sure what that actually means, but presumably that refers to the compiler runtime libraries. My guess is that previously it just ended up being nulled out as a missing weak symbol, but now it's actually being found and linking fails because ... reasons. I'm not good at linkers :) Edit: shows these as:
can you prepare a revert PR?
Done in . If nobody has an idea on how to avoid the linker error, two more options would be to comment out the symbol in our llvm-project fork, or to avoid upgrading clang altogether and just build both Python 2 and Python 3 for that image.
The issue is probably going to be in how exactly the objects that comprise are compiled, not linked. I suspect just ends up ignoring the malformed object or otherwise not reporting the issue, but the object and the relevant symbols ultimately end up in the anyway. Alas, reasons these obscure failures can occur are many – I've seen them occur from things as trivial as forgetting to . The question is: is there perhaps a way to disable ExecutionEngine entirely? Intuitively nothing we do should depend on that code.
Code change:
--set target.x86_64-unknown-linux-gnu.ranlib=/rustroot/bin/llvm-ranlib  --set llvm.thin-lto=true  --set llvm.ninja=false  <del> --set llvm.use-linker=lld  --set rust.use-lld=true  </del> --set rust.jemalloc <del> ENV SCRIPT ../src/ci/pgo.sh python3 ../x.py dist  </del> <ins> ENV SCRIPT ../src/ci/pgo.sh python2.7 ../x.py dist  </ins> --host $HOSTS --target $HOSTS  --include-default-paths  src/tools/build-manifest

Related discussion:
text: And if not, I'm comfortable patching out in our fork as we get closer to Feb 11 and continue having trouble pinpointing exact cause of this problem.
We normally don't link ExecutionEngine, but dist-x8664-linux in particular builds LLVM with ThinLTO, in which case we link as shared, instead of statically linking individual components into rustcllvm.
It seems to be possible to configure the components in using , but I'm not sure to what degree we can restrict those (not sure if this job also ships LLVM tools).
So, I think we could have used to exclude unnecessary parts from , as LLVM tools can still statically link the parts not in the dylib. But in the end, we can't use the option anyway due to
Looks like I'm getting this locally when trying to bootstrap rustc (while building ), might happen since the llvm upgrade but I'm not 100% sure. Are there some workarounds I can put into my for this? I'm using lld to link. <details<summaryBacktrace</summary<p</p</details
which commit are you trying to build?
latest git master
Probably best to open a new issue then; this one has been closed and the steps to reproduce it still work without error -- you might be having a different problem.
Opened
Did anyone file an upstream bug report about this? I'm observing it outside of Rust, but with a similar setup ( with lld+ThinLTO, then linking it into a binary with ). If not, I'd try to build a reproducer.
I've opened for this.
The bug has been fixed, the fix will be in LLVM 12.0.1.
Thanks! We can try updating clang again once the 12.0.1 tag is there.
Code change:
<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. struct Foo<'r>(&'r mut i32); impl<'r> Drop for Foo<'r> { fn drop(&mut self) { *self.0 += 1; } } trait Trait {} impl<'r> Trait for Foo<'r> {} struct Holder<T: ?Sized>(T); fn main() { let mut drops = 0; { let y = &Holder([Foo(&mut drops)]) as &Holder<[Foo]>; // this used to cause an extra drop of the Foo instance let x = &y.0; } assert_eq!(1, drops); drops = 0; { let y = &Holder(Foo(&mut drops)) as &Holder<Trait>; // this used to cause an extra drop of the Foo instance let x = &y.0; } assert_eq!(1, drops); } </ins>

Related discussion:
text: The following function can drop any object arbitrary number of times, using only safe code: Probably bad :) Found while researching
Nominating for P-high
cc
Too bad this doesn't just cancel out the Leakocalypse :stuckouttongue:
(well, any object that implements . But yes, I see the point being made here.)
look, no required. I guess it doesn't work for types that are already unsized.
to be clear, I am looking at this now as well. :)
I guess is related.
I hope it is unrelated. In particular I wrote this on that ticket:
Yeah, it's unrelated. The call happens for , which does need drop.
Code change:
7331 })); assert_eq!(foo, 42); <ins> // Test trailing comma: assert_eq!(("Yeah",), dbg!(("Yeah",))); // Test multiple arguments: assert_eq!((1u8, 2u32), dbg!(1, 2)); // Test multiple arguments + trailing comma: assert_eq!((1u8, 2u32, "Yeah"), dbg!(1u8, 2u32, "Yeah",)); </ins> } fn validate_stderr(stderr: Vec<String>) {

Related discussion:
text: It would be nice if the compiler suggested the intended form: as this seems like a reasonable mistake. This is specific to a particular macro, though, so I'm not sure how flexible we can be with diagnostics here.
Or we could just make the macro accept ...
Code change:
Prior to Rust 1.80 the `target_env = "p1"` key was not set. Currently the `target_feature = "atomics"` is Nightly-only. Note that the precise `#[cfg]` necessary to detect this target may change as the target becomes more stable. <ins> ## Enabled WebAssembly features The default set of WebAssembly features enabled for compilation includes two more features in addition to that which [`wasm32-unknown-unknown`](./wasm32-unknown-unknown.md) enables: * `bulk-memory` * `atomics` For more information about features see the documentation for [`wasm32-unknown-unknown`](./wasm32-unknown-unknown.md), but note that the `mvp` CPU in LLVM does not support this target as it's required that `bulk-memory`, `atomics`, and `mutable-globals` are all enabled. </ins>

Related discussion:
text: 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.
Code change:
Prior to Rust 1.80 the `target_env = "p1"` key was not set. Currently the `target_feature = "atomics"` is Nightly-only. Note that the precise `#[cfg]` necessary to detect this target may change as the target becomes more stable. <ins> ## Enabled WebAssembly features The default set of WebAssembly features enabled for compilation includes two more features in addition to that which [`wasm32-unknown-unknown`](./wasm32-unknown-unknown.md) enables: * `bulk-memory` * `atomics` For more information about features see the documentation for [`wasm32-unknown-unknown`](./wasm32-unknown-unknown.md), but note that the `mvp` CPU in LLVM does not support this target as it's required that `bulk-memory`, `atomics`, and `mutable-globals` are all enabled. </ins>

Related discussion:
text: 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.
Code change:
Prior to Rust 1.80 the `target_env = "p1"` key was not set. Currently the `target_feature = "atomics"` is Nightly-only. Note that the precise `#[cfg]` necessary to detect this target may change as the target becomes more stable. <ins> ## Enabled WebAssembly features The default set of WebAssembly features enabled for compilation includes two more features in addition to that which [`wasm32-unknown-unknown`](./wasm32-unknown-unknown.md) enables: * `bulk-memory` * `atomics` For more information about features see the documentation for [`wasm32-unknown-unknown`](./wasm32-unknown-unknown.md), but note that the `mvp` CPU in LLVM does not support this target as it's required that `bulk-memory`, `atomics`, and `mutable-globals` are all enabled. </ins>

Related discussion:
text: 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.
Code change:
Prior to Rust 1.80 the `target_env = "p1"` key was not set. Currently the `target_feature = "atomics"` is Nightly-only. Note that the precise `#[cfg]` necessary to detect this target may change as the target becomes more stable. <ins> ## Enabled WebAssembly features The default set of WebAssembly features enabled for compilation includes two more features in addition to that which [`wasm32-unknown-unknown`](./wasm32-unknown-unknown.md) enables: * `bulk-memory` * `atomics` For more information about features see the documentation for [`wasm32-unknown-unknown`](./wasm32-unknown-unknown.md), but note that the `mvp` CPU in LLVM does not support this target as it's required that `bulk-memory`, `atomics`, and `mutable-globals` are all enabled. </ins>

Related discussion:
text: 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".
Code change:
Prior to Rust 1.80 the `target_env = "p1"` key was not set. Currently the `target_feature = "atomics"` is Nightly-only. Note that the precise `#[cfg]` necessary to detect this target may change as the target becomes more stable. <ins> ## Enabled WebAssembly features The default set of WebAssembly features enabled for compilation includes two more features in addition to that which [`wasm32-unknown-unknown`](./wasm32-unknown-unknown.md) enables: * `bulk-memory` * `atomics` For more information about features see the documentation for [`wasm32-unknown-unknown`](./wasm32-unknown-unknown.md), but note that the `mvp` CPU in LLVM does not support this target as it's required that `bulk-memory`, `atomics`, and `mutable-globals` are all enabled. </ins>

Related discussion:
text: 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!