Question: { debug!(?obligation, "confirm_fn_pointer_candidate"); <del> // Okay to skip binder; it is reintroduced below. let self_ty = self.infcx.shallow_resolve(obligation.self_ty().skip_binder()); </del> <ins> let self_ty = self .infcx .shallow_resolve(obligation.self_ty().no_bound_vars()) .expect("fn pointer should not capture bound vars from predicate"); </ins> let sig = self_ty.fn_sig(self.tcx()); let trait_ref = closure_trait_ref_and_return_type( self.tcx(),

An there actually does panic for the test. I only moved this code between the files, the same comment and code pattern exists as well for normal closures: Originally posted by in
I couldn't repro this failure, maybe was doing instead of ? The ordering is important here.
I believe I did, yes.


Question: <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. use foo::baz; use bar::baz; //~ ERROR a module named `baz` has already been imported use foo::Quux; use bar::Quux; //~ ERROR a trait named `Quux` has already been imported use foo::blah; use bar::blah; //~ ERROR a type named `blah` has already been imported use foo::WOMP; use bar::WOMP; //~ ERROR a value named `WOMP` has already been imported fn main() {} mod foo { pub mod baz {} pub trait Quux { } pub type blah = (f64, u32); pub const WOMP: u8 = 5; } mod bar { pub mod baz {} pub type Quux = i32; struct blah { x: i8 } pub const WOMP: i8 = -5; } </ins>

I found an error message that seems a bit off to me. The code: Clearly it should fail to compile, and it does. But the error message is: I would expect something like "a module name has already been imported", instead. Is it accurate to call it a type?


Question: let trait_m = tcx.opt_associated_item(impl_m.trait_item_def_id.unwrap()).unwrap(); let impl_trait_ref = tcx.impl_trait_ref(impl_m.impl_container(tcx).unwrap()).unwrap().instantiate_identity(); <del> let param_env = tcx.param_env(impl_m_def_id); </del> // First, check a few of the same things as `compare_impl_method`, // just so we don't ICE during substitution later. check_method_is_structurally_compatible(tcx, impl_m, trait_m, impl_trait_ref, true)?;

This is a use-after-free that compiles with 1.74.0-nightly (2023-09-13 ): cc


Question: ENV RUST_CONFIGURE_ARGS --enable-extended --disable-docs ENV SCRIPT python2.7 ../x.py dist --host $HOSTS --target $HOSTS <del> # FIXME(#36150) this will fail the bootstrap. Probably means something bad is #               happening! ENV NO_LLVM_ASSERTIONS 1 </del>

From . This means we do not blanket turn on LLVM assertions on all of our bots, which we would ideally like to do. I'm going to try turning them off for just the cross bot though.
cc cc
Seems related to somewhat. We do not use the maxnum intrinsic (totally should!) but from the existence of bug for maxnum seems to suggest that a similar issue for some non-maxnum intrinsic is likely to exist (and libcore is kinda intrinsic-heavy).


Question: <ins> error[E0669]: invalid value for constraint in inline assembly --> $DIR/issue-51431.rs:7:32 | LL |         asm! {"mov $0,$1"::"0"("bx"),"1"(0x00)} |                                ^^^^ error: aborting due to previous error </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: //! [`PathBuf`]; note that the paths may differ syntactically by the //! normalization described in the documentation for the [`components`] method. //! <ins> //! ## Case sensitivity //! //! Unless otherwise indicated path methods that do not access the filesystem, //! such as [`Path::starts_with`] and [`Path::ends_with`], are case sensitive no //! matter the platform or filesystem. An exception to this is made for Windows //! drive letters. //! </ins> //! ## Simple usage //! //! Path manipulation includes both parsing components from slices and building

Case sensitivity is a property of the filesystem, not operating system and these functions are filesystem agnostic. As thus, this issue is not actionable. Closing. If you feel differently please complain and I’ll reopen.
It's fine if the functions want to be case-sensitive, but their docs need to be changed to point this out explicitly and noticeably. Every Windows user is going to assume that the functions are case-insensitive just like they are in other languages on the platform. (I imagine OSX users will have the same expectation?) It's made slightly worse because is handled in a special way that makes evaluate to despite the mismatched case. So someone using that as a quick test of their assumption would end up with the wrong idea. Would you mind reopening for this reason?
I think it would also be good to have a crate like provide a that does hit the filesystem. Such an API would also be able to detect when the same folder is specified but using alternate prefixes or mount points or through symbolic links.
The driver letter is a symlink in the Object Manager and lookup is always case-insensitive. Folders are located on the filesystem and may or may not be case sensitive. I do think platform specific behaviour should be documented if it can be a source of confusion.


Question: match expr.node { ast::ExprField(ref base, ident) => { if let ty::ty_struct(id, _) = ty::expr_ty_adjusted(self.tcx, &**base).sty { <del> self.check_field(expr.span, id, NamedField(ident.node)); </del> <ins> self.check_field(expr.span, id, NamedField(ident.node.name)); </ins> } } ast::ExprTupField(ref base, idx) => {

Tracking issue for: rust-lang/rfcs Functional record update does not mark the source as consumed, even if does not implement Copy. This means that e.g. the source's destructor will eventually be run, so the following code prints :
Note that, as discovered, you can also explicitly consume , also allowing code like:
:bomb:
Is legal, even if all members are private? It's a bit surprising
It is. There's the potentially-useful case where some of the members are private, and FRU allows you to update the public ones. Of course it should consume the source even then.
P-backcompat-lang, 1.0 beta
In my opinion the problem here is the privacy violation. The idea is that is expanded to and so forth. In this case, that does not trigger a move, because the types of those fields are . I think that part is acting as expected. What is surprising is that one can do this from outside the module.
That was (but my favored solution isn't minor).
When I initially saw this problem, I did not see it as a privacy violation, for the (obvious?) reason that since no private members of had been mentioned in the code , the client module is not breaking any abstraction introduced by privacy. I think this line of thinking is analogous to outline of the useful case where FRU allows one to update the public members of a type and silently move the private ones as well, via . This is useful for the case where the author of wants to reserve the right to add new private members to while still allowing for clients to use the convenient FRU syntax. I originally was going to try to explain my point of view via analogy with something from hygienic macros: If I were to define (and export) a macro within 's defining module: then it should, in principle, not be a privacy violation to use from client code outside 's defining module. (That is, in principle, hygiene should allow macros to expose controlled access to private internals.) Then I realized the crucial problem with that kind of analogy: is something that the designer of has to choose to put into the module; i.e., it is opt-in. But currently in Rust, FRU is not opt-in; its not even something you can opt out of.


Question: match expr.node { ast::ExprField(ref base, ident) => { if let ty::ty_struct(id, _) = ty::expr_ty_adjusted(self.tcx, &**base).sty { <del> self.check_field(expr.span, id, NamedField(ident.node)); </del> <ins> self.check_field(expr.span, id, NamedField(ident.node.name)); </ins> } } ast::ExprTupField(ref base, idx) => {

Any struct automatically is given support for it, whether it be appropriate for that struct or not. And that seems wrong, at least given examples like the one provided here in . This latter point, that providing support for FRU should not be something that is silently attached to a type like , seems somewhat in line with the thinking given in . But I am also pretty sure we cannot adopt anything of the scope given in that draft. (Still, maybe there's a hint of solution embedded within, in the sense of having some way of marking a type as data vs abstract; see final two bullet points below.) So, as I see it, we can either: out a way to support the point-of-view outlined here in the description for , in that should somehow be treated as consuming . Such a change seems like it would be quite subtle, since we would need to have some way of expressing that code like is sound, even if the types of the fields and are consumed by their respective and methods. (In other words, need to consume , yet somehow not completely consume it. Maybe there's a way to think of it as consuming "whatever is left of the type", I do not know.) Advantages: This would address the bug as described by the issue author, and would not break any code that was not already broken. Drawbacks: It is not clear what the semantics are for this form (in other words: the phrase "would not break any code" above is only true if you first accept that this hypothesized semantics exists). Also, there may not be time to do this properly for 1.0. , try to adopt a data/abstract-type distinction along the lines of the one in draft RFC. (I'm not going to write Advantages/Drawbacks for this; I think we clearly do not have time to do it that way for 1.0) , change FRU into a non-hygienic expansion into the record construction form with all fields listed, in the sense that is synonymous with and subject to privacy checks. Advantages: Seems really simple to implement, and is consistent with at least one core team member's mental model of FRU. Drawbacks: If we did this, then code like the example above would break.


Question: match expr.node { ast::ExprField(ref base, ident) => { if let ty::ty_struct(id, _) = ty::expr_ty_adjusted(self.tcx, &**base).sty { <del> self.check_field(expr.span, id, NamedField(ident.node)); </del> <ins> self.check_field(expr.span, id, NamedField(ident.node.name)); </ins> } } ast::ExprTupField(ref base, idx) => {

, let FRU keep its current hygienic (aka "privacy violating") semantics, but also make FRU something one must opt-in to support on a type. E.g. make a builtin trait that a struct must implement in order to be usable with FRU. (Or maybe its an attribute you attach to the item.) Advantages: Also seems really simple to implement (in the language). Accommodates users of FRU for the example. Drawbacks: If we did this, it would impose a burden on all code today that makes use of FRU, since they would have to start implementing . Thus, not simple to implement for the libraries and the overall ecosystem. , a hybrid between the previous two bullet-points: By default, treat FRU as non-hygienic expansion, but add a builtin trait that one can opt-into to get the hygienic (aka "privacy violating") semantics. As a bonus, perhaps implementing on a struct would also imply implementing on that struct, which seems like it would basically give us something very similar to the semantics desired by (Or, again, maybe its an attribute you attach to the item. This detail does not particularly matter to me.) Advantage: While this is obviously more complicated than the previous two bullet-points, it has the advantage that it has a staged landing strategy: We could just_ implement the change to FRU to be non-hygienic expansion for 1.0 beta. We could add at an arbitrary point in the future; it would not have to be in the 1.0 release. Drawback: People have claimed that some of my past proposals were a bit ... baroque. I imagine this one is no exception. :) (In other words, this semantics is a little complicated to explain to a newcomer.)
I don't want to make a big fuss about it, but I do want to note, again, that our "deadlines" are entirely self-imposed, and that under these circumstances "we don't have time" is slightly odd, because we can make time, any time we want. The blanket refusal to even contemplate doing that - even in light of new information - and to weigh the tradeoffs on their own merits is something I still don't really understand.


Question: match expr.node { ast::ExprField(ref base, ident) => { if let ty::ty_struct(id, _) = ty::expr_ty_adjusted(self.tcx, &**base).sty { <del> self.check_field(expr.span, id, NamedField(ident.node)); </del> <ins> self.check_field(expr.span, id, NamedField(ident.node.name)); </ins> } } ast::ExprTupField(ref base, idx) => {

That out of the way, an additional possibility, let's call it 6., for list: We could just make the "abstract type" vs. "data type" distinction based on "does or doesn't the type have a private field". This doesn't entirely fill me with satisfaction (as with "worse is better" solutions in general), with specific drawbacks being that it doesn't extend cleanly to the nullary case (no fields at all), and that in terms of UX a change of semantics based on the presence or absence of a private field may be unexpected, but on the plus side, it's simpler, and would, I think, work.
Sure, hypothetical show-stopper issues could cause us to revisit our self-imposed schedule. I personally don't think that this issue, on its own at least, provides sufficient motivation for schedule revision. I admit that your draft RFC seems like it addresses a host of issues, so maybe all of them taken in unison would be a different story. (But then again, that's not even my call to make.)
There were a couple more options that I should have put on the list, for completeness, but overlooked. 6 note, the "has any private fields ==abstract-type; all public fields ==data-type", is one of them. This would (probably) be less work than adopting the draft RFC in full, but I am not sure what the other Advantages/Disadvantages are. I invite others to write an Advantages/Drawbacks for this approach (perhaps in an RFC PR). 7 We could add a way for a struct to opt-out of FRU support entirely. So in this approach, one would attach the appropriate attribute to , , etc. Advantages: won't break any existing code Drawbacks: Seems quite fragile; we may be good about auditing our own stdlib, but clients who are not aware of the attribute may inadvertently expose themselves to the same bug that currently plagues .
Also, I just wanted to mention: when I wrote my comment 6 hours ago, I came to the keyboard thinking that the FRU support for adding new private fields to and having still work was an important use case. But after some reflection in the hours since, supporting that use case does not seem as important to me.


Question: match expr.node { ast::ExprField(ref base, ident) => { if let ty::ty_struct(id, _) = ty::expr_ty_adjusted(self.tcx, &**base).sty { <del> self.check_field(expr.span, id, NamedField(ident.node)); </del> <ins> self.check_field(expr.span, id, NamedField(ident.node.name)); </ins> } } ast::ExprTupField(ref base, idx) => {

Here is why: It is relatively easy for a developer who wants to provide that sort of extensible abstraction can still do it, by factoring the type into a all-public front-end with a single public field that holds the all-private back-end, like so: So, given that there exists a reasonable pattern to bring back usable FRU even under the option "(3.) change FRU into a non-hygienic expansion into the record construction form with all fields listed, in the sense that is synonymous with and subject to privacy checks.", I would not object to us adopting (3.) aka solution.
I think that "has any private field" is a decent way to handle abstractness (you can always add a private unit field). On the other hand, Rust supports trait bounds of types – these should handle roles just fine – you shouldn't be able to coerce past a trait bound. By the way, this is somewhat subtle, because coercing to is wrong (as it leaks memory – it coerces past the implicit bound), but coercing to is fine (as the bound isn't used by ). However, this isn't a property of – you still can't coerce to – so we probably want a relatively-sophisticated way to occasionally ignore roles.
I mean, Rust already has a mechanism for ensuring representation-abstraction – private fields – which are semantic (they are handled after type-checking, we probably want to handle them during it, but they definitely aren't handled syntactically or during resolution). It is just that FRU currently accesses them improperly. Also, it doesn't have much to do with e.g. roles – is an abstract type, but it doesn't use any bound on . only uses the implicit bound. A for data-only types would be nice, through.
Another alternative came to me while I was drafting an RFC about this. (But its an alternative that I do not particularly like.) 8a Instead of making "has any private fields" the thing that makes FRU unavailable, instead make the rule be "has all private fields." Thus types like and will not be subject to the vulnerability outlined here. Adding a single field to an otherwise private struct is what changes the nature of a struct with respect to abstraction and FRU, rather than adding a single non- field to an otherwise public struct.


Question: match expr.node { ast::ExprField(ref base, ident) => { if let ty::ty_struct(id, _) = ty::expr_ty_adjusted(self.tcx, &**base).sty { <del> self.check_field(expr.span, id, NamedField(ident.node)); </del> <ins> self.check_field(expr.span, id, NamedField(ident.node.name)); </ins> } } ast::ExprTupField(ref base, idx) => {

8b, which is so similar to 8a that I gave them both the same numeral: Outlaw the trivial FRU form . That is, to use FRU, you have to use at least one field in the constructing expression. Again, this implies that types like and will not be subject to the vulnerability outlined here. (This may be a decent change to make to the language regardless of whatever else happens on this ticket; the only argument in favor of keeping support for such a trivial form is maybe for supporting certain macro-expansions. But fully-general macro-authors already have to tread very carefully around corner cases on structs, due to issues like the empty braces problem (see )
That would leave the vulnerability intact in the case where the type has both public fields and private fields, the fact that no such type currently exists in the standard library notwithstanding (just as a very artificial demonstration, consider a with ).
yep. Library authors would have to factor their structures very carefully. (I described the drawback you mention in the RFC I posted shortly after you wrote your comment, though I did not include the detail of having the private fields be , which does seem like it could make the situation all the more subtle. Not insurmountable, but a definite drawback.) Just to be clear, I'm not saying I prefer (8a) or (8b); I'm just trying to be complete in my exploration of the solution space.
Repurposed as the tracking issue for rust-lang/rfcs
I'll just go snag


Question: panic!(); } <ins> #[test] fn panic_in_write_doesnt_flush_in_drop() { static WRITES: AtomicUsize = AtomicUsize::new(0); struct PanicWriter; impl Write for PanicWriter { fn write(&mut self, _: &[u8]) -> io::Result<usize> { WRITES.fetch_add(1, Ordering::SeqCst); panic!(); } fn flush(&mut self) -> io::Result<()> { Ok(()) } } thread::spawn(|| { let mut writer = BufWriter::new(PanicWriter); writer.write(b"hello world"); writer.flush(); }).join().err().unwrap(); assert_eq!(WRITES.load(Ordering::SeqCst), 1); } </ins> #[bench] fn bench_buffered_reader(b: &mut test::Bencher) { b.iter(|| {

There is a panic safety issue in : after a call panics, the impl of calls again, which means the buffer contents are potentially written twice. This may cause an application to overwrite parts of a file that it did not mean to overwrite (in a DB engine written in Rust, this could cause unrecoverable data corruption!). Demonstration: The expected output of the demo program is , the actual output is: More generally, we need a story for panic safety in Rust. My takeaway from the related discussions (e.g. , , the trait) was that only code and impls should have to worry about panic safety. The demo app contains none of these, so I'd consider this a bug in . (otherwise all implementations would need to provide the strong exception safety guarantee?) Solution: could use temporarily mark the buffer as empty during the calls; so that the impl doesn't do anything after a panic. However, this doesn't help if the panic occurs during a call...
Note that Rust is normally referring to "memory safety" when talking about safety, so the issue here isn't in conflict with the related discussions. It's definitely a bug in , but I want to point out how specific it is here: the only reason you have odd behaviour is because you have a implementation that will panic after successfully writing the data it is given. I'm all for making more robust, but it's not just "if the call panics", it's "if the call panics after successfully writing data". Panicking before a successful write (or if the write fails), would not have the same issue.
If your impl is panicking in the middle of a write, it seems to me like you're in data corruption land with or without a second write. This is not quite the case - and thread locals expand that surface area. What's specifically the expected behavior here? Is the implementation specifically the thing that needs tweaking, or should the totally poison itself? For reference, Java's class has no special handling for exceptions thrown from the inner : , so adjusting alone seems like a reasonable route to take.
Without the , a panic in the middle of a write (without ) only corrupts the part of the file that the application meant to overwrite. In a DB engine context, that means the resulting corruption can be repaired when the transaction is rolled back.


Question: panic!(); } <ins> #[test] fn panic_in_write_doesnt_flush_in_drop() { static WRITES: AtomicUsize = AtomicUsize::new(0); struct PanicWriter; impl Write for PanicWriter { fn write(&mut self, _: &[u8]) -> io::Result<usize> { WRITES.fetch_add(1, Ordering::SeqCst); panic!(); } fn flush(&mut self) -> io::Result<()> { Ok(()) } } thread::spawn(|| { let mut writer = BufWriter::new(PanicWriter); writer.write(b"hello world"); writer.flush(); }).join().err().unwrap(); assert_eq!(WRITES.load(Ordering::SeqCst), 1); } </ins> #[bench] fn bench_buffered_reader(b: &mut test::Bencher) { b.iter(|| {

But with , a panic after some data was written might corrupt parts of the file that are not saved in the rollback journal, so recovery not possible. I think we need some guideline like: If a method call panics, it's a bug to call any additional methods on the same object. Thus, the bug is in . may need something similar to a poison-flag so that the impl can detect whether a previous call panicked, but it doesn't need to protect against it's own methods being called after a panic (that would be considered a bug in the caller). The Java has the same problem, but the expectation in the Java world is different: it's trivially possible to catch an exception and continue using the potentially-invalid state; so in Java's case I would argue that all implementations should provide the strong exception safety guarantee to avoid this kind of issue. Essentially, the Rust world needs to decide between a Java/C++-style "strong exception safety guarantee" (=failing method call should not have any side effects) or a new "no-use-after-panic guarantee" (=after a failing method call, no additional method calls should occur). Some types (like BufWriter) can be compatible with at most one of the guarantees -- strong exception safety requires that a panicking call has no side effects; no-use-after-panic requires that a panicking call has the side effect of suppressing the buffer flush in the impl. The trait seems to be roughly equivalent to basic exception safety. Types that do not implement instead live in the world. Generic types implementing need to be careful not to call any functions on the type parameter from within the implementation if a previous call panicked (unless they use a bound).
triage: P-medium is fixing the data corruption in


Question: // ignore it.  We can't put it on the struct header anyway. RegionKind::ReLateBound(..) => false, <ins> // This can appear in `where Self: ` bounds (#64855): // //     struct Bar<T>(<Self as Foo>::Type) where Self: ; //     struct Baz<'a>(&'a Self) where Self: ; RegionKind::ReEmpty => false, </ins> // These regions don't appear in types from type declarations: <del> RegionKind::ReEmpty | RegionKind::ReErased </del> <ins> RegionKind::ReErased </ins> | RegionKind::ReClosureBound(..) | RegionKind::ReScope(..) | RegionKind::ReVar(..)

Internal compiler error when missing bound on struct. Reproducible on stable/beta/nightly on . Also, not sure if it already has it's own issue, but is causing an illegal instruction error when you run it with on this code as well, which is also reproducible on playground if you turn the backtrace setting on. I tried this code: () I expected to see this happen: Instead, this happened: rustc versions (from playground): <details<summaryBacktrace (note the SIGILL at the end)</summary<p</p</details
cc
triage: P-high, removing nomination label (has PR).


Question: |  |_____| | || LL | || <del> LL | || </del> LL | ||         use std::ptr::null; <ins> LL | ||         use std::task::{Context, RawWaker, RawWakerVTable, Waker}; </ins> ...  || LL | ||         drop(cx_ref); LL | ||     }); | ||_____-^ `&mut Context<'_>` may not be safely transferred across an unwind boundary |  |_____| <del> |        within this `{async block@$DIR/async-is-unwindsafe.rs:12:19: 30:6}` </del> <ins> |        within this `{async block@$DIR/async-is-unwindsafe.rs:12:19: 29:6}` </ins> | <del> = help: within `{async block@$DIR/async-is-unwindsafe.rs:12:19: 30:6}`, the trait `UnwindSafe` is not implemented for `&mut Context<'_>`, which is required by `{async block@$DIR/async-is-unwindsafe.rs:12:19: 30:6}: UnwindSafe` </del> <ins> = help: within `{async block@$DIR/async-is-unwindsafe.rs:12:19: 29:6}`, the trait `UnwindSafe` is not implemented for `&mut Context<'_>`, which is required by `{async block@$DIR/async-is-unwindsafe.rs:12:19: 29:6}: UnwindSafe` = note: `UnwindSafe` is implemented for `&Context<'_>`, but not for `&mut Context<'_>` </ins> note: future does not implement `UnwindSafe` as this value is used across an await <del> --> $DIR/async-is-unwindsafe.rs:26:18 </del> <ins> --> $DIR/async-is-unwindsafe.rs:25:18 </ins> | LL |         let cx_ref = &mut cx; |             ------ has type `&mut Context<'_>` which does not implement `UnwindSafe`

https://crater-
I'll need to re-check later but this seems to bisect to somehow.
The UI test changes from that PR appear to back this up, as confusing as it is.
I'm not sure what's going on in that crate, if it built successfully by mistake, or how that PR interacts with it, so let's cc the PR author and reviewer for validation.
After , no longer implements and , because the context now contains a which doesn't implement those traits. So this is an issue with the standard library and not the crate being built. Repro: label -T-compiler +T-libs +S-has-mcve
WG-prioritization assigning priority (). Noticing this on which says that was meant to be confined on nightly. Unsure about the fallout of this regression but for now marking as critical for tracking purposes. label -I-prioritize +P-critical
Revert up:
Isn't not unwind safe?
That line was by your PR, so while what you say is technically true, talking about what "already happened" when we are traveling back and forth through time via version control may be more confusing than helpful.
That line was already there. I the line below it though. Original PR:
Apologies, I guess I can't count numbers today? Hm, so, the full error of the regression is this: Note that it's trying to make a pointer implement . And for what it's worth, stable does indeed document is . Thus unfortunately that line you pointed to, as opposed to the one I thought you were referring to, is effectively just documenting that all are , and that will include regardless of whether it is is . And confusingly, , unlike .
I have opened as an alternative.


Question: Some(&def::DefVariant(_, variant_id, _)) => { for field in fields { self.check_field(pattern.span, variant_id, <del> NamedField(field.node.ident)); </del> <ins> NamedField(field.node.ident.name)); </ins> } } _ => self.tcx.sess.span_bug(pattern.span,


Question: Some(&def::DefVariant(_, variant_id, _)) => { for field in fields { self.check_field(pattern.span, variant_id, <del> NamedField(field.node.ident)); </del> <ins> NamedField(field.node.ident.name)); </ins> } } _ => self.tcx.sess.span_bug(pattern.span,


Question: Some(&def::DefVariant(_, variant_id, _)) => { for field in fields { self.check_field(pattern.span, variant_id, <del> NamedField(field.node.ident)); </del> <ins> NamedField(field.node.ident.name)); </ins> } } _ => self.tcx.sess.span_bug(pattern.span,


Question: Some(&def::DefVariant(_, variant_id, _)) => { for field in fields { self.check_field(pattern.span, variant_id, <del> NamedField(field.node.ident)); </del> <ins> NamedField(field.node.ident.name)); </ins> } } _ => self.tcx.sess.span_bug(pattern.span,


Question: Some(&def::DefVariant(_, variant_id, _)) => { for field in fields { self.check_field(pattern.span, variant_id, <del> NamedField(field.node.ident)); </del> <ins> NamedField(field.node.ident.name)); </ins> } } _ => self.tcx.sess.span_bug(pattern.span,


Question: Some(&def::DefVariant(_, variant_id, _)) => { for field in fields { self.check_field(pattern.span, variant_id, <del> NamedField(field.node.ident)); </del> <ins> NamedField(field.node.ident.name)); </ins> } } _ => self.tcx.sess.span_bug(pattern.span,


Question: /// /// assert_eq!(n.leading_zeros(), 2); /// ``` <ins> #[doc = concat!("[`ilog2`]: ", stringify!($SelfT), "::ilog2")] </ins> #[stable(feature = "rust1", since = "1.0.0")] #[rustc_const_stable(feature = "const_math", since = "1.32.0")] #[must_use = "this returns the result of the operation,

I was chatting with today, who mentioned it'd be helpful to mention the newly stabilized APIs from the docs. The benefit of using is that even if the type widens, the result doesn't change. It'd be nice if someone could contribute docs mentioning from . This probably just needs to be a one-liner. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim


Question: struct Wrapper<T>(T); struct Test<T: Copy> { <del> f1: extern "C-cmse-nonsecure-call" fn<U: Copy>(U, u32, u32, u32) -> u64, //~ ERROR cannot find type `U` in this scope //~^ ERROR function pointer types may not have generic parameters </del> <ins> f1: extern "C-cmse-nonsecure-call" fn<U: Copy>(U, u32, u32, u32) -> u64, //~^ ERROR cannot find type `U` in this scope //~| ERROR function pointer types may not have generic parameters </ins> f2: extern "C-cmse-nonsecure-call" fn(impl Copy, u32, u32, u32) -> u64, //~^ ERROR `impl Trait` is not allowed in `fn` pointer parameters f3: extern "C-cmse-nonsecure-call" fn(T, u32, u32, u32) -> u64, //~ ERROR [E0798] f4: extern "C-cmse-nonsecure-call" fn(Wrapper<T>, u32, u32, u32) -> u64, //~ ERROR [E0798] } <ins> type WithReference = extern "C-cmse-nonsecure-call" fn(&usize); trait Trait {} type WithTraitObject = extern "C-cmse-nonsecure-call" fn(&dyn Trait) -> &dyn Trait; //~^ ERROR return value of `"C-cmse-nonsecure-call"` function too large to pass via registers [E0798] type WithStaticTraitObject = extern "C-cmse-nonsecure-call" fn(&'static dyn Trait) -> &'static dyn Trait; //~^ ERROR return value of `"C-cmse-nonsecure-call"` function too large to pass via registers [E0798] #[repr(transparent)] struct WrapperTransparent<'a>(&'a dyn Trait); type WithTransparentTraitObject = extern "C-cmse-nonsecure-call" fn(WrapperTransparent) -> WrapperTransparent; //~^ ERROR return value of `"C-cmse-nonsecure-call"` function too large to pass via registers [E0798] type WithVarArgs = extern "C-cmse-nonsecure-call" fn(u32, ...); //~^ ERROR C-variadic function must have a compatible calling convention, like `C` or `cdecl` [E0045] </ins>

<!-- 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: Attribute::NoInline.apply_llfn(Function, val); } } <del> None if requires_inline => Attribute::InlineHint.apply_llfn(Function, val), </del> None => {} }; }

Currently, the compiler is allowed to inline naked functions if it wants to. For a normal function, inlining is fine because the compiler can remove the function prologue/epilogue and the remaining will behave as expected. However for naked functions, the developer provides the prologue/epilogue and those aren't removed by the compiler. This almost surely will result in incorrect behavior. Accordingly I think it would make sense for the compiler to not inline naked functions unless the developer explicitly opted-in.
In the other thread, alistair23 found that
Yes, functions should imply .


Question: <ins> // Regression test for #89606. Used to ICE. // // check-pass // revisions: twenty_eighteen twenty_twentyone // [twenty_eighteen]compile-flags: --edition 2018 // [twenty_twentyone]compile-flags: --edition 2021 struct S<'a>(Option<&'a mut i32>); fn by_ref(s: &mut S<'_>) { (|| { let S(_o) = s; s.0 = None; })(); } fn by_value(s: S<'_>) { (|| { let S(ref _o) = s; let _g = s.0; })(); } struct V<'a>((Option<&'a mut i32>,)); fn nested(v: &mut V<'_>) { (|| { let V((_o,)) = v; v.0 = (None, ); })(); } fn main() { let mut s = S(None); by_ref(&mut s); by_value(s); let mut v = V((None, )); nested(&mut v); } </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. --This bug popped up in CI on a project of ours. This does not reproduce on stable, but does reproduce on nightly and the latest beta (). Bisection shows that was the first build with the regression. Further bisection points to being the commit that introduced the regression. If I had to guess from the PRs in the rollup I'd say seems the most likely, since it touched the code around the error source. <!-- 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
label: +regression-from-stable-to-beta
Reduced:
This assertion is indeed introduced in . The two captures have the same place but different CaptureInfo. cc
Interesting. It's a bit hard to imagine how could have introduced this, since that just sorts a list. Fascinating! Maybe somebody from has a clue?
Actually, it's not at all hard to imagine, because introduced the following: The projections are actually the same, but the types differ in regions, which probably means that this comment is wrong:
Yeah, I just checked and the region of the match is an inferenced variable and gives an concrete ReFree instead.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
Did some analysis: We cannot just replace the with . This will create two mutable references in edition 2021 and fail borrowck. Pre-2018 the places do get merged later so the issue isn't exposed. None of the upvar code makes use of the region info, and writeback will erase it anyway. So I think the fix should just be have the region erased when inserting/looking up from capture_information. I can submit a PR if you haven't started
I just started looking at it but if you have a solution, go for it!


Question: <ins> // Regression test for #89606. Used to ICE. // // check-pass // revisions: twenty_eighteen twenty_twentyone // [twenty_eighteen]compile-flags: --edition 2018 // [twenty_twentyone]compile-flags: --edition 2021 struct S<'a>(Option<&'a mut i32>); fn by_ref(s: &mut S<'_>) { (|| { let S(_o) = s; s.0 = None; })(); } fn by_value(s: S<'_>) { (|| { let S(ref _o) = s; let _g = s.0; })(); } struct V<'a>((Option<&'a mut i32>,)); fn nested(v: &mut V<'_>) { (|| { let V((_o,)) = v; v.0 = (None, ); })(); } fn main() { let mut s = S(None); by_ref(&mut s); by_value(s); let mut v = V((None, )); nested(&mut v); } </ins>

Happy to review your PR
I'm not sure about region code that much but regionchk uses the regions created: I think at one point mentioned getting rid of the region field entirely in UpvarBorrow, but since it wasn't required the discussion didn't proceed. Also it's more like this is a bug of the capture analysis than the sorting. We should never have two same places going into min capture in the list.
I was thinking about erasing the region from s (i.e. the key of captureinformation). But it turns out that's used later to create upvar tuple... So I switched captureinformation from HashMap to a linear vec looked up with custom eq fn instead.


Question: use rustc_span::edition::Edition; use rustc_span::lev_distance::find_best_match_for_name; use rustc_span::symbol::{kw, Ident, Symbol}; <del> use rustc_span::{Span, DUMMY_SP}; </del> <ins> use rustc_span::Span; </ins> use rustc_target::spec::abi; use rustc_trait_selection::traits; use rustc_trait_selection::traits::astconv_object_safety_violations;

<!-- 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
This was likely introduced in (CC rustc 1.65 nightly 2022-08-12 emits the following:


Question: "anyhow", "cargo", "cargo-util", <del> "cargo_metadata 0.12.0", </del> <ins> "cargo_metadata 0.14.0", </ins> "clippy_lints", "crossbeam-channel", "difference", <del> "env_logger 0.7.1", </del> <ins> "env_logger 0.9.0", </ins> "futures 0.3.12", "heck", "home", <del> "itertools 0.9.0", </del> <ins> "itertools 0.10.1", </ins> "jsonrpc-core", "lazy_static", "log",

Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!
This might be due to no longer builds: ` We need a new version I think. The last published version of is 5 months old already :thinking: Can you please check why there are no new versions being published?
TIL scheduled GitHub Action Workflows apparently require regular activity in the repository to keep going :eyes:
I didn't realize anyone was still using those crates so I disabled the action, I believe it was broken anyway. Does rustfmt and/or other crates still use those packages? If so I can try to find time to restart the action.
Racer those crates. And RLS . So without those crates compiling racer with the latest nightly isn't possible, which makes compiling RLS impossible and therefore blocks the sync of RLS back to rust-lang/rust.
Would it maybe be an option to make racer depend on to compile instead of publishing AP crates?
We stopped using them in rustfmt a while ago and I can't imagine a scenario where we'd switch back. Agreed on racer, which AIUI is the last true direct consumer of those crates. However, it's also in and those crates only get bumped in racer when a racer consumer needs them to be bumped.
Ah ok. In that case if this is purely for something in maintenance mode I think my own personal tenure in maintaining these crates is over with, so I would prefer to hand over the reins to someone else. Would someone be willing to volunteer to take over these crates?
let's sync up on #t-infra on Zulip -- I think it makes sense to move these crates into infra control/publication.
Let's wait if Racer can move over to rustc-dev racer-rust/racer. If so, there shouldn't be a need to keep maintaining rustc-ap crates at all. Looking at the dependents on , there really is only , the crates themselves and (which by now uses ).
has some relevant considerations as well.


Question: "anyhow", "cargo", "cargo-util", <del> "cargo_metadata 0.12.0", </del> <ins> "cargo_metadata 0.14.0", </ins> "clippy_lints", "crossbeam-channel", "difference", <del> "env_logger 0.7.1", </del> <ins> "env_logger 0.9.0", </ins> "futures 0.3.12", "heck", "home", <del> "itertools 0.9.0", </del> <ins> "itertools 0.10.1", </ins> "jsonrpc-core", "lazy_static", "log",

One way or another I think the AP crates need to be accounted for as per the accepted RFC, though it certainly would be a simpler story if they no longer need to be updated/published
Happy to coordinate as necessary, just let me know!
Over a month now. Is this gonna be fixed?
it's blocked on


Question: <del> // ignore-tidy-filelength </del> //! Error Reporting Code for the inference engine //! //! Because of the way inference, and in particular region inference,

This issue is a proposal for the deprecation of error code . I opened a PR () as part of an effort to add long error explanations for error codes that didn't have one (). I chose and for my erroneous code example, I used the example from . I quickly realized, through running the example and other code that would also raise and through the CI failure message, that was not being raised. I went back to consult the issue I received the original code example from and noticed comments about not occurring anymore with . The issue was eventually labeled with . But, looking at the current contents of the file, can still be emitted even while it isn't: also doesn't have any UI tests as it is part of the error codes in . Since , is no longer actually emitted (although it is in code that it could) thanks to , I believe it should be deprecated. I would be happy to help deprecate the error code, if it is decided that it should happen. I would just need to know the proper steps to take to deprecate an error code. If there are reasons for why it is still an error code, I would love to be enlightened. claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
If is not emitted anymore then it can be removed immediately. A crater run can also be done to ensure that this is the case. I'm also happy to do this if you want.
Sure, that sounds good.
Sorry just for clarification, do you want me to do the PR or you?


Question: Err(err) } <ins> pub(super) fn attr_on_non_tail_expr(&self, expr: &Expr) { // Missing semicolon typo error. let span = self.prev_token.span.shrink_to_hi(); let mut err = self.sess.create_err(ExpectedSemi { span, token: self.token.clone(), unexpected_token_label: Some(self.token.span), sugg: ExpectedSemiSugg::AddSemi(span), }); let attr_span = match &expr.attrs[..] { [] => unreachable!(), [only] => only.span, [first, rest @ ..] => { for attr in rest { err.span_label(attr.span, ""); } first.span } }; err.span_label( attr_span, format!( "only `;` terminated statements or tail expressions are allowed after {}", if expr.attrs.len() == 1 { "this attribute" } else { "these attributes" }, ), ); if self.token == token::Pound && self.look_ahead(1, |t| t.kind == token::OpenDelim(Delimiter::Bracket)) { // We have // #[attr] // expr // #[not_attr] // other_expr err.span_label(span, "expected `;` here"); err.multipart_suggestion( "alternatively, consider surrounding the expression with a block", vec![ (expr.span.shrink_to_lo(), "{ ".to_string()), (expr.span.shrink_to_hi(), " }".to_string()), ], Applicability::MachineApplicable, ); let mut snapshot = self.create_snapshot_for_diagnostic(); if let [attr] = &expr.attrs[..] && let ast::AttrKind::Normal(attr_kind) = &attr.kind && let [segment] = &attr_kind.item.path.segments[..] && segment.ident.name == sym::cfg && let Ok(next_attr) = snapshot.parse_attribute(InnerAttrPolicy::Forbidden(None)) && let ast::AttrKind::Normal(next_attr_kind) = next_attr.kind && let [next_segment] = &next_attr_kind.item.path.segments[..] && segment.ident.name == sym::cfg && let Ok(next_expr) = snapshot.parse_expr() { // We have for sure // #[cfg(..)] // expr // #[cfg(..)] // other_expr // So we suggest using `if cfg!(..) { expr } else if cfg!(..) { other_expr }`. let margin = self.sess.source_map().span_to_margin(next_expr.span).unwrap_or(0); let sugg = vec![ (attr.span.with_hi(segment.span().hi()), "if cfg!".to_string()), ( attr_kind.item.args.span().unwrap().shrink_to_hi().with_hi(attr.span.hi()), " {".to_string(), ), (expr.span.shrink_to_lo(), "    ".to_string()), ( next_attr.span.with_hi(next_segment.span().hi()), "} else if cfg!".to_string(), ), ( next_attr_kind .item .args .span() .unwrap() .shrink_to_hi() .with_hi(next_attr.span.hi()), " {".to_string(), ), (next_expr.span.shrink_to_lo(), "    ".to_string()), (next_expr.span.shrink_to_hi(), format!("n{}}}", " ".repeat(margin))), ]; err.multipart_suggestion( "it seems like you are trying to provide different expressions depending on  `cfg`, consider using `if cfg!(..)`", sugg, Applicability::MachineApplicable, ); } } err.emit(); } </ins> fn check_too_many_raw_str_terminators(&mut self, err: &mut Diagnostic) -> bool { let sm = self.sess.source_map(); match (&self.prev_token.kind, &self.token.kind) {

Error code: Metadata:
What is the issue you are reporting here ?
Well, I thought that compiler can understand that is related to the block of code, but it fails.
Can you post a minimal reproducible example that demonstrates your issue? Or at least mention exactly what you'd expect to happen and why. Even code that is cfged out is still required to parse successfully.
Let's show you what exactly problem I have. Full code: And I get this error:
You seem to already have posted this a month ago. What you're asking seems a rather big change to me, I'm not that familiar with how the compiler parser works but I believe it currently requires your program syntax to be correct before macros are expanded, which is not true for your example, so some fundamental changes would be needed.
Oh, damn, sorry. I totally forgot that I made a post. Well, if it's not a bug and parser works like this it is bad, anyway, exists alternative way to write like this. But for me my issue is a candidate to feature request or a bug. Anyway, I'm not a lang dev, so I don't know what scales of this defect (?).
The workaround for this is to wrap the expressions in a block:
I solved this issue exactly as you did.
Another way to do this is using the macro and . I personally thinks it is more clear, and should optimize the same.
Work is not the same, due to compile-time evaluating an expression that we pass in it and evaluates only it, but at the same time everything compiles what is inside of .


Question: all(target_vendor = "fortanix", target_env = "sgx") ) ))] <del> mod doc { // On certain platforms right now the "main modules" modules that are // documented don't compile (missing things in `libc` which is empty), // so just omit them with an empty module. #[unstable(issue = "none", feature = "std_internals")] pub mod unix {} #[unstable(issue = "none", feature = "std_internals")] pub mod linux {} #[unstable(issue = "none", feature = "std_internals")] pub mod wasi {} #[unstable(issue = "none", feature = "std_internals")] pub mod windows {} } #[cfg(doc)] #[stable(feature = "os", since = "1.0.0")] pub use doc::*; #[cfg(not(doc))] #[path = "."] mod imp { // If we're not documenting std then we only expose modules appropriate for the // current platform. #[cfg(all(target_vendor = "fortanix", target_env = "sgx"))] pub mod fortanix_sgx; #[cfg(target_os = "hermit")] #[path = "hermit/mod.rs"] pub mod unix; </del> <ins> #[unstable(issue = "none", feature = "std_internals")] pub mod linux {} #[cfg(all( doc, any( all(target_arch = "wasm32", not(target_os = "wasi")), all(target_vendor = "fortanix", target_env = "sgx") ) ))] #[unstable(issue = "none", feature = "std_internals")] pub mod wasi {} #[cfg(all( doc, any( all(target_arch = "wasm32", not(target_os = "wasi")), all(target_vendor = "fortanix", target_env = "sgx") ) ))] #[unstable(issue = "none", feature = "std_internals")] pub mod windows {} </ins> <del> #[cfg(target_os = "android")] pub mod android; #[cfg(target_os = "dragonfly")] pub mod dragonfly; #[cfg(target_os = "emscripten")] pub mod emscripten; #[cfg(target_os = "espidf")] pub mod espidf; #[cfg(target_os = "freebsd")] pub mod freebsd; #[cfg(target_os = "fuchsia")] pub mod fuchsia; #[cfg(target_os = "haiku")] pub mod haiku; #[cfg(target_os = "illumos")] pub mod illumos; #[cfg(target_os = "ios")] pub mod ios; #[cfg(target_os = "l4re")] pub mod linux; #[cfg(target_os = "linux")] pub mod linux; #[cfg(target_os = "macos")] pub mod macos; #[cfg(target_os = "netbsd")] pub mod netbsd; #[cfg(target_os = "openbsd")] pub mod openbsd; #[cfg(target_os = "redox")] pub mod redox; #[cfg(target_os = "solaris")] pub mod solaris; #[cfg(unix)] pub mod unix; </del> <ins> // unix #[cfg(not(all( doc, any( all(target_arch = "wasm32", not(target_os = "wasi")), all(target_vendor = "fortanix", target_env = "sgx") ) )))] #[cfg(target_os = "hermit")] #[path = "hermit/mod.rs"] pub mod unix; #[cfg(not(all( doc, any( all(target_arch = "wasm32", not(target_os = "wasi")), all(target_vendor = "fortanix", target_env = "sgx") ) )))] #[cfg(all(not(target_os = "hermit"), any(unix, doc)))] pub mod unix; </ins> <del> #[cfg(target_os = "vxworks")] pub mod vxworks; </del> <ins> // linux #[cfg(not(all( doc, any( all(target_arch = "wasm32", not(target_os = "wasi")), all(target_vendor = "fortanix", target_env = "sgx") ) )))] #[cfg(any(target_os = "linux", target_os = "l4re", doc))] pub mod linux; </ins> <del> #[cfg(target_os = "wasi")] pub mod wasi; </del> <ins> // wasi #[cfg(not(all( doc, any( all(target_arch = "wasm32", not(target_os = "wasi")), all(target_vendor = "fortanix", target_env = "sgx") ) )))] #[cfg(any(target_os = "wasi", doc))] pub mod wasi; </ins> <del> #[cfg(windows)] pub mod windows; } #[cfg(not(doc))] #[stable(feature = "os", since = "1.0.0")] pub use imp::*; </del> <ins> // windows #[cfg(not(all( doc, any( all(target_arch = "wasm32", not(target_os = "wasi")), all(target_vendor = "fortanix", target_env = "sgx") ) )))] #[cfg(any(windows, doc))] pub mod windows; // Others. #[cfg(target_os = "android")] pub mod android; #[cfg(target_os = "dragonfly")] pub mod dragonfly; #[cfg(target_os = "emscripten")] pub mod emscripten; #[cfg(target_os = "espidf")] pub mod espidf; #[cfg(all(target_vendor = "fortanix", target_env = "sgx"))] pub mod fortanix_sgx; #[cfg(target_os = "freebsd")] pub mod freebsd; #[cfg(target_os = "fuchsia")] pub mod fuchsia; #[cfg(target_os = "haiku")] pub mod haiku; #[cfg(target_os = "illumos")] pub mod illumos; #[cfg(target_os = "ios")] pub mod ios; #[cfg(target_os = "macos")] pub mod macos; #[cfg(target_os = "netbsd")] pub mod netbsd; #[cfg(target_os = "openbsd")] pub mod openbsd; #[cfg(target_os = "redox")] pub mod redox; #[cfg(target_os = "solaris")] pub mod solaris; #[cfg(target_os = "vxworks")] pub mod vxworks; </ins> #[cfg(any(unix, target_os = "wasi", doc))] mod fd;

More information on
To be clear, I'm not actually sure that's a private link, I didn't look at it in detail. It might just be doc(hidden) or something.
I didn't either. Just that most of weird things happening are in .


Question: self.as_operand(block, local_scope, expr) } <ins> /// Returns an operand suitable for use until the end of the current scope expression and /// suitable also to be passed as function arguments. /// /// The operand returned from this function will *not be valid* after an ExprKind::Scope is /// passed, so please do *not* return it from functions to avoid bad miscompiles.  Returns an /// operand suitable for use as a call argument. This is almost always equivalent to /// `as_operand`, except for the particular case of passing values of (potentially) unsized /// types "by value" (see details below). /// /// The operand returned from this function will *not be valid* /// after the current enclosing `ExprKind::Scope` has ended, so /// please do *not* return it from functions to avoid bad /// miscompiles. /// /// # Parameters of unsized types /// /// We tweak the handling of parameters of unsized type slightly to avoid the need to create a /// local variable of unsized type. For example, consider this program: /// /// ```rust /// fn foo(p: dyn Debug) { ... } /// /// fn bar(box_p: Box<dyn Debug>) { foo(*p); } /// ``` /// /// Ordinarily, for sized types, we would compile the call `foo(*p)` like so: /// /// ```rust /// let tmp0 = *box_p; // tmp0 would be the operand returned by this function call /// foo(tmp0) /// ``` /// /// But because the parameter to `foo` is of the unsized type `dyn Debug`, and because it is /// being moved the deref of a box, we compile it slightly differently. The temporary `tmp0` /// that we create *stores the entire box*, and the parameter to the call itself will be /// `*tmp0`: /// /// ```rust /// let tmp0 = box_p; call foo(*tmp0) /// ``` /// /// This way, the temporary `tmp0` that we create has type `Box<dyn Debug>`, which is sized. /// The value passed to the call (`*tmp0`) still has the `dyn Debug` type -- but the way that /// calls are compiled means that this parameter will be passed "by reference", meaning that we /// will actually provide a pointer to the interior of the box, and not move the `dyn Debug` /// value to the stack. /// /// See #68034 for more details. crate fn as_local_call_operand<M>( &mut self, block: BasicBlock, expr: M, ) -> BlockAnd<Operand<'tcx>> where M: Mirror<'tcx, Output = Expr<'tcx>>, { let local_scope = self.local_scope(); self.as_call_operand(block, local_scope, expr) } </ins> /// Compile `expr` into a value that can be used as an operand. /// If `expr` is a place like `x`, this will introduce a /// temporary `tmp = x`, so that we capture the value of `x` at

The following code fails on stable: When compiled in release mode, the assert is optimized out by LLVM even though it checks the exact same condition as the other assert, as can be verified by testing in debug mode. Note that it's theoretically possible for the stack to be aligned correctly such that the bug is suppressed, but that's not likely. The 256's can be replaced with larger alignments if that happens. The bug is caused by the impl of copying to the stack with the default alignment of 16. ()
and seem related
This is a soundness hole.
So... I guess the problem is that the that rustc emits for the unsized local doesn't use ? That's... kind of bad, because it doesn't look like even supports dynamically setting the alignment: If this is correct, the issue should be renamed to something like "unsized locals do not respect alignment".
A way to fix this would be to change the ABI for dynamic trait calls that take by value to always pass by address. When the trait object is created is where the trampoline function would be generated, so there is no additional cost for static calls.
This can also be fixed by not allowing dynamically-sized local variables with an alignment more than some maximum value and having all dynamically-sized locals use that maximum alignment unless optimizations can prove that a smaller alignment suffices.
Messing with the ABI wouldn't help with unsized locals in general (assuming is correct), since e.g. will also need an alloca with dynamic alignment in general. Given only a value, there is no static way to say anything about its alignment, so how would you distinguish whether calling a method on it is OK?
Can we call and then align the pointer for the local ourselves as a workaround until we come up with a good solution?
In clang there's a function which might or might not be useful in this case.
requires a constant alignment. Non constant alignments are . This matches semantics of LLVM instruction, so it's not helping, as alignment of value in is unknown at compile time when moving from .
I think that overallocating for unsized locals of unknown alignment may make sense. You can and then make use of to compute the offset. Sure, it increases stack requirements, but it seems acceptable for , and in most cases you end up with extra 7 bytes on stack or less. 256 alignment seems like an edge case where wasting 255 bytes doesn't matter.


Question: self.as_operand(block, local_scope, expr) } <ins> /// Returns an operand suitable for use until the end of the current scope expression and /// suitable also to be passed as function arguments. /// /// The operand returned from this function will *not be valid* after an ExprKind::Scope is /// passed, so please do *not* return it from functions to avoid bad miscompiles.  Returns an /// operand suitable for use as a call argument. This is almost always equivalent to /// `as_operand`, except for the particular case of passing values of (potentially) unsized /// types "by value" (see details below). /// /// The operand returned from this function will *not be valid* /// after the current enclosing `ExprKind::Scope` has ended, so /// please do *not* return it from functions to avoid bad /// miscompiles. /// /// # Parameters of unsized types /// /// We tweak the handling of parameters of unsized type slightly to avoid the need to create a /// local variable of unsized type. For example, consider this program: /// /// ```rust /// fn foo(p: dyn Debug) { ... } /// /// fn bar(box_p: Box<dyn Debug>) { foo(*p); } /// ``` /// /// Ordinarily, for sized types, we would compile the call `foo(*p)` like so: /// /// ```rust /// let tmp0 = *box_p; // tmp0 would be the operand returned by this function call /// foo(tmp0) /// ``` /// /// But because the parameter to `foo` is of the unsized type `dyn Debug`, and because it is /// being moved the deref of a box, we compile it slightly differently. The temporary `tmp0` /// that we create *stores the entire box*, and the parameter to the call itself will be /// `*tmp0`: /// /// ```rust /// let tmp0 = box_p; call foo(*tmp0) /// ``` /// /// This way, the temporary `tmp0` that we create has type `Box<dyn Debug>`, which is sized. /// The value passed to the call (`*tmp0`) still has the `dyn Debug` type -- but the way that /// calls are compiled means that this parameter will be passed "by reference", meaning that we /// will actually provide a pointer to the interior of the box, and not move the `dyn Debug` /// value to the stack. /// /// See #68034 for more details. crate fn as_local_call_operand<M>( &mut self, block: BasicBlock, expr: M, ) -> BlockAnd<Operand<'tcx>> where M: Mirror<'tcx, Output = Expr<'tcx>>, { let local_scope = self.local_scope(); self.as_call_operand(block, local_scope, expr) } </ins> /// Compile `expr` into a value that can be used as an operand. /// If `expr` is a place like `x`, this will introduce a /// temporary `tmp = x`, so that we capture the value of `x` at

if we keep setting as the default alignment we can skip the overallocating and offset dance for types with an alignment below that.
My idea was that rustc would prohibit coercing overaligned types to a dyn trait that takes by value. So:
The alignment is dynamically determined though, not sure if saving 15 bytes of stack space is worth the conditional branch?
Oh right. Yea that's probably not helpful.
Since , this would be backwards incompatible (at latest) once trait object upcasting is finally implemented: and trait objects would have to have the same alignment restriction (because you can upcast to ), but today you can freely create such objects with any alignment.
I was under the impression that calling didn't require dynamic , is that related to missing MIR optimizations, meaning we have unnecessary moves which end up duplicating the data on the stack using a dynamic ?
Correctness shouldn't rely on optimizations to fire...
Sure, I was just hoping we weren't relying on "unsized locals", only unsized parameters (i.e. ), for what we're exposing as stable. And I was hoping an optimization wouldn't need to be involved to get there. I wonder if it would even be possible to restrict "unsized locals" to the subset where we can handle it entirely through ABI, and not actually have dynamic s anywhere, since that would make me far more comfortable with 's implementation or even stabilization. Ironically, if that works, it's also the subset we could've implemented years earlier than we did, since most of the complexity, unknowns (and apparently bugs) are around dynamic s, not calling trait object methods on a dereference of .
That should be possible. I think everything that is necessary is performing the deref of the box as argument () instead of moving the box contents to a local first () That would also make it possible to call in cg_clif. Cranelift doesn't have alloca support, so the current MIR is untranslatable.
Hmm, but that's not trivially sound because it could lead to MIR calls where argument and return places overlap, which is UB. We'd potentially have to special-case it to derefs, but even then what's to stop someone from doing ? Maybe we could introduce a temporary for the return value instead, for these kinds of virtual calls? That should remove any potential overlap while allowing the call.


Question: self.as_operand(block, local_scope, expr) } <ins> /// Returns an operand suitable for use until the end of the current scope expression and /// suitable also to be passed as function arguments. /// /// The operand returned from this function will *not be valid* after an ExprKind::Scope is /// passed, so please do *not* return it from functions to avoid bad miscompiles.  Returns an /// operand suitable for use as a call argument. This is almost always equivalent to /// `as_operand`, except for the particular case of passing values of (potentially) unsized /// types "by value" (see details below). /// /// The operand returned from this function will *not be valid* /// after the current enclosing `ExprKind::Scope` has ended, so /// please do *not* return it from functions to avoid bad /// miscompiles. /// /// # Parameters of unsized types /// /// We tweak the handling of parameters of unsized type slightly to avoid the need to create a /// local variable of unsized type. For example, consider this program: /// /// ```rust /// fn foo(p: dyn Debug) { ... } /// /// fn bar(box_p: Box<dyn Debug>) { foo(*p); } /// ``` /// /// Ordinarily, for sized types, we would compile the call `foo(*p)` like so: /// /// ```rust /// let tmp0 = *box_p; // tmp0 would be the operand returned by this function call /// foo(tmp0) /// ``` /// /// But because the parameter to `foo` is of the unsized type `dyn Debug`, and because it is /// being moved the deref of a box, we compile it slightly differently. The temporary `tmp0` /// that we create *stores the entire box*, and the parameter to the call itself will be /// `*tmp0`: /// /// ```rust /// let tmp0 = box_p; call foo(*tmp0) /// ``` /// /// This way, the temporary `tmp0` that we create has type `Box<dyn Debug>`, which is sized. /// The value passed to the call (`*tmp0`) still has the `dyn Debug` type -- but the way that /// calls are compiled means that this parameter will be passed "by reference", meaning that we /// will actually provide a pointer to the interior of the box, and not move the `dyn Debug` /// value to the stack. /// /// See #68034 for more details. crate fn as_local_call_operand<M>( &mut self, block: BasicBlock, expr: M, ) -> BlockAnd<Operand<'tcx>> where M: Mirror<'tcx, Output = Expr<'tcx>>, { let local_scope = self.local_scope(); self.as_call_operand(block, local_scope, expr) } </ins> /// Compile `expr` into a value that can be used as an operand. /// If `expr` is a place like `x`, this will introduce a /// temporary `tmp = x`, so that we capture the value of `x` at

(Unrelatedly, I just realize we use a copying-out shim for vtable entries that take by value, even when would be passed as at the call ABI level. We would probably have to make computing the call ABI a query for this microopt to not be expensive)
That would result in being moved to a temp first before dropping and calling the boxed closure. If it wasn't moved first before the drop of , then borrowck would give an error. (I meant for this change to be done at mir construction level, not as an optimization pass, so borrowck should catch any soundness issues)
We can try it, I guess, but right now a lot relies on many redundant copies/moves being created by MIR building and may not catch edge cases like this. But also I don't think moving out of a moves the itself today. Me too, but I was going with the "correct by construction" approach of creating a redundant copy/move, just on the return side, instead of the argument side, of the call.
After revisiting on triage, removing nomination.
pre-triage: nominated for discussion in the next weekly meeting.
I just checked and, a function call roughly this (touched up for clarity): Some of my previous comments assumed the wasn't there and the call would use the destination directly, but given that there is a move, that simplifies my suggestion. <hr/For virtual by-value calls, we can skip one move when building the MIR, specifically the move out of the dereference of a for the argument. Given that we already move the result of the call, there should be no aliasing caused by this, but if we decide to change anything about how we build MIR calls, we'd need to be extra careful. We can also make this pattern be gated by a separate feature-gate (rather than ), and make sure the standard library only uses that feature-gate and not . This should solve any alignment issues might have, because we'd not be using dynamic unless the broader feature is used.
OK, if I understand what's being proposed here, it is to excerpt a subset of the "original unsized-locals plan" -- specifically, to permit locals with unsized types, but only in contexts where we can be guaranteed that we can point to the original storage and don't actually have to move any value (and hence we don't require variable size stack frames).


Question: self.as_operand(block, local_scope, expr) } <ins> /// Returns an operand suitable for use until the end of the current scope expression and /// suitable also to be passed as function arguments. /// /// The operand returned from this function will *not be valid* after an ExprKind::Scope is /// passed, so please do *not* return it from functions to avoid bad miscompiles.  Returns an /// operand suitable for use as a call argument. This is almost always equivalent to /// `as_operand`, except for the particular case of passing values of (potentially) unsized /// types "by value" (see details below). /// /// The operand returned from this function will *not be valid* /// after the current enclosing `ExprKind::Scope` has ended, so /// please do *not* return it from functions to avoid bad /// miscompiles. /// /// # Parameters of unsized types /// /// We tweak the handling of parameters of unsized type slightly to avoid the need to create a /// local variable of unsized type. For example, consider this program: /// /// ```rust /// fn foo(p: dyn Debug) { ... } /// /// fn bar(box_p: Box<dyn Debug>) { foo(*p); } /// ``` /// /// Ordinarily, for sized types, we would compile the call `foo(*p)` like so: /// /// ```rust /// let tmp0 = *box_p; // tmp0 would be the operand returned by this function call /// foo(tmp0) /// ``` /// /// But because the parameter to `foo` is of the unsized type `dyn Debug`, and because it is /// being moved the deref of a box, we compile it slightly differently. The temporary `tmp0` /// that we create *stores the entire box*, and the parameter to the call itself will be /// `*tmp0`: /// /// ```rust /// let tmp0 = box_p; call foo(*tmp0) /// ``` /// /// This way, the temporary `tmp0` that we create has type `Box<dyn Debug>`, which is sized. /// The value passed to the call (`*tmp0`) still has the `dyn Debug` type -- but the way that /// calls are compiled means that this parameter will be passed "by reference", meaning that we /// will actually provide a pointer to the interior of the box, and not move the `dyn Debug` /// value to the stack. /// /// See #68034 for more details. crate fn as_local_call_operand<M>( &mut self, block: BasicBlock, expr: M, ) -> BlockAnd<Operand<'tcx>> where M: Mirror<'tcx, Output = Expr<'tcx>>, { let local_scope = self.local_scope(); self.as_call_operand(block, local_scope, expr) } </ins> /// Compile `expr` into a value that can be used as an operand. /// If `expr` is a place like `x`, this will introduce a /// temporary `tmp = x`, so that we capture the value of `x` at

I'm in favor of this proposal, but I do think we want to be slightly careful to ensure we're not violating soundness. The main concern would be if there is some way to access or re-use the variable that was moved. I attempted to do so with this example () but it fails to compile: The error here arises because the closure would need to capture a to do anything, which prevents a later move. But maybe there is some kind of tricky example that can arise where we re-assign the value during argument evaluation?
compiles and does before , where is the result of .
Borrowck should prevent that, right?
borrowck may rely on MIR building creating extraneous copies, so we can't just assume it helps us. IMO we should limit it to functions taking unsized parameters and function calls passing such parameters or dereferences of es (any other pointer/reference doesn't support moving out of).
Well, I think is right that borrowck would catch violations of soundness in some strict sense, but I guess what I meant is that we might be breaking backwards compatibility.
The example that feels pretty relevant. If I understood your proposal, it would no longer compile. If I recall (thinking back), I had a plan to handle this by save the to an alternate location in the actual call, we pass ownership of and then do a shallow free of the This still seems like it would work, though I'm not sure how easy/elegant it is to formulate. In a sense we'd be rewriting to .
Isn't example dependent on doing a direct virtual call? My understanding is that you can't do this on stable with because the virtual call exists in one place, in libstd, and it doesn't do anything weird, so it would work with a restricted ruleset. EDIT: if it can work on stable, it's because calling 's will move the whole before the assignment is evaluated, which is fine, because the shallow drop is actually inside that , not its caller.
I agree that this code doesn't compile on stable today, but I'm not sure if that's the point. I guess you're saying it's ok for it to stop compiling? I think what I would like is that our overall behavior is as consistent as possible between Sized and Unsized parameters. I think we could actually do a more general change that doesn't special case Sized vs Unsized or anything else.


Question: self.as_operand(block, local_scope, expr) } <ins> /// Returns an operand suitable for use until the end of the current scope expression and /// suitable also to be passed as function arguments. /// /// The operand returned from this function will *not be valid* after an ExprKind::Scope is /// passed, so please do *not* return it from functions to avoid bad miscompiles.  Returns an /// operand suitable for use as a call argument. This is almost always equivalent to /// `as_operand`, except for the particular case of passing values of (potentially) unsized /// types "by value" (see details below). /// /// The operand returned from this function will *not be valid* /// after the current enclosing `ExprKind::Scope` has ended, so /// please do *not* return it from functions to avoid bad /// miscompiles. /// /// # Parameters of unsized types /// /// We tweak the handling of parameters of unsized type slightly to avoid the need to create a /// local variable of unsized type. For example, consider this program: /// /// ```rust /// fn foo(p: dyn Debug) { ... } /// /// fn bar(box_p: Box<dyn Debug>) { foo(*p); } /// ``` /// /// Ordinarily, for sized types, we would compile the call `foo(*p)` like so: /// /// ```rust /// let tmp0 = *box_p; // tmp0 would be the operand returned by this function call /// foo(tmp0) /// ``` /// /// But because the parameter to `foo` is of the unsized type `dyn Debug`, and because it is /// being moved the deref of a box, we compile it slightly differently. The temporary `tmp0` /// that we create *stores the entire box*, and the parameter to the call itself will be /// `*tmp0`: /// /// ```rust /// let tmp0 = box_p; call foo(*tmp0) /// ``` /// /// This way, the temporary `tmp0` that we create has type `Box<dyn Debug>`, which is sized. /// The value passed to the call (`*tmp0`) still has the `dyn Debug` type -- but the way that /// calls are compiled means that this parameter will be passed "by reference", meaning that we /// will actually provide a pointer to the interior of the box, and not move the `dyn Debug` /// value to the stack. /// /// See #68034 for more details. crate fn as_local_call_operand<M>( &mut self, block: BasicBlock, expr: M, ) -> BlockAnd<Operand<'tcx>> where M: Mirror<'tcx, Output = Expr<'tcx>>, { let local_scope = self.local_scope(); self.as_call_operand(block, local_scope, expr) } </ins> /// Compile `expr` into a value that can be used as an operand. /// If `expr` is a place like `x`, this will introduce a /// temporary `tmp = x`, so that we capture the value of `x` at

I think I am basically proposing the same thing as earlier, but with a twist: Today, when building the parameters, we introduce a temporary for each parameter. So if we had we might do: What I am saying is that we could say: If the argument is moved (not copied), and the "place" has outer derefs (e.g., we are passing where is some place), then we assign the place to a temporary and we make the argument to the function be : I don't believe this is observable to end-users, except potentially for when the destructor on runs. I believe that it accepts all the same code we used to accept. It also has nothing specific to or types at all. Does that make sense? I'm very curious to know if anyone sees any problems with it. (One obvious thing: if we ever add , its design would have to accommodate this requirement, but I think that's fine, in fact the complications around getting moves right for precisely this case are one of the reasons we've held off on thus far.)
Can you not reinitialize today? If you move the whole , it is indeed more conservative (and should let us skip unnecessary moves even in cases). But also, do you want to move the locals check from typeck to borrowck? I don't have an intuition for when your approach wouldn't create unsized MIR locals, from the perspective of typeck. However, this is only relevant if we want a stricter feature-gate. At the very least it seems like it would be easier to implement a change only to MIR building, and it should fix problems with for the time being, even without a separate feature-gate.
Hmm, that's a good point, I think do that. Sigh. I knew that seemed too easy. I remember we used to try and prevent that, but we never did it fully, and in the move to NLL we loosened those rules back up, so this compiles: Still, you could do my proposal for unsized types, though it would introduce an incongruity. UPDATE: Oh, wait, I remember now. For unsized types, reinitialization is not possible, because you can't do with an unsized rvalue (we wouldn't know how many bytes to move). So in fact there isn't really the same incongruity.


Question: self.as_operand(block, local_scope, expr) } <ins> /// Returns an operand suitable for use until the end of the current scope expression and /// suitable also to be passed as function arguments. /// /// The operand returned from this function will *not be valid* after an ExprKind::Scope is /// passed, so please do *not* return it from functions to avoid bad miscompiles.  Returns an /// operand suitable for use as a call argument. This is almost always equivalent to /// `as_operand`, except for the particular case of passing values of (potentially) unsized /// types "by value" (see details below). /// /// The operand returned from this function will *not be valid* /// after the current enclosing `ExprKind::Scope` has ended, so /// please do *not* return it from functions to avoid bad /// miscompiles. /// /// # Parameters of unsized types /// /// We tweak the handling of parameters of unsized type slightly to avoid the need to create a /// local variable of unsized type. For example, consider this program: /// /// ```rust /// fn foo(p: dyn Debug) { ... } /// /// fn bar(box_p: Box<dyn Debug>) { foo(*p); } /// ``` /// /// Ordinarily, for sized types, we would compile the call `foo(*p)` like so: /// /// ```rust /// let tmp0 = *box_p; // tmp0 would be the operand returned by this function call /// foo(tmp0) /// ``` /// /// But because the parameter to `foo` is of the unsized type `dyn Debug`, and because it is /// being moved the deref of a box, we compile it slightly differently. The temporary `tmp0` /// that we create *stores the entire box*, and the parameter to the call itself will be /// `*tmp0`: /// /// ```rust /// let tmp0 = box_p; call foo(*tmp0) /// ``` /// /// This way, the temporary `tmp0` that we create has type `Box<dyn Debug>`, which is sized. /// The value passed to the call (`*tmp0`) still has the `dyn Debug` type -- but the way that /// calls are compiled means that this parameter will be passed "by reference", meaning that we /// will actually provide a pointer to the interior of the box, and not move the `dyn Debug` /// value to the stack. /// /// See #68034 for more details. crate fn as_local_call_operand<M>( &mut self, block: BasicBlock, expr: M, ) -> BlockAnd<Operand<'tcx>> where M: Mirror<'tcx, Output = Expr<'tcx>>, { let local_scope = self.local_scope(); self.as_call_operand(block, local_scope, expr) } </ins> /// Compile `expr` into a value that can be used as an operand. /// If `expr` is a place like `x`, this will introduce a /// temporary `tmp = x`, so that we capture the value of `x` at

To be clear, I wasn't proposing changing anything apart from MIR building either, I don't think. IIUC, what you proposed is that would be compiled to: whereas under my proposal (limited to apply to unsized parameters, instead of moved parameters) would yield: I think I mis-stated the problem earlier. It's not so much that your proposal will introduce compilation errors, it's that I think it changes the semantics of code like this in what I see as a surprising way: I believe that this code would compile to the following under your proposal: which means that would be invoked with the new value of , right? Under my proposal, the code would still compile, but it would behave in what I see as the expected fashion. Specifically, it would generate:
Isn't there a way to "lock" that value through the borrow-checker, so further accesses would be disallowed, until the call returns? I'd rather be stricter here. <hr/My point was that if your proposal affects sized moves, you're breaking stable reinitialization. If it doesn't affect sized moves, I don't see how this applies anymore:
Let me just chime in here and say that this is a pain in Miri. Unsized locals are pretty different from sized locals, I had to introduce a bunch of special hacks to make them work. MIR locals even needed a new state just for them: Lazily allocating locals seems odd to me, but at least we can consistently do that for all locals. Elsewhere however to make this lazy initialization actually work out and catch mistakes where an unsized local is "overwritten" with a value of different size: This all feels really unprincipled, and it would be great if at some point we could come up with a coherent semantics for unsized locals in MIR. The worst part is that the size of a local is implicitly determined on the first write to it. It would be much better to be explicit about that, e.g. at time.
I don't think we have anything like this today, but presumably we could add such a thing, but I'm not quite sure what you have in mind. When does this prohibition on further accesses take effect?


Question: self.as_operand(block, local_scope, expr) } <ins> /// Returns an operand suitable for use until the end of the current scope expression and /// suitable also to be passed as function arguments. /// /// The operand returned from this function will *not be valid* after an ExprKind::Scope is /// passed, so please do *not* return it from functions to avoid bad miscompiles.  Returns an /// operand suitable for use as a call argument. This is almost always equivalent to /// `as_operand`, except for the particular case of passing values of (potentially) unsized /// types "by value" (see details below). /// /// The operand returned from this function will *not be valid* /// after the current enclosing `ExprKind::Scope` has ended, so /// please do *not* return it from functions to avoid bad /// miscompiles. /// /// # Parameters of unsized types /// /// We tweak the handling of parameters of unsized type slightly to avoid the need to create a /// local variable of unsized type. For example, consider this program: /// /// ```rust /// fn foo(p: dyn Debug) { ... } /// /// fn bar(box_p: Box<dyn Debug>) { foo(*p); } /// ``` /// /// Ordinarily, for sized types, we would compile the call `foo(*p)` like so: /// /// ```rust /// let tmp0 = *box_p; // tmp0 would be the operand returned by this function call /// foo(tmp0) /// ``` /// /// But because the parameter to `foo` is of the unsized type `dyn Debug`, and because it is /// being moved the deref of a box, we compile it slightly differently. The temporary `tmp0` /// that we create *stores the entire box*, and the parameter to the call itself will be /// `*tmp0`: /// /// ```rust /// let tmp0 = box_p; call foo(*tmp0) /// ``` /// /// This way, the temporary `tmp0` that we create has type `Box<dyn Debug>`, which is sized. /// The value passed to the call (`*tmp0`) still has the `dyn Debug` type -- but the way that /// calls are compiled means that this parameter will be passed "by reference", meaning that we /// will actually provide a pointer to the interior of the box, and not move the `dyn Debug` /// value to the stack. /// /// See #68034 for more details. crate fn as_local_call_operand<M>( &mut self, block: BasicBlock, expr: M, ) -> BlockAnd<Operand<'tcx>> where M: Mirror<'tcx, Output = Expr<'tcx>>, { let local_scope = self.local_scope(); self.as_call_operand(block, local_scope, expr) } </ins> /// Compile `expr` into a value that can be used as an operand. /// If `expr` is a place like `x`, this will introduce a /// temporary `tmp = x`, so that we capture the value of `x` at

In particular, the IR for under your proposal, if I understood, would be But the access to that (I believe) we wish to prevent takes place in the "evaluate remaining arguments" part of things. So I think we'd have to add some sort of "pseudo-move" that tells borrowck that should not be assignable from that point forward, right? Well, it depends on your perspective. It's true that, given the need to permit reinitialization, the check is now specific to unsized values -- i.e., MIR construction will be different depending on whether we know the type to be sized or not. That's unfortunate. However, I think we still maintain a degree of congruence, from an end-user perspective. In particular, users could not have reinitialized a anyhow. However, under my proposal, users can write things like and the code works as expected (versus either having an unexpected result or getting an error). In any case, it seems like we're sort of "narrowing in" on a proposal here: when we see a function call with a parameter that is , and the value being passed is a deref, we want to modify the IR to not introduce a temporary and instead pass that parameter directly from its location, either we do some sort of "no more assignments" lock, or we move the pointer and introduce a temporary (and then pass in a deref of that temporary) Does that sound right so far?
If it's easier to do the more flexible approach (by moving the pointer) than the "locking" approach (which is a bit like borrowing the pointer until all arguments are evaluated, then releasing the borrow and doing a move instead), I don't mind it, I was only arguing with the "uniformity" aspect. Something important here: your approach is stabilizable, while mine is meant more for that one in the standard library, and not much else.
Yes, I was kind of shooting for something that we could conceivably stabilize.
Removing nomination, this was already discussed in triage meeting and it's under control.
So should we maybe try out the approach I proposed and see how well it works?
yes, going to try that out.
For the record, the "new plan" is this.


Question: self.as_operand(block, local_scope, expr) } <ins> /// Returns an operand suitable for use until the end of the current scope expression and /// suitable also to be passed as function arguments. /// /// The operand returned from this function will *not be valid* after an ExprKind::Scope is /// passed, so please do *not* return it from functions to avoid bad miscompiles.  Returns an /// operand suitable for use as a call argument. This is almost always equivalent to /// `as_operand`, except for the particular case of passing values of (potentially) unsized /// types "by value" (see details below). /// /// The operand returned from this function will *not be valid* /// after the current enclosing `ExprKind::Scope` has ended, so /// please do *not* return it from functions to avoid bad /// miscompiles. /// /// # Parameters of unsized types /// /// We tweak the handling of parameters of unsized type slightly to avoid the need to create a /// local variable of unsized type. For example, consider this program: /// /// ```rust /// fn foo(p: dyn Debug) { ... } /// /// fn bar(box_p: Box<dyn Debug>) { foo(*p); } /// ``` /// /// Ordinarily, for sized types, we would compile the call `foo(*p)` like so: /// /// ```rust /// let tmp0 = *box_p; // tmp0 would be the operand returned by this function call /// foo(tmp0) /// ``` /// /// But because the parameter to `foo` is of the unsized type `dyn Debug`, and because it is /// being moved the deref of a box, we compile it slightly differently. The temporary `tmp0` /// that we create *stores the entire box*, and the parameter to the call itself will be /// `*tmp0`: /// /// ```rust /// let tmp0 = box_p; call foo(*tmp0) /// ``` /// /// This way, the temporary `tmp0` that we create has type `Box<dyn Debug>`, which is sized. /// The value passed to the call (`*tmp0`) still has the `dyn Debug` type -- but the way that /// calls are compiled means that this parameter will be passed "by reference", meaning that we /// will actually provide a pointer to the interior of the box, and not move the `dyn Debug` /// value to the stack. /// /// See #68034 for more details. crate fn as_local_call_operand<M>( &mut self, block: BasicBlock, expr: M, ) -> BlockAnd<Operand<'tcx>> where M: Mirror<'tcx, Output = Expr<'tcx>>, { let local_scope = self.local_scope(); self.as_call_operand(block, local_scope, expr) } </ins> /// Compile `expr` into a value that can be used as an operand. /// If `expr` is a place like `x`, this will introduce a /// temporary `tmp = x`, so that we capture the value of `x` at

When generating the arguments to a call, we ordinarily will make a temporary containing the value of each argument: But we will modify this such that, for arguments that meet the following conditions: The argument is moved (not copied), and its type is not known to be , and the "place" has outer derefs (e.g., we are passing P where P is some place), then we assign the place P (instead of ) to a temporary and we make the argument to the function be (instead of ). This means that given where , we used to generate but now we generate We are now moving the box itself, which is slightly different than the semantics for values known to be sized. In particular, it does not permit of the box after having moved its contents. But that is not supported for unsized types anyway. The change does permit modifications to the callee during argument evaluation and they will work in an analogous way to how they would work with sized values. So given something like: we will find that we (a) save the old value of to a temporary and then (b) overwrite while evaluating the arguments and then (c) invoke the with the old value of .
Update: There is also
is a perfectly normal operand, I don't know what you mean. It's the same kind of as we currently have in (on the RHS)
Oh sorry, somehow I thought operands could only refer directly to locals, not also dereference them. I think I am beginning to see the pieces here -- together with function argument handling, this entirely avoids having to dynamically determine the size of a local. I have to agree that is quite elegant, even though baking "pass-by-reference" into MIR semantics still seems like a heavy hammer to me. On the other hand this places a severe restriction on now unsized locals may be used, basically taking back large parts of Is there some long-term plan to bring that back (probably requires with dynamic alignment in LLVM)? Or should we amend the RFC or at least the tracking issue with the extra restrictions?
I would keep the more general feature but use two different feature-gates (if we can). And just like with a few other feature-gates () we could warn that (the general one) is incomplete and could lead to misaligned variables (or something along those lines).


Question: self.as_operand(block, local_scope, expr) } <ins> /// Returns an operand suitable for use until the end of the current scope expression and /// suitable also to be passed as function arguments. /// /// The operand returned from this function will *not be valid* after an ExprKind::Scope is /// passed, so please do *not* return it from functions to avoid bad miscompiles.  Returns an /// operand suitable for use as a call argument. This is almost always equivalent to /// `as_operand`, except for the particular case of passing values of (potentially) unsized /// types "by value" (see details below). /// /// The operand returned from this function will *not be valid* /// after the current enclosing `ExprKind::Scope` has ended, so /// please do *not* return it from functions to avoid bad /// miscompiles. /// /// # Parameters of unsized types /// /// We tweak the handling of parameters of unsized type slightly to avoid the need to create a /// local variable of unsized type. For example, consider this program: /// /// ```rust /// fn foo(p: dyn Debug) { ... } /// /// fn bar(box_p: Box<dyn Debug>) { foo(*p); } /// ``` /// /// Ordinarily, for sized types, we would compile the call `foo(*p)` like so: /// /// ```rust /// let tmp0 = *box_p; // tmp0 would be the operand returned by this function call /// foo(tmp0) /// ``` /// /// But because the parameter to `foo` is of the unsized type `dyn Debug`, and because it is /// being moved the deref of a box, we compile it slightly differently. The temporary `tmp0` /// that we create *stores the entire box*, and the parameter to the call itself will be /// `*tmp0`: /// /// ```rust /// let tmp0 = box_p; call foo(*tmp0) /// ``` /// /// This way, the temporary `tmp0` that we create has type `Box<dyn Debug>`, which is sized. /// The value passed to the call (`*tmp0`) still has the `dyn Debug` type -- but the way that /// calls are compiled means that this parameter will be passed "by reference", meaning that we /// will actually provide a pointer to the interior of the box, and not move the `dyn Debug` /// value to the stack. /// /// See #68034 for more details. crate fn as_local_call_operand<M>( &mut self, block: BasicBlock, expr: M, ) -> BlockAnd<Operand<'tcx>> where M: Mirror<'tcx, Output = Expr<'tcx>>, { let local_scope = self.local_scope(); self.as_call_operand(block, local_scope, expr) } </ins> /// Compile `expr` into a value that can be used as an operand. /// If `expr` is a place like `x`, this will introduce a /// temporary `tmp = x`, so that we capture the value of `x` at

We could also add runtime asserts that the (dynamic) alignment is respected, once we know could never trigger them (e.g. from stable code).
I was wondering about that too. It seems like it'd be good to review the more general feature in any case. This is partly why I brought up the idea of wanting a guaranteed "no alloca" path -- this was something I remember us discussing long ago, and so in some sense I feel like the work we're doing here isn't just working around LLVM's lack of dynamic alignment support (though it is doing that, too) but also working to complete the feature as originally envisioned.
I two notes to the tracking issue so we don't overlook this in the future.
This is probably expected, but the fix failed to actually make sound:


Question: <ins> // Copyright 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. //compile-flags: -Z borrowck=mir #![feature(slice_patterns)] fn nop(_s: &[& i32]) {} fn nop_subslice(_s: &[i32]) {} fn const_index_ok(s: &mut [i32]) { if let [ref first, ref second, _, ref fourth, ..] = *s { if let [_, _, ref mut third, ..] = *s { nop(&[first, second, third, fourth]); } } } fn const_index_err(s: &mut [i32]) { if let [ref first, ref second, ..] = *s { if let [_, ref mut  second2, ref mut third, ..] = *s { //~ERROR nop(&[first, second, second2, third]); } } } fn const_index_from_end_ok(s: &mut [i32]) { if let [.., ref fourth, ref third, _, ref first] = *s { if let [.., ref mut second, _] = *s { nop(&[first, second, third, fourth]); } } } fn const_index_from_end_err(s: &mut [i32]) { if let [.., ref fourth, ref third, _, ref first] = *s { if let [.., ref mut third2, _, _] = *s { //~ERROR nop(&[first, third, third2, fourth]); } } } fn const_index_mixed(s: &mut [i32]) { if let [.., _, ref from_end4, ref from_end3, _, ref from_end1] = *s { if let [ref mut from_begin0, ..] = *s { nop(&[from_begin0, from_end1, from_end3, from_end4]); } if let [_, ref mut from_begin1, ..] = *s { //~ERROR nop(&[from_begin1, from_end1, from_end3, from_end4]); } if let [_, _, ref mut from_begin2, ..] = *s { //~ERROR nop(&[from_begin2, from_end1, from_end3, from_end4]); } if let [_, _, _, ref mut from_begin3, ..] = *s { //~ERROR nop(&[from_begin3, from_end1, from_end3, from_end4]); } } if let [ref from_begin0, ref from_begin1, _, ref from_begin3, _, ..] = *s { if let [.., ref mut from_end1] = *s { nop(&[from_begin0, from_begin1, from_begin3, from_end1]); } if let [.., ref mut from_end2, _] = *s { //~ERROR nop(&[from_begin0, from_begin1, from_begin3, from_end2]); } if let [.., ref mut from_end3, _,  _] = *s { //~ERROR nop(&[from_begin0, from_begin1, from_begin3, from_end3]); } if let [.., ref mut from_end4, _, _, _] = *s { //~ERROR nop(&[from_begin0, from_begin1, from_begin3, from_end4]); } } } fn const_index_and_subslice_ok(s: &mut [i32]) { if let [ref first, ref second, ..] = *s { if let [_, _, ref mut tail..] = *s { nop(&[first, second]); nop_subslice(tail); } } } fn const_index_and_subslice_err(s: &mut [i32]) { if let [ref first, ref second, ..] = *s { if let [_, ref mut tail..] = *s { //~ERROR nop(&[first, second]); nop_subslice(tail); } } } fn const_index_and_subslice_from_end_ok(s: &mut [i32]) { if let [.., ref second, ref first] = *s { if let [ref mut tail.., _, _] = *s { nop(&[first, second]); nop_subslice(tail); } } } fn const_index_and_subslice_from_end_err(s: &mut [i32]) { if let [.., ref second, ref first] = *s { if let [ref mut tail.., _] = *s { //~ERROR nop(&[first, second]); nop_subslice(tail); } } } fn subslices(s: &mut [i32]) { if let [_, _, _, ref s1..] = *s { if let [ref mut s2.., _, _, _] = *s { //~ERROR nop_subslice(s1); nop_subslice(s2); } } } fn main() { let mut v = [1,2,3,4]; const_index_ok(&mut v); const_index_err(&mut v); const_index_from_end_ok(&mut v); const_index_from_end_err(&mut v); const_index_and_subslice_ok(&mut v); const_index_and_subslice_err(&mut v); const_index_and_subslice_from_end_ok(&mut v); const_index_and_subslice_from_end_err(&mut v); subslices(&mut v); } </ins>

Minimal example: This will complain about multiple mutable borrows, even though it should be valid.
Noted in (but may deserve a separate bug report?). (FYI, slice patterns are unstable for a reason; they're pretty buggy at the moment).
should be closed after MIR borrowck will be by default


Question: LLVM_BUILD_DIR= LLVM_INST_DIR=$CFG_LLVM_ROOT do_reconfigure=0 <ins> # Check that LLVm FileCheck is available. Needed for the tests need_cmd $LLVM_INST_DIR/bin/FileCheck </ins> fi if [ ${do_reconfigure} -ne 0 ] then # because git is hilarious, it might have put the module index

Trying to package rust 1.2 into Debian & Ubuntu, I get the following test failures: I am using Debian LLVM 3.6.1 packages (version 3.6.1-1)
is in the package. I wonder whether we want a check in that makes a requirement or one that disables the respective tests if it is not available.
That was indeed the issue. I installed it and I have issue now.
Addressed in
These test should be optional until LLVM has a way to install FileCheck