Question: check_expr(fcx, &**idx); let raw_base_t = fcx.expr_ty(&**base); let idx_t = fcx.expr_ty(&**idx); <del> if ty::type_is_error(raw_base_t) || ty::type_is_bot(raw_base_t) { </del> <ins> if ty::type_is_error(raw_base_t) { </ins> fcx.write_ty(id, raw_base_t); <del> } else if ty::type_is_error(idx_t) || ty::type_is_bot(idx_t) { </del> <ins> } else if ty::type_is_error(idx_t) { </ins> fcx.write_ty(id, idx_t); } else { let (_, autoderefs, field_ty) = autoderef(fcx, expr.span, raw_base_t, Some(base.id), lvalue_pref, |base_t, _| ty::index(base_t)); match field_ty { <del> Some(ty) => { </del> <ins> Some(ty) if !ty::type_is_bot(ty) => { </ins> check_expr_has_type(fcx, &**idx, ty::mk_uint()); fcx.write_ty(id, ty); fcx.write_autoderef_adjustment(base.id, base.span, autoderefs); } <del> None => { </del> <ins> _ => { </ins> // This is an overloaded method. let base_t = structurally_resolved_type(fcx, expr.span,

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


Question: path = self.parse_path(PathStyle::Type)?; path_span = path_lo.to(self.prev_span); } else { <del> path = ast::Path { segments: Vec::new(), span: DUMMY_SP }; </del> path_span = self.span.to(self.span); <ins> path = ast::Path { segments: Vec::new(), span: path_span }; </ins> } // See doc comment for `unmatched_angle_bracket_count`.

root: yup-oauth2 - 360 detected crates which regressed due to this; cc <details</details
I think this might have been caused by
I can confirm that is the cause. Patch coming shortly.


Question: res } <ins> // Clears (and restores) the `in_scope_lifetimes` field. Used when // visiting nested items, which never inherit in-scope lifetimes // from their surrounding environment. fn without_in_scope_lifetime_defs<T>( &mut self, f: impl FnOnce(&mut LoweringContext<'_>) -> T, ) -> T { let old_in_scope_lifetimes = std::mem::replace(&mut self.in_scope_lifetimes, vec![]); // this vector is only used when walking over impl headers, // input types, and the like, and should not be non-empty in // between items assert!(self.lifetimes_to_define.is_empty()); let res = f(self); assert!(self.in_scope_lifetimes.is_empty()); self.in_scope_lifetimes = old_in_scope_lifetimes; res } </ins> pub(super) fn lower_mod(&mut self, m: &Mod) -> hir::Mod { hir::Mod { inner: m.inner,

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


Question: } pub fn is(&self, mode: mode_t) -> bool { <del> self.mode & libc::S_IFMT == mode </del> <ins> self.masked() == mode } fn masked(&self) -> mode_t { self.mode & libc::S_IFMT </ins> } }

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


Question: <ins> error: pattern on wrong side of `@` --> $DIR/intersection-patterns.rs:13:9 | LL |         Some(x) @ y => {} |         -------^^^- |         |         | |         |         binding on the right, should be on the left |         pattern on the left, should be on the right |         help: switch the order: `y @ Some(x)` error: left-hand side of `@` must be a binding --> $DIR/intersection-patterns.rs:23:9 | LL |         Some(x) @ Some(y) => {} |         -------^^^------- |         |         | |         |         also a pattern |         interpreted as a pattern, not a binding | = note: bindings are `x`, `mut x`, `ref x`, and `ref mut x` error: pattern on wrong side of `@` --> $DIR/intersection-patterns.rs:32:9 | LL |         1 ..= 5 @ e => {} |         -------^^^- |         |         | |         |         binding on the right, should be on the left |         pattern on the left, should be on the right |         help: switch the order: `e @ 1 ..=5` error: aborting due to 3 previous errors </ins>

The compiler could suggest that identifier must precede the pattern in the following code: playpen link: Current error message: It could be improved as:
modify labels: A-diagnostics C-feature-request T-compiler
So what happens after is that we've parsed a and then follows which is not a valid token after a parsed . To fix this we can, after having parsed in , check if follows and then emit appropriate suggestions. We will need to use some heuristics to figure out what the user wants based on the structure of . Some of the suggestions would be and some not. cc


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

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: def::DefVariant(_, variant_id, _) => { for field in fields { self.check_field(expr.span, variant_id, <del> NamedField(field.ident.node)); </del> <ins> NamedField(field.ident.node.name)); </ins> } } _ => self.tcx.sess.span_bug(expr.span,

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: def::DefVariant(_, variant_id, _) => { for field in fields { self.check_field(expr.span, variant_id, <del> NamedField(field.ident.node)); </del> <ins> NamedField(field.ident.node.name)); </ins> } } _ => self.tcx.sess.span_bug(expr.span,

, 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: def::DefVariant(_, variant_id, _) => { for field in fields { self.check_field(expr.span, variant_id, <del> NamedField(field.ident.node)); </del> <ins> NamedField(field.ident.node.name)); </ins> } } _ => self.tcx.sess.span_bug(expr.span,

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: def::DefVariant(_, variant_id, _) => { for field in fields { self.check_field(expr.span, variant_id, <del> NamedField(field.ident.node)); </del> <ins> NamedField(field.ident.node.name)); </ins> } } _ => self.tcx.sess.span_bug(expr.span,

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: def::DefVariant(_, variant_id, _) => { for field in fields { self.check_field(expr.span, variant_id, <del> NamedField(field.ident.node)); </del> <ins> NamedField(field.ident.node.name)); </ins> } } _ => self.tcx.sess.span_bug(expr.span,

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: self.opts.debugging_opts.print_enum_sizes } pub fn nonzeroing_move_hints(&self) -> bool { <del> !self.opts.debugging_opts.disable_nonzeroing_move_hints </del> <ins> self.opts.debugging_opts.enable_nonzeroing_move_hints </ins> } pub fn sysroot<'a>(&'a self) -> &'a Path { match self.opts.maybe_sysroot {

It looks like that when a local variable is initialized in a loop and dropped in the same loop, the stack local drop flag for that local isn't reinitialized to "not dropped" when the loop runs after the first time. Concretely, this test passes on stable and fails on nightly right now: cc
Interestingly this slight variation on the above code does drop twice as expected:


Question: format!("*{}", code) }; return Some(( <del> sp, </del> <ins> expr.span, </ins> message, suggestion, Applicability::MachineApplicable,

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: I expected that the help text would give syntactically correct code, or that there would be no help text. Instead, this happened: The provided code snippet is not valid - it tries to deference the else-block, which is impossible. Better would be to put the inside the else-block. <!-- 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. --: Also occurs on stable, 1.50.0. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim I have a fix for this bug + an improvement. Gotta got for now but will submit the PR later today.


Question: // Encode the command and arguments in a command line string such // that the spawned process may recover them using CommandLineToArgvW. let mut cmd: Vec<u16> = Vec::new(); <ins> // CreateFileW has special handling for .bat and .cmd files, which means we // need to add an extra pair of quotes surrounding the whole command line // so they are properly passed on to the script. // See issue #91991. let is_batch_file = Path::new(prog) .extension() .map(|ext| ext.eq_ignore_ascii_case("cmd") || ext.eq_ignore_ascii_case("bat")) .unwrap_or(false); if is_batch_file { cmd.push(b'"' as u16); } </ins> // Always quote the program name so CreateProcess doesn't interpret args as // part of the name if the binary wasn't found first time. append_arg(&mut cmd, prog, Quote::Always)?;

I tried this code: I expected to see this happen: Instead, this happened: This is caused by different quote handling. The first (correct) command line for the spawned process (as observed by ) is: The broken one is: The command for must be in additional set of quotes, as the first and last one are stripped. It works when there are no spaces in the arguments due to the exception rule, see Stable. It worked up until nightly-2021-11-20 nightly-2021-11-21 modify labels: +regression-from-stable-to-nightly -regression-untriaged
This is caused by Rust now handling finding the exe to run itself (for security reasons). The fix here would be. as you say, to detect or extensions and add the extra quotes. The underlying function call here is . As the documentation says, this can only be used to run files. However, an undocumented feature of is that it will do this for us if given a or file. Previously we used to leave the argument blank and let it guess the right application from the argument. So apparently it would fill in for the application name and add plus the extra quotes to . But now that we do fill in the ourselves, it will still change to and add to but evidentially doesn't add the extra quotes. Thus we need to do this ourselves.
That seems reasonable; could you or someone on the Windows team submit a PR adding the requisite quoting (since quoting is hard to get right)?
Oops, sorry! I had a PR lined up but forgot to submit.


Question: <ins> // revisions: explicit implicit //[implicit] check-pass #![forbid(coherence_leak_check)] #![feature(negative_impls, with_negative_coherence)] pub trait Marker {} #[cfg(implicit)] impl<T: ?Sized> !Marker for &T {} #[cfg(explicit)] impl<'a, T: ?Sized + 'a> !Marker for &'a T {} trait FnMarker {} // Unifying these two impls below results in a `T: '!0` obligation // that we shouldn't need to care about. Ideally, we'd treat that // as an assumption when proving `&'!0 T: Marker`... impl<T: ?Sized + Marker> FnMarker for fn(T) {} impl<T: ?Sized> FnMarker for fn(&T) {} //[explicit]~^ ERROR conflicting implementations of trait `FnMarker` for type `fn(&_)` //[explicit]~| WARN this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! fn main() {} </ins>

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. -- I expected to see this happen: Compiles successfully Instead, this happened: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: label A-coherence F-negative_impls requires-nightly T-compiler
I'll look into it


Question: // on the GAT itself. for (region_b, region_b_idx) in &regions { // Again, skip `'static` because it outlives everything. Also, we trivially <del> // know that a region outlives itself. if ty::ReStatic == **region_b || region_a == region_b { </del> <ins> // know that a region outlives itself. Also ignore `ReError`, to avoid // knock-down errors. if matches!(**region_b, ty::ReStatic | ty::ReError(_)) || region_a == region_b { </ins> continue; } if region_known_to_outlive(

<!-- 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


Question: 35 |     #[unstable = "1200"] impl S { } |     ^^^^^^^^^^^^^^^^^^^^ <del> error: aborting due to 9 previous errors </del> <ins> error: aborting due to 8 previous errors </ins>

Minimal example: Error message (ran in playground): Tested on nightly as well ()
Related:
twice without checking the return value. Modify it to return and check where it is being called ether both calls have returned an (cancel one, emit the other, return ), wether only one was created (emit it, return ) or none has (return ).
I'll fix this, thanks for the instruction!
I would happily have a go at this, if that's ok with
Sure go for it!
have you had time to work on this? If not could I give it a go? :)
I totally thought I was going to have time, but I had a crazy week at work this week. Go ahead and give it a go :) I'll find another bug to work on when I definitely have time
It looks like the PR to fix this was merged but has a few dangling threads. There seems to be some confusion about short-circuiting functionality and the necessity of the patch and also the error count still reads 2 rather than 1. Should a new issue be opened with those issues and this issue closed?


Question: "byteorder", "cargo_metadata 0.9.1", "colored", <del> "compiletest_rs", </del> <ins> "compiletest_rs 0.4.0", </ins> "directories", "env_logger 0.7.1", "getrandom",

Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver 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! And nominating for compiler team prioritization.


Question: let break_x = self.with_loop_scope(loop_node_id, move |this| { let expr_break = hir::ExprKind::Break(this.lower_loop_destination(None), Some(x_expr)); <del> this.arena.alloc(this.expr(span, expr_break, ThinVec::new())) </del> <ins> this.arena.alloc(this.expr(gen_future_span, expr_break, ThinVec::new())) </ins> }); self.arm(ready_pat, break_x) };

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


Question: use std::mem; use crate::errors::{ <del> ChangeFieldsToBeOfUnitType, IgnoredDerivedImpls, MultipleDeadCodes, ParentInfo, UselessAssignment, </del> <ins> ChangeFields, IgnoredDerivedImpls, MultipleDeadCodes, ParentInfo, UselessAssignment, </ins> }; // Any local node that may call something in its body block should be

The idea of changing a field to unit type to preserve field numbering makes sense for fields in the middle of a tuple. However, if the unused field is at the end, or it's the only field, then deleting it won't affect field numbering of any other field. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim


Question: // A rest pattern `..`. self.bump(); // `..` PatKind::Rest <ins> } else if self.check(&token::DotDotDot) && !self.is_pat_range_end_start(1) { self.recover_dotdotdot_rest_pat(lo) </ins> } else if let Some(form) = self.parse_range_end() { self.parse_pat_range_to(form)? // `..=X`, `...X`, or `..X`. } else if self.eat_keyword(kw::Underscore) {

` The problem here is that we have instead of The compiler however points towards in the error message instead of the superfluous : Fun fact: when using four dots , it correctly points at the last dot :) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
seems like a simple issue to fix. If I were to take a shot at fixing this, where would I start?
Mentoring instructions: Add a branch after this one... instead of , check that . This should be interpreted as a as in the previous branch, but an error should also be emitted. (Add the code for error emission in a separate method, with an appropriate , where the span of the is replaced with . See for an example on emitting an error with a suggestion.)
Sure thing! Will get to it right after work. Thanks for the pointers.
assign


Question: unsafe { let mut fds = [0, 0]; <del> // Like above, see if we can set cloexec atomically #[cfg(target_os = "linux")] { match cvt(libc::socketpair(fam, ty | libc::SOCK_CLOEXEC, 0, fds.as_mut_ptr())) { Ok(_) => { return Ok((Socket(FileDesc::new(fds[0])), Socket(FileDesc::new(fds[1])))); } Err(ref e) if e.raw_os_error() == Some(libc::EINVAL) => {} Err(e) => return Err(e), </del> <ins> cfg_if::cfg_if! { if #[cfg(target_os = "linux")] { // Like above, set cloexec atomically cvt(libc::socketpair(fam, ty | libc::SOCK_CLOEXEC, 0, fds.as_mut_ptr()))?; Ok((Socket(FileDesc::new(fds[0])), Socket(FileDesc::new(fds[1])))) } else { cvt(libc::socketpair(fam, ty, 0, fds.as_mut_ptr()))?; let a = FileDesc::new(fds[0]); let b = FileDesc::new(fds[1]); a.set_cloexec()?; b.set_cloexec()?; Ok((Socket(a), Socket(b))) </ins> } } <del> cvt(libc::socketpair(fam, ty, 0, fds.as_mut_ptr()))?; let a = FileDesc::new(fds[0]); let b = FileDesc::new(fds[1]); a.set_cloexec()?; b.set_cloexec()?; Ok((Socket(a), Socket(b))) </del> } }

Good question! There are 6 workarounds in for older Linux versions (that I could find). Increasing the minimum version to 2.6.32 (aka 3rd Kernel LTS, aka RHEL 6) would fix 5 of them. Code links are inline: uses the flag with  (mentioned above, in 2.6.23) uses with  ( in 2.6.24, there is also the mention of a bug occuring on "some linux kernel at some point") uses  to atomically set the flag on the pipe fds ( in 2.6.27) uses with  ( in 2.6.27) uses  to permit use of ( in 2.6.28) ~ ( in 4.5, not fixed by this proposal)~ As you can see, the workarounds fixed by this proposal all have a similar flavor. Originally posted by in
Kernel updated in .
As noted, needs a much newer kernel 4.5, so we'll still need that fallback. But all the stuff should be ok to assume available now.
The new minimal version is 2.6.27 from what I can see, so "Socket::accept uses accept4(2) to permit use of SOCK_CLOEXEC" still needs a fallback, right?
The builder is using 2.6.32 headers, so I would call that our new minimum.
Ah right; I am actually not sure where I got the 27 from...
The title of suggested 2.6.27, but we went a little higher to match the actual distros in use.
I know this is ancient history, but do you recall the problem with ? You introduced that comment about "some kernel" in , and you were the last to update it in . If the problem kernels were before 2.6.32, then I'd like to clean that up now.
Just digging in kernel history, I did find one hiccup in , but that bug was introduced and resolved during the 3.7 development cycle, not in a release.
IIRC we just mirrored what musl did at the time, which looks like it : Looks like the original mailing list thread is gone and there's no comments in the musl source, and I don't recall what happened here. I suspect it would be safe to remove those workarounds and just assume works one the first try until someone says differently.


Question: <ins> error[E0309]: the parameter type `T` may not live long enough --> $DIR/min-choice-reject-ambiguous.rs:17:5 | LL |     type_test::<'_, T>() // This should pass if we pick 'b. |     ^^^^^^^^^^^^^^^^^^ ...so that the type `T` will meet its required lifetime bounds | help: consider adding an explicit lifetime bound... | LL |     T: 'b + 'a, |           ++++ error[E0309]: the parameter type `T` may not live long enough --> $DIR/min-choice-reject-ambiguous.rs:28:5 | LL |     type_test::<'_, T>() // This should pass if we pick 'c. |     ^^^^^^^^^^^^^^^^^^ ...so that the type `T` will meet its required lifetime bounds | help: consider adding an explicit lifetime bound... | LL |     T: 'c + 'a, |           ++++ error[E0700]: hidden type for `impl Cap<'b> + Cap<'c>` captures lifetime that does not appear in bounds --> $DIR/min-choice-reject-ambiguous.rs:39:5 | LL | fn test_ambiguous<'a, 'b, 'c>(s: &'a u8) -> impl Cap<'b> + Cap<'c> |                   -- hidden type `&'a u8` captures the lifetime `'a` as defined here ... LL |     s |     ^ | help: to declare that `impl Cap<'b> + Cap<'c>` captures `'a`, you can add an explicit `'a` lifetime bound | LL | fn test_ambiguous<'a, 'b, 'c>(s: &'a u8) -> impl Cap<'b> + Cap<'c> + 'a |                                                                    ++++ error: aborting due to 3 previous errors Some errors have detailed explanations: E0309, E0700. For more information about an error, try `rustc --explain E0309`. </ins>

The following code should pass regardless of the declaration order of lifetimes: This is related to but it's different in that we do have a lower bound region, , but we fail to recognize that because , which is responsible for calculating from , assumes that the outlive relation is a total order, which is not true. Here is the graph of : ! So we need an efficient algorithm that works for partial order relations, but the one that comes to mind is . The perf may not be really important here but I'm curious to see the alternatives. label C-bug T-compiler A-borrow-checker E-mentor E-help-wanted <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Here is the code of concern The code should calculate the from a set of universal regions (). The relations are encoded in and are guaranteed to be transitive and reflexive. The relation graph may have cycles and can be sparse. The goal here is to find a unique minimum choice that is known to be outlived by all other regions. If none can be found, the function returns . Regions that have cycles between them are considered equivalent so we can pick either one of them as a unique choice. e.g. , we can pick either one of as a minimum choice.


Question: <ins> // This is a non-regression test for issue #117146, where NLL and `-Zpolonius=next` computed // different loan scopes when a region flowed into an SCC whose representative was an existential // region. // revisions: nll polonius // [polonius] compile-flags: -Zpolonius=next fn main() { let a = (); let b = |_| &a; //[nll]~^ ERROR `a` does not live long enough //[polonius]~^^ ERROR `a` does not live long enough bad(&b); //[nll]~^ ERROR implementation of `Fn` //[nll]~| ERROR implementation of `FnOnce` //[polonius]~^^^ ERROR implementation of `Fn` //[polonius]~| ERROR implementation of `FnOnce` } fn bad<F: Fn(&()) -> &()>(_: F) {} </ins>

File: snippet: 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
cc removing the println macro from around the match avoids the ice :thinking:
Fun :)
A more minimal version would be:


Question: Some((ident.name, ns)), ) } <ins> /// Construct the list of in-scope lifetime parameters for async lowering. /// We include all lifetime parameters, either named or "Fresh". /// The order of those parameters does not matter, as long as it is /// deterministic. fn record_lifetime_params_for_async( &mut self, fn_id: NodeId, async_node_id: Option<(NodeId, Span)>, ) { if let Some((async_node_id, _)) = async_node_id { let mut extra_lifetime_params = self.r.extra_lifetime_params_map.get(&fn_id).cloned().unwrap_or_default(); for rib in self.lifetime_ribs.iter().rev() { extra_lifetime_params.extend( rib.bindings.iter().map(|(&ident, &(node_id, res))| (ident, node_id, res)), ); match rib.kind { LifetimeRibKind::Item => break, LifetimeRibKind::AnonymousCreateParameter { binder, .. } => { if let Some(earlier_fresh) = self.r.extra_lifetime_params_map.get(&binder) { extra_lifetime_params.extend(earlier_fresh); } } _ => {} } } self.r.extra_lifetime_params_map.insert(async_node_id, extra_lifetime_params); } } </ins> } struct LifetimeCountVisitor<'a, 'b> {

Example: yields <details<summaryBacktrace</summary</details
cc and
This has to do with late-bound regions and RPITITs. I have a fix, but it's probably not right nor is it cleaned up much. I'll put it up for scrutiny soon though.
Actually nvm, it was a silly little resolver bug.
label +I-ICE +C-bug


Question: Some((ident.name, ns)), ) } <ins> /// Construct the list of in-scope lifetime parameters for async lowering. /// We include all lifetime parameters, either named or "Fresh". /// The order of those parameters does not matter, as long as it is /// deterministic. fn record_lifetime_params_for_async( &mut self, fn_id: NodeId, async_node_id: Option<(NodeId, Span)>, ) { if let Some((async_node_id, _)) = async_node_id { let mut extra_lifetime_params = self.r.extra_lifetime_params_map.get(&fn_id).cloned().unwrap_or_default(); for rib in self.lifetime_ribs.iter().rev() { extra_lifetime_params.extend( rib.bindings.iter().map(|(&ident, &(node_id, res))| (ident, node_id, res)), ); match rib.kind { LifetimeRibKind::Item => break, LifetimeRibKind::AnonymousCreateParameter { binder, .. } => { if let Some(earlier_fresh) = self.r.extra_lifetime_params_map.get(&binder) { extra_lifetime_params.extend(earlier_fresh); } } _ => {} } } self.r.extra_lifetime_params_map.insert(async_node_id, extra_lifetime_params); } } </ins> } struct LifetimeCountVisitor<'a, 'b> {

I'm seeing an internal compiler error on the following input (found by ):
Report from : regressed nightly: nightly-2020-02-07
It looks like caused the regression. (The error happens at but not at .) cc
The specific commit where the error starts happening is .
triage: P-high. Removing nomination. Added regression stable-to-nightly tag.
Fixed by


Question: fn make_items(mut self: Box<ExpandResult<'a>>) -> Option<SmallVector<P<ast::Item>>> { let mut ret = SmallVector::zero(); <del> loop { </del> <ins> while self.p.token != token::Eof { </ins> match self.p.parse_item_with_outer_attributes() { Some(item) => ret.push(item), <del> None => break </del> <ins> None => self.p.span_fatal( self.p.span, &format!("expected item, found `{}`", self.p.this_token_to_string())[] ) </ins> } } Some(ret)

Testcase: : : Output: Should output, instead, the parse errors from . Probably misplacing the diagnostic emitter somehow, when creating the nested parser for the included source, and doesn't have an .
(I suspect this is an easy fix, but am not quite sure)


Question: self.tcx().mk_region(ReScope(lub)) } <del> (&ReEarlyBound(_), &ReEarlyBound(_) | &ReFree(_)) | (&ReFree(_), &ReEarlyBound(_) | &ReFree(_)) => { </del> <ins> (&ReEarlyBound(_) | &ReFree(_), &ReEarlyBound(_) | &ReFree(_)) => { </ins> self.region_rels.lub_free_regions(a, b) }

() Errors: Backtrace: modify labels: +I-hang +T-compiler +C-bug +A-lifetimes
somewhat minimized: To replicate this I needed: async two other arguments by ref at least one arg must not be bound to , compiles quickly the problematic argument must be contain an indirection: compiles fine. and also freeze. and a trait object containing at least one non marker trait explicitly bound to . and are both ok
repro is a regression in 1.43. It compiles immediately with 1.39 through 1.42.
I am currently bisecting this using
regression in modify labels: -E-needs-bisection
FYI who had context on .


Question: <ins> error[E0277]: the trait bound `K: Hash` is not satisfied --> $DIR/bad-index-due-to-nested.rs:20:5 | LL |     map[k] |     ^^^ the trait `Hash` is not implemented for `K` | note: required by a bound in `<HashMap<K, V> as Index<&K>>` --> $DIR/bad-index-due-to-nested.rs:9:8 | LL |     K: Hash, |        ^^^^ required by this bound in `<HashMap<K, V> as Index<&K>>` help: consider restricting type parameter `K` | LL | fn index<'a, K: std::hash::Hash, V>(map: &'a HashMap<K, V>, k: K) -> &'a V { |               +++++++++++++++++ error[E0277]: the trait bound `V: Copy` is not satisfied --> $DIR/bad-index-due-to-nested.rs:20:5 | LL |     map[k] |     ^^^ the trait `Copy` is not implemented for `V` | note: required by a bound in `<HashMap<K, V> as Index<&K>>` --> $DIR/bad-index-due-to-nested.rs:10:8 | LL |     V: Copy, |        ^^^^ required by this bound in `<HashMap<K, V> as Index<&K>>` help: consider restricting type parameter `V` | LL | fn index<'a, K, V: std::marker::Copy>(map: &'a HashMap<K, V>, k: K) -> &'a V { |                  +++++++++++++++++++ error[E0308]: mismatched types --> $DIR/bad-index-due-to-nested.rs:20:9 | LL | fn index<'a, K, V>(map: &'a HashMap<K, V>, k: K) -> &'a V { |              - this type parameter LL |     map[k] |         ^ |         | |         expected `&K`, found type parameter `K` |         help: consider borrowing here: `&k` | = note:   expected reference `&K` found type parameter `K` error[E0308]: mismatched types --> $DIR/bad-index-due-to-nested.rs:20:5 | LL | fn index<'a, K, V>(map: &'a HashMap<K, V>, k: K) -> &'a V { |                 - this type parameter               ----- expected `&'a V` because of return type LL |     map[k] |     ^^^^^^ |     | |     expected `&V`, found type parameter `V` |     help: consider borrowing here: `&map[k]` | = note:   expected reference `&'a V` found type parameter `V` error: aborting due to 4 previous errors Some errors have detailed explanations: E0277, E0308. For more information about an error, try `rustc --explain E0277`. </ins>

I tried this code (): I expected to see this happen: rustc outputs an error saying that I need to add the and traits on . Instead, this happened: which is jarring to see, and unhelpful, because HashMap does support Index, but only with particular trait bounds on . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The reduced case: works as expected, perhaps it is caused when the implementer is not from the local crate?
claim


Question: <ins> // #124563 use std::marker::PhantomData; pub trait Trait {} pub trait Foo { type Trait: Trait; type Bar: Bar; fn foo(&mut self); } pub struct FooImpl<'a, 'b, A: Trait>(PhantomData<&'a &'b A>); impl<'a, 'b, T> Foo for FooImpl<'a, 'b, T> where T: Trait, { type Trait = T; type Bar = BarImpl<'a, 'b, T>; //~ ERROR lifetime bound not satisfied fn foo(&mut self) { self.enter_scope(|ctx| { //~ ERROR lifetime may not live long enough BarImpl(ctx); //~ ERROR lifetime may not live long enough }); } } impl<'a, 'b, T> FooImpl<'a, 'b, T> where T: Trait, { fn enter_scope(&mut self, _scope: impl FnOnce(&mut Self)) {} } pub trait Bar { type Foo: Foo; } pub struct BarImpl<'a, 'b, T: Trait>(&'b mut FooImpl<'a, 'b, T>); impl<'a, 'b, T> Bar for BarImpl<'a, 'b, T> where T: Trait, { type Foo = FooImpl<'a, 'b, T>; } fn main() {} </ins>

<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'expected region for ('a//0) but found Type(&'{erased} mut FooImpl<'{erased}, '{erased}, T/) when instantiating args=[&'{erased} mut FooImpl<'{erased}, '{erased}, T/, '?27, ?2t, Closure(DefId(0:22 ~ a[a197]::{impl}::foo::{closure}), ['{erased}, '{erased}, T/, i32, Binder(fn((&ReLateParam(DefId(0:22 ~ a[a197]::{impl}::foo::{closure}), BrAnon) mut FooImpl<'{erased}, '{erased}, T/,)), []), ()])]'', 'thread 'rustc' panicked at 'expected region for ('a//0) but found Type(&'{erased} mut FooImpl<'{erased}, '{erased}, T/) when instantiating args=[&'{erased} mut FooImpl<'{erased}, '{erased}, T/, '?27, ?2t, Closure(DefId(0:22 ~ a[a197]::{impl}::foo::{closure}), ['{erased}, '{erased}, T/, i32, Binder(fn((&ReLateParam(DefId(0:22 ~ a[a197]::{impl}::foo::{closure}), BrAnon) mut FooImpl<'{erased}, '{erased}, T/,)), []), ()])]'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [mirborrowck] borrow-checking [mirborrowck] borrow-checking --
ICEs on nightly and beta, but not on stable. Minimized further: <details<summaryProgram output</summary</details
The ICE is another one from , cc
Still reproduces on 1.81.0-nightly (2024-06-13 ) -E-needs-test
I'll look into it later today.


Question: <ins> // #124563 use std::marker::PhantomData; pub trait Trait {} pub trait Foo { type Trait: Trait; type Bar: Bar; fn foo(&mut self); } pub struct FooImpl<'a, 'b, A: Trait>(PhantomData<&'a &'b A>); impl<'a, 'b, T> Foo for FooImpl<'a, 'b, T> where T: Trait, { type Trait = T; type Bar = BarImpl<'a, 'b, T>; //~ ERROR lifetime bound not satisfied fn foo(&mut self) { self.enter_scope(|ctx| { //~ ERROR lifetime may not live long enough BarImpl(ctx); //~ ERROR lifetime may not live long enough }); } } impl<'a, 'b, T> FooImpl<'a, 'b, T> where T: Trait, { fn enter_scope(&mut self, _scope: impl FnOnce(&mut Self)) {} } pub trait Bar { type Foo: Foo; } pub struct BarImpl<'a, 'b, T: Trait>(&'b mut FooImpl<'a, 'b, T>); impl<'a, 'b, T> Bar for BarImpl<'a, 'b, T> where T: Trait, { type Foo = FooImpl<'a, 'b, T>; } fn main() {} </ins>

: <details<summary<strongBacktrace</strong</summary<p</p</details
This looks to be a recent regression from cc and is on beta 1.79, but is just in diagnostics.


Question: <ins> // This test is a regression test for #34792 // check-pass pub struct A; pub struct B; pub trait Foo { type T: PartialEq<A> + PartialEq<B>; } pub fn generic<F: Foo>(t: F::T, a: A, b: B) -> bool { t == a && t == b } pub fn main() {} </ins>

rustc 1.12.0-nightly ( 2016-07-10) Changing the order of bounds in the associated type declaration changes which causes a spurious "mismatched types" error. Using UFCS works around the issue: The same issue exists with bounds like to compare with itself as well as another type. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cf.
Looks like this is caused by on the set of bounds from the trait, but that is just find the first one (in the order they are internally stored), this needs to filter and produce a vector of bounds or something similar. cc
Update: using filter and then calling on all matching bounds does not fix this issue.
I believe your problem is . Right now it works fine because the above would trigger for vs or vs . However, it's incorrect with your changes as is dropped in favor of even if and are not equal. The correct form would be more like this:
I guess that you didn't just call , but are also packaging up the specific bound that was matched? Anyway, not having seen the full diff, the general direction of these changes make sense to me.
Related:
triage: P-medium
Triage: :
This is fixed on current master. Should be closed.
I would like to work on this issue if its still relevant?
As mentioned the original code now compiles: Closing as there doesn’t seem to be anything left to do here.
do we have any regression test? I couldn't see any.
Oh good point. Sorry I missed the label. Yes, feel free to work on adding a regression test!
claim


Question: return; } <ins> // #90113: Do not count an inaccessible reexported item as a candidate. if let NameBindingKind::Import { binding, .. } = name_binding.kind { if this.is_accessible_from(binding.vis, parent_scope.module) && !this.is_accessible_from(name_binding.vis, parent_scope.module) { return; } } </ins> // collect results based on the filter function // avoid suggesting anything from the same module in which we are resolving if ident.name == lookup_ident.name

Bisected to a rollup, but I think it's very likely to be . cc searched nightlies: from nightly-2021-10-01 to nightly-2021-10-19 regressed nightly: nightly-2021-10-02 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
The old suggestion was actually incorrect because it suggested , which is a private import. However, the new error is "more incorrect" IMO since it says something confusing (and incorrect).
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium


Question: hir_typeck_convert_to_str = try converting the passed type into a `&str` <ins> hir_typeck_ctor_is_private = tuple struct constructor `{$def}` is private </ins> hir_typeck_expected_default_return_type = expected `()` because of default return type hir_typeck_expected_return_type = expected `{$expected}` because of return type

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


Question: <ins> //@ run-pass // Tests against a regression surfaced by crater in https://github.com/rust-lang/rust/issues/125193 // Unwind Safety is not a very coherent concept, but we'd prefer no regressions until we kibosh it // and this is an unstable feature anyways sooo... use std::panic::UnwindSafe; use std::task::Context; fn unwind_safe<T: UnwindSafe>() {} fn main() { unwind_safe::<Context<'_>>(); // test UnwindSafe unwind_safe::<&Context<'_>>(); // test RefUnwindSafe } </ins>

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: <ins> #![feature(half_open_range_patterns)] fn main() { match [1, 2] { [a.., a] => {} //~ ERROR cannot find value `a` in this scope } } </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. --error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: rustc 1.57.0 ( 2021-11-29) running on x8664-unknown-linux-gnu note: compiler flags: -C embed-bitcode=no -C debuginfo=2 -C incremental --crate-type bin note: some of the compiler flags provided by cargo are hidden query stack during panic: end of query stack <!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
reduced:
Minimized this a tiny bit further, and I have a detailed explanation why this occurs: So this bug first starts going wrong in late resolution. Specifically, , we define the as a binding when we see the second element (ident subpattern) of the slice pattern, and then bind it later when we walk thru the (expression!) in the first slice pattern element. Essentially, since we treat as being defined here: and then resolve that as the path for we reach a situation where we expect a variable to have been defined before it has been lowered in HIR, which leads to the ICE later on, since we expect to have lowered that path element.
Wonder how difficult it would be to make have subpatterns instead of subexpressions... edit: wouldn't help, see below..
Actually, I don't think fixing this just for ranges is sufficient. I can reproduce this same issue with this: Maybe I can just delay this panic as a span bug, since we're always gonna error out anyways. I think I would ideally like to fix this by making sure we separate bindings in patterns from affecting resolution for expressions in patterns. edit: Ended up fixing it the right way.
claim


Question: //! The various pretty-printing routines. <ins> use crate::session_diagnostics::UnprettyDumpFail; </ins> use rustc_ast as ast; use rustc_ast_pretty::pprust; use rustc_errors::ErrorGuaranteed;

If you , you get a normal error like but if you try to at the same time: rust will panic which is a bit weird. Mayne that panic should be demoted to a regular error? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
To reproduce: `
claim


Question: _ => unreachable!(), }; <del> write_or_print(&out, ofile); </del> <ins> write_or_print(&out, ofile, tcx.sess); </ins> } // In an ideal world, this would be a public function called by the driver after


Question: <ins> // check-pass #![feature(generic_associated_types)] pub trait Foo { type Assoc<'c>; fn function() -> for<'x> fn(Self::Assoc<'x>); } fn main() {} </ins>

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Slightly minimized:
I understand the issue here, and have a solution but it might not be optimal. claim


Question: // Confirm the `type Output: Sized;` bound that is present on `FnOnce` let cause = obligation.derived_cause(BuiltinDerivedObligation); <del> // The binder on the Fn obligation is "less" important than the one on // the signature, as evidenced by how we treat it during projection. // The safe thing to do here is to liberate it, though, which should // have no worse effect than skipping the binder here. let liberated_fn_ty = self.infcx.replace_bound_vars_with_placeholders(obligation.predicate.rebind(self_ty)); let output_ty = self .infcx .replace_bound_vars_with_placeholders(liberated_fn_ty.fn_sig(self.tcx()).output()); </del> <ins> let output_ty = self.infcx.replace_bound_vars_with_placeholders(sig.output()); </ins> let output_ty = normalize_with_depth_to( self, obligation.param_env,

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: use syntax_pos::symbol::Symbol; use rustc::session::Session; use rustc::session::config::PrintRequest; <ins> use rustc_data_structures::fx::FxHashSet; </ins> use rustc_target::spec::{MergeFunctions, PanicStrategy}; use libc::c_int; use std::ffi::CString;

LLVM's MergeFunctions introduces aliases which can trigger a bug in macOS's linker when compiling with ThinLTO: For this reason Firefox has to be built with a patched version of when compiling with xLTO. Since the bug in question is pretty nasty (the above example shows a program just returning a different value with no indication that anything is wrong), we should probably try to not trigger it. Right now, however, it seems that one cannot even turn the MergeFunctions pass off in stable Rust. (I wonder if the pass should even be disabled by default on macOS?) cc & (this seems related to )
Is it a mergefunc bug or a ThinLTO bug? Can it be triggered without ThinLTO? If not, I would rather not blindly disable it on macOS, at least not when ThinLTO isn't enabled.
It's not a bug in mergefunc. It might not even be a bug in ThinLTO. It's just that mergefunc is the only thing in that generates symbol aliases in LLVM IR, and these are what can lead to "miscompilations" when using the macOS linker.
Has the ld64 bug been reported somewhere?
We could use to prevent the pass from emitting aliases on macOS, AFAIK.
This is already supported via either or in the target spec.
Do you mean that the test case also fails with enabled, or that we already have a knob to disable them?
Answering my own question, we already have a knob for that.
Which was because .
As and point to there is the unstable option which I've only tested on nightly. I guess there could be a stabilized option, but maybe what you really want to do is to patch the x8664 macos target definition (I believe this is the correct one: ).
Yes, I've been told that it has been reported to Apple. On nightly, one can already control the mergefunc pass. On stable, however, one is stuck with the default behavior. That's what this issue is mostly about.
just want to double-check my understanding: I would have thought one could use the options and to override the set of passes, even on the stable channel. Am I incorrect about this? (If I am correct, I nonetheless will admit that this is an ugly (and very fragile) method to opt out of the MergeFunctions pass)
I think that is correct, yes.


Question: use syntax_pos::symbol::Symbol; use rustc::session::Session; use rustc::session::config::PrintRequest; <ins> use rustc_data_structures::fx::FxHashSet; </ins> use rustc_target::spec::{MergeFunctions, PanicStrategy}; use libc::c_int; use std::ffi::CString;

It would be rather hard, however, to re-create the set of passes meaningfully, I suspect. Even the compiler delegates this to methods within LLVM, iirc.
I think using might work on stable.
So did that help,
Unfortunately not. Specifying this gives me:


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. // aux-build:issue-11908-1.rs // ignore-android this test is incompatible with the android test runner // error-pattern: multiple dylib candidates for `collections` found // This test ensures that if you have the same rlib or dylib at two locations // in the same path that you don't hit an assertion in the compiler. // // Note that this relies on `libcollections` to be in the path somewhere else, // and then our aux-built libraries will collide with libcollections (they have // the same version listed) extern crate collections; fn main() {} </ins>

Built glfw-rs using rust 0.10-pre. When referencing this crate in another source file and building, I get error: internal compiler error: unexpected failure This message reflects a bug in the Rust compiler. We would appreciate a bug report: note: the compiler hit an unexpected failure path. this is a bug Ok(task 'rustc' failed at 'assertion failed: ()', ) This is on OSX 10.9: rustc 0.10-pre ( 2014-02-18 10:16:48 -0800) host: x8664-apple-darwin
This means that you've got two versions of the same lying around, and doesn't like having two versions. This will be fixed by , I just need to land it :(
I have just build the library for the first time, and I can only find one dylib for it on my system (next to the rlib, but I gues that shouldn't cause any problems). Is there another possibility for this error? Gesendet: Mittwoch, 19. Februar 2014 um 01:09 UhrVon: "Alex Crichton" : mozilla/rust hhildebr : Re: [rust] Compiler error when referencing crate "glfw-rs" () This means that you've got two versions of the same libglfw- lying around, and rustc doesn't like having two versions. This will be fixed by , I just need to land it :( — Reply to this email directly or view it on GitHub.
my reading of is that having a dylib and an rlib simultaneously is a problem.
Having a dylib and an rlib simultaneously should not be a problem, it is in fact quite common. Having 2 dylibs and 1 rlib or 2 rlibs and 1 dylib however is a problem.
sorry, my mistake in parsing the title of .
Yes, indeed, I had several identical dylibs, but it wasn't the glfw-rs.. there were rust libs in /usr/local/lib and /usr/local/lib/rustlib/... Thanks! Gesendet: Mittwoch, 19.


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. // aux-build:issue-11908-1.rs // ignore-android this test is incompatible with the android test runner // error-pattern: multiple dylib candidates for `collections` found // This test ensures that if you have the same rlib or dylib at two locations // in the same path that you don't hit an assertion in the compiler. // // Note that this relies on `libcollections` to be in the path somewhere else, // and then our aux-built libraries will collide with libcollections (they have // the same version listed) extern crate collections; fn main() {} </ins>

Februar 2014 um 17:15 UhrVon: "Alex Crichton" : mozilla/rust hhildebr : Re: [rust] Compiler error when referencing crate "glfw-rs" () Having a dylib and an rlib simultaneously should not be a problem, it is in fact quite common. Having 2 dylibs and 1 rlib or 2 rlibs and 1 dylib however is a problem. — Reply to this email directly or view it on GitHub.
so can we close this ticket now, in that case? Or do you want to wait for alexcrichton's patches to land, and see what things look like for you then?
Nono, the ticket can be closed for now. Thanks for your help! Gesendet: Mittwoch, 19. Februar 2014 um 21:30 UhrVon: "Felix S Klock II" : mozilla/rust hhildebr : Re: [rust] Compiler error when referencing crate "glfw-rs" () so can we close this ticket now, in that case? Or do you want to wait for alexcrichton's patches to land, and see what things look like for you then? — Reply to this email directly or view it on GitHub.


Question: <ins> error[E0284]: type annotations needed: cannot satisfy `<Bar as Foo>::T == ()` --> $DIR/coherence-constrained.rs:14:5 | LL |     async fn foo(&self) {} |     ^^^^^^^^^^^^^^^^^^^ cannot satisfy `<Bar as Foo>::T == ()` error[E0284]: type annotations needed: cannot satisfy `<Bar as Foo>::T == ()` --> $DIR/coherence-constrained.rs:22:5 | LL |     async fn foo(&self) {} |     ^^^^^^^^^^^^^^^^^^^ cannot satisfy `<Bar as Foo>::T == ()` error[E0119]: conflicting implementations of trait `Foo` for type `Bar` --> $DIR/coherence-constrained.rs:18:1 | LL | impl Foo for Bar { | ---------------- first implementation here ... LL | impl Foo for Bar { | ^^^^^^^^^^^^^^^^ conflicting implementation for `Bar` error: aborting due to 3 previous errors Some errors have detailed explanations: E0119, E0284. For more information about an error, try `rustc --explain E0119`. </ins>

No response No response No response
(for compiler people:) We could fix this by merging the impl WF and coherence checks into one compiler stage. I'll put up a PR and see what T-types thinks.
labels +AsyncAwait-Triaged We discussed this in a WG-async meeting and are deferring to the resolution suggested above. He noted that this is a fix to the diagnostics only. That fact that this is an error is correct.


Question: pub static G: fn() = G0; pub static H: &(dyn Fn() + Sync) = &h; pub static I: fn() = Helper(j).mk(); <ins> pub static K: fn() -> fn() = { #[inline(never)] fn k() {} #[inline(always)] || -> fn() { k } }; </ins> static X: u32 = 42; static G0: fn() = g;

Regression in ( cc modify labels: +regression-from-stable-to-stable -regression-untriaged
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Beta backport accepted as per compiler team . A backport PR will be authored by the release team at the end of the current development cycle. label +beta-accepted


Question: <ins> fn main() {} #[cfg(FALSE)] fn container() { const extern "Rust" PUT_ANYTHING_YOU_WANT_HERE bug() -> usize { 1 } //~^ ERROR expected `fn` //~| ERROR `const extern fn` definitions are unstable } </ins>

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


Question: } } <ins> #[doc(hidden)] #[stable(feature = "rust1", since = "1.0.0")] pub fn from_elem<T: Clone>(elem: T, n: usize) -> Vec<T> { unsafe { let mut v = Vec::with_capacity(n); let mut ptr = v.as_mut_ptr(); // Write all elements except the last one for i in 1..n { ptr::write(ptr, Clone::clone(&elem)); ptr = ptr.offset(1); v.set_len(i); // Increment the length in every step in case Clone::clone() panics } if n > 0 { // We can write the last element directly without cloning needlessly ptr::write(ptr, elem); v.set_len(n); } v } } </ins> //////////////////////////////////////////////////////////////////////////////// // Common trait implementations for Vec ////////////////////////////////////////////////////////////////////////////////

Super easy to implement for anyone interested. The implementation in the RFC is sound, although the new code should be abstracted out into a function that the macro calls for inline and macro-sanity reasons. The function needs to be marked as public/stable, but should otherwise be marked as #[doc(hidden)], as it is not intended to be called directly -- only by the macro.
Willing to mentor on details.
I'd like to give it a shot :)
By the way: The seems very sparse. If it's okay, I'd expand that a bit while I'm on it, or should that go into a seperate PR?
Yeah, that's totally reasonable to do at the same time!
Great! What would be the preferred place where to put the new function? I've it to as for now (currently compiling it)
Since it's supposed to only be used by the macro (and will be doc(hidden)), it makes sense to me to put it in Putting it in makes sense, too, though.
has a section labeled "Internal methods and functions" that seemed to fit well.


Question: <ins> #![feature(marker_trait_attr)] #[marker] trait Marker {} impl Marker for &'_ () {} //~ ERROR type annotations needed impl Marker for &'_ () {} //~ ERROR type annotations needed fn main() {} </ins>

Not sure if we have a test for the following and rust #![feature(markertraitattr)] #[marker] trait Marker {} impl Marker for &' () {} impl Marker for &' () {} If not, we need to add them, since they would be important for special casing during canonicalization. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I can help add this test if needed. (Did not rustbot claim so as to not remove lcnr from assignee)
Sure :) would help out if nothing else
assign Rageking8
Error: Parsing assign command in failed: ...' Rageking8' ''... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
assign
label +F-markertraitattr In case this needs to be indexed in the future.


Question: <ins> // astconv uses `FreshTy(0)` as a dummy `Self` type when instanciating trait objects. // This `FreshTy(0)` can leak into substs, causing ICEs in several places. // Using `save-analysis` triggers type-checking `f` that would be normally skipped // as `type_of` emitted an error. // // compile-flags: -Zsave-analysis </ins> #![feature(trait_alias)] pub trait SelfInput = Fn(&mut Self);

<!-- 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: /// Basic usage: /// /// ``` <del> /// #![feature(nonzero_leading_trailing_zeros)] </del> #[doc = concat!("let n = std::num::", stringify!($Ty), "::new(0b0101000).unwrap();")] /// /// assert_eq!(n.trailing_zeros(), 3); /// ``` <del> #[unstable(feature = "nonzero_leading_trailing_zeros", issue = "79143")] #[rustc_const_unstable(feature = "nonzero_leading_trailing_zeros", issue = "79143")] </del> <ins> #[stable(feature = "nonzero_leading_trailing_zeros", since = "1.53.0")] #[rustc_const_stable(feature = "nonzero_leading_trailing_zeros", since = "1.53.0")] </ins> #[inline] pub const fn trailing_zeros(self) -> u32 { // SAFETY: since `self` can not be zero it is safe to call cttz_nonzero

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


Question: pub fn hash_hir_item_like<F: FnOnce(&mut Self)>(&mut self, item_attrs: &[ast::Attribute], <ins> is_const: bool, </ins> f: F) { let prev_overflow_checks = self.overflow_checks_enabled; <del> if attr::contains_name(item_attrs, "rustc_inherit_overflow_checks") { </del> <ins> if is_const || attr::contains_name(item_attrs, "rustc_inherit_overflow_checks") { </ins> self.overflow_checks_enabled = true; } let prev_hash_node_ids = self.node_id_hashing_mode;

Found via rust-icci: https://travis- The commit history of the regex crate contains on changeset that only adds a comment which in turn leads to the body of a function being moved. This results in the update of the source location pointed to by a potential overflow panic message. This message is not updated properly in incremental mode: I have not found out yet why the change is not detected. HIR fingerprinting has special treatment of operations that can trigger overflows: There must be some kind of mismatch between when HIR fingerprinting thinks that an operation can panic and when we actually emit panic messages. This is another span-related papercut cc
Full IR files for reference:


Question: } /// Parse a 'for' .. 'in' expression ('for' token already eaten) <del> pub fn parse_for_expr(&mut self, opt_ident: Option<ast::Ident>) -> PResult<P<Expr>> { </del> <ins> pub fn parse_for_expr(&mut self, opt_ident: Option<ast::Ident>, span_lo: BytePos) -> PResult<P<Expr>> { </ins> // Parse: `for <src_pat> in <src_expr> <src_loop_block>` <del> let lo = self.last_span.lo; </del> let pat = try!(self.parse_pat_nopanic()); try!(self.expect_keyword(keywords::In)); let expr = try!(self.parse_expr_res(Restrictions::RESTRICTION_NO_STRUCT_LITERAL)); let loop_block = try!(self.parse_block()); let hi = self.last_span.hi; <del> Ok(self.mk_expr(lo, hi, ExprForLoop(pat, expr, loop_block, opt_ident))) </del> <ins> Ok(self.mk_expr(span_lo, hi, ExprForLoop(pat, expr, loop_block, opt_ident))) </ins> } /// Parse a 'while' or 'while let' expression ('while' token already eaten) <del> pub fn parse_while_expr(&mut self, opt_ident: Option<ast::Ident>) -> PResult<P<Expr>> { </del> <ins> pub fn parse_while_expr(&mut self, opt_ident: Option<ast::Ident>, span_lo: BytePos) -> PResult<P<Expr>> { </ins> if self.token.is_keyword(keywords::Let) { <del> return self.parse_while_let_expr(opt_ident); </del> <ins> return self.parse_while_let_expr(opt_ident, span_lo); </ins> } <del> let lo = self.last_span.lo; </del> let cond = try!(self.parse_expr_res(Restrictions::RESTRICTION_NO_STRUCT_LITERAL)); let body = try!(self.parse_block()); let hi = body.span.hi; <del> return Ok(self.mk_expr(lo, hi, ExprWhile(cond, body, opt_ident))); </del> <ins> return Ok(self.mk_expr(span_lo, hi, ExprWhile(cond, body, opt_ident))); </ins> } /// Parse a 'while let' expression ('while' token already eaten) <del> pub fn parse_while_let_expr(&mut self, opt_ident: Option<ast::Ident>) -> PResult<P<Expr>> { let lo = self.last_span.lo; </del> <ins> pub fn parse_while_let_expr(&mut self, opt_ident: Option<ast::Ident>, span_lo: BytePos) -> PResult<P<Expr>> { </ins> try!(self.expect_keyword(keywords::Let)); let pat = try!(self.parse_pat_nopanic()); try!(self.expect(&token::Eq)); let expr = try!(self.parse_expr_res(Restrictions::RESTRICTION_NO_STRUCT_LITERAL)); let body = try!(self.parse_block()); let hi = body.span.hi; <del> return Ok(self.mk_expr(lo, hi, ExprWhileLet(pat, expr, body, opt_ident))); </del> <ins> return Ok(self.mk_expr(span_lo, hi, ExprWhileLet(pat, expr, body, opt_ident))); </ins> } <del> pub fn parse_loop_expr(&mut self, opt_ident: Option<ast::Ident>) -> PResult<P<Expr>> { let lo = self.last_span.lo; </del> <ins> pub fn parse_loop_expr(&mut self, opt_ident: Option<ast::Ident>, span_lo: BytePos) -> PResult<P<Expr>> { </ins> let body = try!(self.parse_block()); let hi = body.span.hi; <del> Ok(self.mk_expr(lo, hi, ExprLoop(body, opt_ident))) </del> <ins> Ok(self.mk_expr(span_lo, hi, ExprLoop(body, opt_ident))) </ins> } fn parse_match_expr(&mut self) -> PResult<P<Expr>> {

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


Question: <ins> // 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. // include file for issue-21146.rs parse_error </ins>

Testcase: : : Output: Should output, instead, the parse errors from . Probably misplacing the diagnostic emitter somehow, when creating the nested parser for the included source, and doesn't have an .
(I suspect this is an easy fix, but am not quite sure)


Question: "list" will list all of the available passes", "NAMES"), optopt("", "llvm-args", "A list of arguments to pass to llvm, comma  separated", "ARGS"), <ins> optflag("", "no-rpath", "Disables setting the rpath in libs/exes"), </ins> optopt( "",  "out-dir", "Write output to compiler-chosen filename in <dir>", "DIR"),

Currently (something after 0.5) rustc (IIUIC) is using rpaths to point libs and binaries to the appropriate locations. This is problematic when rustc and the other libs/bins are package e.g. for Fedora. The rpath usage should be made optional - can be used instead - and LDLIBRARYPATH.
Why is this problematic for packaging? Is it because the rpath values end up with the wrong values? Each crate's rpath has several values, one of which is supposed to be the final installation location (controlled with ). Can we just provide more control over which locations are used during rpathing?
In general Fedora recommends to not use rpaths [0], because the paths are hardcoded in the binary. Fedora preferres to point the dynamic linker to the appropriate paths [1]. But yes, we are more flexible about internal libraries - which the case is here. So yes, it would also help us if we could controll the rpath path (which goes a bit into the direction if issue ) [0] [1]
The following rpath is used in e.g. the cargo binary: The rpath referres to rpm's buildroot, where the lib won't stay (it will be instaled to ) Maybe the problem could adressed if the rpath would respect - but this could lead to problems at build time. Maybe LDLIBRARYPATH can be used to point to the correct dir's at build time, and the rpath can be used to point to the correct dir's at runtime. Just my 2ct - but you ar ethe expert :)
Thanks for those links. We do generate rpaths with the expectation that some of them will be invalidated by moving the binaries around. It's possible we could consider removing rpath, but it sure is nice to not think about dynamic loading when running binaries out of my build directory. We could easily add a flag to the configure script, to turn off the rpath for all the rust-provided libraries, with the assumption that package managers would modify during install. If we did that I feel like we would still want the installed rustc to generate rpaths with user-built libraries - otherwise the experience would be different depending on the rust installation. We could also just remove rpath completely - it doesn't work on windows anyway.


Question: "list" will list all of the available passes", "NAMES"), optopt("", "llvm-args", "A list of arguments to pass to llvm, comma  separated", "ARGS"), <ins> optflag("", "no-rpath", "Disables setting the rpath in libs/exes"), </ins> optopt( "",  "out-dir", "Write output to compiler-chosen filename in <dir>", "DIR"),

Another thing to consider is that, if we just used rustpkg for all builds, and let rustpkg install all libraries at a known location, then we might be able to conveniently not use rpath while still doing the right thing at load time. Can user directories like be put into ?
Yes - I can fully understand how easy running rust in the build directory is when using rpaths :) For the build directory use case it should be possible to create wrappers for rustc and friends which use to point to the correct dirs. You mention thet some libs might reside in , could you explain the overall concept you are following with this? In general I'd expect libraries to appear in /lib, /usr/lib some and some private /usr/lib/myapp. There are also some xdg specs that specify and - but let usfirst see what you say about ~/.rustpkg. Oh, I don't think that ~/.rustpkg would be expanded correctly if put into
Just to summarize my thoughts: If rpath is used, the rpath path beeing used should only use directories below (to point to non-standard dirs containing libs relevant for a rust component). The rpath path should not point to any build-time dir. To include libraries at buildtime or when using the binaries in the build directory I'd suggest using wrappers (isn't autotools doing it like this?) which set appropriately.
Any follow up thoughts?
Our package manager will by default not be installing libraries to a system location and will instead put them in the user's directory, . This doesn't seem out of the ordinary to me; consider cabal, etc. The behavior you recommend requires some deep changes to how Rust works, so need to be considered carefully. Does the current behavior prevent packaging in Fedora, and is there a minimal change we can make to unblock packaging? You'll probably be interested in this subject.
Thanks for the rustpkg explanation. Do I understand that rustpkg will create binaries and libs with rpaths pointing to the user's specific rustpkg dir ? My feeling is that this user specific rpaths should be configurable at build time. The use case is obviously when the binary or lib is going to be installed systemwide. The only rpath exception is the rpath pointing to the system wide package specific libdir (e.g. ).


Question: "list" will list all of the available passes", "NAMES"), optopt("", "llvm-args", "A list of arguments to pass to llvm, comma  separated", "ARGS"), <ins> optflag("", "no-rpath", "Disables setting the rpath in libs/exes"), </ins> optopt( "",  "out-dir", "Write output to compiler-chosen filename in <dir>", "DIR"),

I think that I'll spend a bit more time with looking at and and might get a better feeling for the problem. Btw.: I noted that the libdir isn't configurabel. Fedora for example keeps x86_64 libs in (/usr)?/lib64, and i686 in (/usr)/lib. IIUIC this is currently not possible with rust as the libs will be installed to /usr/lib/arch-specific-path
The point about libdir is well taken and I updated . I am not entirely sure how rustpkg does it's build now or how and intend for it to work, but based on the current language design I would expect that, yes, binaries installed to would have rpaths pointing there. Currently there are several rpaths configured for each linked library so that they hopefully fall back to something useful when the libraries are moved around during install or during the bootstrapping process, something like: The relative path to the library The absolute path to where the library was at build time The system installation path Under this scheme I would expect that would, when linking against libraries in , create rpaths to .
Yes, there are several rpaths used (seen in and ) and I'd say - even with looking at rust itself, without the packaging glasses on - that it should be configurable what rpaths are used. Maybe it should be an option of . As said, system wide binaries are the best example for binaries where you don't want to many rpaths - including no rpaths pointing to some user dir.
Please don't tag TJC :(
Sorry, TJC! Maybe it's time to give in and start working on Rust :) Seriously though, sorry. I'm sure it's a real PITA.
mentioned that this is a security issue, which I didn't realize. Debian also says .
By the way, it's possible to strip this with but it would be much nicer to not require a third party tool.
I generally wonder why you don't add a user-specific to to point to the user specific rustpkg dir instead of using rpath. That makes it much easier to cope with - and that would also be in par with (at least) the Fedora guidelines. And I suppose with Debian's too, as it's the common way. (See 3rd party java binaries. They modify the to point to some hidden dir in the userdir.)
We used to.


Question: "list" will list all of the available passes", "NAMES"), optopt("", "llvm-args", "A list of arguments to pass to llvm, comma  separated", "ARGS"), <ins> optflag("", "no-rpath", "Disables setting the rpath in libs/exes"), </ins> optopt( "",  "out-dir", "Write output to compiler-chosen filename in <dir>", "DIR"),

Users kept forgetting and/or getting annoyed having to adjust it when running from a build dir. Rpaths made it possible to run foo/bar/rustc no matter which rustc you chose.
right. IIUIC - I always feel like a noob when it comes to autotools - autotools are generating wrappers for binaries which are created during a build process and moves the original binaries to hiddend irectories. The wrappers are then modifying the environment (setting env vars etc) to achieve the same goal (so e.g. that rustc can be run from the dev directory without messing with the env vars yourself). I wonder if this could help.
Okay, it's actually not autools which creates these wrappers but libtool:
Sorry, I didn't mean to imply a disinterest in fixing this better, just noting how it came to be. Also strongly disinterested in using libtool. Would prefer going back to telling users to set env vars.
How about defaulting to static linking (when it works)? Dynamic linking is valuable, but mostly for global installs handled by a package manager. Of course, if we end up with a bunch of tools using that would be wasteful. I think RPATH will just lead to confusion, and it's an easy security hole to leave open.
I would be very happy to get static linking working well enough to make it a default in many such cases. But we ought to do the right thing when linking dynamically too. Is rpath-using- considered acceptable? I.e. is it just the absolute paths that are problematic?
The absolute paths are the ones that can easily be a security issue, so isn't that bad. I would still rather avoid it for a globally installed package but it's easy enough to strip for people who don't need it and won't be an issue if you don't know about it (like the absolute path could be). Using the rpath could be a flag, but the absolute path should never be there.
Nominating for milestone 2: backwards compatible. (The choice of whether one needs to put a setting in or use some configure flag for certain systems, etc, seems like a backwards compatibility issue. Though maybe I misunderstand and these are issues only for people developing itself, not for clients of ?) It also could well be that this is more appropriately assocated with milestone 1: well-defined.


Question: "list" will list all of the available passes", "NAMES"), optopt("", "llvm-args", "A list of arguments to pass to llvm, comma  separated", "ARGS"), <ins> optflag("", "no-rpath", "Disables setting the rpath in libs/exes"), </ins> optopt( "",  "out-dir", "Write output to compiler-chosen filename in <dir>", "DIR"),

I suspect and have a more concrete notion about this.
I don't have anything much to add to this despite it coming up for triage today. I think it has to be fixed still, I'm still happy to do it via whatever combination of static linking by default and use of is sufficient for packagers, and I haven't seen any clear movement on it in the meantime.
accepted for backwards-compatible milestone
I'm getting worried that we won't resolve this for 1.0. I agree this is important to fix. Here's my current suggestion: Modify the build system to once again set LDLIBRARYPATH/PATH to find the appropriate dynamic libraries. Add a flag to rustc to disable rpath Add a configure flag to disable rpathing the rust build itself. Packagers can use this to do whatever they want. With this logic the rust package itself could avoid rpath where distros have their own way of dealing with library paths. The rustc installed by these distros would still be rpathing user's crates for the sake of convenience. Is this an acceptable compromise or do distros want us to completely disable rpath? I'm afraid that doing so would provide an inconsistent developer experience depending on how rustc is acquired; if we need to do that then we instead must find a way to completely eliminate rpath.
If we start to just statically link everything by default then rpath becomes much less important and we can just say it's up to users to figure it out if they opt into dynamic linking.
I think we should completely remove absolute rpaths. It's okay to have $ORIGIN-based ones but it may not be a good default. I'm not sure what the answer is to that, but agree that static linking basically resolves this.
It doesn't appear that this is fully working. There are still rpaths in the binaries when configured with even though the flag for rustc does work. /usr/bin/rustc: RPATH=$ORIGIN/../lib:/build/rust-git/src/rust/x8664-unknown-linux-gnu/stage1/lib/rustlib/x8664-unknown-linux-gnu/lib:/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib
What steps did you follow to having the rpath show up? I thought I double checked on linux that the configure flag worked, but I may have overlooked something.


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. // Test that attempts to implicitly coerce a value into an // object respect the lifetime bound on the object type. fn a(v: &[u8]) -> Box<Clone + 'static> { let x: Box<Clone + 'static> = box v; //~ ERROR does not outlive x } fn b(v: &[u8]) -> Box<Clone + 'static> { box v //~ ERROR does not outlive } fn c(v: &[u8]) -> Box<Clone> { box v // OK thanks to lifetime elision } fn d<'a,'b>(v: &'a [u8]) -> Box<Clone+'b> { box v //~ ERROR does not outlive } fn e<'a:'b,'b>(v: &'a [u8]) -> Box<Clone+'b> { box v // OK, thanks to 'a:'b } fn main() { } </ins>

This should not compile, since is for some non- and thus will contain as well. It compiles fine however and results in the varying output depending on the optimization level (which shows that this is an UB out of the "safe" code). Tested with and playpen.
A more self-contained example that shouldn't type-check:
It seems that this has been possible since generalized lifetime bounds went in.
Huh. This was supposed to be fixed. I'll take a look.
P-backcompat-lang, 1.0
OK, simple oversight. PR coming soon. Amazing we have no test for this. It occurs only with coercions. (In general, this code path could be cleaned up, and will be as part of implementing generalized where clauses, making these kinds of oversights harder to do.)


Question: // down as much as possible (without going negative), and then // adding back in whatever we couldn't factor into steals. Some(data) => { <del> self.steals += 1; </del> if self.steals > MAX_STEALS { match self.cnt.swap(0, atomics::SeqCst) { DISCONNECTED => {

PRs are bouncing due to test timeouts. Nothing has landed since cc
Very, very unfortunately, just landed. This means that the breakage is not unconditional.
Segfault!
had also been reporting segfaults on master.
I got a segfault on
What is causing this?
Weird, seemed to make it through.
This appears to be because of a channel deadlock. Investigating now.
Fixed the deadlock, investigating the segfault now.


Question: /// # Example /// /// ```rust <ins> /// # #![allow(deprecated)] </ins> /// use url::encode; /// /// let url = encode("https://example.com/Rust (programming language)");

Users should use the cargo-ified Deprecate for a release or two then delete. cc
:+1:
Related:
I tried this: Hoping to deprecate the whole crate, but then building this program does not emit any warning: I expected a deprecation warning on the line. Is there another way to achieve this, or do I need to annotate individual items in the crate?
That should have worked, but you may need to remove the annotation above (they may be conflicting). I would also personally find it very helpful to annotate methods in particular what the path forward is (or just a general post about how to migrate).
Removing worked, thanks. Should this deprecation go through the RFC process, or can I assume that the team wants it since filed this issue? The documentation at explains how to use rust-url, and in particular the concept of relative v.s. non-relative URL schemes (e.g. vs ) which is a bit unusual. I believe this sufficient to make migration straightforward, but I’m obviously biased. Any feedback on the documentation is welcome. (I’ll make the deprecation message include the documentation’s URL, it seems more useful landing page than the github repo.)
Having an issue is sometimes considered a "todo item" rather than "everyone has approved this", you'll find both styles of issues on the issue tracker. We don't have much precedent for deprecating an in-tree crate, so we're forging new territory here. I'd like to start moving crates out of the repo, however, so I hope to have some more on this topic soon.