Question: intravisit::walk_foreign_item(self, it); } <del> fn visit_stmt(&mut self, e: &'tcx hir::Stmt<'tcx>) { // We will call `add_id` when we walk // the `StmtKind`. The outer statement itself doesn't // define the lint levels. intravisit::walk_stmt(self, e); </del> <ins> fn visit_stmt(&mut self, s: &'tcx hir::Stmt<'tcx>) { self.add_id(s.hir_id); intravisit::walk_stmt(self, s); </ins> } fn visit_expr(&mut self, e: &'tcx hir::Expr<'tcx>) {

I tried this code: I expected to catch lint and suppress it, as it should. Instead, compiler issues a diagnostic both about unused value and unfulfilled lint expectation: It does work as expected though if is applied to function. I used the latest stable (Rust 1.81), but it is reproducible both on latest beta (2024-09-04 ) and latest nightly (2024-09-05 ). labels: +F-lintreasons, +A-diagnostics <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This issue is not limited to just . Others attrs like or don't work either. For instance, the following variant of the reproducer with replaced with emits the warning even though it shouldn't: Playground: This broken behaviour goes as far back as at least 2021 (couldn't build and test earlier rustc) We emit the lint on the HIR node corresponding to . However, the or levels, which are supposed to override the default level of the lint, are associated with or bound to the node underlying the as shown in the figure below: The end result is that the lint's level is never knocked down to or since when searching for levels we start from the node on which the lint is triggered and go up the chain of parents. So in this case we look for the level on and then on the and so on. We never look for it on the where the levels actually exist. As it happens in the lowered HIR does have the / attrs for both the node and its child node. However when adding the levels in the we do not add anything for the node as shown here (note the comment): If were to add the level for as well the issue will go away. However, if we do that we will still have one problem in the case of which is that we will end up with two expectations and the one on the will not be fullfilled and hence we will still see a warning about unfulfilled expectation. To prevent that I think we should take the following approach: when an attr like or etc.


Question: intravisit::walk_foreign_item(self, it); } <del> fn visit_stmt(&mut self, e: &'tcx hir::Stmt<'tcx>) { // We will call `add_id` when we walk // the `StmtKind`. The outer statement itself doesn't // define the lint levels. intravisit::walk_stmt(self, e); </del> <ins> fn visit_stmt(&mut self, s: &'tcx hir::Stmt<'tcx>) { self.add_id(s.hir_id); intravisit::walk_stmt(self, s); </ins> } fn visit_expr(&mut self, e: &'tcx hir::Expr<'tcx>) {

are present for more than one HIR node in the and if one node is the (direct or indirect) parent of the other node, then add the level only_ for parent node. This will take care of any lints on the child (since we always walk up the HIR hierachy as mentioned earlier) as well as the parent and it will not cause any warnings about missed expectations. I am new to this area so if someone can review this idea or suggest alternatives that will be great. since you seemed to have worked in this area recently, can you please weigh in?
Your investigation is accurate, and the fix is simple: visit the statement node when building lint levels. Do you mind making such a pr ? I don't think we need any special adjustment for cases, duplicated attributes are already taken into account, but a test won't hurt.
Thanks . Yes, I'll put together a PR. My only concern is if all we do is add the level at , although it will work perfectly for , etc., in the case of we will end up with an unfulfilled expectation on the node which will appear to the user as a warning. But anyway let me have a go and see what happens.
Opened draft PR that adds the lint on . It does suffer from the extra warning problem.


Question: }; let msg = match name { NamedField(name) => format!("field `{}` of {} is private", <del> token::get_ident(name), struct_desc), </del> <ins> token::get_name(name), struct_desc), </ins> UnnamedField(idx) => format!("field #{} of {} is private", idx + 1, struct_desc), };

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: }; let msg = match name { NamedField(name) => format!("field `{}` of {} is private", <del> token::get_ident(name), struct_desc), </del> <ins> token::get_name(name), struct_desc), </ins> UnnamedField(idx) => format!("field #{} of {} is private", idx + 1, struct_desc), };

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: }; let msg = match name { NamedField(name) => format!("field `{}` of {} is private", <del> token::get_ident(name), struct_desc), </del> <ins> token::get_name(name), struct_desc), </ins> UnnamedField(idx) => format!("field #{} of {} is private", idx + 1, struct_desc), };

, 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: }; let msg = match name { NamedField(name) => format!("field `{}` of {} is private", <del> token::get_ident(name), struct_desc), </del> <ins> token::get_name(name), struct_desc), </ins> UnnamedField(idx) => format!("field #{} of {} is private", idx + 1, struct_desc), };

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: }; let msg = match name { NamedField(name) => format!("field `{}` of {} is private", <del> token::get_ident(name), struct_desc), </del> <ins> token::get_name(name), struct_desc), </ins> UnnamedField(idx) => format!("field #{} of {} is private", idx + 1, struct_desc), };

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: }; let msg = match name { NamedField(name) => format!("field `{}` of {} is private", <del> token::get_ident(name), struct_desc), </del> <ins> token::get_name(name), struct_desc), </ins> UnnamedField(idx) => format!("field #{} of {} is private", idx + 1, struct_desc), };

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: <del> error[E0080]: evaluation of `<A<()> as Foo<()>>::BAR` failed --> $DIR/issue-50814-2.rs:14:24 | LL |     const BAR: usize = [5, 6, 7][T::BOO]; |                        ^^^^^^^^^^^^^^^^^ index out of bounds: the length is 3 but the index is 42 note: erroneous constant encountered --> $DIR/issue-50814-2.rs:18:6 | LL |     &<A<T> as Foo<T>>::BAR |      ^^^^^^^^^^^^^^^^^^^^^ note: the above error was encountered while instantiating `fn foo::<()>` --> $DIR/issue-50814-2.rs:30:22 | LL |     println!("{:x}", foo::<()>() as *const usize as usize); |                      ^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0080`. </del>

File: /tmp/icemaker/issue--2.rs 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
cc


Question: ); let predicates = tcx.projection_predicates(trait_ty.def_id); debug!("compare_projection_bounds: projection_predicates={:?}", predicates); for predicate in predicates { <del> let concrete_ty_predicate = match predicate.kind() { ty::PredicateKind::Trait(poly_tr, c) => poly_tr .map_bound(|tr| { let trait_substs = translate_predicate_substs(tr.trait_ref.substs); ty::TraitRef { def_id: tr.def_id(), substs: trait_substs } }) .with_constness(*c) .to_predicate(tcx), ty::PredicateKind::Projection(poly_projection) => poly_projection .map_bound(|projection| { let projection_substs = translate_predicate_substs(projection.projection_ty.substs); ty::ProjectionPredicate { projection_ty: ty::ProjectionTy { substs: projection_substs, item_def_id: projection.projection_ty.item_def_id, }, ty: projection.ty.subst(tcx, rebased_substs), } }) .to_predicate(tcx), ty::PredicateKind::TypeOutlives(poly_outlives) => poly_outlives .map_bound(|outlives| { ty::OutlivesPredicate(impl_ty_value, outlives.1.subst(tcx, rebased_substs)) }) .to_predicate(tcx), _ => bug!("unexepected projection predicate kind: `{:?}`", predicate), }; </del> <ins> let concrete_ty_predicate = predicate.subst(tcx, rebased_substs); debug!("compare_projection_bounds: concrete predicate = {:?}", concrete_ty_predicate); </ins> let traits::Normalized { value: normalized_predicate, obligations } = traits::normalize( &mut selcx, <del> param_env, </del> <ins> normalize_param_env, </ins> normalize_cause.clone(), &concrete_ty_predicate, ); debug!("compare_projection_bounds: normalized predicate = {:?}", normalized_predicate); inh.register_predicates(obligations);

So I had a trait system in my (nightly) code for a while now that utilized specialization, but it no longer seems to be working after a recent update: Now, I haven't been following the development of the specialization feature too closely, so it is possible that this is somehow actually intended and I am missing something. However, given that this previously compiled and ran just fine a couple weeks ago and given that the specialization incomplete warning was only recently, I am inclined to think that it is probably a regression of some sort. compiler version:
Another MVCE (): Regressed in , looks like
cc as far as I can tell this wasn't an intended outcome of the change?
It wasn't really, it was just slightly more complex to have this still work after that PR.
Would you mind describing at a high level what needs to be done?
It looks like the problem stems from the bound predicate not being fully normalized when checking the defaulted associated type. From my reproducer above: which should instead be . I'm not certain yet how this ought to be implemented. Perhaps a pass after normalization that looks for occurrences of the defaulted type ( in this case) and replaces it with the defaulted type. Seems simple enough, in theory :) But maybe there are cases I'm not thinking of.


Question: G(); H(); I(); <ins> K()(); </ins> }

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: ENV HOSTS=armv7-unknown-linux-gnueabihf <del> ENV RUST_CONFIGURE_ARGS --enable-full-tools --disable-docs </del> <ins> ENV RUST_CONFIGURE_ARGS --enable-full-tools --enable-profiler --disable-docs </ins> ENV SCRIPT python3 ../x.py dist --host $HOSTS --target $HOSTS

I am new to the Rust ecosystem, but as part of my own learning curve, I wanted to create a small personal project which includes test coverage executed on my raspberry pi server. My setup contains a self-hosted Gitlab-instance (which runs inside docker) running on a 32-bit based Raspbian on my Raspberry Pi 4 (with 8gb RAM). After some hours of trying to get working I tried to reproduce my problems, and found out, that are missing for armv7-unknown-linux-gnueabihf. I opened up an issue on the GRCOV-project (), because I first thought I was missing some important instruction to set up my system. It now seems to me that the package provided via does not include the required crates/libs to make it work to have code coverage being analysed. install the docker engine + docker cli (locally on intel/amd-based system; and on a raspberry pi with 32bit operating system) create a new project in a new folder containing a normal project (inited via ) Content of : create a aside of that folder: create that container: run container: execute the following inside the container:
My guess is the version of you are compiling with was built without set in its build configuration (e.g., ).
This may be related to
Hm, is related to musl, you sure it is related? As I am using official -image, where can I check/see, if it was built with ? The defaults seem to have no profiler to get built into
Related in the sense that both issues report that the build of the compiler for their target platforms does not set "profiler = true". Yes, the default is "profiler = false", but various pre-built distros enable "profiler = true". Some don't. I don't know who makes those decisions, whether we should change this to enable "profiler = true" by default in the future, and/or whether the profiler_builtins library works or not for some platforms.
Is there any update on this? Is this simply a matter of adding to the Dockerfile, or are there other pieces missing too?
I think this is something pretty low-level to be enabled first inside the compiled rust docker image, nothing that can just be activated via that parameter. I will try to re-check on the upcoming weekend to see if there has something changed silently.


Question: ENV HOSTS=armv7-unknown-linux-gnueabihf <del> ENV RUST_CONFIGURE_ARGS --enable-full-tools --disable-docs </del> <ins> ENV RUST_CONFIGURE_ARGS --enable-full-tools --enable-profiler --disable-docs </ins> ENV SCRIPT python3 ../x.py dist --host $HOSTS --target $HOSTS

Nope, still the same issue. Retried on a fresh install of the whole system (Bullseye-based raspbianOS ... whatever its called) and got the same output: versions: EDIT: just to point out, the used rust comes from the docker-container, not the hosting OS
Potential duplicate of ?
similar but no duplicate, because the other issue targets MUSL, this is ARMv7-specific
Right, but the root cause appears to be an issue with the releases provided for tier 2 targets, which affects both.
This already got suggested here: All it comes down to "profiler_builtins" not being present. If both issues are having the same root cause, thats okay, but as every target is configured differently (like already mentioned here: ), so I do not see a duplicate here. is specificly targeting MUSL, this is non-MUSL and includes an easy reproducable example.
Is there a way to activate it when building the compiler manually as a temporary solution?
Try building with (see PR ). if you get linker errors, try linking with as described in
I verified that with today's Rust Nightly, code coverage is working. See This target "just works"; it doesn't require forcing like powerpc-unknown-linux-gnu.


Question: <ins> // check-pass #![feature(associated_type_defaults)] use std::io::Read; trait View { type Deserializers: Deserializer<Item = Self::RequestParams>; type RequestParams = DefaultRequestParams; } struct DefaultRequestParams; trait Deserializer { type Item; fn deserialize(r: impl Read) -> Self::Item; } 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
It looks like it's correctly complied on rustc 1.48.0-nightly:
I dont think this should compile at all. After all, we cause UB, the value of the const generic does not comply with the rules of .
A str being valid utf-8 is not a language invariant, so this should not be UB to my knowledge. cc I do expect this to be the correct behavior, so marking as
We do have to compare the s to check for equality though, which might cause library ub so :shrug:
I think you are free to decide on your own invariant here -- assuming that two are equal if and only if the underlying are equal, it's your call whether you want to allow non-UTF-8 in types or not. What is the plan for other library types? Like, imagine a user defined a newtype around that must be even. The compiler cannot even know that such an invariant exists so it cannot be enforced. Equality checking anyway happens by comparing the underlying bytes. So if we follow that analogy, the non-UTF-8 should be fine, but we have to make sure that we use the right notion of equality.
:+1: yeah, see for more details here I guess One concern is that we probably want to print s in and in encodings, so we need to either deal with invalid utf there or forbid it entirely :thinking: Will have to keep that in mind before stabilizing parameters.
Yeah, you could either use (so any special treatment of is confined to the printing code) or make a very special compiler-understood type even for the type system itself (and reject non-UTF-8 strings early). The former seems more principled to me but that is just a slight preference.


Question: <ins> // check-pass #![feature(associated_type_defaults)] use std::io::Read; trait View { type Deserializers: Deserializer<Item = Self::RequestParams>; type RequestParams = DefaultRequestParams; } struct DefaultRequestParams; trait Deserializer { type Item; fn deserialize(r: impl Read) -> Self::Item; } fn main() {} </ins>

won't work for symbol mangling, as otherwise two distinct types can have the same symbol: (current ICE is unrelated, as const generics is not yet fully supported there) Printing invalid utf8 as bytes might be simpler there :thinking: I guess cc about that
Oh, this is not just pretty-printing but needs to be injective? Then I guess some or so (for "invalid") would work.


Question: ty::Ref(..) | ty::RawPtr(_) => { return self.field(cx, index).llvm_type(cx); } <del> ty::Adt(def, _) if def.is_box() => { </del> <ins> // only wide pointer boxes are handled as pointers // thin pointer boxes with scalar allocators are handled by the general logic below ty::Adt(def, substs) if def.is_box() && cx.layout_of(substs.type_at(1)).is_zst() => { </ins> let ptr_ty = cx.tcx.mk_mut_ptr(self.ty.boxed_ty()); return cx.layout_of(ptr_ty).scalar_pair_element_llvm_type(cx, index, immediate); }

While working on , I've run into the following ICE. On further consideration, the issue also appears with as long as is non zero sized. This ICE was likely not encountered during testing of because in the case of , is zero sized. In the example below, removing the borrow of will cause the compilation to succeed. could you take a look at this? :) cc you may run into this as well on <!-- 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<pFrom playground </p</details
This ice is still showing up in . We are using it over in in embedded programming to allocate from heaps located on externally mounted sdram.
Vec is not affected by this, and can even be used to get a Box. This code did not ICE on playground.
Interestingly, trying to print the Box created in that way gives the same ICE as
Hello, I get this error in two flavor: By ref: Produce the following: Without ref: Cause: Where does implement both and traits.
I'm hitting this issue too, on code that basically equates to this: Seems like there are plenty of ways to reproduce this in here, but if a minimal test case is needed, I would be happy to try to provide one. I just made a repro, wasn't really that tricky.
As far as I understand it, the issue is as follows: std is special cased, it has the attribute This corresponds to , which returns true if the type as been annotated to be a Somewhere, some code which uses makes an assumption that such a box data type only contains one field, the inner pointer itself. This causes the allocator struct field to be removed. This breaks when there is a non ZST allocator field that needs to be accessed in generated code. I'm guessing this might be related to the special deref move semantics for boxes?


Question: ty::Ref(..) | ty::RawPtr(_) => { return self.field(cx, index).llvm_type(cx); } <del> ty::Adt(def, _) if def.is_box() => { </del> <ins> // only wide pointer boxes are handled as pointers // thin pointer boxes with scalar allocators are handled by the general logic below ty::Adt(def, substs) if def.is_box() && cx.layout_of(substs.type_at(1)).is_zst() => { </ins> let ptr_ty = cx.tcx.mk_mut_ptr(self.ty.boxed_ty()); return cx.layout_of(ptr_ty).scalar_pair_element_llvm_type(cx, index, immediate); }

Is the case where the compiler should call for the for the box in the case where a deref move is performed even handled correctly as is today?
It seems that is the one that developed the feature, in He had been warned of the incomming issue, , and opt for a "workaround", can you give us more information about the problem you , the workaround you choose, any hint for why it isn't working, and maybe give us possible path to explore ?


Question: fn main() { static foo: Fn() -> u32 = || -> u32 { //~^ ERROR: mismatched types <ins> //~| ERROR: `std::ops::Fn() -> u32 + 'static: std::marker::Sized` is not satisfied </ins> 0 }; }

This looks unintentional, and has been broken in all cases, until a few releases ago, AFAICT. Should this be covered by WF rules? cc Unsized constants cause an ICE, in both old trans and MIR trans: Unsized statics appear to work, but only in old trans: I believe this is possible because a constant DST lvalue in old trans is merely the fat pointer. It seems useful to allow an unsized , but IMO it should require a sized RHS instead, i.e.: And, of course, this should all go through the RFC process, to figure out all the finer details.
Should it be ? I don't think A needs to be an lvalue.
It makes more sense for constants, but I gave the example with because that's the only one that works today (although by accident).
Hmm? I mean the static is desugared into a const. works today.
The idea being that a static and a const reference both give access to one lvalue.
No, has different semantics: it allows an somewhere within and is guaranteed not to be duplicated.
Hmm? Both of these gives me a "error: cannot borrow a constant which contains interior mutability, create a static instead". This is what I'd suspect as the lvalue from the promoted has nothing to do with being a or a .
Let me rewrite my desugaring to account for that, oops.
Oh and my confusion really just stemmed from forgetting about the constants referring to statics rule. [Kind of a funny rule when works, but this is an orthogonal issue.]
I think in the meantime unsized statics should probably error, perhaps dependent on a crater run, though I doubt there's many people relying on said bug. It's much easier to relax restrictions than tighten them.
Will prepare a patch to turn this into an error, hopefully nobody has been abusing it.


Question: = note: the only supported types are integers, `bool` and `char` = help: more complex types are supported with `#![feature(adt_const_params)]` <del> error: aborting due to 7 previous errors </del> <ins> error: `&dyn for<'a> Foo<'a>` is forbidden as the type of a const generic parameter --> $DIR/unusual-rib-combinations.rs:29:21 | LL | struct Bar<const N: &'a (dyn for<'a> Foo<'a>)>; |                     ^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: the only supported types are integers, `bool` and `char` = help: more complex types are supported with `#![feature(adt_const_params)]` error: aborting due to 9 previous errors </ins> <del> Some errors have detailed explanations: E0106, E0214, E0308. </del> <ins> Some errors have detailed explanations: E0106, E0214, E0308, E0771. </ins> For more information about an error, try `rustc --explain E0106`.

This is a fuzzed test case, found with and minimized with . I wasn't able to find any similar issues: : <details<summary<strongBacktrace</strong</summary<p</p</details
This is related to , do we need to keep this ICE or we cover it at here:
The assert was in If you have a reproducer, then it can be to and the assert can be removed.
label +S-bug-has-mcve


Question: <ins> error[E0283]: type annotations needed: cannot resolve `_: A` --> $DIR/issue-63496.rs:4:21 | LL |     const C: usize; |     --------------- required by `A::C` LL | LL |     fn f() -> ([u8; A::C], [u8; A::C]); |                     ^^^^ error[E0283]: type annotations needed: cannot resolve `_: A` --> $DIR/issue-63496.rs:4:33 | LL |     const C: usize; |     --------------- required by `A::C` LL | LL |     fn f() -> ([u8; A::C], [u8; A::C]); |                                 ^^^^ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0283`. </ins>

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


Question: where A: DoubleEndedIterator + ExactSizeIterator, B: DoubleEndedIterator + ExactSizeIterator; <ins> fn fold<Acc, F>(self, init: Acc, f: F) -> Acc where F: FnMut(Acc, Self::Item) -> Acc; </ins> // This has the same safety requirements as `Iterator::__iterator_get_unchecked` unsafe fn get_unchecked(&mut self, idx: usize) -> <Self as Iterator>::Item where

<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: same codegen or similar in performance Instead, this happened: array has way worse codegen <details<summaryAssembly</summary<p</p</details<!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.64 <!-- Provide the version you are using that has the regression. --65 till now. Regressed in nightly-2022-08-13, maybe LLVM 15 ?: : <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. -- modify labels: +regression-from-stable-to-stable -regression-untriaged <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
WG-prioritization assigning priority (). cc since this regressed in the LLVM 15 update label -I-prioritize +P-medium +T-compiler
I've seen llvm doing these strange 1-byte-at-a-time "vectorizations" in other places too. This might be a more general problem. In this case we can probably paper over it by implementing TrustedRandomAccess for the array iter.
Unfortunately, the array iterator is fundamentally worse right now, because indexing into it -- a fundamental part of being a by-value array iterator -- keeps it from SRoAing and thus doesn't optimize well. This is why when I was making better I ended up making to not have to use . Sadly, for the foreseeable future you're better off using the "weaker" slice iterator when you can.
My guess is that the SROA is missing something in the opaque pointer mode.


Question: where A: DoubleEndedIterator + ExactSizeIterator, B: DoubleEndedIterator + ExactSizeIterator; <ins> fn fold<Acc, F>(self, init: Acc, f: F) -> Acc where F: FnMut(Acc, Self::Item) -> Acc; </ins> // This has the same safety requirements as `Iterator::__iterator_get_unchecked` unsafe fn get_unchecked(&mut self, idx: usize) -> <Self as Iterator>::Item where

claim
It's not about vectorization. This optimization can be restored by using . But highly unrecommended. Upstream issue:
The upstream issue is closed. claim


Question: fn visit_impl_item(&mut self, ii: &'a ImplItem) { let def_data = match ii.node { ImplItemKind::Method(MethodSig { <del> header: FnHeader { asyncness: IsAsync::Async { closure_id, return_impl_trait_id, }, .. }, .. }, ..) => { </del> <ins> header: ref header @ FnHeader { asyncness: IsAsync::Async { .. }, .. }, ref decl, }, ref body) => { </ins> return self.visit_async_fn( ii.id, <del> closure_id, return_impl_trait_id, </del> ii.ident.name, ii.span, <del> |this| visit::walk_impl_item(this, ii) </del> <ins> header, &ii.generics, decl, body, </ins> ) } ImplItemKind::Method(..) | ImplItemKind::Const(..) =>

suggested this is because when we lower the async function, we add `), whereas it should be parented as something outside of the impl trait context (as that is how such an expression would be parented, if it actually existing in the AST). I have a bit of code where I'd like to use a reference with a lifetime in an "async" function, which panics the compiler. I tried this code: I expected to see this happen: My understanding was that async functions are allowed to take references as parameters. helped to debug this a little bit and there is a suspicion that named lifetimes are somehow not properly propagated. I stumbled into this because I wanted to have 2 args with references, but if the lifetimes are elided the compiler asks for them to be . Adding them ICEs the compiler. Instead, this happened: I got a compiler panic. Backtrace:
suggested might be related
It would appear one can workaround this by using async blocks manually: I still need to test this does what I expect.
why do you need the immediately invoked closure there,
Yeah, just noticed. I think I also had some other issue / ICE, but I don't remember exactly what it was. Gonna have to check it again. Also, I don't think I knew that on blocks was a thing.
I didn't quite understand why I needed the move. I am trying to fix the original ICE, I think I got some time today tomorrow, hopefully, will make some progress. But compiler newbie, so might not work out.
You need to move to avoid the closure borrowing the references locally. It's the same situation as with I just removed all immeditaly invoked functions from eval :wink:
I am playing around with similar types of borrowing patterns, namely using StreamObj to carry a stream around inside of a struct. I can't seem to use the posted work-arounds: I am taking this working code and I'm refactoring it. Starts as: this works, compiles and runs. Then I try my hand at refactoring to move the stream out of the same scope as the await code pulling out values.


Question: fn visit_impl_item(&mut self, ii: &'a ImplItem) { let def_data = match ii.node { ImplItemKind::Method(MethodSig { <del> header: FnHeader { asyncness: IsAsync::Async { closure_id, return_impl_trait_id, }, .. }, .. }, ..) => { </del> <ins> header: ref header @ FnHeader { asyncness: IsAsync::Async { .. }, .. }, ref decl, }, ref body) => { </ins> return self.visit_async_fn( ii.id, <del> closure_id, return_impl_trait_id, </del> ii.ident.name, ii.span, <del> |this| visit::walk_impl_item(this, ii) </del> <ins> header, &ii.generics, decl, body, </ins> ) } ImplItemKind::Method(..) | ImplItemKind::Const(..) =>

Now I can get the same ICE as this ticket: ICE: full backtrace: Then I try some of your posted workarounds and they don't do the trick, here's my best try: but this fails to compile due to an ownership issue I can't figure out:
your final borrow error is because Fahrenheit while your contains a local stack borrow. You could try using  instead of Fahrenheit.
Alternatively to what suggested, you could move the code in to an async fn:


Question: let path = cfg_file.unwrap_or_else(|| src_path.join("config.toml")); let settings = format!( "# Includes one of the default files in src/bootstrap/defaultsn <del> profile = "{}"n", profile </del> <ins> profile = "{}"n changelog-seen = {}n", profile, VERSION </ins> ); t!(fs::write(path, settings));

New contributors haven't use before, so there's no reason for them to read the changelog: nothing has changed.
I can tackle this.
that would be great! To get started, take a look at . In addition to adding , also add . You'll have to move from to so you can access it in . You should also double check that the changelog warning isn't printed during the command itself. I'm not sure exactly how to do that without reading the code, but I expect it to be a simple or something like that.


Question: use std::path::PathBuf; pub static BINARY_PATH: OnceLock<PathBuf> = OnceLock::new(); <del> pub const RUN_OPTION: &str = "*doctest-inner-test"; pub const BIN_OPTION: &str = "*doctest-bin-path"; </del> <ins> pub const RUN_OPTION: &str = "RUSTDOC_DOCTEST_RUN_NB_TEST"; </ins> #[allow(unused)] pub fn doctest_path() -> Option<&'static PathBuf> {{

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


Question: <ins> fn hello<Q>() -> Vec<Q> { Vec::<Q>::mew() //~^ ERROR no function or associated item named `mew` found for struct `Vec<Q>` in the current scope } fn main() {} </ins>

<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: param types with same index differ in name'', 'thread 'rustc' panicked at 'assertion failed: param types with same index differ in name'' File: --auto-reduced (treereduce-rust): original: Version information ` Command:
thanks for the stack trace for this class of ICEs, it's just the right thing that I need. Minimal:


Question: <ins> // Copyright 2012 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. //compile-flags: -Z borrowck=mir #![feature(slice_patterns)] fn mut_head_tail<'a, A>(v: &'a mut [A]) -> Option<(&'a mut A, &'a mut [A])> { match *v { [ref mut head, ref mut tail..] => { Some((head, tail)) } [] => None } } fn main() { let mut v = [1,2,3,4]; match mut_head_tail(&mut v) { None => {}, Some((h,t)) => { *h = 1000; t.reverse(); } } } </ins>

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


Question: <ins> error[E0425]: cannot find value `bogus` in this scope --> $DIR/issue-59134-1.rs:8:37 | LL |         const CONST: Self::MyType = bogus.field; |                                     ^^^^^ not found in this scope error: aborting due to previous error For more information about this error, try `rustc --explain E0425`. </ins>

When using this branch of bitflags: through a patch in a local directory rls crashes with the following errors:
i had enabled dev overrides for dependencies in using: removing that out the output from rls is now the normal debug flags but still the same errors:
This is now causing widespread ICEs in the RLS. Nominating to get this fixed (maybe has an idea?). See for a simpler reproducer.
I encountered this issue trying out which causes rustc to crash on when invoked by RLS. I can confirm it's the exact same backtrace as
I ran into this trying out on Windows 10. RLS inside vscode ends up panicking with this backtrace: (note for repro: I had changed the default feature in tui-rs to be "crossterm" because the default feature "termion" doesn't compile on windows - but after the termion compile errors, rustc was giving me a similar panic anyway)
JFYI I could work around this problem by adding to my
I tried that with the tui-rs (it had ) but same panic. [Edit] you're right, I had missed the inside the version.
Thanks !
Running into the same issue when trying to build Clap
Same issue in vscode on linuxmint and rust 1.34.1 when trying to build glib (dependency of gtk).
There is no need to list every crate which depends on , it only clutters the thread and makes less visible.
Here's a small repro, extracted from what is doing: I'm struggling to get a repro without the compile error, though.
Thank you for such a small repro! I’ll take a closer look tomorrow and see what may be causing that. On Tue, 7 May 2019 at 22:32, Sean Gillespie <:
Looks like isn't written back for a resolution error? That still repros without , right?
Correct, it does. Further minimized repro:
Interesting. I managed to reduce it to: with: Any other combination is okay, it has to be under under and it has to be combined with a field access (bare unknown identifier doesn't ICE). I'm only guessing but it seems that it tries to emplace def 'path' under a which seems to skip a def path segment?


Question: <ins> error[E0425]: cannot find value `bogus` in this scope --> $DIR/issue-59134-1.rs:8:37 | LL |         const CONST: Self::MyType = bogus.field; |                                     ^^^^^ not found in this scope error: aborting due to previous error For more information about this error, try `rustc --explain E0425`. </ins>

I think this is confirmed by A, what I believe is, more accurate guess is that we somehow don't correctly nest appropriate typeck tables when visiting .
Oh, you need to have one table per body: look in HIR for fields and map all of those cases back to the AST. This makes a lot more sense now: so is not wrong, but is looking in the wrong place.
What about this: Seems like we need to before walking the expression of the associated const?
Hm, probably! I imagined the problem is we don't nest it before visiting trait items (hence missing segment) but you may be right! Let's see :sweat_smile:
With the fix applied this still ICEs on (this time for type) which means we should nest tables for as well


Question: } declare_lint! { <ins> /// The `function_item_references` lint detects function references that are /// formatted with [`fmt::Pointer`] or transmuted. /// /// [`fmt::Pointer`]: https://doc.rust-lang.org/std/fmt/trait.Pointer.html /// /// ### Example /// /// ```rust /// fn foo() { } /// /// fn main() { ///     println!("{:p}", &foo); /// } /// ``` /// /// {{produces}} /// /// ### Explanation /// /// Taking a reference to a function may be mistaken as a way to obtain a /// pointer to that function. This can give unexpected results when /// formatting the reference as a pointer or transmuting it. This lint is /// issued when function references are formatted as pointers, passed as /// arguments bound by [`fmt::Pointer`] or transmuted. pub FUNCTION_ITEM_REFERENCES, Warn, "suggest casting to a function pointer when attempting to take references to function items", } declare_lint! { </ins> /// The `uninhabited_static` lint detects uninhabited statics. /// /// ### Example

I tried this code: I expected to see this happen: The compilation succeed or guide me to (1) cast the to with . (2) borrow the : . But in this case the addresses printed are the same (what?). Instead, this happened*: Cryptic error message: There is : . It took me minutes before I found the workaround. But it still surprised me. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
This creates a reference-to-function-pointer (type ), a double indirection. So it is not what you want. The error could possibly be improved, and the entire situation documented better, but I think getting an error is expected here. is not a function pointer, it is an anonymous ) (of size 0) indicating exactly the function it was created from. This type coerces to a function pointer, but cannot know what type to coerce it to. Printing function pointers is easy (well, if they are not polymorphic via ), but printing these function singleton ZSTs is hard.
It might also be worth linting against .
helps with the docs. But to close this issue, it would probably make sense to write a lint against where is the name of a function. That should be a matter of adding a new in which checks all expressions for being . That path we can pass to to get a . Now we just need to check if that refers to a function: pass the to . At least I hope that makes sense, someone stop me if this is all wrong. ;)
I'd like to help write this lint. The default level for the lint should be right? claim
Yeah, feels like a reasonable start.
Nominated for lang team discussion. It seems we usually ask for lints to be approved before shipping them, so let's get that process started. sorry for this, I wasn't aware of this part of the process. You can still go ahead and implement this if you want, but depending on what the lang team decides, we should submit this lint to clippy instead of the compiler itself. That might require minor adjustments, but the main work you are putting in and the testcases will be useful either way.


Question: } declare_lint! { <ins> /// The `function_item_references` lint detects function references that are /// formatted with [`fmt::Pointer`] or transmuted. /// /// [`fmt::Pointer`]: https://doc.rust-lang.org/std/fmt/trait.Pointer.html /// /// ### Example /// /// ```rust /// fn foo() { } /// /// fn main() { ///     println!("{:p}", &foo); /// } /// ``` /// /// {{produces}} /// /// ### Explanation /// /// Taking a reference to a function may be mistaken as a way to obtain a /// pointer to that function. This can give unexpected results when /// formatting the reference as a pointer or transmuting it. This lint is /// issued when function references are formatted as pointers, passed as /// arguments bound by [`fmt::Pointer`] or transmuted. pub FUNCTION_ITEM_REFERENCES, Warn, "suggest casting to a function pointer when attempting to take references to function items", } declare_lint! { </ins> /// The `uninhabited_static` lint detects uninhabited statics. /// /// ### Example

:)
As a point of interest, this would have been extremely useful in helping debug a segfault in The original code used , not .
Without the cast, this should not compile as transmute checks that the sizes match. I assume what you describe happens when using , i.e., not just remove the but also add a .
Unfortunately I never committed the broken code so I'm not sure what I had originally ... the closest thing is which doesn't compile. Sorry for the noise.
no worries. I already have the lint implemented, but in that case I'll wait until they discuss to write the tests
I think should compile. That's no noise, it seems very relevant. :)
poll T-lang Should we add a lint for taking a reference to a fn?
Team member has asked teams: T-lang, for consensus on: [x] [x] [x] [ ] [x] [ ]
I think I agree here, but to confirm: this isn't actually about linting the taking of a reference to a place of type, but just about using on the voldemort-typed function name constants, right?
Yes.
Discussed in a (rather small) meeting today: Those present felt a lint would make sense. If somebody wanted to go ahead and try to author one, please feel free and nominate the resulting PR for discussion.
all right, so if you want to open a PR, everything is settled for that. :)


Question: /// If a file already exists in the source_map with the same id, that file is returned /// unmodified pub fn new_source_file(&self, filename: FileName, src: String) -> Lrc<SourceFile> { <ins> self.try_new_source_file(filename, src) .unwrap_or_else(|OffsetOverflowError| { eprintln!("fatal error: rustc does not support files larger than 4GB"); errors::FatalError.raise() }) } fn try_new_source_file( &self, filename: FileName, src: String ) -> Result<Lrc<SourceFile>, OffsetOverflowError> { </ins> let start_pos = self.next_start_pos(); // The path is used to determine the directory for loading submodules and

I know that having huge literal in source is a bad idea, but it should not cause ICE :( It looks like something overflowed. Version: Command, output and backtrace: Here is the generator of the source:
cc
Took a quick look. We certainly have a restriction that any file can't be that large, because we use u32 for indexing. And looks like we never try to enforce it anywhere. I think the place to do that would be . Do we have any way to panic without this being marked as ICE? I don't want to thread to each , and this seems like a marginal error where it's totally OK to panic. This is even OK in the IDE context I think: IDE should enforce reasonable max size of the file (something like 10mb, not 4gb) at the virtual file system layer. The "just panic" fix is here:
Do we have any way to panic without this being marked as ICE? or if the context is available.
I tried to compile the same thing in gcc and clang: With gcc: With clang: EDIT: Opened


Question: CONST_EVALUATABLE_UNCHECKED, INEFFECTIVE_UNSTABLE_TRAIT_IMPL, UNINHABITED_STATIC, <ins> FUNCTION_ITEM_REFERENCES, </ins> ] }


Question: CONST_EVALUATABLE_UNCHECKED, INEFFECTIVE_UNSTABLE_TRAIT_IMPL, UNINHABITED_STATIC, <ins> FUNCTION_ITEM_REFERENCES, </ins> ] }


Question: /// f.read_to_string(&mut buf).unwrap(); /// assert_eq!(&buf, hello); /// ``` <del> #[unstable(feature = "seek_rewind", issue = "85149")] </del> <ins> #[stable(feature = "seek_rewind", since = "1.55.0")] </ins> fn rewind(&mut self) -> Result<()> { self.seek(SeekFrom::Start(0))?; Ok(())

<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilization. Make sure to include the relevant RFC for the feature if it has one. If the new feature is small, it may be fine to skip the RFC process. In that case, you can use use in your initial implementation PR. The reviewer will ask you to open a tracking issue if they agree your feature can be without an RFC. --Feature gate: This is a tracking issue for the convenience method . [x] Implementation: [x] Final commenting period (FCP) [x] Stabilization PR: <!-- Once the feature has gone through a few release cycles and there are no unresolved questions left, the feature might be ready for stabilization. If this feature didn't go through the RFC process, a final commenting period (FCP) is always needed before stabilization. This works as follows: A library team member can kick off the stabilization process, at which point the rfcbot will ask all the team members to verify they agree with stabilization. Once enough members agree and there are no concerns, the final commenting period begins: this issue will be marked as such and will be listed in the next This Week in Rust newsletter. If no blocking concerns are raised in that period of 10 days, a stabilzation PR can be opened by anyone. --<!-- Include any open questions that need to be answered before the feature can be stabilised. If multiple (unrelated) big questions come up, it can be a good idea to open a separate issue for each, to make it easier to keep track of the discussions. It's useful to link any relevant discussions and conclusions (whether on GitHub, Zulip, or the internals forum) here. --- None yet.
merge
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 .


Question: /// f.read_to_string(&mut buf).unwrap(); /// assert_eq!(&buf, hello); /// ``` <del> #[unstable(feature = "seek_rewind", issue = "85149")] </del> <ins> #[stable(feature = "seek_rewind", since = "1.55.0")] </ins> fn rewind(&mut self) -> Result<()> { self.seek(SeekFrom::Start(0))?; Ok(())

: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.
I missed it completely in nigthlies sadly, else I would have proposed it returns the of the old offset, because currently it cannot replace , only the form without assignement.


Question: def update_submodules(self): """Update submodules""" <del> if (not os.path.exists(os.path.join(self.rust_root, ".git"))) or  self.get_toml('submodules') == "false": </del> <ins> has_git = os.path.exists(os.path.join(self.rust_root, ".git")) # This just arbitrarily checks for cargo, but any workspace member in # a submodule would work. has_submodules = os.path.exists(os.path.join(self.rust_root, "src/tools/cargo/Cargo.toml")) if not has_git and not has_submodules: print("This is not a git repository, and the requisite git submodules were not found.") print("If you downloaded the source from https://github.com/rust-lang/rust/releases,") print("those sources will not work. Instead, consider downloading from the source") print("releases linked at") print("https://forge.rust-lang.org/infra/other-installation-methods.html#source-code") print("or clone the repository at https://github.com/rust-lang/rust/.") raise SystemExit(1) if not has_git or self.get_toml('submodules') == "false": </ins> return default_encoding = sys.getdefaultencoding()

I run cp ans then build && install and I get: $ build && install downloading extracting G:rust-1.59.0rust-1.59.0buildcache2022-01-13rust-std-1.58.0-x8664-pc-windows- downloading extracting G:rust-1.59.0rust-1.59.0buildcache2022-01-13rustc-1.58.0-x8664-pc-windows- downloading extracting G:rust-1.59.0rust-1.59.0buildcache2022-01-13cargo-1.58.0-x8664-pc-windows- Building rustbuild error: failed to load manifest for workspace member Caused by: failed to read Caused by: The system cannot find the file specified. (os error 2) failed to run: G:rust-1.59.0rust-1.59.0buildx86_64-pc-windows-gnustage0bin build --manifest-path G:rust-1.59.0rust-1.59.0 Build completed unsuccessfully in 0:08:36
Can you say more about how you obtained and extracted the rust source? If you downloaded and extracted from , the directory should be there.
I downloaded the source from here: and the src/tools/rust-installer is there and is empty.
Ah, the tagged GitHub releases shouldn't be used. They do not include the git submodules. The link above is the one that should be used. Unfortunately we don't have the ability to disable GitHub releases, but we can probably add an error message to x.py if it can detect this scenario.
I did build && install and got $ build && install Building rustbuild Finished dev [unoptimized] target(s) in 1m 06s warning: creating symbolic link to failed with Incorrect function. (os error 1) Building stage0 std artifacts (x8664-pc-windows-gnu -x8664-pc-windows-gnu) Finished release [optimized] target(s) in 39.


Question: def update_submodules(self): """Update submodules""" <del> if (not os.path.exists(os.path.join(self.rust_root, ".git"))) or  self.get_toml('submodules') == "false": </del> <ins> has_git = os.path.exists(os.path.join(self.rust_root, ".git")) # This just arbitrarily checks for cargo, but any workspace member in # a submodule would work. has_submodules = os.path.exists(os.path.join(self.rust_root, "src/tools/cargo/Cargo.toml")) if not has_git and not has_submodules: print("This is not a git repository, and the requisite git submodules were not found.") print("If you downloaded the source from https://github.com/rust-lang/rust/releases,") print("those sources will not work. Instead, consider downloading from the source") print("releases linked at") print("https://forge.rust-lang.org/infra/other-installation-methods.html#source-code") print("or clone the repository at https://github.com/rust-lang/rust/.") raise SystemExit(1) if not has_git or self.get_toml('submodules') == "false": </ins> return default_encoding = sys.getdefaultencoding()

65s Copying stage0 std from stage0 (x8664-pc-windows-gnu -x8664-pc-windows-gnu / x8664-pc-windows-gnu) Building LLVM for x8664-pc-windows-gnu running: "cmake" "G:rustc-1.59.0-srcrustc-1.59.0-srcsrc/llvm-project/llvm" "-G" "Ninja" "-DLLVMENABLEASSERTIONS=OFF" "-DLLVMENABLEPLUGINS=OFF" "-DLLVMTARGETSTOBUILD=AArch64;ARM;BPF;Hexagon;MSP430;Mips;NVPTX;PowerPC;RISCV;Sparc;SystemZ;WebAssembly;X86" "-DLLVMEXPERIMENTALTARGETSTOBUILD=AVR;M68k" "-DLLVMINCLUDEEXAMPLES=OFF" "-DLLVMINCLUDEDOCS=OFF" "-DLLVMINCLUDEBENCHMARKS=OFF" "-DLLVMINCLUDETESTS=OFF" "-DLLVMENABLETERMINFO=OFF" "-DLLVMENABLELIBEDIT=OFF" "-DLLVMENABLEBINDINGS=OFF" "-DLLVMENABLEZ3SOLVER=OFF" "-DLLVMPARALLELCOMPILEJOBS=4" "-DLLVMTARGETARCH=x8664" "-DLLVMDEFAULTTARGETTRIPLE=x8664-pc-windows-gnu" "-DLLVMINSTALLUTILS=ON" "-DLLVMENABLEZLIB=OFF" "-DLLVMENABLELIBXML2=OFF" "-DLLVMVERSIONSUFFIX=-rust-dev" "-DCMAKEINSTALLMESSAGE=LAZY" "-" "-" "-" "-DCMAKECFLAGS=-ffunction-sections -fdata-sections -m64" "-DCMAKECXXFLAGS=-ffunction-sections -fdata-sections -m64" "-DCMAKEINSTALLPREFIX=G:rustc-1.59.0-srcrustc-1.59.0-srcbuildx8664-pc-windows-gnullvm" "-DCMAKEASMFLAGS= -ffunction-sections -fdata-sections -m64" "-DCMAKEBUILDTYPE=Release" -- Could NOT find Backtrace (missing: BacktraceLIBRARY BacktraceINCLUDEDIR) -- Native target architecture is X86 -- Threads enabled. -- Doxygen disabled. -- Go bindings disabled.


Question: def update_submodules(self): """Update submodules""" <del> if (not os.path.exists(os.path.join(self.rust_root, ".git"))) or  self.get_toml('submodules') == "false": </del> <ins> has_git = os.path.exists(os.path.join(self.rust_root, ".git")) # This just arbitrarily checks for cargo, but any workspace member in # a submodule would work. has_submodules = os.path.exists(os.path.join(self.rust_root, "src/tools/cargo/Cargo.toml")) if not has_git and not has_submodules: print("This is not a git repository, and the requisite git submodules were not found.") print("If you downloaded the source from https://github.com/rust-lang/rust/releases,") print("those sources will not work. Instead, consider downloading from the source") print("releases linked at") print("https://forge.rust-lang.org/infra/other-installation-methods.html#source-code") print("or clone the repository at https://github.com/rust-lang/rust/.") raise SystemExit(1) if not has_git or self.get_toml('submodules') == "false": </ins> return default_encoding = sys.getdefaultencoding()

-- Ninja version: 1.10.2 -- Could NOT find OCaml (missing: OCAMLFIND OCAMLVERSION OCAMLSTDLIBPATH) -- OCaml bindings disabled. -- LLVM host triple: x8664-w64-windows-gnu -- LLVM default target triple: x8664-pc-windows-gnu -- LLVMHello ignored -- Loadable modules not supported on this platform. -- Targeting AArch64 -- Targeting ARM -- Targeting BPF -- Targeting Hexagon -- Targeting MSP430 -- Targeting Mips -- Targeting NVPTX -- Targeting PowerPC -- Targeting RISCV -- Targeting Sparc -- Targeting SystemZ -- Targeting WebAssembly -- Targeting X86 -- Targeting AVR -- Targeting M68k -- BugpointPasses ignored -- Loadable modules not supported on this platform. -- Configuring done -- Generating done -- Build files have been written to: G:/rustc-1.59.0-src/rustc-1.59.0-src/build/x8664-pc-windows-gnu/llvm/build running: "cmake" "--build" "." "--target" "install" "--config" "Release" "--" "-j" "4" [1/2594] Building FAILED: G:/rustc-1.59.0-src/rustc-1.59.0-src/build/x8664-pc-windows- /C "cd /D G:rustc-1.59.0-srcrustc-1.59.0-srcbuildx8664-pc-windows-gnullvmbuild && G:rustc-1.59.0-srcrustc-1.59.0-srcbuildx8664-pc-windows-gnullvmbuildbinllvm- -gen-attrs -I G:/rustc-1.59.0-src/rustc-1.59.0-src/src/llvm-project/llvm/include/llvm/IR -IG:/rustc-1.59.0-src/rustc-1.59.0-src/build/x8664-pc-windows-gnu/llvm/build/include -IG:/rustc-1.59.0-src/rustc-1.59.0-src/src/llvm-project/llvm/include G:/rustc-1.59.0-src/rustc-1.59.


Question: def update_submodules(self): """Update submodules""" <del> if (not os.path.exists(os.path.join(self.rust_root, ".git"))) or  self.get_toml('submodules') == "false": </del> <ins> has_git = os.path.exists(os.path.join(self.rust_root, ".git")) # This just arbitrarily checks for cargo, but any workspace member in # a submodule would work. has_submodules = os.path.exists(os.path.join(self.rust_root, "src/tools/cargo/Cargo.toml")) if not has_git and not has_submodules: print("This is not a git repository, and the requisite git submodules were not found.") print("If you downloaded the source from https://github.com/rust-lang/rust/releases,") print("those sources will not work. Instead, consider downloading from the source") print("releases linked at") print("https://forge.rust-lang.org/infra/other-installation-methods.html#source-code") print("or clone the repository at https://github.com/rust-lang/rust/.") raise SystemExit(1) if not has_git or self.get_toml('submodules') == "false": </ins> return default_encoding = sys.getdefaultencoding()

0-src/src/llvm- --write-if-changed -o -d " [2/2594] Building FAILED: G:/rustc-1.59.0-src/rustc-1.59.0-src/build/x8664-pc-windows- /C "cd /D G:rustc-1.59.0-srcrustc-1.59.0-srcbuildx8664-pc-windows-gnullvmbuild && G:rustc-1.59.0-srcrustc-1.59.0-srcbuildx8664-pc-windows-gnullvmbuildbinllvm- -gen-intrinsic-impl -I G:/rustc-1.59.0-src/rustc-1.59.0-src/src/llvm-project/llvm/include/llvm/IR -IG:/rustc-1.59.0-src/rustc-1.59.0-src/build/x8664-pc-windows-gnu/llvm/build/include -IG:/rustc-1.59.0-src/rustc-1.59.0-src/src/llvm-project/llvm/include G:/rustc-1.59.0-src/rustc-1.59.0-src/src/llvm- --write-if-changed -o -d " [3/2594] Building IntrinsicsARM.h. FAILED: include/llvm/IR/IntrinsicsARM.h G:/rustc-1.59.0-src/rustc-1.59.0-src/build/x8664-pc-windows-gnu/llvm/build/include/llvm/IR/IntrinsicsARM.h /C "cd /D G:rustc-1.59.0-srcrustc-1.59.0-srcbuildx8664-pc-windows-gnullvmbuild && G:rustc-1.59.0-srcrustc-1.59.0-srcbuildx8664-pc-windows-gnullvmbuildbinllvm- -gen-intrinsic-enums -intrinsic-prefix=arm -I G:/rustc-1.59.0-src/rustc-1.59.0-src/src/llvm-project/llvm/include/llvm/IR -IG:/rustc-1.59.0-src/rustc-1.59.


Question: def update_submodules(self): """Update submodules""" <del> if (not os.path.exists(os.path.join(self.rust_root, ".git"))) or  self.get_toml('submodules') == "false": </del> <ins> has_git = os.path.exists(os.path.join(self.rust_root, ".git")) # This just arbitrarily checks for cargo, but any workspace member in # a submodule would work. has_submodules = os.path.exists(os.path.join(self.rust_root, "src/tools/cargo/Cargo.toml")) if not has_git and not has_submodules: print("This is not a git repository, and the requisite git submodules were not found.") print("If you downloaded the source from https://github.com/rust-lang/rust/releases,") print("those sources will not work. Instead, consider downloading from the source") print("releases linked at") print("https://forge.rust-lang.org/infra/other-installation-methods.html#source-code") print("or clone the repository at https://github.com/rust-lang/rust/.") raise SystemExit(1) if not has_git or self.get_toml('submodules') == "false": </ins> return default_encoding = sys.getdefaultencoding()

0-src/build/x8664-pc-windows-gnu/llvm/build/include -IG:/rustc-1.59.0-src/rustc-1.59.0-src/src/llvm-project/llvm/include G:/rustc-1.59.0-src/rustc-1.59.0-src/src/llvm- --write-if-changed -o include/llvm/IR/IntrinsicsARM.h -d include/llvm/IR/IntrinsicsARM.h.d" [4/2594] Building IntrinsicsHexagon.h. FAILED: include/llvm/IR/IntrinsicsHexagon.h G:/rustc-1.59.0-src/rustc-1.59.0-src/build/x8664-pc-windows-gnu/llvm/build/include/llvm/IR/IntrinsicsHexagon.h /C "cd /D G:rustc-1.59.0-srcrustc-1.59.0-srcbuildx8664-pc-windows-gnullvmbuild && G:rustc-1.59.0-srcrustc-1.59.0-srcbuildx8664-pc-windows-gnullvmbuildbinllvm- -gen-intrinsic-enums -intrinsic-prefix=hexagon -I G:/rustc-1.59.0-src/rustc-1.59.0-src/src/llvm-project/llvm/include/llvm/IR -IG:/rustc-1.59.0-src/rustc-1.59.0-src/build/x8664-pc-windows-gnu/llvm/build/include -IG:/rustc-1.59.0-src/rustc-1.59.0-src/src/llvm-project/llvm/include G:/rustc-1.59.0-src/rustc-1.59.0-src/src/llvm- --write-if-changed -o include/llvm/IR/IntrinsicsHexagon.h -d include/llvm/IR/IntrinsicsHexagon.h.d" ninja: build stopped: subcommand failed.


Question: def update_submodules(self): """Update submodules""" <del> if (not os.path.exists(os.path.join(self.rust_root, ".git"))) or  self.get_toml('submodules') == "false": </del> <ins> has_git = os.path.exists(os.path.join(self.rust_root, ".git")) # This just arbitrarily checks for cargo, but any workspace member in # a submodule would work. has_submodules = os.path.exists(os.path.join(self.rust_root, "src/tools/cargo/Cargo.toml")) if not has_git and not has_submodules: print("This is not a git repository, and the requisite git submodules were not found.") print("If you downloaded the source from https://github.com/rust-lang/rust/releases,") print("those sources will not work. Instead, consider downloading from the source") print("releases linked at") print("https://forge.rust-lang.org/infra/other-installation-methods.html#source-code") print("or clone the repository at https://github.com/rust-lang/rust/.") raise SystemExit(1) if not has_git or self.get_toml('submodules') == "false": </ins> return default_encoding = sys.getdefaultencoding()

thread 'main' panicked at ' command did not execute successfully, got: exit code: 1 build script failed, must exit now', C:UsersDragon boy.cargoregistrysrccmake-0.1.44src note: run with environment variable to display a backtrace finished in 70.343 seconds Build completed unsuccessfully in 0:04:02


Question: hasher.finish() }; let end_pos = start_pos.to_usize() + src.len(); <ins> if end_pos > u32::max_value() as usize { return Err(OffsetOverflowError); } </ins> let (lines, multibyte_chars, non_narrow_chars) = analyze_source_file::analyze_source_file(&src[..], start_pos); <del> SourceFile { </del> <ins> Ok(SourceFile { </ins> name, name_was_remapped, unmapped_path: Some(unmapped_path),


Question: fn main() { let x = Foo; x.zero(0)   //~ ERROR this function takes 0 parameters but 1 parameter was supplied <ins> //~^ NOTE expected 0 parameters </ins> .one()     //~ ERROR this function takes 1 parameter but 0 parameters were supplied //~^ NOTE the following parameter type was expected <ins> //~| NOTE expected 1 parameter </ins> .two(0);   //~ ERROR this function takes 2 parameters but 1 parameter was supplied //~^ NOTE the following parameter types were expected <ins> //~| NOTE expected 2 parameters </ins> let y = Foo; y.zero()

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


Question: <ins> error: expected `;`, found `#` --> $DIR/multiple-tail-expr-behind-cfg.rs:5:64 | LL |     #[cfg(feature = "validation")] |     ------------------------------ only `;` terminated statements or tail expressions are allowed after this attribute LL |     [1, 2, 3].iter().map(|c| c.to_string()).collect::<String>() |                                                                ^ expected `;` here LL |     #[cfg(not(feature = "validation"))] |     - unexpected token | help: add `;` here | LL |     [1, 2, 3].iter().map(|c| c.to_string()).collect::<String>(); |                                                                + help: alternatively, consider surrounding the expression with a block | LL |     { [1, 2, 3].iter().map(|c| c.to_string()).collect::<String>() } |     +                                                             + help: it seems like you are trying to provide different expressions depending on `cfg`, consider using `if cfg!(..)` | LL ~     if cfg!(feature = "validation") { LL ~         [1, 2, 3].iter().map(|c| c.to_string()).collect::<String>() LL ~     } else if cfg!(not(feature = "validation")) { LL ~         String::new() LL +     } | error: expected `;`, found `#` --> $DIR/multiple-tail-expr-behind-cfg.rs:12:64 | LL |     #[attr] |     ------- only `;` terminated statements or tail expressions are allowed after this attribute LL |     [1, 2, 3].iter().map(|c| c.to_string()).collect::<String>() |                                                                ^ expected `;` here LL |     #[attr] |     - unexpected token | help: add `;` here | LL |     [1, 2, 3].iter().map(|c| c.to_string()).collect::<String>(); |                                                                + help: alternatively, consider surrounding the expression with a block | LL |     { [1, 2, 3].iter().map(|c| c.to_string()).collect::<String>() } |     +                                                             + error: cannot find attribute `attr` in this scope --> $DIR/multiple-tail-expr-behind-cfg.rs:13:7 | LL |     #[attr] |       ^^^^ error: aborting due to 3 previous errors </ins>

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


Question: <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. #![deny(unused_variable)] fn main() { for _ in range(1i, 101) { let x = (); //~ ERROR: unused variable: `x` match () { a => {} //~ ERROR: unused variable: `a` } } } </ins>

compiles without a peep, even though and are unused. Commenting out the gives the expected output:
I think this an be closed
Thanks (fixed in )


Question: signature. Each type parameter must be explicitly declared, in an angle-bracket-enclosed, comma-separated list following the function name. <del> ```{.ignore} fn iter<T, F>(seq: &[T], f: F) where T: Copy, F: Fn(T) { for elt in seq { f(*elt); } } fn map<T, U, F>(seq: &[T], f: F) -> Vec<U> where T: Copy, U: Copy, F: Fn(T) -> U { let mut acc = vec![]; for elt in seq { acc.push(f(*elt)); } acc } </del> <ins> ```rust,ignore // foo is generic over A and B fn foo<A, B>(x: A, y: B) { </ins> ``` Inside the function signature and body, the name of the type parameter can be used as a type name. [Trait](#traits) bounds can be specified for type parameters to allow methods with that trait to be called on values of that type. This is <del> specified using the `where` syntax, as in the above example. </del> <ins> specified using the `where` syntax: ```rust,ignore fn foo<T>(x: T) where T: Debug { ``` </ins> When a generic function is referenced, its type is instantiated based on the context of the reference. For example, calling the `iter` function defined

In the in the section it is stated that (emphasis mine) But the example shows a type parameter on , which requires parenthesis-enclosed type parameters rather than angle-brackets. mentioned on IRC that this might be some special case to open the possibility to easier change the traits at a later time (if I understood correctly), but I found it confusing to see a specialization using parenthesis without ever having heard they existed.
Isn't the text referring to Those angle brackets? "following the function name"
Yeah, I suspect the real confusion here is that the syntax with parens has not yet been introduced (nor is it explained anywhere, apparently), so it's the wrong example at this point in the document, and it's not clear to a first-time reader what is being referred to. It seems like there should be a sufficient example here that doesn't use closures, maybe one simple one with and , and one using traits over collections or iterators or something, to demonstrate that parameterized types can appear in the bounds, to make it easier to understand. That said, the reference is explicitly not intended to be pedagogical, and implicitly not yet expected to be complete.


Question: #![allow(unused_variables)]; //~ ERROR expected item, found `;` <del> //~^ ERROR `main` function </del> fn foo() {} <ins> //~^ ERROR `main` function </ins>

Tested on nightly and stable. The second diagnostic is strange. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-diagnostics S-has-mvce
claim
any idea why rustbot ignored me?
Just guessing, the missing + for S-has-mcve maybe?
Oops, this should'nt've been closed.


Question: See [LICENSE-APACHE](LICENSE-APACHE), [LICENSE-MIT](LICENSE-MIT), and [COPYRIGHT](COPYRIGHT) for details. <ins> ## Trademark [trademark]: #trademark The Rust programming language is an open source, community project governed by a core team. It is also sponsored by the Mozilla Foundation (“Mozilla”), which owns and protects the Rust and Cargo trademarks and logos (the “Rust Trademarks”). If you want to use these names or brands, please read the [media guide][media-guide]. Third-party logos may be subject to third-party copyrights and trademarks. See [Licenses][policies-licenses] for details. [media-guide]: https://www.rust-lang.org/policies/media-guide [policies-licenses]: https://www.rust-lang.org/policies/licenses </ins>

Want to fix this bug? There are . This github repository does not contain a trademark file, and I am curious if still applies, as it would seem. Debian and some other distributions are applying patches against the Rust language and Cargo package. I assume this qualifies as something which requires explicit approval? If so, removing or restricting packages from Cargo would also be considered a modification. e.g. some distributions may wish to block access to Cargo downloads that are not in compliance with license standards. Just wanted to get some clarification on this as it is not mentioned here in the repo and some folks seems to think that because there is no trademark "here" that rust-lang can be distributed with modifications without approval. I believe the only way such modifications would be allowed unrestricted, is if "rust" was not used at all in the package and it was clearly defined as a rebranded fork that is not affiliated with the official package - Otherwise the trademark policy is still enforced.
This question should be asked at the linked on the Legal page rather than here.
Just received a response. It seems a may be useful to direct people to the appropriate from github. This issue can be closed once trademark notification is included or mentioned on Thank you.
I've tagged this issue as and . To close this bug, we should add a new section to that mentions that there are trademarks on the rust name and logo, and link to If you want to fix this bug and need any help, please let me know, and I'm happy to assist!
Hi I'd like to work on this and opened to add a section about trademarks. But I'm not sure whether I made appropriate wording. Could you please help to review? Thanks a lot.
Any news regarding this ^ Cheers


Question: #[rustc_const_unstable(feature = "const_waker", issue = "102012")] pub const fn build(self) -> Context<'a> { let ContextBuilder { waker, local_waker, ext, _marker, _marker2 } = self; <del> Context { waker, local_waker, ext, _marker, _marker2 } </del> <ins> Context { waker, local_waker, ext: AssertUnwindSafe(ext), _marker, _marker2 } </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: ///     } /// } /// ``` <del> fn lower_expr_await(&mut self, await_span: Span, expr: &Expr) -> hir::ExprKind<'hir> { let dot_await_span = expr.span.shrink_to_hi().to(await_span); </del> <ins> fn lower_expr_await(&mut self, dot_await_span: Span, expr: &Expr) -> hir::ExprKind<'hir> { let full_span = expr.span.to(dot_await_span); </ins> match self.generator_kind { Some(hir::GeneratorKind::Async(_)) => {} Some(hir::GeneratorKind::Gen) | None => { let mut err = struct_span_err!( self.sess, <del> await_span, </del> <ins> dot_await_span, </ins> E0728, "`await` is only allowed inside `async` functions and blocks" ); <del> err.span_label(await_span, "only allowed inside `async` functions and blocks"); </del> <ins> err.span_label(dot_await_span, "only allowed inside `async` functions and blocks"); </ins> if let Some(item_sp) = self.current_item { err.span_label(item_sp, "this is not `async`"); }

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: <ins> // compile-flags:--test // run-pass // ignore-emscripten no subprocess support use std::fmt; use std::fmt::{Display, Formatter}; pub struct A(Vec<u32>); impl Display for A { fn fmt(&self, _f: &mut Formatter<'_>) -> fmt::Result { self.0[0]; Ok(()) } } #[test] fn main() { let result = std::panic::catch_unwind(|| { let a = A(vec![]); eprintln!("{}", a); }); assert!(result.is_err()); } </ins>

I tried this code (using ): I expected to see this happen: The thread should've panicked with 'Index out of bounds: the len is 0 but the index is 0' Instead, this happened: Thread crashes with SIGILL (illegal instruction) This bug works in stable, beta and nightly. It also does the same in . Here is my (I figured that it might be useful given the nature of the bug). The bug doesn't appear if run from main, nor if run directly (without passing from the Display impl). : <details<summaryBacktrace</summary<prunning 1 test thread panicked while processing panic. aborting. error: test failed, to rerun pass '--lib' Caused by: process didn't exit successfully: (signal: 4, SIGILL: illegal instruction) </p</details
This seems to be due to the . Using instead works fine.
I can reproduce. This seems to happen if LOCALSTDERR is initialized (e.g., with setpanic) which leads us to this . Note that the RefCell there is borrowed so that we can write to it, but then when we go to panic we try to temporarily . This borrows the RefCell mutably, again, leading to a panic. Since this happens within an existing panic, we abort the process. Smaller example:


Question: <ins> error: using function pointers as const generic parameters is forbidden --> $DIR/default-ty-closure.rs:3:20 | LL | struct X<const FN: fn() = { || {} }>; |                    ^^^^ | = note: the only supported types are integers, `bool` and `char` error: aborting due to 1 previous error </ins>

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
really need to add auto-bisection to icemaker reports... Regression in nightly-2021-04-26 found 9 bors merge commits in the specified range commit[0] 2021-04-24: Auto merge of - davidhewitt:revert-, r=GuillaumeGomez commit[1] 2021-04-24: Auto merge of - RalfJung:const-fn-feature-flags, r=oli-obk commit[2] 2021-04-25: Auto merge of - jyn514:no-span, r=GuillaumeGomez commit[3] 2021-04-25: Auto merge of - CDirkx:rt, r=m-ou-se commit[4] 2021-04-25: Auto merge of - cuviper:array-method-dispatch, r=nikomatsakis,m-ou-se commit[5] 2021-04-25: Auto merge of - RalfJung:black-box, r=Mark-Simulacrum commit[6] 2021-04-25: Auto merge of - lcnr:const-generics-defaults-name-res, r=varkor commit[7] 2021-04-25: Auto merge of - RalfJung:miri, r=RalfJung commit[8] 2021-04-25: Auto merge of - jsha:ephemeral-collapse, r=GuillaumeGomez maybe ?
hm, with , this crashes like this:
Hmm, I'm confused by the result of the bisection, I expected it to find a relatively recent commit since the reproducer doesn't ICE on stable (1.73) (while it does ICE on beta and nightly):
Doesn't ICE if is enabled.
this feature fixing an ice instead of causing one, that's a first...
This errors cleanly since beta 1.76.


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. // no-prefer-dynamic #[crate_id = "collections#0.10-pre"]; #[crate_type = "dylib"]; </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. // no-prefer-dynamic #[crate_id = "collections#0.10-pre"]; #[crate_type = "dylib"]; </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: let err = LifetimeOutliveErr { span: *span }; let mut diag = self.infcx.tcx.sess.create_err(err); <del> let fr_name = self.give_region_a_name(*fr).unwrap(); </del> <ins> // In certain scenarios, such as the one described in issue #118021, // we might encounter a lifetime that cannot be named. // These situations are bound to result in errors. // To prevent an immediate ICE, we opt to create a dummy name instead. let fr_name = self.give_region_a_name(*fr).unwrap_or(RegionName { name: kw::UnderscoreLifetime, source: RegionNameSource::Static, }); </ins> fr_name.highlight_region_name(&mut diag); let outlived_fr_name = self.give_region_a_name(*outlived_fr).unwrap(); outlived_fr_name.highlight_region_name(&mut diag);

<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'called on a value'', 'thread 'rustc' panicked at 'called on a value'' 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<!-- query stack: [mirborrowck] borrow-checking [mirdropselaboratedandconstchecked] elaborating drops for [mirforctfe] caching mir of for CTFE [evaltoallocationraw] const-evaluating + checking [evaltovaltree] evaluating type-level constant [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
Regression in nightly-2022-06-08 found 7 bors merge commits in the specified range commit[0] 2022-06-06: Auto merge of - flip1995:clippyup, r=Manishearth commit[1] 2022-06-06: Auto merge of - matthiaskrgr:rollup-ajyvjd3, r=matthiaskrgr commit[2] 2022-06-07: Auto merge of - RalfJung:miri, r=RalfJung commit[3] 2022-06-07: Auto merge of - jackh726:remove-borrowck-mode, r=nikomatsakis commit[4] 2022-06-07: Auto merge of - scottmcm:add-coldcc, r=nagisa,lcnr commit[5] 2022-06-07: Auto merge of - Dylan-DPC:rollup-ya51k1k, r=Dylan-DPC commit[6] 2022-06-07: Auto merge of - Dylan-DPC:rollup-0ae3pwp, r=Dylan-DPC ERROR: no CI builds available between and within last 167 days
I guess? :thinking: