Question: ); } <ins> let is_fn_trait = [ self.tcx.lang_items().fn_trait(), self.tcx.lang_items().fn_mut_trait(), self.tcx.lang_items().fn_once_trait(), ] .contains(&Some(trait_ref.def_id())); let is_target_feature_fn = if let ty::FnDef(def_id, _) = trait_ref.skip_binder().self_ty().kind { !self.tcx.codegen_fn_attrs(def_id).target_features.is_empty() } else { false }; if is_fn_trait && is_target_feature_fn { err.note( "`#[target_feature]` functions do not implement the `Fn` traits", ); } </ins> // Try to report a help message if !trait_ref.has_infer_types_or_consts() && self.predicate_can_apply(obligation.param_env, trait_ref)

(Moved from with an PoC.) The following program () demonstrates how current implementation of allows using a targetfeature from safe code without ensuring it's actually available: This is unsound because it allows executing (e.g.) AVX instructions on CPUs that do not implement them, which is UB. It only works because "safe fns with targetfeatures" are erroneously considered to implement the FnOnce/FnMut/Fn traits.
Proposed resolution: It would probably be better to add the to functions implicitly during lowering to HIR. Implicit is already to functions in blocks in the same way. That would make the unsafety checker the only place (besides AST lowering) where they would be treated specially. Like, "yes, the function is unsafe, but we know that it's safe to call in this specific context, so the unsafe block can be omitted". The special coercion checks would no longer be necessary in that case.
Or perhaps the RFC should be revised to still require writing and only unsafety checker need to be enhanced to allow calling unsafe functions without unsafe blocks in the situations known to be safe. That would be even less magic, which is good, IMO. The ergonomic regression would be minor because would still be not required at call sites.
Good catch. Another option is that referencing, not calling, a target-feature function is unsafe, but I guess that is a bit inconsistent given that this already compiles (): In other words, accessing a safe target feature 1.1 function would be unsafe (unless the target feature is in scope), not just calling it. I think that this is what I would expect somehow, but I would expect it to apply uniformly to both safe and unsafe target feature functions (and that's not an option). The downside of this approach is that we don't know why the function was declared unsafe, not really -- was it only because of the target feature? Or were there additional requirements that would have made it unsafe?
For example, a whole bunch of functions take raw pointers and use them to access memory, so they need to be unsafe even if the respective target feature is enabled in the calling context.
The downside of this approach is that we don't know why the function was declared unsafe, not really -- was it only because of the target feature? Or were there additional requirements that would have made it unsafe? Ah, right, that's a good argument.


Question: ); } <ins> let is_fn_trait = [ self.tcx.lang_items().fn_trait(), self.tcx.lang_items().fn_mut_trait(), self.tcx.lang_items().fn_once_trait(), ] .contains(&Some(trait_ref.def_id())); let is_target_feature_fn = if let ty::FnDef(def_id, _) = trait_ref.skip_binder().self_ty().kind { !self.tcx.codegen_fn_attrs(def_id).target_features.is_empty() } else { false }; if is_fn_trait && is_target_feature_fn { err.note( "`#[target_feature]` functions do not implement the `Fn` traits", ); } </ins> // Try to report a help message if !trait_ref.has_infer_types_or_consts() && self.predicate_can_apply(obligation.param_env, trait_ref)

The "unsafety checker enhancement" should only affect unsafe functions that are made unsafe through , but not other means (explicit or block).
I'm new to the compiler, but it seemed non-trivial to change functions to unsafe when lowering to HIR. It looks to me like you'd end up with just as many exceptions (ignoring the unsafe in some scenarios), in addition tracking the origin of the . On the other hand it was pretty trivial to not implement the Fn traits instead. I'll open a PR with my fix, but please close it if the other method is preferred.
So there are sort of two questions here. One of them is what user-visible behavior is permitted, and the other is how precisely that is implemented in the compiler. I think the latter only concerns the team in-so-far as it represents the impact on the language spec and on the "mental model" that users must keep in mind. Nominating for the lang-team meeting to discuss solution, which is simply to make "target-feature" functions not implement the traits (just as functions do not implement the traits, along with functions with non-Rust ABIs etc).
I think I was tagged by mistake :wink:
Apologies! Fixed. Github autocompleted that for me. Here I was feeling so grateful to it.
We discussed this in . The conclusion was that the fix that proposed is good for right now. It's already the case that many items do not implement the function trait (e.g., those with custom ABIs or which are unsafe), so this would be "yet another" case (admittedly a somewhat different one in that this case doesn't show up in the type of function pointers, for better or worse). We uncovered a few other interesting observations: pointed out that their ideal preference would be to have something like " only implements " within an unsafe block, but of course the trait system has no precedent for that. It would be sort of like a attached to the impl block (i.e., the impl is usable in some context where unsafe code is allowed). Another possibility might be " only implements within a fn that has a suitable target feature in scope". This is an interesting idea because, although the pointer could escape in the form of a , the idea is that once you enter , you've already demonstrated that you possess the target feature, so it's ok if the value escapes.


Question: ); } <ins> let is_fn_trait = [ self.tcx.lang_items().fn_trait(), self.tcx.lang_items().fn_mut_trait(), self.tcx.lang_items().fn_once_trait(), ] .contains(&Some(trait_ref.def_id())); let is_target_feature_fn = if let ty::FnDef(def_id, _) = trait_ref.skip_binder().self_ty().kind { !self.tcx.codegen_fn_attrs(def_id).target_features.is_empty() } else { false }; if is_fn_trait && is_target_feature_fn { err.note( "`#[target_feature]` functions do not implement the `Fn` traits", ); } </ins> // Try to report a help message if !trait_ref.has_infer_types_or_consts() && self.predicate_can_apply(obligation.param_env, trait_ref)

(This would be like a clause.) To that end, I was thinking that you could model this last point using closures, but I found that it doesn't work. In particular, gives an error, even if it appears inside of a function annotated with . This seems like something we should discuss, but it's a separate issue. We did discuss briefly whether target features should be part of the type of function pointers but I think the conclusion was 'well maybe but there is already stable code out there that lets you coerce, and it seems rather niche'. We also discussed whether we should permit one to annotate closures with target-feature annotations. In any case, those are things we can address separately from this issue, but the point is that adopting more accepting solutions can be done in the future.
I'm going to move the question of whether closures should "inherit" target features to the main tracking issue -- I'm not sure if that is something that was discussed as part of the original RFC discussion?
Opened to discuss closures.


Question: ty ); // Fast path: if this is a primitive simple `==` will work <del> let saw_impl = impl_type == ty; </del> <ins> // NOTE: the `match` is necessary; see #92662. // this allows us to ignore generics because the user input // may not include the generic placeholders // e.g. this allows us to match Foo (user comment) with Foo<T> (actual type) let saw_impl = impl_type == ty || match (impl_type.kind(), ty.kind()) { (ty::Adt(impl_def, _), ty::Adt(ty_def, _)) => { debug!("impl def_id: {:?}, ty def_id: {:?}", impl_def.did, ty_def.did); impl_def.did == ty_def.did } _ => false, }; </ins> if saw_impl { Some(trait_) } else { None } })

<!-- 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. --Example code: docs build successfully on 1.57.0: docs fail to build on 1.59.0-nightly ( 2022-01-04): </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-{channel} -regression-untriaged --The generics appear necessary for the bug. Removing them from either the type or the trait resolves the failure. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Probably . searched nightlies: from nightly-2022-01-06 to nightly-2022-01-07 regressed nightly: nightly-2022-01-07 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: aarch64-apple-darwin Reproduce with: </details
just saw this, I think might be caused by this change: I'm looking into it
claim


Question: #[derive(Clone)] enum Enum { <del> Variant1, //~ ERROR: variant is never used </del> <ins> Variant1, //~ ERROR: variant is never constructed </ins> Variant2, }

I was changing some code from integer constants to a proper enum and was greeted by the following warning: The warning sounded weird to me because I was pattern-matching on that damn variant in various places of the code; but I was pointed out to the fact that I wasn't actually creating that value. Maybe the warning should be rewritten to explicitly mention value creation? Cc
cc that looks like your thing
duplicate of
Yup! Closing in favor of that.


Question: /// of the type. fn in_any_value_of_ty(_cx: &ConstCx<'_, 'tcx>, _ty: Ty<'tcx>) -> bool; <del> fn in_static(cx: &ConstCx<'_, 'tcx>, def_id: DefId) -> bool { // `mir_const_qualif` does return the qualifs in the final value of a `static`, so we could // use value-based qualification here, but we shouldn't do this without a good reason. Self::in_any_value_of_ty(cx, cx.tcx.type_of(def_id)) } </del> fn in_projection_structurally( cx: &ConstCx<'_, 'tcx>, per_local: &impl Fn(Local) -> bool,

root: gb2260-0.1.1: v. root: imperative - 3 (1 gh, 2 ) detected crates which regressed due to this <detailscommitted-0.1.11: v. imperative-1.0.1: v. epage/committed: v. </detailscc (likely MIR borrowck related, though not the transition itself as that happened last cycle)
Probably a result of the soundness fixes in
This is a change in promotion. cc
Minimized:
Maybe ?
or . No, it's neither of these.
It's , likely .


Question: /// with this error. /// /// [`from_utf8_unchecked`]: struct.String.html#method.from_utf8_unchecked <del> /// [`&str`]: ../../std/primitive.str.html </del> <ins> /// [`String`]: struct.String.html </ins> /// [`u8`]: ../../std/primitive.u8.html /// [`Vec<u8>`]: ../../std/vec/struct.Vec.html /// [`str::from_utf8`]: ../../std/str/fn.from_utf8.html <del> /// [`as_bytes`]: struct.String.html#method.as_bytes </del> <ins> /// [`into_bytes`]: struct.String.html#method.into_bytes </ins> /// [`FromUtf8Error`]: struct.FromUtf8Error.html /// [`Err`]: ../../std/result/enum.Result.html#variant.Err #[inline]

This chunk was supposedly copy-pasted as is from It should read A String ([]) is made of bytes
Hi there. Can I pick this up as first-timer task?


Question: self.lldb_git_commit_hash = self.git_commit_hash("lldb", "x86_64-unknown-linux-gnu"); self.miri_git_commit_hash = self.git_commit_hash("miri", "x86_64-unknown-linux-gnu"); <ins> self.check_toolstate(); </ins> self.digest_and_sign(); let manifest = self.build_manifest(); self.write_channel_files(&self.rust_release, &manifest);

Looking at https://rust-, it seems like Miri is getting shipped as a rustup component even though the tests fail. Unfortunately, Miri is currently entirely usable, so it'd probably be better if it did not get shipped in this state. Is that something we can do? Cc
maybe we can make the miri toolstate always go to even if it technically is just
what would be the best place to change this? I think I'd prefer Miri not to be shipped at all when the tests fail; I'd rather people stick to an old-but-working Miri than to a new-but-broken one. I found but that does not seem to decide if a component gets built for distribution or not.
seems to suggest that it is supposed to work as you describe that it should be working. Since it obviously doesn't and I can't see how that comment could be true from looking at the source, I'm guessing this is some refactoring fallout. I'll dig a little into git blame
I found it. The comment was for rls in but then the code making the comment true was removed later
See for why this is hard to fix: the builders don't even run the tool tests, so they cannot know if the tests pass. :/ Also, that's probably for the better actually, as the "tools" builder sets --cfg miri to be more Miri-friendly and we don't want that in the release artifacts.
One (crazy?) thing we could so is have the dist builders query the toolstate repo to figure out if the tests are passing...
That will either retrieve an outdated toolstate or will need to block until the toolstate is uploaded ...
Without blocking it would lag behind by 1 merged PR, yes.
would it be possible to add some kind of build assert so Miri fails on builders when Rust internals change too much?
Well builders already know when Miri fails to build because internals change too much. The issue is things that make Miri still compile but break the test suite.
would it be possible to at least change the logic that opens issues such that for Miri, it opens an issue like when the tests fail? I could also try to implement that if you point me to the right place. So far we have had zero cases of Miri tests spuriously failing.


Question: self.lldb_git_commit_hash = self.git_commit_hash("lldb", "x86_64-unknown-linux-gnu"); self.miri_git_commit_hash = self.git_commit_hash("miri", "x86_64-unknown-linux-gnu"); <ins> self.check_toolstate(); </ins> self.digest_and_sign(); let manifest = self.build_manifest(); self.write_channel_files(&self.rust_release, &manifest);

That should be easy to do:
Gave it a shot at
had an interesting idea: can't we do the "don't ship broken tools" as part of a post-processing step? We anyway do some little amount of work when a commit hits (as opposed to ), such as actually updating the toolstate repo. So maybe that could also either delete the broken components from the S3 bucket, or else generate a file to be put into the S3 bucket that says which of the components are really there so that the broken ones can be considered "not there"? do you think something like that would be possible?
Thinking about this again, probably the most natural place to do this is in the . That could "just" also check the toolstate database for the commit it is promoting, and then (possibly only for certain tools) not add them to the nightly if their toolstate is not green.
This is biting us again right now, where CI knows that Miri is broken but we ship the component anyway, leading to CI failures in downstream projects that have Miri in their CI.
For another case where this issue got quite painful, see
My PR is because I was incorrectly assuming that all commits have their toolstate recorded in the toolstate repo. Reopening.
FTR, for testing , I downloaded some artifacts: then I edited my : and finally I ran This produces stuff in .
So looks like we have logic in that specifically does not commit to the toolstate repo if nothing changed: Unfortunately, this means that we cannot easily fetch the toolstate of the to-be-produced release in build-manifest, which caused my to fail. Would it be okay for you to change this logic to record the toolstate of all commits in the toolstate repo? Or would you prefer if I try to find another approach for solving this issue? Right now I am somewhat out of ideas though if we cannot even use the toolstate repo to communicate this information.
Wouldn't it be simpler to save list of "good" components to something like and upload it alongside tarballs? Running would show what you need.
I guess we could upload the two JSON files from the two tool runners somehow? Not sure which would be the right places to hook for that, though.
Status: blocked on which is blocked on
This seems to be finally fixed!


Question: self.lldb_git_commit_hash = self.git_commit_hash("lldb", "x86_64-unknown-linux-gnu"); self.miri_git_commit_hash = self.git_commit_hash("miri", "x86_64-unknown-linux-gnu"); <ins> self.check_toolstate(); </ins> self.digest_and_sign(); let manifest = self.build_manifest(); self.write_channel_files(&self.rust_release, &manifest);

Today nightly was shipped with , and everything looks normal :tada:
Miri is "test-fail" now, so with the next nightly we should be able to see if indeed it gets removed from rustup as it should.
Confirmed it's working! On miri is missing.


Question: } TokenTree::Token(t) => { <del> // Doc comments cannot appear in a matcher. debug_assert!(!matches!(t, Token { kind: DocComment(..), .. })); // If the token matches, we can just advance the parser. Otherwise, this // match hash failed, there is nothing to do, and hopefully another item in // `cur_items` will match. if token_name_eq(&t, token) { </del> <ins> // If it's a doc comment, we just ignore it and move on to the next tt in // the matcher. If the token matches, we can just advance the parser. // Otherwise, this match has failed, there is nothing to do, and hopefully // another item in `cur_items` will match. if matches!(t, Token { kind: DocComment(..), .. }) { item.idx += 1; self.cur_items.push(item); } else if token_name_eq(&t, token) { </ins> item.idx += 1; self.next_items.push(item); }

Cross post from Works fine on stable Rust.
That post is written by me. I've opened a PR , and made some comments there. I'm not an expert on Rust, actually I'm an amateur programmer, and this is what I can do for now.
61.0-nightly ( 2022-03-22) works so this is a very recent nightly regression.
I see that too when compiling
same issue on ubuntu20
Maybe related to this issue. Here is a snippet of macro with on the match side: Pass with rustc 1.61.0-nightly ( 2022-03-22), you can try this snippet via Failed with rustc 1.61.0-nightly ( 2022-03-23), you can try this snippet via , the code can be expanded on playground with: Expand macros in code using the nightly compiler. 61.0-nightly (2022-03-19 )
The piece of code looks surprising, but bisection lead to
Ok, I found it :smile:
Thanks for the report. Should be an easy fix, I will get to it on Monday.
I think is right to some extent. Even in previous Rust version, stuff in the matcher is not so useful and will be ignored like normal comments : With rustc 1.61.0-nightly ( 2022-03-22) or other versions before, the result is: With rustc 1.61.0-nightly ( 2022-03-23), the result is:
Note that the playground's nightly is a few days old and cannot be upgraded because of how this issue affects ring ;-)
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
That's an interesting observation! But I'm not a language expert and I never intended to change behaviour in , so I will fix this problem by going back to the old behaviour.


Question: }; use rustc_hir::def_id::DefId; use rustc_macros::{LintDiagnostic, Subdiagnostic}; <del> use rustc_middle::ty::{Predicate, Ty, TyCtxt}; </del> <ins> use rustc_middle::ty::{PolyExistentialTraitRef, Predicate, Ty, TyCtxt}; </ins> use rustc_session::parse::ParseSess; use rustc_span::{edition::Edition, sym, symbol::Ident, Span, Symbol};

<!-- 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. --ICE with in I just noticed the error actually says openpgp-card at the bottom, perhaps compilation doesn't even get to the final crate. In any case, I'm no good at minimizing these things, so I'm handing this off to people who are good at that. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details label +E-needs-mcve
searched nightlies: from nightly-2023-01-01 to nightly-2023-01-15 regressed nightly: nightly-2023-01-14 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
This fixes the ICE, although I'm not sure if that's the right approach
label -E-needs-mcve


Question: <ins> // The error message here still is pretty confusing. fn main() { let mut result = vec![1]; // The type of `result` is constrained to be `Vec<{integer}>` here. // But the logic we use to find what expression constrains a type // is not sophisticated enough to know this. let mut vector = Vec::new(); vector.sort(); result.push(vector); //~^ ERROR mismatched types // So it thinks that the type of `result` is constrained here. } fn example2() { let mut x = vec![1]; x.push(""); //~^ ERROR mismatched types } </ins>

I tried this code on nightly: I expected to see this happen: compiler does not panic. Instead, this happened: compiler panics and suggests I open a bug report. I initially posted to , but says this is a different issue, despite panicking on the same line in . (Though I'm realizing now that might be the proximal cause but not very related to the root cause.) : <details<summaryPanic message</summary<p</p</detailsThanks all for maintaining Rust, by the way.
Thanks!
searched nightlies: from nightly-2022-12-01 to nightly-2023-01-21 regressed nightly: nightly-2023-01-07 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
It's , i'll fix it unless someone beats me to it since I'm busy this weekend
Hi it's Justin from Commure :wave:. I found a compiler panic you made :grinning:
sorry for causing you trouble


Question: /// /// assert_eq!(actual, expected); /// ``` <del> #[unstable(feature = "ptr_hash", reason = "newly added", issue = "56286")] </del> <ins> #[stable(feature = "ptr_hash", since = "1.35.0")] </ins> pub fn hash<T: ?Sized, S: hash::Hasher>(hashee: *const T, into: &mut S) { use hash::Hash; hashee.hash(into);

Implemented in as .
Updated from: to: in . Thanks
Seems straightforward enough to me. fcp 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] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete.
Question: We have , should we have as well?
We could, but that’s going quickly into diminishing returns IMO. You can always use something like


Question: ENV TARGETS=$TARGETS,aarch64-fuchsia ENV TARGETS=$TARGETS,wasm32-unknown-unknown ENV TARGETS=$TARGETS,wasm32-wasi <del> # FIXME(#61022) - reenable solaris # ENV TARGETS=$TARGETS,sparcv9-sun-solaris # ENV TARGETS=$TARGETS,x86_64-sun-solaris </del> <ins> ENV TARGETS=$TARGETS,sparcv9-sun-solaris ENV TARGETS=$TARGETS,x86_64-sun-solaris </ins> ENV TARGETS=$TARGETS,x86_64-unknown-linux-gnux32 ENV TARGETS=$TARGETS,x86_64-unknown-cloudabi ENV TARGETS=$TARGETS,x86_64-fortanix-unknown-sgx

Today's nightly (25-05-2019) is missing rust-std for: : https://rust- : https://rust-
This was pointed out in and looks to be fixed in It seems that flew in under the radar of where the actual change to disable these targets happened. want to send a PR to revert the changes so the targets are built again?
Yes, I will do it today.


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. fn main() { let v = &[]; //~ ERROR cannot determine a type for this local variable: unconstrained type let it = v.iter(); } </ins>

Here is the error Here is the code that generates the error My system is x86_64 archlinux. The rust compiler version is Let me know if you guys need anything else. (The code is really short so it shouldn't be hard to just type it in to duplicate the bug)
It only needs one line for me
Workaround (in the sense that the compiler no longer ICE's): I think there is some unfortunate interaction here with the way we attempt to infer which kind of numeric literals are in the array (, , etc) and other code not being prepared to handle the that results when you don't have that information available.
This is almost certainly a duplicate of (but maybe the integer inference codepath is slightly different?).
This also causes the same ICE -
Similarly:
Looks like it's been fixed.


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. fn main() { let v = &[]; //~ ERROR cannot determine a type for this local variable: unconstrained type let it = v.iter(); } </ins>

Swapping the order of the branches compiles fine. cc
Just checked: this fails with a normal closure too, not just a proc.
Compiles fine now but potentially needs a test.


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. fn main() { let v = &[]; //~ ERROR cannot determine a type for this local variable: unconstrained type let it = v.iter(); } </ins>

Versions: Code to reproduce the ICE: Compilation output:
Seems to be fine now but potentially needs a test.
Nope, still failing. An updated example:
That code example fails to compile, but it's because the function signature for is wrong. It should be: When you make that change and make the struct fields public, the code compiles fine. Without the change I also didn't see any internal compiler errors. Rust Version: 0.12.0-pre-nightly, , Linux x8664
Yeah, I think this can be closed.
Flagging as needstest (not sure if one is checked in already)


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. fn main() { let v = &[]; //~ ERROR cannot determine a type for this local variable: unconstrained type let it = v.iter(); } </ins>

It gives
cc
Looks like it no longer causes an ICE.
I agree, it is fixed, I close it.


Question: if w > 2 { val = utf8_acc_cont_byte!(val, s[i + 2]); } if w > 3 { val = utf8_acc_cont_byte!(val, s[i + 3]); } <del> return CharRange {ch: unsafe { transmute(val as u32) }, next: i}; </del> <ins> return CharRange {ch: unsafe { transmute(val) }, next: i}; </ins> } return multibyte_char_range_at_reverse(*self, prev);

We need some way to interpret a as UTF-8, using the replacement character for invalid sequences instead of conditions. This would ideally be provided in the form of an .
Could we remove the current condition API in favour of this? It doesn't really seem to offer anything but failing, and we already have an API returning an .
I would be quite pleased if we could do that. Using the condition is rather awkward, and I would rather just have replacement chars myself.
This is a duplicate of , no?
And also the e-mail thread here I think is relevant:
This is an implementation of a mostly complete → UTF-8 decoder
It's only a duplicate if the intended resolution of is to use the replacement char instead of conditions, but it's unclear from the discussion if that's the plan.
I guess my thinking was that a maximally expressive condition-based solution would let one express a replacement char approach using conditions. But I don't actually favor doing that at this point. Or at least, I don't favor making that the only way to accomplish this, since I suspect a more specialized approach will be much nicer to use (both in terms of programmer convenience and in terms of efficiency). So okay, this is not a duplicate of .
Rust needs to support both fatal and replacement error handling modes, it should follow the WHATWG spec simonsapin has said (edit by is WHATWG spec.)
the fatal mode is already handled by the API
well, the current functions in str don't handle decoding buffers in chunks like the proposed encodings API. But yes, it does handle one-off decoding with 'fatal' error handling.
I think we need to improve/extend our API along the lines suggested here for 1.0. Nominating for P-backcompat-lang. (Arguably we could avoid the backwards compatibility hazard by offering a fail-only method for 1.0 and then adding an alternative entry point that provides the more flexible API supporting replacement characters in post 1.0. But I think this case is important enough that we should try to get the primary API method to provide both choices up front. That, or put dynamic fluid support in for representing the state of that choice.)
I submitted a PR for this last night, although I forgot there was an open issue too so I didn't link them. The PR is


Question: <ins> // Copyright 2018 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. #![feature(fn_traits)] fn main() { <fn() as Fn()>::call; //~^ ERROR associated type bindings are not allowed here [E0229] } </ins>

Code works cc
Bug triage: on current nightly (), this no longer is an ICE, but yields the following error:


Question: | sym::default_lib_allocator | sym::start | sym::custom_mir, <ins> .. </ins> ] => {} [name, ..] => { match BUILTIN_ATTRIBUTE_MAP.get(name) { // checked below Some(BuiltinAttribute { type_: AttributeType::CrateLevel, .. }) => {} Some(_) => { <del> // FIXME: differentiate between unstable and internal attributes just like we do with features instead // of just accepting `rustc_` attributes by name. That should allow trimming the above list, too. </del> <ins> // FIXME: differentiate between unstable and internal attributes just // like we do with features instead of just accepting `rustc_` // attributes by name. That should allow trimming the above list, too. </ins> if !name.as_str().starts_with("rustc_") { span_bug!( attr.span,

<!-- ICE: Rustc '' 'error: internal compiler error: builtin attribute "shouldpanic" not handled by ', 'error: internal compiler error: builtin attribute "shouldpanic" not handled by ' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [checkmodattrs] checking attributes in top-level module [analysis] running analysis passes on this crate --
there are a bunch more which probably all follow the pattern... 2 "errorreason": "error: internal compiler error: builtin attribute "allow" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "cfgattr" not handled by ", 4 "errorreason": "error: internal compiler error: builtin attribute "cfg" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "cmsenonsecureentry" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "collapsedebuginfo" not handled by ", 6 "errorreason": "error: internal compiler error: builtin attribute "deny" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "doc" not handled by ", 4 "errorreason": "error: internal compiler error: builtin attribute "inline" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "macroexport" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "optimize" not handled by ", 4 "errorreason": "error: internal compiler error: builtin attribute "procmacroderive" not handled by ", 14 "errorreason": "error: internal compiler error: builtin attribute "procmacro" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "shouldpanic" not handled by ",
cc
Taking a look
Problem is the previous match falls through to the fallback case for etc. because it has 1 segments ... and then since et al. is a attribute, it triggers the ICE.
I have a candidate fix locally, doing some more testing
Opened as a candidate fix.


Question: repr_packed, repr_simd, repr_transparent, <ins> require, </ins> residual, result, rhs,

I was looking at namely issue when I thought about this. If work is being put into improving error messages when somebody uses a keyword that defines a function in another language, there should also be improved error messages if someone uses the incorrect directive to bring something into the scope of their module or namespace/ Given the following code: The current output is: The error message should preferably suggest the user to use the directive to bring something into scope of their module. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
For the record, on nightly, both and suggest using . I'm sure it's not that difficult to add .
ah. I was not aware of this. Less work to do then!
[Ignore this, just notes]
And also add ? Rust may go tooooo friendly in diagnostic message . Do you mind that I make a PR for it? I'm a newbie in hacking Rust compiler.
Sure! The earlier message should clarify where the edits are needed to be made. Ain't nothing as a diagnostic too friendly. =)
Remember to assign yourself using rustbot. Just a note for the future, usually if someone has already claimed an issue, it's not exactly common for someone else to fix it [aside from if the issue is abandoned by the claimee]. Since you're a newcomer here, I removed my assignment (and because I was working on another). However, you can find loads of easy issues with the E-Easy and/or E-Mentor tag for gaining experience. A few resources that might be helpful - Have fun hacking on Rust!
claim
Totally forgot about ! Good catch!


Question: <ins> goto: file://|DOC_PATH|/lib2/struct.Foo.html // This test checks that the font weight is correctly applied. assert: ("//*[@class='docblock type-decl']//a[text()='Alias']", {"font-weight": "400"}) assert: ("//*[@class='structfield small-section-header']//a[text()='Alias']", {"font-weight": "400"}) assert: ("#method.a_method > code", {"font-weight": "600"}) assert: ("#associatedtype.X > code", {"font-weight": "600"}) assert: ("#associatedconstant.Y > code", {"font-weight": "600"}) </ins>

It looks like a CSS rule is being applied incorrectly. It also looks weird if you click through to the type alias's page (). ! !
I'm not really sure, could that be slipped in ?
It turns out it was actually much more recent. The PR causing the regression was , cc searched nightlies: from nightly-2021-05-01 to nightly-2021-06-12 regressed nightly: nightly-2021-06-04 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
The culprit CSS rule is here: It also caused which was fixed by .
Ah, I have missed this one. Sending a fix.
Assigning priority as in the prioritization working group. label: +P-medium -I-prioritize
The fix should be merged in less than 3 hours. ;)
I know, but we had already agreed on a priority :)
Oh I see. Thanks for taking care of that then! :)


Question:
} if let Some(ref dox) = i.impl_item.opt_doc_value() {  if trait_.is_none() && i.inner_impl().items.is_empty() {   if trait_.is_none() && impl_.items.is_empty() {  w.write_str( "

This impl block contains no items.

<p align="center"<img width="400" src=""</pI would prefer if only the negative impl signature were rendered here (and any doc comment on the negative impl). Not even a collapsed-by-default accordion to show the trait's contents. The reader can click the trait's name to see what is in it if they need. Having associated items of a negative impl rendered is inconvenient because something like <kbdCTRL+F</kbdfor "fn position" will land the reader deep in the middle of the big impl showing them APIs that their type does not have. Example of this occurring in standard library documentation:  Mentioning tracking issue.


Question: <ins> // Regression test for #121534 // Tests that no ICE occurs in KnownPanicsLint when it // evaluates an operation whose operands have different // layout types even though they have the same type. // This situation can be contrived through the use of // unions as in this test //@ build-pass union Union { u32_field: u32, i32_field: i32, } pub fn main() { let u32_variant = Union { u32_field: 2 }; let i32_variant = Union { i32_field: 3 }; let a = unsafe { u32_variant.u32_field }; let b = unsafe { i32_variant.u32_field }; let _diff = a - b; } </ins>

<!-- ICE: Rustc '' 'error: internal compiler error: invalid asymmetric binary op Sub: (i32), 2 (u32)', 'error: internal compiler error: invalid asymmetric binary op Sub: (i32), 2 (u32)' File: --auto-reduced (treereduce-rust): original () : Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [mirdropselaboratedandconstchecked] elaborating drops for [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
Const prop We need to make it not do union field accesses
Reduced a bit further:
claim


Question: <ins> error: invalid `?` in type --> $DIR/issue-103748-ICE-wrong-braces.rs:3:36 | LL | struct Apple((Apple, Option(Banana ? Citron))); |                                    ^ `?` is only allowed on expressions, not types | help: if you meant to express that the type might not contain a value, use the `Option` wrapper type | LL | struct Apple((Apple, Option(Option<Banana > Citron))); |                             +++++++       ~ error: expected one of `)` or `,`, found `Citron` --> $DIR/issue-103748-ICE-wrong-braces.rs:3:38 | LL | struct Apple((Apple, Option(Banana ? Citron))); |                                     -^^^^^^ expected one of `)` or `,` |                                     | |                                     help: missing `,` error[E0412]: cannot find type `Citron` in this scope --> $DIR/issue-103748-ICE-wrong-braces.rs:3:38 | LL | struct Apple((Apple, Option(Banana ? Citron))); |                                      ^^^^^^ not found in this scope error[E0214]: parenthesized type parameters may only be used with a `Fn` trait --> $DIR/issue-103748-ICE-wrong-braces.rs:3:22 | LL | struct Apple((Apple, Option(Banana ? Citron))); |                      ^^^^^^^^^^^^^^^^^^^^^^^ only `Fn` traits may use parentheses | help: use angle brackets instead | LL | struct Apple((Apple, Option<Banana ? Citron>)); |                            ~               ~ error[E0072]: recursive type `Apple` has infinite size --> $DIR/issue-103748-ICE-wrong-braces.rs:3:1 | LL | struct Apple((Apple, Option(Banana ? Citron))); | ^^^^^^^^^^^^  ----- recursive without indirection | help: insert some indirection (e.g., a `Box`, `Rc`, or `&`) to break the cycle | LL | struct Apple((Box<Apple>, Option(Banana ? Citron))); |               ++++     + error: aborting due to 5 previous errors Some errors have detailed explanations: E0072, E0214, E0412. For more information about an error, try `rustc --explain E0072`. </ins>

<details<summary<strongFull output including backtrace</strong</summary<p</p</detailsRegression from () <details<summaryBisection details</summarybisected with <a href=''cargo-bisect-rustc</av0.6.4 searched nightlies: from nightly-2022-10-06 to nightly-2022-10-28 regressed nightly: nightly-2022-10-09 searched commit range: regressed commit: Host triple: x8664-apple-darwin </details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
this function call crash for the assertion fail, from the log, is with count = 1, and is also 1 when crashing. Do you have any clue? is implemented at here, I'm still not quite familar with the query part:
It looks like the parens are parsed as generic parameters for a type that doesn't have generic parameters? The simple fix is just check .
I think a reasonable fix is modifying the API for , It reasonable to add assertion for , but it's better to return false for outside of expected range?
Have a test on C++'s , which also has this assertion: emm, it's better to keep it for .
claim
I'd be curious to know if we can maintain an invariant in the HIR that it does not contain generics that do not align with . That was what I assumed when writing that code, but that may be too optimistic.
I considered removing the assert too, but I think it's better to have it since it exposes invalid assumptions as in this case.
We should (replacing the assertion) -- that's probably fine as long as it's understood why the does not line up here, and it's understood why we can't fix it somewhere upstream (e.g. in parsing or lowering instead)
I have a general question for , why we just exit when we find a fatal error in parsing (which can not recover by simply autofix).


Question: <ins> error: invalid `?` in type --> $DIR/issue-103748-ICE-wrong-braces.rs:3:36 | LL | struct Apple((Apple, Option(Banana ? Citron))); |                                    ^ `?` is only allowed on expressions, not types | help: if you meant to express that the type might not contain a value, use the `Option` wrapper type | LL | struct Apple((Apple, Option(Option<Banana > Citron))); |                             +++++++       ~ error: expected one of `)` or `,`, found `Citron` --> $DIR/issue-103748-ICE-wrong-braces.rs:3:38 | LL | struct Apple((Apple, Option(Banana ? Citron))); |                                     -^^^^^^ expected one of `)` or `,` |                                     | |                                     help: missing `,` error[E0412]: cannot find type `Citron` in this scope --> $DIR/issue-103748-ICE-wrong-braces.rs:3:38 | LL | struct Apple((Apple, Option(Banana ? Citron))); |                                      ^^^^^^ not found in this scope error[E0214]: parenthesized type parameters may only be used with a `Fn` trait --> $DIR/issue-103748-ICE-wrong-braces.rs:3:22 | LL | struct Apple((Apple, Option(Banana ? Citron))); |                      ^^^^^^^^^^^^^^^^^^^^^^^ only `Fn` traits may use parentheses | help: use angle brackets instead | LL | struct Apple((Apple, Option<Banana ? Citron>)); |                            ~               ~ error[E0072]: recursive type `Apple` has infinite size --> $DIR/issue-103748-ICE-wrong-braces.rs:3:1 | LL | struct Apple((Apple, Option(Banana ? Citron))); | ^^^^^^^^^^^^  ----- recursive without indirection | help: insert some indirection (e.g., a `Box`, `Rc`, or `&`) to break the cycle | LL | struct Apple((Box<Apple>, Option(Banana ? Citron))); |               ++++     + error: aborting due to 5 previous errors Some errors have detailed explanations: E0072, E0214, E0412. For more information about an error, try `rustc --explain E0072`. </ins>

I have a real Dev experience when working on , I was editing an file with 3k+ lines of code, and I forgetted remove an extra '{', then the compiler give about 20+ errors, the first two are from parsing: But there are many many other errors from later phases... I need to scroll up several pages to the beginning of error to find the rootcause.
If we can not get valid AST in parsing, later phases such as analysising will report out extra (mostly unhelpful) errors?
The assertion is inside of the data structure. I generally expect data structures to simply assert on pre-conditions. We could put a delay-bug before the call, but that also seems like overkill since that is already on the error-reporting path. I agree there are cases where rustc should quit sooner. But in general I think we have to err on the side of recover-and-continue if there is some possibility that more helpful errors may be emitted.
This can happen. The parser should be more realistic on what it recovers and avoid errors from later passes that do not make sense. A few years back we would stop as soon as any error occurred in a given pass and avoid trying any further evaluation, and that was also a usability issue, because people would get a false sense of "how much work is left to fix". We shouldn't have a blanket evaluation stop, but maybe be more aggressive about pruning the AST when multiple parse errors have occurred.
do you want to take over this issue? I currently don't have any clue about the rootcause. Or we give it an simple fix now.
I can take a look.


Question: // Multibyte case is a fn to allow char_range_at to inline cleanly fn multibyte_char_range_at(s: &str, i: uint) -> CharRange { <del> let mut val = s[i] as uint; </del> <ins> let mut val = s[i] as u32; </ins> let w = UTF8_CHAR_WIDTH[val] as uint; assert!((w != 0));


Question: let crate_types = if options.proc_macro_crate { vec![config::CrateType::ProcMacro] } else { <del> vec![config::CrateType::Dylib] </del> <ins> vec![config::CrateType::Rlib] </ins> }; let sessopts = config::Options {

I have a no_std crate that imports std when testing: However, I get this error during testing: Allocating on the heap during testing does appear to work, so I'm assuming this is just a case of the warning still being emitted.
I have the same issue. Any update?
builds the crate both as a library (for doctests) and as a test executable. You only pull in std for the test executable, so the error message could be coming from building as a library.
I have the same issue, error message seems to be spurious
Yeah, the error message is emitted when building the library. Funnily enough, it does not cause the build to fail. That is, still continues running and then exits with success (0). Sadly, there is currently no way to link in a default allocator (or for that matter) for doctests. There is the unstable feature that provides , but I don't see how to achieve something similar without relying on unstable features. I simply use until this is fixed.
Related:
modify labels: +T-rustdoc
Error: Parsing label command in failed: labels +T-rustdo... Please let know if you're having trouble with this bot.
If you don't put inside the doctest it will be linked against even when testing a crate, you can think of each doctest as a separate crate. If you do want a different allocator you can add a static like in a normal binary. Even though this error message is printed the doc tests should still be running.
Also see the error is basically spurious.


Question: let crate_types = if options.proc_macro_crate { vec![config::CrateType::ProcMacro] } else { <del> vec![config::CrateType::Dylib] </del> <ins> vec![config::CrateType::Rlib] </ins> }; let sessopts = config::Options {

I noticed this in the output running locally: and that didn't make tests fail. Cc:
Same with panic_unwind:
This error message is printed when running , but before running any test. The code printing it is in . It looks like rustdoc is using that code in order to load the crate and find doctests in it. But since it’s not actually compiling this crate, not having an allocator is not a problem. So I think there are two issues: rustdoc keeps doing its thing even though there are errors. It probably should call something like on its instance at some point. This error should not occur in the first place. One way to inhibit it would be to tell that we’re "compiling" an rlib () rather than some other crate type. rlibs do not need (yet) to have an allocator defined. This is possibly this line: The first issue could in some other situation hide a real problem, but in this case it makes the second one mostly harmless. The only bad consequence is some noise in the output of a test run.
Related:
modify labels: +T-rustdoc
Error: Parsing label command in failed: labels +T-rustdo... Please let know if you're having trouble with this bot.


Question: #![feature(ptr_offset_from)] #![feature(rustc_attrs)] #![feature(receiver_trait)] <del> #![feature(slice_from_raw_parts)] </del> #![feature(specialization)] #![feature(staged_api)] #![feature(std_internals)]

In stable Rust, the only way to get a with an arbitrary length is through . Unfortunately, that function returns a , which makes it very dubious to use with arbitrary raw pointers.
Given that isn't defined for , what would be the value of being able to create ?
Why would you want one, but also, this seems like it depends on (yet to be decided?) details of the memory model. Is the fleeting moment where a reference exists in enough to invoke UB if the pointer is invalid?
If the reference is , then this is insta-UB for sure.
Is there anything holding [] from stabilizing? If not, I'd like to propose stabilization of these functions, as they are rather simple in concept and allow avoiding manifesting references during (slice) pointer manipulation. cc If I'm reading the various issue threads correctly, the validity invariant of pointer metadata is at max that of the metadata type. For slice pointers, the metadata is typed at . Context: I happen to currently be writing a library that cannot use the reference-based functions, because though the pointers are known to be non-null (and valid), it is not (and cannot be, with the current abstraction) known whether the pointer has unique or shared provenance (thus should use or to be sound). (Specifically, I'm now adding the bits required to handle erasing slice types. I can bifurcate my function into and , but so far, it works fine with one operating over , and it'd be sad to have the / split hanging around even after these functions stabilize (assuming they can)).
I don't recall any reason that cannot be stabilized.
The implementation PR used this feature requested as a tracking issue, but this wasn’t labelled properly. Doing so now.
By the way, would also cover this :)


Question: #[doc(keyword = "struct")] // <del> /// The `struct` keyword. </del> <ins> /// The keyword used to define structs. </ins> /// <del> /// The `struct` keyword is used to define a struct type. </del> <ins> /// Structs in Rust come in three flavours: Regular structs, tuple structs, /// and empty structs. </ins> /// <del> /// Example: </del> <ins> /// ```rust /// struct Regular { ///     field1: f32, ///     field2: String, ///     pub field3: bool /// } /// /// struct Tuple(u32, String); </ins> /// <ins> /// struct Empty; </ins> /// ``` <del> /// struct Foo { ///     field1: u32, ///     field2: String, </del> <ins> /// /// Regular structs are the most commonly used. Each field defined within them has a name and a /// type, and once defined can be accessed using `example_struct.field` syntax. The fields of a /// struct share its mutability, so `foo.bar = 2;` would only be valid if `foo` was mutable. Adding /// `pub` to a field makes it visible to code in other modules, as well as allowing it to be /// directly accessed and modified. /// /// Tuple structs are similar to regular structs, but its fields have no names. They are used like /// tuples, with deconstruction possible via `let TupleStruct(x, y) = foo;` syntax.  For accessing /// individual variables, the same syntax is used as with regular tuples, namely `foo.0`, `foo.1`, /// etc, starting at zero. /// /// Empty structs, or unit-like structs, are most commonly used as markers, for example /// [`PhantomData`]. Empty structs have a size of zero bytes, but unlike empty enums they can be /// instantiated, making them similar to the unit type `()`. Unit-like structs are useful when you /// need to implement a trait on something, but don't need to store any data inside it. /// /// # Instantiation /// /// Structs can be instantiated in a manner of different ways, each of which can be mixed and /// matched as needed. The most common way to make a new struct is via a constructor method such as /// `new()`, but when that isn't available (or you're writing the constructor itself), struct /// literal syntax is used: /// /// ```rust /// # struct Foo { field1: f32, field2: String, etc: bool } /// let example = Foo { ///     field1: 42.0, ///     field2: "blah".to_string(), ///     etc: true, /// }; /// ``` /// /// It's only possible to directly instantiate a struct using struct literal syntax when all of its /// fields are visible to you. /// /// There are a handful of shortcuts provided to make writing constructors more convenient, most /// common of which is the Field Init shorthand. When there is a variable and a field of the same /// name, the assignment can be simplified from `field: field` into simply `field`. The following /// example of a hypothetical constructor demonstrates this: /// /// ```rust /// struct User { ///     name: String, ///     admin: bool, </ins> /// } <ins> /// /// impl User { ///     pub fn new(name: String) -> Self { ///         Self { ///             name, ///             admin: false, ///         } ///     } /// } /// ``` /// /// Another shortcut for struct instantiation is available, used when you need to make a new /// struct that has the same values as most of a previous struct of the same type, called struct /// update syntax: /// /// ```rust /// # struct Foo { field1: String, field2: () } /// # let thing = Foo { field1: "".to_string(), field2: () }; /// let updated_thing = Foo { ///     field1: "a new value".to_string(), ///     ..thing /// }; </ins> /// ``` /// <del> /// There are different kinds of structs. For more information, take a look at the /// [Rust Book][book]. </del> <ins> /// Tuple structs are instantiated in the same way as tuples themselves, except with the struct's /// name as a prefix: `Foo(123, false, 0.1)`. /// /// Empty structs are instantiated with just their name, and don't need anything else. `let thing = /// EmptyStruct;` /// /// # Style conventions /// /// Structs are always written in CamelCase, with few exceptions. While the trailing comma on a /// struct's list of fields can be omitted, it's usually kept for convenience in adding and /// removing fields down the line. /// /// For more information on structs, take a look at the [Rust Book][book] or the /// [Reference][reference]. </ins> /// <ins> /// [`PhantomData`]: marker/struct.PhantomData.html </ins> /// [book]: https://doc.rust-lang.org/book/second-edition/ch05-01-defining-structs.html <ins> /// [reference]: https://doc.rust-lang.org/reference/items/structs.html </ins> mod struct_keyword { }

Consider the following code (): It currently yields the following diagnostic messages: This line is what I object to: It has two problems: It uses the terminology when discussing building up an instance of the struct . It uses a tuple struct form in the example rewrite it provides; but our is a braced struct with named fields.
Is GitHub suffering from some kind of cache-consistency problem!? (I guess so: they're investigating service unavailability.) I apparently-successfully opened PR to fix this, but then it wasn't showing up in the and the pull/ URL was 404ing, so then I thought that it might not have actually gone through, so then I tried to resubmit, and then that failed with an "A pull request already exists" flash message, and then I wanted to try submitting under a different branch name, and/or rebased so as to have a different SHA (on the theory that maybe the problem had something to do with the fact that I was reusing the branch name from the my PR of last year in which the "variant of the expected type" message was introduced, even though it would be really surprising if a site as old and usually-stable as GitHub didn't already handle that case), but then the "Compare branches" pages aren't showing the open-pull-request form that they usually do. Typically I wouldn't even bother commenting about this kind of glitch (trusting that our friends at GitHub will sort it out any mere availability issue soon enough), but the fact that other PR pages are loading fine for me makes me wonder if there's some kind of bad state associated with in particular?!
Is GitHub suffering from some kind of cache-consistency problem!? (I guess so: they're investigating service unavailability.)


Question: #[doc(keyword = "struct")] // <del> /// The `struct` keyword. </del> <ins> /// The keyword used to define structs. </ins> /// <del> /// The `struct` keyword is used to define a struct type. </del> <ins> /// Structs in Rust come in three flavours: Regular structs, tuple structs, /// and empty structs. </ins> /// <del> /// Example: </del> <ins> /// ```rust /// struct Regular { ///     field1: f32, ///     field2: String, ///     pub field3: bool /// } /// /// struct Tuple(u32, String); </ins> /// <ins> /// struct Empty; </ins> /// ``` <del> /// struct Foo { ///     field1: u32, ///     field2: String, </del> <ins> /// /// Regular structs are the most commonly used. Each field defined within them has a name and a /// type, and once defined can be accessed using `example_struct.field` syntax. The fields of a /// struct share its mutability, so `foo.bar = 2;` would only be valid if `foo` was mutable. Adding /// `pub` to a field makes it visible to code in other modules, as well as allowing it to be /// directly accessed and modified. /// /// Tuple structs are similar to regular structs, but its fields have no names. They are used like /// tuples, with deconstruction possible via `let TupleStruct(x, y) = foo;` syntax.  For accessing /// individual variables, the same syntax is used as with regular tuples, namely `foo.0`, `foo.1`, /// etc, starting at zero. /// /// Empty structs, or unit-like structs, are most commonly used as markers, for example /// [`PhantomData`]. Empty structs have a size of zero bytes, but unlike empty enums they can be /// instantiated, making them similar to the unit type `()`. Unit-like structs are useful when you /// need to implement a trait on something, but don't need to store any data inside it. /// /// # Instantiation /// /// Structs can be instantiated in a manner of different ways, each of which can be mixed and /// matched as needed. The most common way to make a new struct is via a constructor method such as /// `new()`, but when that isn't available (or you're writing the constructor itself), struct /// literal syntax is used: /// /// ```rust /// # struct Foo { field1: f32, field2: String, etc: bool } /// let example = Foo { ///     field1: 42.0, ///     field2: "blah".to_string(), ///     etc: true, /// }; /// ``` /// /// It's only possible to directly instantiate a struct using struct literal syntax when all of its /// fields are visible to you. /// /// There are a handful of shortcuts provided to make writing constructors more convenient, most /// common of which is the Field Init shorthand. When there is a variable and a field of the same /// name, the assignment can be simplified from `field: field` into simply `field`. The following /// example of a hypothetical constructor demonstrates this: /// /// ```rust /// struct User { ///     name: String, ///     admin: bool, </ins> /// } <ins> /// /// impl User { ///     pub fn new(name: String) -> Self { ///         Self { ///             name, ///             admin: false, ///         } ///     } /// } /// ``` /// /// Another shortcut for struct instantiation is available, used when you need to make a new /// struct that has the same values as most of a previous struct of the same type, called struct /// update syntax: /// /// ```rust /// # struct Foo { field1: String, field2: () } /// # let thing = Foo { field1: "".to_string(), field2: () }; /// let updated_thing = Foo { ///     field1: "a new value".to_string(), ///     ..thing /// }; </ins> /// ``` /// <del> /// There are different kinds of structs. For more information, take a look at the /// [Rust Book][book]. </del> <ins> /// Tuple structs are instantiated in the same way as tuples themselves, except with the struct's /// name as a prefix: `Foo(123, false, 0.1)`. /// /// Empty structs are instantiated with just their name, and don't need anything else. `let thing = /// EmptyStruct;` /// /// # Style conventions /// /// Structs are always written in CamelCase, with few exceptions. While the trailing comma on a /// struct's list of fields can be omitted, it's usually kept for convenience in adding and /// removing fields down the line. /// /// For more information on structs, take a look at the [Rust Book][book] or the /// [Reference][reference]. </ins> /// <ins> /// [`PhantomData`]: marker/struct.PhantomData.html </ins> /// [book]: https://doc.rust-lang.org/book/second-edition/ch05-01-defining-structs.html <ins> /// [reference]: https://doc.rust-lang.org/reference/items/structs.html </ins> mod struct_keyword { }

I apparently-successfully opened PR to fix this, but then it wasn't showing up in the and the pull/ URL was 404ing, so then I thought that it might not have actually gone through, so then I tried to resubmit, and then that failed with an "A pull request already exists" flash message, and then I wanted to try submitting under a different branch name, and/or rebased so as to have a different SHA (on the theory that maybe the problem had something to do with the fact that I was reusing the branch name from the my PR of last year in which the "variant of the expected type" message was introduced, even though it would be really surprising if a site as old and usually-stable as GitHub didn't already handle that case), but then the "Compare branches" pages aren't showing the open-pull-request form that they usually do. Typically I wouldn't even bother commenting about this kind of glitch (trusting that our friends at GitHub will sort it out any mere availability issue soon enough), but the fact that other PR pages are loading fine for me makes me wonder if there's some kind of bad state associated with in particular?!


Question: #[doc(keyword = "struct")] // <del> /// The `struct` keyword. </del> <ins> /// The keyword used to define structs. </ins> /// <del> /// The `struct` keyword is used to define a struct type. </del> <ins> /// Structs in Rust come in three flavours: Regular structs, tuple structs, /// and empty structs. </ins> /// <del> /// Example: </del> <ins> /// ```rust /// struct Regular { ///     field1: f32, ///     field2: String, ///     pub field3: bool /// } /// /// struct Tuple(u32, String); </ins> /// <ins> /// struct Empty; </ins> /// ``` <del> /// struct Foo { ///     field1: u32, ///     field2: String, </del> <ins> /// /// Regular structs are the most commonly used. Each field defined within them has a name and a /// type, and once defined can be accessed using `example_struct.field` syntax. The fields of a /// struct share its mutability, so `foo.bar = 2;` would only be valid if `foo` was mutable. Adding /// `pub` to a field makes it visible to code in other modules, as well as allowing it to be /// directly accessed and modified. /// /// Tuple structs are similar to regular structs, but its fields have no names. They are used like /// tuples, with deconstruction possible via `let TupleStruct(x, y) = foo;` syntax.  For accessing /// individual variables, the same syntax is used as with regular tuples, namely `foo.0`, `foo.1`, /// etc, starting at zero. /// /// Empty structs, or unit-like structs, are most commonly used as markers, for example /// [`PhantomData`]. Empty structs have a size of zero bytes, but unlike empty enums they can be /// instantiated, making them similar to the unit type `()`. Unit-like structs are useful when you /// need to implement a trait on something, but don't need to store any data inside it. /// /// # Instantiation /// /// Structs can be instantiated in a manner of different ways, each of which can be mixed and /// matched as needed. The most common way to make a new struct is via a constructor method such as /// `new()`, but when that isn't available (or you're writing the constructor itself), struct /// literal syntax is used: /// /// ```rust /// # struct Foo { field1: f32, field2: String, etc: bool } /// let example = Foo { ///     field1: 42.0, ///     field2: "blah".to_string(), ///     etc: true, /// }; /// ``` /// /// It's only possible to directly instantiate a struct using struct literal syntax when all of its /// fields are visible to you. /// /// There are a handful of shortcuts provided to make writing constructors more convenient, most /// common of which is the Field Init shorthand. When there is a variable and a field of the same /// name, the assignment can be simplified from `field: field` into simply `field`. The following /// example of a hypothetical constructor demonstrates this: /// /// ```rust /// struct User { ///     name: String, ///     admin: bool, </ins> /// } <ins> /// /// impl User { ///     pub fn new(name: String) -> Self { ///         Self { ///             name, ///             admin: false, ///         } ///     } /// } /// ``` /// /// Another shortcut for struct instantiation is available, used when you need to make a new /// struct that has the same values as most of a previous struct of the same type, called struct /// update syntax: /// /// ```rust /// # struct Foo { field1: String, field2: () } /// # let thing = Foo { field1: "".to_string(), field2: () }; /// let updated_thing = Foo { ///     field1: "a new value".to_string(), ///     ..thing /// }; </ins> /// ``` /// <del> /// There are different kinds of structs. For more information, take a look at the /// [Rust Book][book]. </del> <ins> /// Tuple structs are instantiated in the same way as tuples themselves, except with the struct's /// name as a prefix: `Foo(123, false, 0.1)`. /// /// Empty structs are instantiated with just their name, and don't need anything else. `let thing = /// EmptyStruct;` /// /// # Style conventions /// /// Structs are always written in CamelCase, with few exceptions. While the trailing comma on a /// struct's list of fields can be omitted, it's usually kept for convenience in adding and /// removing fields down the line. /// /// For more information on structs, take a look at the [Rust Book][book] or the /// [Reference][reference]. </ins> /// <ins> /// [`PhantomData`]: marker/struct.PhantomData.html </ins> /// [book]: https://doc.rust-lang.org/book/second-edition/ch05-01-defining-structs.html <ins> /// [reference]: https://doc.rust-lang.org/reference/items/structs.html </ins> mod struct_keyword { }

This code snippet () results in the following lint output: The should contain the literal string , not the expanded macro that it repreesnts.
Ah, I think this is because we should be using (to get the code the user actually wrote) (to render the AST); I could PR this tonight.


Question: #[doc(keyword = "struct")] // <del> /// The `struct` keyword. </del> <ins> /// The keyword used to define structs. </ins> /// <del> /// The `struct` keyword is used to define a struct type. </del> <ins> /// Structs in Rust come in three flavours: Regular structs, tuple structs, /// and empty structs. </ins> /// <del> /// Example: </del> <ins> /// ```rust /// struct Regular { ///     field1: f32, ///     field2: String, ///     pub field3: bool /// } /// /// struct Tuple(u32, String); </ins> /// <ins> /// struct Empty; </ins> /// ``` <del> /// struct Foo { ///     field1: u32, ///     field2: String, </del> <ins> /// /// Regular structs are the most commonly used. Each field defined within them has a name and a /// type, and once defined can be accessed using `example_struct.field` syntax. The fields of a /// struct share its mutability, so `foo.bar = 2;` would only be valid if `foo` was mutable. Adding /// `pub` to a field makes it visible to code in other modules, as well as allowing it to be /// directly accessed and modified. /// /// Tuple structs are similar to regular structs, but its fields have no names. They are used like /// tuples, with deconstruction possible via `let TupleStruct(x, y) = foo;` syntax.  For accessing /// individual variables, the same syntax is used as with regular tuples, namely `foo.0`, `foo.1`, /// etc, starting at zero. /// /// Empty structs, or unit-like structs, are most commonly used as markers, for example /// [`PhantomData`]. Empty structs have a size of zero bytes, but unlike empty enums they can be /// instantiated, making them similar to the unit type `()`. Unit-like structs are useful when you /// need to implement a trait on something, but don't need to store any data inside it. /// /// # Instantiation /// /// Structs can be instantiated in a manner of different ways, each of which can be mixed and /// matched as needed. The most common way to make a new struct is via a constructor method such as /// `new()`, but when that isn't available (or you're writing the constructor itself), struct /// literal syntax is used: /// /// ```rust /// # struct Foo { field1: f32, field2: String, etc: bool } /// let example = Foo { ///     field1: 42.0, ///     field2: "blah".to_string(), ///     etc: true, /// }; /// ``` /// /// It's only possible to directly instantiate a struct using struct literal syntax when all of its /// fields are visible to you. /// /// There are a handful of shortcuts provided to make writing constructors more convenient, most /// common of which is the Field Init shorthand. When there is a variable and a field of the same /// name, the assignment can be simplified from `field: field` into simply `field`. The following /// example of a hypothetical constructor demonstrates this: /// /// ```rust /// struct User { ///     name: String, ///     admin: bool, </ins> /// } <ins> /// /// impl User { ///     pub fn new(name: String) -> Self { ///         Self { ///             name, ///             admin: false, ///         } ///     } /// } /// ``` /// /// Another shortcut for struct instantiation is available, used when you need to make a new /// struct that has the same values as most of a previous struct of the same type, called struct /// update syntax: /// /// ```rust /// # struct Foo { field1: String, field2: () } /// # let thing = Foo { field1: "".to_string(), field2: () }; /// let updated_thing = Foo { ///     field1: "a new value".to_string(), ///     ..thing /// }; </ins> /// ``` /// <del> /// There are different kinds of structs. For more information, take a look at the /// [Rust Book][book]. </del> <ins> /// Tuple structs are instantiated in the same way as tuples themselves, except with the struct's /// name as a prefix: `Foo(123, false, 0.1)`. /// /// Empty structs are instantiated with just their name, and don't need anything else. `let thing = /// EmptyStruct;` /// /// # Style conventions /// /// Structs are always written in CamelCase, with few exceptions. While the trailing comma on a /// struct's list of fields can be omitted, it's usually kept for convenience in adding and /// removing fields down the line. /// /// For more information on structs, take a look at the [Rust Book][book] or the /// [Reference][reference]. </ins> /// <ins> /// [`PhantomData`]: marker/struct.PhantomData.html </ins> /// [book]: https://doc.rust-lang.org/book/second-edition/ch05-01-defining-structs.html <ins> /// [reference]: https://doc.rust-lang.org/reference/items/structs.html </ins> mod struct_keyword { }

ARC is beginning to infect more and more types, and they each must have a clone method, but there is no trait to implement.
related
Along with this, we should provide a default implementation of Clonable for all copyable types.
Closing this now that has been implemented. There are no doubt some types left that should have a implementation, but they can be dealt with on a case-by-case basis.


Question: let mut _0: *const &u8; let mut _2: *const &u8; let mut _3: *const &u8; <ins> let mut _4: *const &u8; </ins> scope 1 (inlined generic_cast::<&u8, &u8>) { <del> debug x => _3; let mut _4: *const &u8; </del> <ins> debug x => _4; let mut _5: *const &u8; </ins> } bb0: { StorageLive(_2); StorageLive(_3); <del> _3 = _1; </del> StorageLive(_4); <del> _4 = _3; -         _2 = move _4 as *const &u8 (PtrToPtr); +         _2 = move _4; </del> <ins> _4 = _1; StorageLive(_5); _5 = _4; -         _3 = move _5 as *const &u8 (PtrToPtr); +         _3 = move _5; StorageDead(_5); </ins> StorageDead(_4); <del> StorageDead(_3); </del> <ins> -         _2 = move _3 as *const &u8 (PtrToPtr); +         _2 = move _3; </ins> _0 = _2; <ins> StorageDead(_3); </ins> StorageDead(_2); return; }

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: . I expected to see this happen: it compiles, since raw pointer casts should be allowed even for completely different types. Instead, this happened: it fails with: It looks like for some reason the compiler creates a lifetime obligation here. Strangely, it works with : .
I've looked into this. The issue is that typeck considers this cast to be a "coercion cast", because typeck thinks that you could replace the function body with just since the types are the same (it also triggers the lint (allow-by-default)). HIR typeck isn't aware of lifetimes. So then THIR building and MIR building build MIR that doesn't contain a cast but instead just assigns one to the other. The borrow checker is rightfully not pleased. The bug here is that the THIR does not contain an explicit cast anymore. I'm not sure how to best fix this, as the current logic for "is this a no-op cast (called coercion cast in the code)" is just "try to coerce the types in the same way that happens on coercion sites and if it works it has to be useless". Which is wrong in the presence of lifetimes. It seems like the current strategy works this way because it reuses some code in THIR building. Thinking about it a little more, this is very special to pointer casts, because only pointer casts are allowed to change the type like this. Maybe THIR building should just special case pointer casts to always be emitted?
Unfortunately due to this bug there is that should be turned into a raw pointer cast, but we cannot.
I think that's a different case, these are boxes and not raw pointers, and box-box casts are not allowed to do arbitrary changes (and are in fact coercion casts, so the doesn't actually do anything). The error there is correct and this needs a transmute.
I'd like to replace the transmutes by raw pointer casts, which IMO is much preferable, similar to But this bug is in the way of that.


Question: // extern-return-TwoU64s // foreign-fn-with-byval // issue-28676 <ins> // issue-62350-sysv-neg-reg-counts </ins> // struct-return // ignore-android

We encountered this with WebRender, where we exposed a method in Rust to the Gecko, and the last parameters supplied appeared random on the Rust side. I made a reduced test case adapted from it that you can grab at: It is a very simple test case where the C++ program puts all the parameters on the stack, prints the expected values of some of them, and calls the Rust method. The Rust method prints the values it received. We have enough parameters to fill up the registers used in the calling convention, and once we get to pushing things on the stack, it goes wrong. You can see from the output that they mismatch. ./build- && ./run- outputs c++ expect width=7 height=8 c++ expect slice=9 10 11 12 c++ expect outset=13. 13. 13. 13. c++ expect repeat h=0 v=0 got rust image 6 width 7 height 8 got rust slice SideOffsets { top: 9, right: 10, bottom: 11, left: 12 } got rust outset LayoutGeometry { top: 0.0, left: 0.0, width: 0.0, height: 0.0 } got rust repeat h=26 v=58 Note that the earlier parameters are correct, but the last 3 (outset, repeat h and repeat v) are all incorrect.
Is there an upstream issue in WebRender you can link? What platform is this happening on?
The Gecko side integrating with WebRender was disabled, and I have been working to re-enable this in You can find the code in question at: I intend to just work around this using structs for the moment as part of the aforementioned bug.
We're seeing this on all of our x64 platforms (win, mac, linux; all using clang). It looks like a pretty clear bug in our sysv callee ABI for x64 when there are lots of arguments.
<details<summaryrustc callee llvm-ir </summary</details<details<summaryclang caller llvm-ir </summary</detailsJust the signatures:
Note to self: can go negative from scalar integer arguments after the 6 integer registers have been exhausted and then is always true. Will try to fix soon (also I wonder if this is a stable-to-stable regression from years ago?).


Question: // extern-return-TwoU64s // foreign-fn-with-byval // issue-28676 <ins> // issue-62350-sysv-neg-reg-counts </ins> // struct-return // ignore-android

Looks like this was working circa 1.0, but has been broken at least since 1.12. Oof.
Do you need this fixed on beta as well, btw?
it would certainly be great if you uplifted this, but we have to work around it for the next few weeks anyway


Question: } // Determine if a node with the given attributes should be included in this configuation. <del> fn in_cfg(&mut self, attrs: &[ast::Attribute]) -> bool { </del> <ins> pub fn in_cfg(&mut self, attrs: &[ast::Attribute]) -> bool { </ins> attrs.iter().all(|attr| { // When not compiling with --test we should not compile the #[test] functions if !self.should_test && is_test_or_bench(attr) {

This fails on stable because rust still parses the unstable module: It's possible to work around this by conditionally defining a macro and then having the macro define the module but that's a bit messy:
Or implement the module in another file. I think this is a fundamental limitation -- you can't skip forward over an item if you don't understand the syntax that the item is using. The only way we could solve it is with time travel, i.e., doing a point release of stable that knows the syntax but not what it means.
That's actually what I'm doing in my project (still the same problem). That is, I have the following in my : And a module,
Modules are parsed before 's are parsed, which has been an issue for as long as I can remember. Can someone find whether there is an issue tracking this?
Dupe of . cc ( expert!)
Though this'll be fixed by the above PR, the workaround for current stable is


Question: } // Determine if a node with the given attributes should be included in this configuation. <del> fn in_cfg(&mut self, attrs: &[ast::Attribute]) -> bool { </del> <ins> pub fn in_cfg(&mut self, attrs: &[ast::Attribute]) -> bool { </ins> attrs.iter().all(|attr| { // When not compiling with --test we should not compile the #[test] functions if !self.should_test && is_test_or_bench(attr) {

The ABI string for is validated while being parsed, meaning one can get errors about in 'd off modules: (Compiled without .) This isn't necessarily wrong, but it is weird and somewhat annoying if one needs it. (It can be worked-around by hiding the block behind a macro: .)
Any ideas where we could move the check into? Any of borrowck, typeck, lints, privacy and resolve don’t exactly fit. I think trans thematically is the best place to have it, but it is a shame to have it error out so late for such an easy to detect and obvious error. I’m personally fine keeping it a parse error, IMO there’s no reason to have cfg blocks with code that does not compile.
NB. we can add a special pass if necessary (i.e. there's no reason for us to compromise by putting the error in trans). Yeah, of course. However, there are cases when the d code does compile, e.g. I encountered this in where I an ABI and had to use it in inside a module. Similarly, if we add ABIs in future, someone might have code designed to compile with Rust 1.0.0, but can take advantage of the newer ABI if it is available.
The block might be to gate nightly-only code. The code within the gated block is compiled only when a cargo feature is enabled; the code outside it works both on stable and nightly. I hit it myself; I'm playing with the SIMD work from pull request, but I want to keep the crate working on stable. .


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. // error-pattern:explicit failure pub fn main() { fail!(); println!("{}", 1i); } </ins>

Here is the error Here is the code that generates the error My system is x86_64 archlinux. The rust compiler version is Let me know if you guys need anything else. (The code is really short so it shouldn't be hard to just type it in to duplicate the bug)
It only needs one line for me
Workaround (in the sense that the compiler no longer ICE's): I think there is some unfortunate interaction here with the way we attempt to infer which kind of numeric literals are in the array (, , etc) and other code not being prepared to handle the that results when you don't have that information available.
This is almost certainly a duplicate of (but maybe the integer inference codepath is slightly different?).
This also causes the same ICE -
Similarly:
Looks like it's been fixed.


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. // error-pattern:explicit failure pub fn main() { fail!(); println!("{}", 1i); } </ins>

Swapping the order of the branches compiles fine. cc
Just checked: this fails with a normal closure too, not just a proc.
Compiles fine now but potentially needs a test.


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. // error-pattern:explicit failure pub fn main() { fail!(); println!("{}", 1i); } </ins>

Versions: Code to reproduce the ICE: Compilation output:
Seems to be fine now but potentially needs a test.
Nope, still failing. An updated example:
That code example fails to compile, but it's because the function signature for is wrong. It should be: When you make that change and make the struct fields public, the code compiles fine. Without the change I also didn't see any internal compiler errors. Rust Version: 0.12.0-pre-nightly, , Linux x8664
Yeah, I think this can be closed.
Flagging as needstest (not sure if one is checked in already)


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. // error-pattern:explicit failure pub fn main() { fail!(); println!("{}", 1i); } </ins>

It gives
cc
Looks like it no longer causes an ICE.
I agree, it is fixed, I close it.


Question: There’s just one line of this first example left: ```rust,ignore <del> println!("You guessed: {}", input); </del> <ins> println!("You guessed: {}", guess); </ins> } ``` This prints out the string we saved our input in. The `{}`s are a placeholder, <del> and so we pass it `input` as an argument. If we had multiple `{}`s, we would </del> <ins> and so we pass it `guess` as an argument. If we had multiple `{}`s, we would </ins> pass multiple arguments: ```rust

Just found the Learn chapter has appeared in nightlies. While working through it the very first bit of code it gets me to run has a bug! It is note the last line we are printing which is there return value of read_line (appears to be number of bytes read) and not the actual string which is what the chapter text implies. Trivial fix... Took me a while to find, but I figured out where the book source is and will submit PR despite it being one word change so far ;).
I guess I made my pull request from that commit badly, but it's I guess this should be closed if that is accepted.


Question: <ins> // compile-flags: -Zsave-analysis </ins> // only-x86_64 <ins> // Also test for #72960 </ins> #![feature(asm)]

<!-- 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. --code from ./src/test/ui/asm/issue- <!-- 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. --repo is @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Does this still happen with (now merged)
I can confirm its fixed. We can probably close this issue.
Closing this, thanks for taking a look!


Question: }; ``` <del> At the moment, `if` and `match`, as well as the looping constructs `for`, `while`, and `loop`, are forbidden inside a `const`, `static`, or `const fn`. </del> <ins> At the moment, `for` loops, `.await`, and the `Try` operator (`?`) are forbidden inside a `const`, `static`, or `const fn`. </ins> <del> This will be allowed at some point in the future, but the implementation is not yet complete. See the tracking issue for [conditionals] or [loops] in a const context for the current status. </del> <ins> This may be allowed at some point in the future, but the implementation is not yet complete. See the tracking issues for [`async`] and [`?`] in `const fn`, and (to support `for` loops in `const fn`) the tracking issues for [`impl const Trait for Ty`] and [`&mut T`] in `const fn`. </ins> <del> [conditionals]: https://github.com/rust-lang/rust/issues/49146 [loops]: https://github.com/rust-lang/rust/issues/52000 </del> <ins> [`async`]: https://github.com/rust-lang/rust/issues/69431 [`?`]: https://github.com/rust-lang/rust/issues/74935 [`impl const Trait for Ty`]: https://github.com/rust-lang/rust/issues/67792 [`&mut T`]: https://github.com/rust-lang/rust/issues/57349 </ins>

I have to use some sort of loop construct within a const function. does explain that loop constructs are at the moment not supported, but as I was trying out first and the compiler rejected it, it would have been helpful if the explanation would hint me towards working. I think the doc just needs a small update and I think the file to update is I tried this code: <!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
, , and are also allowed, but is not.
if it helps, the reason is forbidden but the others work is that uses and traits in const functions are still unstable (search for 'for loops' on https://rust-).
yeah, that's understandable. The confusion on my side was simply that I didn't know I was allowed to user other control flow constructs until somebody mentioned it on IRC I actually could.


Question: <ins> error[E0597]: borrowed value does not live long enough --> $DIR/issue-52049.rs:16:10 | LL |     foo(&unpromotable(5u32)); |          ^^^^^^^^^^^^^^^^^^ - temporary value only lives until here |          | |          temporary value does not live long enough | = note: borrowed value must be valid for the static lifetime... error: aborting due to previous error For more information about this error, try `rustc --explain E0597`. </ins>

suggests but still won't give us a lifetime. We should not emit the if the required lifetime is for the inside the source presume there's some code already checking for producing the "borrowed value must be valid for the static lifetime" message, find that code and bubble up the knowledge about that until you have it in the scope of the "consider using a binding to increase its lifetime" message 't emit the message in that case 'll already fail a bunch of tests, I don't think you need any new tests. Running should succeed and give you a bunch of changes to commit. Check that all changes make sense and just commit them.
can I take this on if nobody is working on this?
All yours!
closing it, as required code change has been merged.


Question: id, expr_ty.repr(self.tcx()), def); match def { <del> def::DefStruct(..) | def::DefVariant(..) => { </del> <ins> def::DefStruct(..) | def::DefVariant(..) | def::DefFn(..) | def::DefStaticMethod(..) => { </ins> Ok(self.cat_rvalue_node(id, span, expr_ty)) } <del> def::DefFn(..) | def::DefStaticMethod(..) | def::DefMod(_) | def::DefForeignMod(_) | def::DefStatic(_, false) | </del> <ins> def::DefMod(_) | def::DefForeignMod(_) | def::DefStatic(_, false) | </ins> def::DefUse(_) | def::DefTrait(_) | def::DefTy(_) | def::DefPrimTy(_) | def::DefTyParam(..) | def::DefTyParamBinder(..) | def::DefRegion(_) | def::DefLabel(_) | def::DefSelfTy(..) | def::DefMethod(..) => {

Hello! The following dumps core when run on my machine (Ubuntu 12.04 LTS, rust-nightly downloaded today (18th Apr)). Ziad Hatahet confirmed the same on a slightly older version of rust.
There's an extra layer of indirection in that struct definition. A is a pointer to a pointer to a function. A statement like expands to . That's obviously creating a dangling pointer onto the stack which is why it ends up crashing. Adjusting the struct definition to should make things work as you want. There's also a bug in rustc for even letting that program compile. I'm not sure if it's already been run into and filed.
cc
This fixes it: But I didn't quite understand why.
it probably happens to reset that part of the stack to the right value.
p.s. This is still crashing in . Thanks
Nominating, something fishy is going on here.
Here's the simplest possible reduction I could make:
Is the compiler mixing up the function pointer with the actual function code? That is, is like So writing is like , i.e. a non- reference to the function pointer.
It's just creating an alloca, storing the function pointer into it, borrowing that, and returning the borrowed pointer. For example, on the program I get this LLVM IR: Basically, the borrow checker doesn't seem to be in on the joke that is referring to a local alloca.
That is the behaviour I would expect if my statement were true. (The double in the LLVM signature indicates what I was talking about: a function value is already the pointer, and so the name doesn't have lifetime.)
0 backcompat-lang
This is probably a mismatch between trans/mem-categorization. I expect mem-categorization is saying that the "reference to the fn" is a static item, but trans is translating it into an rvalue (and hence on the stack).


Question: <ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. struct Foo; fn main() { || if let Foo::NotEvenReal() = Foo {}; //~ ERROR E0599 } </ins>

I was playing around with some code which can be found and is attached below. When I click on output I get the following output: I don't have a rust installation locally right now, so I cannot create the backtrace. I'll add it later today. The code which triggers this:
Stack trace: (There is no ICE with (nothing generated either due to type error). Perhaps playpen should use instead.)
You can get backtrace on playpen here: !
Looks like this has been fixed recently


Question: <ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. struct Foo; fn main() { || if let Foo::NotEvenReal() = Foo {}; //~ ERROR E0599 } </ins>

I was in the middle of making a big changes to some code when this panic occurred. I was expecting a lot of compiler errors but got a compiler panic instead! :fearful: I ran the build with and the panic still occurred. Run to get this. Here's the full output with : Since I was in the middle of editing, there's no commit to point to, so I just attached my source code as is so you have something to debug. When you download it and run , the compiler should panic. The repo is called . I don't know how to narrow this issue down, or else I would try to find a smaller example for you. Hope this is good enough.
Some context for the change that caused this: Before this error happened, I changed the file . I split into two structs, and . I was relying on the compiler to find all the places where that change would effect things, and it seems that something went wrong in the compiler while trying to do that.
Once I fix that, everything works again. No more compiler panic. So it seems to have something to do with when I split up that struct. All the messed up pattern matches caused a panic. (Actually just fixing 2 broken pattern matches fixed the problem.)
I've just encountered this myself. I managed to reduce it down: It looks like this happens when a closure's body is a single (non-block) expression, and a tuple struct pattern is used somewhere in the expression. A simple workaround (if anyone needs one for some reason), then, is to just make the closure body a block:


Question: <ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. struct Foo; fn main() { || if let Foo::NotEvenReal() = Foo {}; //~ ERROR E0599 } </ins>

Related code: Compiler panic: Note that everything is fine if I annotate the lifetimes: I am running , the MSVC x64 version.
I just ran into this. Managed to reduce the crash to Explicit lifetimes indeed fix it:
don't know if this helps, but I came up with minimal test case


Question: <ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. struct Foo; fn main() { || if let Foo::NotEvenReal() = Foo {}; //~ ERROR E0599 } </ins>

Playground Output: Other example (possibly different bug): Output:
I just got the same ICE on linux with both the and builds. My case is essentially the same. You create an iterator of references to sub-elements of some thing which has been passed in by reference. The compiler should figure out that the iterator can only live as long as the original object, but ICEs instead. ()