Question: target_family: Some("windows".to_string()), is_like_windows: true, is_like_msvc: true, <ins> // set VSLANG to 1033 can prevent link.exe from using // language packs, and avoid generating Non-UTF-8 error // messages if a link error occurred. link_env: vec![("VSLANG".to_string(), "1033".to_string())], </ins> pre_link_args: args, crt_static_allows_dylibs: true, crt_static_respected: true,

A localized (e.g. German) MSVC can produce non-UTF-8 output, which can become almost unreadable in the way it's currently forwarded to the user. This can be seen in an (otherwise unrelated) issue comment: Note especially this line: That output might be a lot longer for multiple LNK errors (one line per error, but the lines are not properly separated in the output, because they are converted to ) and become really hard to read. If possible, the output should be converted to Unicode in this case. (previously reported as ) NOTE from Please install Visual Studio English Language Pack side by side with your favorite language pack for UI
I’m surprised we try to interpret any output in Windows as UTF-8 as opposed to UTF-16, like we should.
I suspect that the MSVC compiler's raw output is encoded as Windows-1252 or Windows-1250 (for German) depending on the current console code page and not as UTF-16. Does solve the encoding problem?
No, neither in nor in (usually I'm working with the latter). It prints but the encoding problems persist.
Is it just MSVC which is localized, or is your system codepage itself different? If we know that a certain program's output is the system codepage we could use with to convert it. Perhaps we could check whether the output is UTF-8, and attempt to do the codepage conversion if it isn't.
I am using a German localized Windows. How can I find out the system codepage? The default CP for console windows is "850 (OEM - Multilingual Lateinisch I)".
You can call  with or .
That returns codepage numbers 1252 for and 850 for .
In which case the output from the linker appears to be , so now someone just has to add code to rustc which detects when the linker output isn't utf-8 on windows and use with instead.
I ran into this problem as well (also on a German Windows 10). As a workaround it helps if you go to in Win 10 to Settings -Region and Language -Language and add English as a language and make it default ( you may have to log out and back in again). After that, programs like should output using a locale that works with rust as it is right now.


Question: target_family: Some("windows".to_string()), is_like_windows: true, is_like_msvc: true, <ins> // set VSLANG to 1033 can prevent link.exe from using // language packs, and avoid generating Non-UTF-8 error // messages if a link error occurred. link_env: vec![("VSLANG".to_string(), "1033".to_string())], </ins> pre_link_args: args, crt_static_allows_dylibs: true, crt_static_respected: true,

It would still be great if this could be fixed in rust :)
Just saw another instance of this in , except with ) (a common encoding in China), where got printed instead of the desired .
Using nightly 2019-07-04, we can confirm that this issue is fixed. (I'm using Chinese version of Visual Studio).
For me, it still does not work even with nightly build (1.38 x86_64-pc-windows-msvc, Russian version of VS). I try to compile a Hello world project in Intellij Idea but always get the exception:
Could you execute and see what that outputs?
That's a little strange. Could you open "x64 Native Tools Command Prompt for Visual Studio 2019" from start menu, and execute the following command: And see whether the output is English? If the output's still not in English, would you mind open "Visual Studio Installer" from start menu, choose "Modify" for the corresponding Visual Studio edition, and in the Language packs tab, install the English language pack. And try the instructions above again?
thanks! The hint about installing the English language pack has made the previous error disappear. But now I have another message while running in Idea: I haven't changed the path to the std library, it's looks like
Yes, this is the same error as before, it's because you didn't install windows sdk. Choose the newest one in the visual studio installer too.
thank you again. Now it's compiling and running. I'm happy ;) Just out of curiosity: was I supposed to know in advance that I would need an English lang pack and a Windows SDK when installing Visual Studio?
Please feel free to point out places where Rust tells you to install Visual Studio but does not tell you to install the Windows SDK, so that we can fix those places. It might still be worth implementing the text encoding version of the fix for people who don't have the English language pack, though I really wish we could just get unicode output out of VS without having to specify a language.
sorry, seems I was a bit inattentive. Now I double-checked: after starting rustup- the screen info says, I should assure that I have Windows SDK installed. So my fault, nothing to fix there :) Thanks.
This is not a fix anymore.


Question: target_family: Some("windows".to_string()), is_like_windows: true, is_like_msvc: true, <ins> // set VSLANG to 1033 can prevent link.exe from using // language packs, and avoid generating Non-UTF-8 error // messages if a link error occurred. link_env: vec![("VSLANG".to_string(), "1033".to_string())], </ins> pre_link_args: args, crt_static_allows_dylibs: true, crt_static_respected: true,

refer to
Please make sure you have installed Visual Studio English Language Pack side by side with your favorite language pack for UI for this to work.
I'm not sure this problem is really fixed. The PR that closed this kinda works around the issue because English is usually ASCII which is the same in UTF-8. However, as noted above, this relies on the Visual Studio English language pack being installed which it isn't always. And that there's no non-ascii output (e.g. file paths, etc). The suggestion to use with seems like a better fix, imho.


Question: python2.7 "$BUILD_SOURCESDIRECTORY/src/tools/publish_toolstate.py" "$(git rev-parse HEAD)" "$(git log --format=%s -n1 HEAD)" "" "" cd .. rm -rf rust-toolstate <del> condition: and(succeeded(), eq(variables['IMAGE'], 'mingw-check')) </del> <ins> condition: and(succeeded(), not(variables.SKIP_JOB), eq(variables['IMAGE'], 'mingw-check')) </ins> displayName: Verify the publish_toolstate script works - bash: |

This issue is meant to track where on Travis we currently whenever the commit message looks like it updates a submodule. We should enable something similar for Azure Pipelines where whenever a PR is detected as updating a submodule (either via actually looking at the git history or at the git commit message) then we schedule the builder on the PR. The purpose of this PR build is to help weed out errors even sooner than before where we're just running a smoke tests on Linux on each PR.


Question: #![crate_name = "foo"] <del> // The goal of this test is to answer that it won't be generated as a list because </del> <ins> // The goal of this test is to ensure that it won't be generated as a list because </ins> // block doc comments can have their lines starting with a star. // @has foo/fn.foo.html

Hi, I've just published a new version of my crate and the generated documentation is including a lot of bullet points that have never been included before. When I generate the docs locally on the 1.8.1 source code using the latest stable version of rust I see the same formatting for the 1.8.0 that generated, so I think this is a bug that's slipped into the nightly version of Stable local docs: ! ! My guess is that it's because I'm using block comments, the unwanted bullet points seem to match up with empty lines in the documentation comment which consist of just a . Thanks
Seems potentially related to , but the latest builds were from a nightly that should have that fixed in; cc you probably have some idea on where the issue is.
This is highly surprising indeed. Can you run with the last nightly locally and tell us if it reproduces the bug please? If so, I'll try to check what's wrong in rustdoc.
I have ran cargo doc on the latest nightly locally (nightly-x86_64-unknown-linux-gnu rustc 1.60.0-nightly ( 2022-01-20)) and it has reproduced the bug - I see the same generated docs as from the build.
It'll be fixed by
Thanks, is there any way I can get to rebuild the docs for the affected versions or will I have to submit a new version of my library to get a fixed build?
Sure. But that for that, please open an issue on repository directly.


Question: <del> error[E0271]: type mismatch resolving `<Empty<_> as Stream>::Item == Repr` --> $DIR/issue-89008.rs:38:43 | LL |     fn line_stream<'a, Repr>(&'a self) -> Self::LineStreamFut<'a, Repr> { |                        ----               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ type mismatch resolving `<Empty<_> as Stream>::Item == Repr` |                        | |                        this type parameter | note: expected this to be `()` --> $DIR/issue-89008.rs:17:17 | LL |     type Item = (); |                 ^^ = note:   expected unit type `()` found type parameter `Repr` error: aborting due to previous error For more information about this error, try `rustc --explain E0271`. </del>

<!-- 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. --Playing around with (the not yet stable) and features I stumbled over the below problem, where type parameters to nested TAIT/GAT with lifetime parameters cause a "this type parameter needs to be std::marker::Sized" compiler error. The following code fails to compile with below compiler error (): In contrast, the following code, without lifetime type parameters compiles without any error. <!-- 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. --:
This gives a different error. Minimized:
GATs issue triage: not blocking. Seems like a TAITs bug; not sure there's anything for GATs to change here.
Compiles just fine now.
I guess this issue can just be closed if there's a test already?
I think test needs to be moved to correct place?
Hello, first time contributing to rust. I was trying to resolve this issue and after looking at the test I am a little confused. To me it looks like the test code is failing correctly and I can't understand where the TAIT bug is. has a concrete type whereas the function is generic over . So to me it looks like the raised error is correct. Changing the implementation to makes the code compile. I am sorry if I am missing something here. If the test is correct then would moving the test to resolve this issue? I also don't think relates to this test.
Yeah, I messed up my minimization. The test should just use the original MCVE in the OP. And that is indeed fixed.
For clarity: this can be closed when the current known-bug test is moved to the main directory for GAT tests and changed to use the OP MCVE.


Question:
}).is_some(); render_deref_methods(w, cx, impl_, containing_item, has_deref_mut)?; }  write!(w, "
Trait  Implementations
")?;   write!(w, "
 Trait Implementations
 ")?;  for i in &traits { let did = i.trait_did().unwrap(); let assoc_link = AssocItemLink::GotoSource(did, &i.inner_impl().provided_trait_methods);

A page like has many things that could be useful to link to. These should be possible to link to by clicking on: [x] The header [x] 's on a page. [x] at the top On it's hit or miss: [x] Examples [x] Associated Types [x] Required Methods [x] Implementors On [x] Provided Methods I don't have any big use cases but when I want to link to these for something like this bug I can't link to any specific line. I gotta say go to vec page, scroll 75% to bottom. Squint hard to see it.
Just ran into this today; I'd really like to have links from the impls in the Implementors section to the source containing the impl.
Triage: we always need more links....
Update: Headers written in docs and (most) auto-generated headers are either fully hyperlinked or have a "section marker" symbol that shows up on hover. Major auto-generated page headers have links in the top of the sidebar of the page. Impl blocks do not have hyperlinks (yet); that's
Since got merged and closed out , that was the last major request on this issue, so i'll close this out. If you think of something else that needs a hyperlinked header, feel free to open a new issue or reopen this one.


Question: let externs = options.externs.clone(); let render_options = options.render_options.clone(); let scrape_examples_options = options.scrape_examples_options.clone(); <ins> let document_private = options.render_options.document_private; </ins> let config = core::create_config(options); interface::create_compiler_and_run(config, |compiler| {

The ICE appears with and , but not . Beta: <details<summary<strongBacktrace</strong</summary<p</p</details
this is a regression affecting the release that is being prepared today.
I'll take a look.


Question: <ins> PRINT-ATTR INPUT (DISPLAY): fn foo < T > () where T : Copy + { } PRINT-ATTR INPUT (DEBUG): TokenStream [ Ident { ident: "fn", span: $DIR/trailing-plus.rs:11:1: 11:3 (#0), }, Ident { ident: "foo", span: $DIR/trailing-plus.rs:11:4: 11:7 (#0), }, Punct { ch: '<', spacing: Alone, span: $DIR/trailing-plus.rs:11:7: 11:8 (#0), }, Ident { ident: "T", span: $DIR/trailing-plus.rs:11:8: 11:9 (#0), }, Punct { ch: '>', spacing: Alone, span: $DIR/trailing-plus.rs:11:9: 11:10 (#0), }, Group { delimiter: Parenthesis, stream: TokenStream [], span: $DIR/trailing-plus.rs:11:10: 11:12 (#0), }, Ident { ident: "where", span: $DIR/trailing-plus.rs:11:13: 11:18 (#0), }, Ident { ident: "T", span: $DIR/trailing-plus.rs:11:19: 11:20 (#0), }, Punct { ch: ':', spacing: Alone, span: $DIR/trailing-plus.rs:11:20: 11:21 (#0), }, Ident { ident: "Copy", span: $DIR/trailing-plus.rs:11:22: 11:26 (#0), }, Punct { ch: '+', spacing: Alone, span: $DIR/trailing-plus.rs:11:27: 11:28 (#0), }, Group { delimiter: Brace, stream: TokenStream [], span: $DIR/trailing-plus.rs:11:29: 12:2 (#0), }, ] </ins>

The following code: is currently pretty-printed as: If this occurs in a macro invocation, it leads to an instance of
Extra info (but it boils down to what said): Using I get the following log: Rendered diff:
This applies to all trailing separators in theory (except that the separator is leading rather than trailing in this case), but in other cases the difference is fixed up by fuzzy comparison in .


Question: } #[test] <del> #[cfg_attr(any(target_os = "vxworks", target_os = "android"), ignore)] </del> <ins> #[cfg_attr(any(target_os = "vxworks"), ignore)] </ins> fn exit_reported_right() { let p = if cfg!(target_os = "windows") { Command::new("cmd").args(&["/C", "exit 1"]).spawn() } else { <del> Command::new("false").spawn() </del> <ins> shell_cmd().arg("-c").arg("false").spawn() </ins> }; assert!(p.is_ok()); let mut p = p.unwrap();

To enable test on android bot and test/run-pass/rtio- It looks to me RtioProcess does not work properly on android.
logs are
Hm this may be an FFI issue with libuv. I realized during my uv rewrite that libuv is giving us an int64t exit status and we think it's a cint. Once lands this may be fixed.
Hmm, this issue number has propagated to several more tests that are cfg-disabled on android. (Some of which are now failing when I mixed in a Boehm/BDW conservative GC into the runtime, in particular .)
Also, has landed, so it would be good to determine if these tests now work on Android.
Triage: I have no idea how to test this, but a lot has changed in a year (especially the removal of green & libuv), so these may be magically fixed; if someone can check.
Triage: is gone, but all these tests in are still ignored for android.
I tried to run these tests with but they all failed with , which seems suspect (at least for the tests that invoke , , , etc.). Is there a better way to test? I have an android device available.


Question: is_valid = false; } <del> sym::hidden if !self.check_doc_hidden(attr, meta_index, meta, hir_id, target, ) => { is_valid = false; } </del> // no_default_passes: deprecated // passes: deprecated // plugins: removed, but rustdoc warns about it itself

The warning by claims that on an impl item is ignored by rustdoc, but it isn't necessarily. The warning says: which is not true in the following repro: This warning is a false positive. Rustdoc does pay attention to this attribute. For the code above, the rendered documentation of and looks like: <table<tr<td<img src="https://user-" height="185"</td<td<img src="https://user-" height="300"</td</tr</tableAfter removing the supposedly unused attribute and rendering again, the "nasty uninteresting type" that we wanted not shown is going to get rendered on both pages: <table<tr<td<img src="https://user-" height="185"</td<td<img src="https://user-" height="300"</td</tr</table( :


Question: is_valid = false; } <del> sym::hidden if !self.check_doc_hidden(attr, meta_index, meta, hir_id, target, ) => { is_valid = false; } </del> // no_default_passes: deprecated // passes: deprecated // plugins: removed, but rustdoc warns about it itself

Just wanted to add that this is also affecting , but in a different way: <img width="500" src="https://user-"The isn't there at all without the : <img width="500" src="https://user-"Based on the above, this isn't correct: it actually hides the entire thing, at least for associated constants.
In your case, it's inherent associated items being accidentally flagged which is which was meaning the most recent nightly should not have your issue anymore. Sorry for the inconvenience. The longer I look this lint, the less I like it.


Question: if let Ok(snippet) = self.infcx.tcx.sess.source_map().span_to_snippet(span) { let is_option = move_ty.starts_with("std::option::Option"); let is_result = move_ty.starts_with("std::result::Result"); <del> if is_option || is_result { </del> <ins> if (is_option || is_result) && use_spans.map_or(true, |v| !v.for_closure()) { </ins> err.span_suggestion( span, &format!("consider borrowing the `{}`'s content", if is_option {

gives the error: Error0507 gives a wrong suggestion here:
Error: Label D-invalid-suggestion can only be set by Rust team members Please let know if you're having trouble with this bot.
modify labels: A-suggestion-diagnostics C-bug T-compiler


Question: <ins> // test for `doc(hidden)` with impl parameters in the same crate. #![crate_name = "foo"] #[doc(hidden)] pub enum HiddenType {} #[doc(hidden)] pub trait HiddenTrait {} pub enum MyLibType {} // @!has foo/enum.MyLibType.html '//*[@id="impl-From%3CHiddenType%3E"]' 'impl From<HiddenType> for MyLibType' impl From<HiddenType> for MyLibType { fn from(it: HiddenType) -> MyLibType { match it {} } } pub struct T<T>(T); // @!has foo/enum.MyLibType.html '//*[@id="impl-From%3CT%3CT%3CT%3CT%3CHiddenType%3E%3E%3E%3E%3E"]' 'impl From<T<T<T<T<HiddenType>>>>> for MyLibType' impl From<T<T<T<T<HiddenType>>>>> for MyLibType { fn from(it: T<T<T<T<HiddenType>>>>) -> MyLibType { todo!() } } // @!has foo/enum.MyLibType.html '//*[@id="impl-HiddenTrait"]' 'impl HiddenTrait for MyLibType' impl HiddenTrait for MyLibType {} // @!has foo/struct.T.html '//*[@id="impl-From%3CMyLibType%3E"]' 'impl From<MyLibType> for T<T<T<T<HiddenType>>>>' impl From<MyLibType> for T<T<T<T<HiddenType>>>> { fn from(it: MyLibType) -> T<T<T<T<HiddenType>>>> { match it {} } } </ins>

Last line yields several occurrences of in the generated file. ## Expected behavior No occurrences of anywhere since it was label C-bug T-rustdoc cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I expect the fix is to check for just after
claim
cc I checked for doc(hidden) like this: But it doesn't seem to work, as my test would fail. I also tried using the same way to check for but it also failed. I noticed that the issue involves so I might need to iterate over generic parameters, I cannot find any function that does that in , so can someone point me in the right direction? Thanks :)
You can look at how the pass works:
am I right in understanding this only happens for cross-crate traits, and impls for hidden traits in the same crate are still hidden? In other words, just makes the cross-crate case consistent?
I believe so, yes: the pass was already taking care of such cases for local types. FWIW, the thing that motivated this discussion was noticing a leaking on the docs for , but not on the ones for


Question: return; } <ins> if !ensure_stage1_toolchain_placeholder_exists(stage_path) { println!( "Failed to create a template for stage 1 toolchain or confirm that it already exists" ); return; } </ins> if try_link_toolchain(&stage_path[..]) { println!( "Added `stage1` rustup toolchain; try `cargo +stage1 build` on a separate rust project to run a newly-built toolchain"

I tried this code on a fresh git clone of rust-lang/rust: I expected to see this happen: setup works without errors. Instead, this happened: x.py gives an error: This feature was introduced in and worked at that time. do you have time to look into this? The original bug report was from Nazar Mokrynskyi , not sure their github username. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Yes, I'll take a look over the next few days.
Hello. Is there a workaround for this issue for now? I got But when I ran , I got .
OK. After reading the zulip thread, I figured out how to work around it. After running , succeeded.
claim


Question: legacy_imports: LegacyMacroImports, allow_shadowing: bool) { let import_macro = |this: &mut Self, name, ext: Rc<_>, span| { <ins> this.used_crates.insert(module.def_id().unwrap().krate); </ins> if let SyntaxExtension::NormalTT(..) = *ext { this.macro_names.insert(name); }

When on latest rust nightly , you get an ICE when compiling .
Its a pretty recent regression, it can't be reproduced with .
Okay, managed to minimize it: Looks like a regression of . cc any ideas on this?
Yeah, this was caused by an oversight in -- fixed in .


Question: use crate::mir::*; use crate::ty::subst::SubstsRef; <del> use crate::ty::{CanonicalUserTypeAnnotation, Ty}; </del> <ins> use crate::ty::{self, CanonicalUserTypeAnnotation, Ty}; </ins> use rustc_span::Span; macro_rules! make_mir_visitor {

Originally posted by in , see that PR discussion for more detail <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
are you still looking into this? If so, please reassign yourself
claim


Question: self.lookup_and_handle_method(expr.hir_id); } hir::ExprKind::Assign(ref left, ref right, ..) => { <del> // Ignore write to field self.visit_expr(base_expr(left)); </del> <ins> self.handle_assign(left); </ins> self.visit_expr(right); 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. --Here's a reduced test-case from Firefox source code: Compiling that program warns with: Which is obviously not true. <!-- 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. --:
Seems like this is a regression from .
cc
Oops, sorry! Technically, field is, in fact, never read. What went wrong is is written and read through other ways. I think restricting the lint to non-reference fields should work, and will submit a PR to do so quickly. Please double check whether my thinking is correct.
Ah, yeah, I somehow thought that the macro was needed to trigger the bug but it is not. That sounds good. Writes to mutable references have side effects so doing that seems ok.
Would that also cover this case here, in the idna crate? (The field is a reference to an type, which is in fact returned to the caller of .)
Yeah, I think it's the same.
Ah, this was closed, but the bug leaked into beta (as mentioned in ) while the fix is only in nightly. Reopening and tagging as stable-to-beta regression
Assigning and removing .
As noted on , we're going to resolve the beta issue by reverting PR on beta (which I have assigned myself to take care of).
This was a regression affecting beta 1.51, closing this.


Question: if let Some(ref dir) = build.lldb_python_dir { cmd.arg("--lldb-python-dir").arg(dir); } <ins> let llvm_config = build.llvm_config(target); let llvm_version = output(Command::new(&llvm_config).arg("--version")); cmd.arg("--llvm-version").arg(llvm_version); </ins> cmd.args(&build.flags.args);

I believe this is due to travis using system llvm which misses the fix backported in . cc
Can we do anything about this?
Our best bet is to add a for tests, I think (alternative is to drop support for LLVM pre 3.9, which would be a shame, even if its buggy in certain cases). Implementation of such directive could be implemented by injecting an environment variable or some such (done ) and checking for that in
There's no need to set an extra environment variable, just check if is set (or if you're boring :wink: )
but… but… what if people have on their own systems too?
cc
no we do not have existing infrastructure for this. I'd prefer to avoid as that's not the relevant piece here, but rather something like or . Distros or anyone else building with an older LLVM are likely to hit this and we'd need a solution for them as well. That being said I think it's fine to temporarily disable the test until we get that. There's basically a 0% chance of us regressing that test as it's just an LLVM bug, and they already have a regression test upstream as well.
Another option would be to create a base Docker image (publishing it to Docker Hub) that is just and the appropriate steps to build whatever version of LLVM we want.
We currently advertise ourselves as supporting LLVM 3.7+, and Travis is kinda our test for that, so I'd prefer to not pull that forward just yet (but instead just fix this)
For the record, I downgraded our LLVM version in a botched rebase and only this test stopped it at bors. Hopefully, someone would have noticed the absence of a fix, but you can't count of that.
touche!


Question: } } <ins> fn collect_predicates_for_types(&mut self, obligation: &TraitObligation<'tcx>, trait_def_id: ast::DefId, types: Vec<Ty<'tcx>>) -> Vec<PredicateObligation<'tcx>> { let derived_cause = match self.tcx().lang_items.to_builtin_kind(trait_def_id) { Some(_) => { self.derived_cause(obligation, BuiltinDerivedObligation) }, None => { self.derived_cause(obligation, ImplDerivedObligation) } }; let normalized = project::normalize_with_depth(self, obligation.cause.clone(), obligation.recursion_depth + 1, &types); let obligations = normalized.value.iter().map(|&nested_ty| { // the obligation might be higher-ranked, e.g. for<'a> &'a // int : Copy. In that case, we will wind up with // late-bound regions in the `nested` vector. So for each // one we instantiate to a skolemized region, do our work // to produce something like `&'0 int : Copy`, and then // re-bind it. This is a bit of busy-work but preserves // the invariant that we only manipulate free regions, not // bound ones. self.infcx.try(|snapshot| { let (skol_ty, skol_map) = self.infcx().skolemize_late_bound_regions(&ty::Binder(nested_ty), snapshot); let skol_predicate = util::predicate_for_trait_def( self.tcx(), derived_cause.clone(), trait_def_id, obligation.recursion_depth + 1, skol_ty); match skol_predicate { Ok(skol_predicate) => Ok(self.infcx().plug_leaks(skol_map, snapshot, &skol_predicate)), Err(ErrorReported) => Err(ErrorReported) } }) }).collect::<Result<Vec<PredicateObligation<'tcx>>, _>>(); match obligations { Ok(mut obls) => { obls.push_all(normalized.obligations.as_slice()); obls }, Err(ErrorReported) => Vec::new() } } </ins> /////////////////////////////////////////////////////////////////////////// // CONFIRMATION //

For example, this code does not compile: cc
I think this may be another instance of
Trusting analysis, closing in favor of but adding test case there as well.
(it of course would be good to confirm that this actually is an instance of -- my initial reaction when I saw it was "they might be related ... but wait, wasn't part of the opt-in-builtin-bounds work to be able to move the special case handling of / out into library code...?"; I've only done some rough skimming that makes me think the hypothesis remains plausible.)
Ah either way is fine by me, I personally like fewer issues :). We can reopen once is addressed one way or another if necessary (or if you'd like to reopen now that's also fine by me!)
oh that was really just a note to myself as much as anything else, not a comment on your choice to close this ticket. :)
I don't think this code uses type-contents. If it does, that is itself a bug! Either way, we should keep this open for the time being.
cc


Question: } } <ins> fn collect_predicates_for_types(&mut self, obligation: &TraitObligation<'tcx>, trait_def_id: ast::DefId, types: Vec<Ty<'tcx>>) -> Vec<PredicateObligation<'tcx>> { let derived_cause = match self.tcx().lang_items.to_builtin_kind(trait_def_id) { Some(_) => { self.derived_cause(obligation, BuiltinDerivedObligation) }, None => { self.derived_cause(obligation, ImplDerivedObligation) } }; let normalized = project::normalize_with_depth(self, obligation.cause.clone(), obligation.recursion_depth + 1, &types); let obligations = normalized.value.iter().map(|&nested_ty| { // the obligation might be higher-ranked, e.g. for<'a> &'a // int : Copy. In that case, we will wind up with // late-bound regions in the `nested` vector. So for each // one we instantiate to a skolemized region, do our work // to produce something like `&'0 int : Copy`, and then // re-bind it. This is a bit of busy-work but preserves // the invariant that we only manipulate free regions, not // bound ones. self.infcx.try(|snapshot| { let (skol_ty, skol_map) = self.infcx().skolemize_late_bound_regions(&ty::Binder(nested_ty), snapshot); let skol_predicate = util::predicate_for_trait_def( self.tcx(), derived_cause.clone(), trait_def_id, obligation.recursion_depth + 1, skol_ty); match skol_predicate { Ok(skol_predicate) => Ok(self.infcx().plug_leaks(skol_map, snapshot, &skol_predicate)), Err(ErrorReported) => Err(ErrorReported) } }) }).collect::<Result<Vec<PredicateObligation<'tcx>>, _>>(); match obligations { Ok(mut obls) => { obls.push_all(normalized.obligations.as_slice()); obls }, Err(ErrorReported) => Vec::new() } } </ins> /////////////////////////////////////////////////////////////////////////// // CONFIRMATION //

The following doesn't compile, but I believe it should: Error: Even though , and . In fact, this compiles:
should be , because the old definition that didn't use assoc types was . Probably the code that detects builtin bounds wasn't updated to handle associated types. cc
This breaks us in hyper. For now, I'll have to manually , knowing that it's safe.,,


Question: #[primary_span] pub span: Span, } <ins> #[derive(Diagnostic)] #[diag(hir_analysis::missing_parentheses_in_range, code = "E0689")] pub struct MissingParentheseInRange { #[primary_span] #[label(hir_analysis::missing_parentheses_in_range)] pub span: Span, pub ty_str: String, pub method_name: String, #[subdiagnostic] pub add_missing_parentheses: Option<AddMissingParenthesesInRange>, } #[derive(Subdiagnostic)] #[multipart_suggestion_verbose( hir_analysis::add_missing_parentheses_in_range, applicability = "maybe-incorrect" )] pub struct AddMissingParenthesesInRange { pub func_name: String, #[suggestion_part(code = "(")] pub left: Span, #[suggestion_part(code = ")")] pub right: Span, } </ins>

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should something like this: label +D-confusing +D-invalid-suggestion <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim


Question: (config.mode == common::Pretty && parse_name_directive(ln, "ignore-pretty")) || (config.target != config.host && parse_name_directive(ln, "ignore-cross-compile")) || <del> ignore_gdb(config, ln) || ignore_lldb(config, ln); </del> <ins> ignore_gdb(config, ln) || ignore_lldb(config, ln) || ignore_llvm(config, ln); </ins> props.should_fail = props.should_fail || parse_name_directive(ln, "should-fail"); });


Question: |      ^^^ type aliases cannot be used as traits | help: you might have meant to use `#![feature(trait_alias)]` instead of a `type` alias <del> --> $DIR/issue-3907.rs:5:1 </del> | <del> LL | type Foo = dyn issue_3907::Foo; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ </del> <ins> LL | trait Foo = dyn issue_3907::Foo; | </ins> help: consider importing this trait instead | LL | use issue_3907::Foo;

I managed to reproduce the problem with this snippet: The compiler yells E0404 at me, but fair enough I always ask it to a bit more about it :) However this time, it only says this: This is confusing because the snippet above doesn't involve the keyword so I didn't understand initially what I was doing wrong, then I read the error message again: I first tried this, and it worked, but having to repeat the whole syntax everywhere wasn't too compelling, hence the alias: The compiler error message makes it very clear that I can't alias a trait, but the E0404 explanation doesn't mention it at all. I hope the description could also include this use case as I've seen sometimes EXXXX explanations go over several facets of the same problem. That won't help me, but maybe others that may trip on the same problem. I would have submitted a pull request for the docs myself, but I have no idea why you can't use type aliases for traits so I can't it ;) I'm using stable Rust 1.19.0 (on Fedora).
One more thing, even though the compiler lets me create an alias for a trait, I don't know when I can use such an alias. Maybe this should be explained too.
Current output (in nightly):
Current output: No structured suggestion for the nightly feature (should be and the feature flag).


Question: // `public_items` map, so we can skip inserting into the // paths map if there was already an entry present and we're // not a public item. <del> if !self.cache.paths.contains_key(&item.item_id.expect_def_id()) </del> <ins> let item_def_id = item.item_id.expect_def_id(); if !self.cache.paths.contains_key(&item_def_id) </ins> || self .cache .effective_visibilities <del> .is_directly_public(self.tcx, item.item_id.expect_def_id()) </del> <ins> .is_directly_public(self.tcx, item_def_id) </ins> { <del> self.cache.paths.insert( item.item_id.expect_def_id(), (self.cache.stack.clone(), item.type_()), ); </del> <ins> self.cache .paths .insert(item_def_id, (self.cache.stack.clone(), item.type_())); </ins> } } }

Generated rustdoc JSON for every one of dozens of crates I've looked at seems to contain unexpected inlined items that look like an block and its contents. I expected to see this happen: rustdoc JSON file contains only the items defined or re-exported by the corresponding crate. Instead, this happened: the rustdoc JSON file contains items like this: In this example, is and here are the names of the items contained in that impl (also part of the rustdoc JSON): Similarly, you can find items from : Invocation for generating rustdoc JSON: : You can find a variety of pre-generated rustdoc JSON files with this issue here: Briefly discussed in Zulip: https://rust- I'll have to work around this behavior to shield , which uses the same codebase as the playground link above. I can hold off on updating the playground for, say, another week, but at some point I'll need to upgrade it to include my workaround which means those items will cease being shown. label +T-rustdoc +A-rustdoc-json
Possibly duplicate of
Might be! Definitely at least some overlap, not entirely sure if duplicate. Do you mind if I ship the workaround for this in cargo-semver-checks and the playground, which will hide these items from our lints and from queries in the playground?
Yeah, it's easy enough to reproduce in raw json, I'm not worried about the repro breaking.


Question: <ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. struct Foo; impl Foo { fn putc(&self, b: u8) { } fn puts(&self, s: &str) { for byte in s.bytes() { self.putc(byte) } } } fn main() {} </ins>

Minimised example: Both the and the fail in the same way, with an ICE: Adding bounds to and on the trait or in the fn’s where clause doesn’t fix it, but changing to does fix it. (In the particular case that I was dealing with, the lifetime could_ be changed to where this was a problem, but it would only have taken a slight variation of it for me to be in a situation where I needed a non- implementation. There were, of course, other arguments which were using the .) The whole thing around there seems a bit fragile and I’m not quite sure what’s supposed to work and what’s not; if we just take an and transmute it to , for example, we get “error: cannot transmute to or from a type that contains type parameters in its interior [E0139]”. Anyway, an ICE is always a bug, so here’s the report!
No longer repros. compiles now. Fails with: But no ICE.


Question: <ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. struct Foo; impl Foo { fn putc(&self, b: u8) { } fn puts(&self, s: &str) { for byte in s.bytes() { self.putc(byte) } } } fn main() {} </ins>

While trying to learn how to return a closure.... I came across this.. gives....
Commenting-out the body of still results in an ICE.
I can't seem to produce an ICE no matter what I do.
Those closure kinds info are already gone, so I think many related bugs are gone as well. e.g. I cannot reproduce a bug related to closure kinds and macro


Question: <ins> // check-pass // aux-build:test-macros.rs // compile-flags: -Z span-debug #![no_std] // Don't load unnecessary hygiene information from std extern crate std; #[macro_use] extern crate test_macros; macro_rules! empty_stmt { ($s:stmt) => { print_bang!($s); // Currently, all attributes are ignored // on an empty statement #[print_attr] #[rustc_dummy(first)] #[rustc_dummy(second)] $s } } fn main() { empty_stmt!(;); } </ins>

This the the of a proc macro crate : And here is the of another crate: When building, this outputs: 49.0, 1.50.0-beta.5 rustc 1.51.0-nightly ( 2021-01-05) binary: rustc commit-hash: commit-date: 2021-01-05 host: x86_64-unknown-linux-gnu release: 1.51.0-nightly
cc
cc
Assigning as discussed as part of the and removing .
assigning to self to confirm if is the cause of the breakage, and if so, revert the PR until it can be revised to handle this case.
This is caused by us not handling properly - I'm working on a fix.
Opened


Question: <ins> #!/bin/sh CARGO_TARGET_DIR=$(pwd)/target/ export CARGO_TARGET_DIR echo 'Deprecated! `util/dev` usage is deprecated, please use `cargo dev` instead.' cd clippy_dev && cargo run -- "$@" </ins>

The following sample crashed rustc: Removing the , or unwrapping the (leaving only ), or replacing the predicate (leaving ), solves the crash. Reproduced on Windows 64-bit, Fedora 32-bit, Ubuntu 64-bit. Full crash log (thanks to ) @ Short crash message:
Fixed pending
Fixed in


Question: <ins> #!/bin/sh CARGO_TARGET_DIR=$(pwd)/target/ export CARGO_TARGET_DIR echo 'Deprecated! `util/dev` usage is deprecated, please use `cargo dev` instead.' cd clippy_dev && cargo run -- "$@" </ins>

While I was playing with the new rustc 0.6, I encountered an internal compiler error The source code is here: Compiler version is 0.6, built with gcc, on OS X 10.7.5
If you run rustc under gdb and break on , could you paste the backtrace here?
OK. Here is the backtrace:
Looks like stack exhaustion to me. What happens if you remove ?
The code compiles with no problem when I wrap the rest of the code with mod block. Like:
This yields a proper error message now; closing.


Question: <ins> #!/bin/sh CARGO_TARGET_DIR=$(pwd)/target/ export CARGO_TARGET_DIR echo 'Deprecated! `util/dev` usage is deprecated, please use `cargo dev` instead.' cd clippy_dev && cargo run -- "$@" </ins>

When you download the 0.6 tarball and execute ./configure && make, a download occurs. and a wget info dump appears. It would be really awesome if this piece was integrated with the tarball. Not all environments are friendly to downloading arbitrary code off the net. E.g., I might be in a SCIF[1] and experimenting with Rust on a machine disconnected from the public net. Or I might be on a laptop working in a no-wifi area. :-/ (I know this is probably a real low priority issue, but it IS a (usually minor) hassle) [1]
Please note that you can avoid that if you already have a (compatible) locally installed rust compiler. Check the --local-rust and --local-rust-root parameters for ./configure. Also, I'm against bundling binaries in source tarballs. They are target-dependent and bundling all of them will make the released archive quite large. Downloading an external bootstrapper is a minor issue for downstream packagers too, though. See
far-future
Yeah, you can also just populate the directory in your builddir with an appropriate snapshot tarball. There's not much else we can do here. Putting binaries in a source tarball feels even worse, to me. Closing as I don't expect we're going to much change the requirements here and have several workable workarounds.


Question: <ins> #!/bin/sh CARGO_TARGET_DIR=$(pwd)/target/ export CARGO_TARGET_DIR echo 'Deprecated! `util/dev` usage is deprecated, please use `cargo dev` instead.' cd clippy_dev && cargo run -- "$@" </ins>

As seen in , LLVM has lots of places where it will insert calls to libm directly, not switching stacks. One of places that I recall seeing this before is the translation of the instruction. Rust has floating point modulus and presumably it is doing it in the red zone.
We can solve this with an lang item.
Is this an issue with calls to compiler-rt too? Or are they compiled in some special way to avoid the issue?
Nominating for milestone 5, production-ready
, , and are also all generated. As far as I can tell, we can't prevent it from generating these by altering the IR we output.
We can possibly be selective about when we emit memcpy/memmov, second guessing LLVM (like, never for big things)
accepted for production-ready milestone
Closing due to segmented stacks being gone (stack switches no longer a thing)


Question: id: AllocId, liveness: AllocCheck, ) -> InterpResult<'static, (Size, Align)> { <del> // Regular allocations. if let Ok(alloc) = self.get(id) { return Ok((Size::from_bytes(alloc.bytes.len() as u64), alloc.align)); } // Function pointers. if let Ok(_) = self.get_fn_alloc(id) { return if let AllocCheck::Dereferencable = liveness { // The caller requested no function pointers. err!(DerefFunctionPointer) } else { Ok((Size::ZERO, Align::from_bytes(1).unwrap())) }; } // Foreign statics. // Can't do this in the match argument, we may get cycle errors since the lock would // be held throughout the match. let alloc = self.tcx.alloc_map.lock().get(id); match alloc { Some(GlobalAlloc::Static(did)) => { assert!(self.tcx.is_foreign_item(did)); // Use size and align of the type let ty = self.tcx.type_of(did); let layout = self.tcx.layout_of(ParamEnv::empty().and(ty)).unwrap(); return Ok((layout.size, layout.align.abi)); </del> <ins> // Don't use `self.get` here as that will // a) cause cycles in case `id` refers to a static // b) duplicate a static's allocation in miri match self.alloc_map.get_or(id, || Err(())) { Ok((_, alloc)) => Ok((Size::from_bytes(alloc.bytes.len() as u64), alloc.align)), Err(()) => { // Not a local allocation, check the global `tcx.alloc_map`. // Can't do this in the match argument, we may get cycle errors since the lock would // be held throughout the match. let alloc = self.tcx.alloc_map.lock().get(id); match alloc { Some(GlobalAlloc::Static(did)) => { // Use size and align of the type. let ty = self.tcx.type_of(did); let layout = self.tcx.layout_of(ParamEnv::empty().and(ty)).unwrap(); Ok((layout.size, layout.align.abi)) }, Some(GlobalAlloc::Memory(alloc)) => // Need to duplicate the logic here, because the global allocations have // different associated types than the interpreter-local ones. Ok((Size::from_bytes(alloc.bytes.len() as u64), alloc.align)), Some(GlobalAlloc::Function(_)) => { if let AllocCheck::Dereferencable = liveness { // The caller requested no function pointers. err!(DerefFunctionPointer) } else { Ok((Size::ZERO, Align::from_bytes(1).unwrap())) } }, // The rest must be dead. None => if let AllocCheck::MaybeDead = liveness { // Deallocated pointers are allowed, we should be able to find // them in the map. Ok(*self.dead_alloc_map.get(&id) .expect("deallocated pointers should all be recorded in  `dead_alloc_map`")) } else { err!(DanglingPointerDeref) }, } </ins> } <del> _ => {} } // The rest must be dead. if let AllocCheck::MaybeDead = liveness { // Deallocated pointers are allowed, we should be able to find // them in the map. Ok(*self.dead_alloc_map.get(&id) .expect("deallocated pointers should all be recorded in `dead_alloc_map`")) } else { err!(DanglingPointerDeref) </del> } }

Let's tying to compile this code.This code compiled ok on stable and on nightly-2019-06-17 (for example at rust play site) But in current rustc 1.37.0-nightly ( 2019-06-26) compilation fails with message:
Bisected to: Ok Fail ...
I bisected to , which is also part of the range identified. I get build failures when I try to bisect further into the commits of that PR. cc
Hmm curious, we do have tests for such situations. I'll investigate, but it'll drop into beta today. It's probably an easy fix
Today? Beta cutoff is on Tuesday.
Not this time I believe
Beta cutoff is 2019-06-29 https://rust-
triage: P-high, remove nomination, assign to
FYI, Oli is on vacation for 2 weeks.
Should this be marked regression-from-stable-to-beta now?


Question: <ins> // We used to not lower the extra `b @ ..` into `b @ _` which meant that no type // was registered for the binding `b` although it passed through resolve. // This resulted in an ICE (#69103). fn main() { let [a @ .., b @ ..] = &mut [1, 2]; //~^ ERROR `..` can only be used once per slice pattern b; let [.., c @ ..] = [1, 2]; //~^ ERROR `..` can only be used once per slice pattern c; // This never ICEd, but let's make sure it won't regress either. let (.., d @ ..) = (1, 2); //~^ ERROR `..` patterns are not allowed here d; } </ins>

The ICE only occurs when is used. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Nominating due to impending stabilization, even though stable doesn't ICE yet
Simplified:


Question: replace_late_bound_regions(tcx, value, |_, _| ty::ReStatic).0 } <ins> /// Rewrite any late-bound regions so that they are anonymous.  Region numbers are /// assigned starting at 1 and increasing monotonically in the order traversed /// by the fold operation. /// /// The chief purpose of this function is to canonicalize regions so that two /// `FnSig`s or `TraitRef`s which are equivalent up to region naming will become /// structurally identical.  For example, `for<'a, 'b> fn(&'a int, &'b int)` and /// `for<'a, 'b> fn(&'b int, &'a int)` will become identical after anonymization. pub fn anonymize_late_bound_regions<'tcx, HR>(tcx: &ctxt<'tcx>, sig: &HR) -> HR where HR: HigherRankedFoldable<'tcx> { let mut counter = 0; replace_late_bound_regions(tcx, sig, |_, db| { counter += 1; ReLateBound(db, BrAnon(counter)) }).0 } </ins> /// Replaces the late-bound-regions in `value` that are bound by `value`. pub fn replace_late_bound_regions<'tcx, HR, F>( tcx: &ty::ctxt<'tcx>,

Backtrace:
Well, this is interesting. It's broken all the way back to 0.10. I think it's been a bug in the type id implementation since it first landed. Here's a smaller test case:
is there a particular reason explicitly checks that all regions it encounters are ? Trans doesn't seem to go out of its way to erase late-bound regions in fn type signatures, which results in this ICE. I could add a call to in trans to fix this, but it would be cheaper to just ignore regions during hashing.
Ended up catching me
It seems we actually want to take late-bound regions into account when hashing. For example, the following should hold:


Question: set -ex source shared.sh <del> curl https://cmake.org/files/v3.6/cmake-3.6.3.tar.gz | tar xzf - </del> <ins> CMAKE=3.13.4 curl -L https://github.com/Kitware/CMake/releases/download/v$CMAKE/cmake-$CMAKE.tar.gz | tar xzf - </ins> mkdir cmake-build cd cmake-build <del> hide_output ../cmake-3.6.3/configure --prefix=/rustroot </del> <ins> hide_output ../cmake-$CMAKE/configure --prefix=/rustroot </ins> hide_output make -j10 hide_output make install cd .. rm -rf cmake-build <del> rm -rf cmake-3.6.3 </del> <ins> rm -rf cmake-$CMAKE </ins>

The docs currently claim that the minimum Linux kernel version for is 2.6.18 (released September 20th, 2006). This is because RHEL 5 used that kernel version. However, RHEL 5 entered ELS on March 31, 2017. Should we continue to support RHEL 5 for , or should we increase the minimum Linux Kernel version to 2.6.27 (2nd LTS) or 2.6.32 (RHEL 6, 3rd LTS)? . Even bumping the min-version to 2.6.27 would allow us to remove most of the Linux-specific hacks in . Example: .
Given that RHEL is the only reason we keep comically old kernel versions around, I would propose that Rust only support RHEL until Maintenance Support ends. This is (essentially) what we already did for RHEL 4. Rust never supported RHEL 4, and back when RHEL 5 still had maintenance support. It would be nice to get someone from Red Hat or a RHEL customer to comment. This policy would allow us to increment the minimum kernel from 2.6.18 to 2.6.32 (and remove a lot of Linux-specific hacks). Note that RHEL has a weird (and very long) support system for RHEL 4, 5, and 6 (sources: and ). It has 5 major steps: Full Support Normal support of the OS Maintenance Support 1 Bug/Security fixes Limited hardware refresh Maintenance Support 2 Bug/Security fixes The end of this phase is considered "Product retirement" Extended Life Cycle Support (ELS) Additional paid product from Red Hat Gives updates for a longer period of time No additional releases/images Extended Life Phase (ELP) No more updates Limited Technical Support End date not given by Red Hat Current status of RHEL versions: RHEL 4 Not supported by Rust Currently in ELP (no end date specified) ELS ended March 31, 2017 RHEL 5 Supported by Rust Currently in ELS Maintenance Support ended March 31, 2017 ELS ends November 30, 2020 RHEL 6 Supported by Rust Currently in Maintenance Support 2 Maintenance Support ends November 30, 2020
cc which I think they could be related.


Question: set -ex source shared.sh <del> curl https://cmake.org/files/v3.6/cmake-3.6.3.tar.gz | tar xzf - </del> <ins> CMAKE=3.13.4 curl -L https://github.com/Kitware/CMake/releases/download/v$CMAKE/cmake-$CMAKE.tar.gz | tar xzf - </ins> mkdir cmake-build cd cmake-build <del> hide_output ../cmake-3.6.3/configure --prefix=/rustroot </del> <ins> hide_output ../cmake-$CMAKE/configure --prefix=/rustroot </ins> hide_output make -j10 hide_output make install cd .. rm -rf cmake-build <del> rm -rf cmake-3.6.3 </del> <ins> rm -rf cmake-$CMAKE </ins>

It also may be worth to drop support of Windows XP and Vista (especially considering that panics are broken on XP since June 2016, see: ). Previously it was discussed . cc
Besides , which other things would we be able to clean up?
Good question! There are 6 workarounds in for older Linux versions (that I could find). Increasing the minimum version to 2.6.32 (aka 3rd Kernel LTS, aka RHEL 6) would fix 5 of them. Code links are inline: (mentioned above, in 2.6.23) ( in 2.6.24, there is also the mention of a bug occuring on "some linux kernel at some point") to atomically set the flag on the pipe fds ( in 2.6.27) ( in 2.6.27) to permit use of ( in 2.6.28) ( in 4.5, not fixed by this proposal) As you can see, the workarounds fixed by this proposal all have a similar flavor.
I am Red Hat's maintainer for Rust on RHEL -- thanks for the cc. I try to keep an eye on new issues, but this one slipped past me. Red Hat only ships the Rust toolchain to customers for RHEL 7 and RHEL 8. If our customers would like to use Rust on older RHEL, they can do so via , and we'll support them in the same way we would for any other third-party software. Internally we do also build and use on RHEL 6, mostly because it's needed to ship Firefox updates. This is where it gets a little hairy, because each RHEL N is bootstrapped on RHEL N-1 and often kept that way -- meaning a lot of our RHEL 6 builders are still running on a RHEL 5 kernel. I would have to apply local workarounds if upstream Rust loses the ability to run on 2.6.18 kernels. We prefer to keep fixes upstream as much as possible, both for open sharing and to avoid bitrot. Is there much of a benefit to removing the current workarounds? I agree all of that code is annoying and cumbersome, but it's already written, and as far as I know it hasn't been a maintenance burden. Do you see otherwise?


Question: set -ex source shared.sh <del> curl https://cmake.org/files/v3.6/cmake-3.6.3.tar.gz | tar xzf - </del> <ins> CMAKE=3.13.4 curl -L https://github.com/Kitware/CMake/releases/download/v$CMAKE/cmake-$CMAKE.tar.gz | tar xzf - </ins> mkdir cmake-build cd cmake-build <del> hide_output ../cmake-3.6.3/configure --prefix=/rustroot </del> <ins> hide_output ../cmake-$CMAKE/configure --prefix=/rustroot </ins> hide_output make -j10 hide_output make install cd .. rm -rf cmake-build <del> rm -rf cmake-3.6.3 </del> <ins> rm -rf cmake-$CMAKE </ins>

If there are any known issues with such Linux compatibility code, I am definitely willing to take assignment for fixing them.
(Not a Rust maintainer, but I'm a Rust user and maintain a lot of other OSS software so I have well-developed feelings around supporting Very Old Software :-)) Do you have any sense of on what timeline Rust would be able to drop support for 2.6.18 kernels without causing you pain? In general I don't think people mind supporting configurations that have users and are painful to work around, but needing to support them for forever is a bitter pill to swallow! Particularly as they get harder and harder to test over time (already I have no idea how to test on really old kernels besides building it myself). So if there was an estimate "we'd like to be able to support this until Q2 2020", even if it's not set in stone, I think that would be very helpful!
The other benefit would be that Rust wouldn't have to use CentOS 5 for CI, which means we don't have to patch LLVM (and Emscripten LLVM) to compile on those systems. Of course that's also fairly limited in scope.
As soon as we stop shipping Firefox and Thunderbird updates on RHEL 6, I won't need Rust there anymore. AFAIK this does correspond to the end of Maintenance Support, November 30, 2020. Then I'll be on to RHEL 7 builders as my minimum, probably still with some RHEL 6 2.6.32 kernels involved. It should be fine for me if we update CI to CentOS 6. This is mostly concerned with how the release binaries are linked to GLIBC symbol versions, which is all in userspace. It's a broader community question whether any other Rust users still care about running on RHEL or CentOS 5. (Small caveat - glibc support for a symbol can still return , .)
I noticed that Red Hat also has Extended Life Cycle Support (ELS) for RHEL 6 until June 30, 2024. Will you need RHEL 5 to work during this time? I don't know how ELS works with Firefox updates. Also, is there any reason RHEL 4 support wasn't an issue prior to March 31, 2017 (while RHEL 5 was still normally supported)?


Question: set -ex source shared.sh <del> curl https://cmake.org/files/v3.6/cmake-3.6.3.tar.gz | tar xzf - </del> <ins> CMAKE=3.13.4 curl -L https://github.com/Kitware/CMake/releases/download/v$CMAKE/cmake-$CMAKE.tar.gz | tar xzf - </ins> mkdir cmake-build cd cmake-build <del> hide_output ../cmake-3.6.3/configure --prefix=/rustroot </del> <ins> hide_output ../cmake-$CMAKE/configure --prefix=/rustroot </ins> hide_output make -j10 hide_output make install cd .. rm -rf cmake-build <del> rm -rf cmake-3.6.3 </del> <ins> rm -rf cmake-$CMAKE </ins>

This issue came up for me when dealing with opening files in , see for more info. No single RHEL 5 issue is that bad, it's mainly just the sum of a bunch of tiny issues.
I'm not on that team, but AFAIK we don't ship Firefox updates for ELS. The last build I see for RHEL 5 was . Maybe there could be an exception for a severe security issue, but I really doubt we'd rebase to newer Firefox for that, which means Rust requirements won't change. New Firefox ESR versions do require a newer Rust toolchain too, which is generally why we have to keep up. Otherwise we could just freeze some older compat rustc while upstream moves on. Rust wasn't required until Firefox 52.
that makes perfect sense to me, thanks for clarifying. So the proposed policy would be: Support RHEL until RHEL is retired (i.e. ends normal support). This would mean: Supporting RHEL 5 (v2.6.18) until November 30, 2020 Supporting RHEL 6 (v2.6.32) until June 30, 2024 Supporting RHEL 7 (v3.10) until May, 2029 This is a much longer support tail than any other Linux distros (that I know of), so it would also be the effective minimum kernel version of , , and their dependencies. How does that sound to people? EDIT: The alternative to this would be Support RHEL until it is retired, taking the table above and incrementing the RHEL versions by 1. It would also mean being able to drop RHEL 5 support now.
Sure, that's ideal for me. :smile: As mentioned, is just needed for kernel support, as far as I'm concerned. Userspace concerns like GLIBC symbol versions can stick to currently supported for my needs.
Red Hat should backport the features we need (CLOEXEC and getrandom, in particular) to whatever kernels that it wants Rust to support. I don't know any good reason why they don't do so, other than it's cheaper to convince the whole world to keep supporting older kernel versions than it is to do the backports. We should change that dynamic.


Question: set -ex source shared.sh <del> curl https://cmake.org/files/v3.6/cmake-3.6.3.tar.gz | tar xzf - </del> <ins> CMAKE=3.13.4 curl -L https://github.com/Kitware/CMake/releases/download/v$CMAKE/cmake-$CMAKE.tar.gz | tar xzf - </ins> mkdir cmake-build cd cmake-build <del> hide_output ../cmake-3.6.3/configure --prefix=/rustroot </del> <ins> hide_output ../cmake-$CMAKE/configure --prefix=/rustroot </ins> hide_output make -j10 hide_output make install cd .. rm -rf cmake-build <del> rm -rf cmake-3.6.3 </del> <ins> rm -rf cmake-$CMAKE </ins>

The alternative to this would be Support RHEL N until it is retired I think we should not officially support retired OS versions (well, maybe with some grace period), so I prefer this option. Supporting 14 year old kernels seems a bit too much to me. each RHEL N is bootstrapped on RHEL N-1 and often kept that way -- meaning a lot of our RHEL 6 builders are still running on a RHEL 5 kernel Is it possible to apply kernel patches to those builders to add support for functionality like CLOEXEC? Or build Firefox separately on RHEL 6?
I think it won't be fruitful for us to debate the merits of stable enterprise kernels, but no, this is not a possibility. An alternative take is "Red Hat should be responsible for the work in Rust to maintain the support they want" -- here I am, ready and willing. I definitely can't change those kernels. The ones that are stuck on N-1 are precisely to avoid rocking the boat, and backporting features is a big change. Some of our arches do eventually update the builders to their matching N kernel, but some don't, and I don't know all the reasons. If the workarounds are removed, then I will have to reapply them in our own builds. This assumes I keep using only our own binaries -- if I ever have to re-bootstrap from upstream binaries for stage0, I would also have to use some interception (like ) to hack in the workarounds. This is all possible, but much worse than the status quo of maintaining support here.
I think this sounds reasonable. We aren't going to be able to update these kernels, it's just a question of when we would drop support for these OSes. Especially given that we wont need RHEL 5 CI support, I think that leaving things as they are is fine. I opened this issue to verify two things: 1) That we weren't intending on supporting RHEL 5 "forever", and had a clear date when to drop support. 2) That someone from Red Hat actively cared about supporting these older kernels. It looks like both these things are true. We should remove RHEL 5 workarounds after November 30, 2020. This issue can be postponed until then.


Question: set -ex source shared.sh <del> curl https://cmake.org/files/v3.6/cmake-3.6.3.tar.gz | tar xzf - </del> <ins> CMAKE=3.13.4 curl -L https://github.com/Kitware/CMake/releases/download/v$CMAKE/cmake-$CMAKE.tar.gz | tar xzf - </ins> mkdir cmake-build cd cmake-build <del> hide_output ../cmake-3.6.3/configure --prefix=/rustroot </del> <ins> hide_output ../cmake-$CMAKE/configure --prefix=/rustroot </ins> hide_output make -j10 hide_output make install cd .. rm -rf cmake-build <del> rm -rf cmake-3.6.3 </del> <ins> rm -rf cmake-$CMAKE </ins>

EDIT: For our use case in , we were able to add compatibility for RHEL 5 .
See for a recent case where supporting such ancient kernels required extra manual work ( to the 2 lines mentioned by above). I am not sure how often that comes up, but probably the hardest part is to even notice that it happens -- and even then those codepaths will likely linger untested.
Yes, but this will still be true in general. If the CI kernel is newer than whatever kernel baseline we choose, it will be possible for newer syscalls to pass undetected. I don't know if we have any control over that -- can we choose a particular VM image? So that leaves us with a stated policy of support. The more that developers are aware of such issues, the better, but I'm the one most likely to notice when my build actually fails. If I come back with a fix, I at least need the project to be receptive. I haven't been in the habit of building nightly on our RHEL6 builders, but maybe I should! Catching this early is better for everyone involved...
That seems reasonable. How quick is the Rust related bootstrapping? Could it be run automatically (or more frequently)? This is an interesting point. If I hadn't made that change, would have kept working on RHEL 5, it just would have leaked an FD. I'm not sure how we would even test for this sort of thing. This isn't a RHEL 5 specific concern, I just don't know how Rust tests these types of resource leak issues in general.
About 2 hours. Automation is harder, since I believe our build system needs my credentials, but I'll look into what is possible here. Yeah, that's a lot more subtle than an !


Question: // preventing the latter from being formatted. ignore_fmt.add(&format!("!/{}", untracked_path)).expect(&untracked_path); } <ins> if !check && paths.is_empty() { if let Some(files) = get_modified_files(build) { for file in files { println!("formatting modified file {file}"); ignore_fmt.add(&format!("/{file}")).expect(&file); } } } </ins> } else { println!("Not in git tree. Skipping git-aware format checks"); }

Since rustfmt is deterministic and idempotent, running it twice on the same file should always have the same output (if it's not both of those things, it's a bug). So we can avoid running it unless the file has changed, which should make without arguments much faster. Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This will need to be careful to still rerun rustfmt when we bump its version (which happens about every 6 weeks). Maybe we can generate a file and format everything if it doesn't yet exist or has the wrong version.
Hello, I want to work on that. How would the detection of modified files work ?
you can use to see modified files. Make sure to fall back to formatting all files if that command fails for some reason, we support building from source tarballs without git installed.
This means that already-commited files that were not formatted when committed would not be formatted, right ?
Ah, good point. You can use to find where the two diverged and compare all files since then. And should still look at all files unconditionally.
Thanks, I will start working on this ! claim
That assumes that the rust-lang remote is labeled as origin. I call that upstream and my fork origin. Using the local master may also not work if one does on branch.
Yes, has a more general solution.
PR is up at


Question: LL |     #[deprecated(since(b), note = "a")] //~ ERROR incorrect meta item |                  ^^^^^^^^ <ins> error[E0565]: literal in `deprecated` value must be a string --> $DIR/deprecation-sanity.rs:19:25 | LL |     #[deprecated(note = b"test")] //~ ERROR literal in `deprecated` value must be a string |                         ^^^^^^^ help: consider removing the prefix: `"test"` error[E0565]: item in `deprecated` must be a key/value pair --> $DIR/deprecation-sanity.rs:22:18 | LL |     #[deprecated("test")] //~ ERROR item in `deprecated` must be a key/value pair |                  ^^^^^^ </ins> error[E0550]: multiple deprecated attributes <del> --> $DIR/deprecation-sanity.rs:22:1 </del> <ins> --> $DIR/deprecation-sanity.rs:28:1 </ins> | LL | fn multiple1() { } //~ ERROR multiple deprecated attributes | ^^^^^^^^^^^^^^^^^^ error[E0538]: multiple 'since' items <del> --> $DIR/deprecation-sanity.rs:24:27 </del> <ins> --> $DIR/deprecation-sanity.rs:30:27 </ins> | LL | #[deprecated(since = "a", since = "b", note = "c")] //~ ERROR multiple 'since' items |                           ^^^^^^^^^^^ <del> error: aborting due to 7 previous errors </del> <ins> error: aborting due to 9 previous errors </ins> <del> Some errors occurred: E0538, E0541, E0550, E0551. </del> <ins> Some errors occurred: E0538, E0541, E0550, E0551, E0565. </ins> For more information about an error, try `rustc --explain E0538`.

Look for example to It is deprecated, and in source code there is hint what should be used instead: but in generated html documentation there is no hint about
isn't the correct syntax for the attribute. It should be . You can see it work: . This isn't a rustdoc issue. It's an issue with rustc that it doesn't reject .


Question: // ensure that we issue lints in a repeatable order def_ids.sort_by_cached_key(|&def_id| self.tcx.def_path_hash(def_id)); <del> for def_id in def_ids { </del> <ins> 'lifetimes: for def_id in def_ids { </ins> debug!("check_uses_for_lifetimes_defined_by_scope: def_id = {:?}", def_id); let lifetimeuseset = self.lifetime_uses.remove(&def_id);

I tried this code: I expected to see this happen: the code is correct. Instead, this happened: Just swap the functions, then the code compiles: Update : The examples may be misleading. I forgot that takes effect on a single item. It was a typo. Here is a new example. It should be correct. But the compiler does not accept it. <!-- 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. --: :
Very strange. I'm thinking we have some stateful HIR lowering code that is hanging onto state it shouldn't.
This bug existed as far back as November 2019 (when was stabilized), so it's not a recent regression.
Marking this as P-medium based on the
I did some digging into this. I'm brand new to the compiler so slowly learning the architecture along the way. Below are some thoughts on what I've seen so far. The desugared HIR for both samples is the same: async first async last As expected both resolves the same set of lifetimes (from ) and process them in the same order (since ). Dump from the property at the first iteration: async first async last Interestingly both included the lifetime as used only once in the opaque/desugared async function and both . However, for the second case (async last) the compilation still succeeds - this is really confusing and I'm probably missing something big about the compiler architecture. Need to dig deeper.
The examples may be misleading. I forgot that takes effect on a single item. It was a typo. Here is a new example.
Makes sense. Then the behavior is no longer magical and makes a lot of sense.
Based on what I've seen the desugaring process is working correctly and the object is keeping the correct state. The lifetime linting identifies the lifetime as only used once within the return opaque type generated by the desugaring process. This behavior seems correct since we'd still want to catch this for an opaque type implementation from the user. My suggestion would be to include an exception in the linting specifically for opaque types of async functions that use a lifetime name already declared in the generic params of the parent function. I have validated this simple change (I named the loop ) and propose to include it alongside .


Question: // ensure that we issue lints in a repeatable order def_ids.sort_by_cached_key(|&def_id| self.tcx.def_path_hash(def_id)); <del> for def_id in def_ids { </del> <ins> 'lifetimes: for def_id in def_ids { </ins> debug!("check_uses_for_lifetimes_defined_by_scope: def_id = {:?}", def_id); let lifetimeuseset = self.lifetime_uses.remove(&def_id);

One more question for the team ( what would we expect in this case? This compiles successfully, which is counter intuitive by looking at the function signature. It compiles because the desugared generator uses the same lifetime as the async function.


Question: _ => self.get(item.def_id), }; <ins> // Update levels of nested things. match item.kind { hir::ItemKind::Enum(ref def, _) => { for variant in def.variants { let variant_level = self.update_with_hir_id(variant.id, item_level); if let Some(ctor_hir_id) = variant.data.ctor_hir_id() { self.update_with_hir_id(ctor_hir_id, item_level); } for field in variant.data.fields() { self.update_with_hir_id(field.hir_id, variant_level); } } } hir::ItemKind::Impl(ref impl_) => { for impl_item_ref in impl_.items { if impl_.of_trait.is_some() || self.tcx.visibility(impl_item_ref.id.def_id) == ty::Visibility::Public { self.update(impl_item_ref.id.def_id, item_level); } } } hir::ItemKind::Trait(.., trait_item_refs) => { for trait_item_ref in trait_item_refs { self.update(trait_item_ref.id.def_id, item_level); } } hir::ItemKind::Struct(ref def, _) | hir::ItemKind::Union(ref def, _) => { if let Some(ctor_hir_id) = def.ctor_hir_id() { self.update_with_hir_id(ctor_hir_id, item_level); } for field in def.fields() { if field.vis.node.is_pub() { self.update_with_hir_id(field.hir_id, item_level); } } } hir::ItemKind::Macro(ref macro_def) => { self.update_reachability_from_macro(item.def_id, macro_def); } hir::ItemKind::ForeignMod { items, .. } => { for foreign_item in items { if self.tcx.visibility(foreign_item.id.def_id) == ty::Visibility::Public { self.update(foreign_item.id.def_id, item_level); } } } hir::ItemKind::OpaqueTy(..) | hir::ItemKind::Use(..) | hir::ItemKind::Static(..) | hir::ItemKind::Const(..) | hir::ItemKind::GlobalAsm(..) | hir::ItemKind::TyAlias(..) | hir::ItemKind::Mod(..) | hir::ItemKind::TraitAlias(..) | hir::ItemKind::Fn(..) | hir::ItemKind::ExternCrate(..) => {} } </ins> // Mark all items in interfaces of reachable items as reachable. match item.kind { // The interface is empty. <del> hir::ItemKind::ExternCrate(..) => {} </del> <ins> hir::ItemKind::Macro(..) | hir::ItemKind::ExternCrate(..) => {} </ins> // All nested items are checked by `visit_item`. hir::ItemKind::Mod(..) => {} <ins> // Handled in the access level of in rustc_resolve </ins> hir::ItemKind::Use(..) => {} // The interface is empty. hir::ItemKind::GlobalAsm(..) => {}

EDIT (ehuss) Reproduction: Clone <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
We are seeing this too on rustc 1.60.0-nightly ( 2022-01-10) running on aarch64-apple-darwin
label +I-prioritize
cc This seems to have regressed starting with .
I'm taking a look
I can reproduce and I did find some differences in the access level table. seems to be missing when it's supposed to be Reachable in the good version. I'll investigate further Updates: Actually, the whole Impl seems to be missing. It should be marked as Reachable but is not even there. claim
Marking as , as .
Same on Mac, on x86_64-apple-darwin as well, same toolchain version (rustc 1.60.0-nightly ( 2022-01-10))
As an update for those watching: currently, the best workaround is to use an older nightly. The good news is that a fix PR is open (), with people working on getting it in shape to be merged.


Question: "rls-rustc", "rls-span", "rls-vfs", <del> "rustc-serialize", </del> "rustc-workspace-hack", "rustc_tools_util 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)", "rustfmt-nightly",

Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.


Question: ByteStr(_) | ByteStrRaw(..) => "byte string" } } <ins> // See comments in `interpolated_to_tokenstream` for why we care about // *probably* equal here rather than actual equality fn probably_equal_for_proc_macro(&self, other: &Lit) -> bool { mem::discriminant(self) == mem::discriminant(other) } </ins> } pub(crate) fn ident_can_begin_expr(ident: ast::Ident, is_raw: bool) -> bool {

This is minimized from the dramatic forum thread . The following code is fine in nightly-2018-04-12 but breaks with nightly-2018-04-15. Oddly, lots of minor perturbations make it succeed. For example remove the two characters and it works. Or remove the single quote in the string and it works.
Alrighty-roo. As everything these days with hygiene, there's a couple of bugs here. With this one though I think only two! Everything has to do here with basically. AKA anything that runs through that falls off The usual reasons we think you fall off the "happy path" are due to things like inner attributes, , macro expansion, etc. None of that's present here! It should be the case that above can be losslessly converted to a based on what we've cached. Turns out though had a bug in it (surprise surprise!). There we're using to compare the resulting two token streams which eventually bottoms out in . As it turns out this isn't quite what we want! The implementation is structural, but the token stream we get when stringifying is slightly different than what we parsed. Here in the example you're using the literal string , but rustc stringifies this token as . Similarly if you replaced the string with something like it'll be stringified as . This means that the tokens are not literally byte-for-byte equal, which means we fall off the happy path! tl;dr the token stream of is not equivalent to the token stream . This causes us to fall off the happy path and used a stringified token stream. OK so in the case above we're falling off the happy path when we didn't expect to, but even still there's some weird bad hygiene behavior when we're not on the happy path. There's still something to fix! It turns out that there's also a regression due to (found via bisection). Before that PR this example would compile just fine, afterwards though it's hitting this error. can you help diagnose this and see what's going on? The reduced test case I have right now is: (note the inner attribute on to force using a non-cached token stream)
I've posted a fix for the "happy path" at will actually fix example above.


Question: ByteStr(_) | ByteStrRaw(..) => "byte string" } } <ins> // See comments in `interpolated_to_tokenstream` for why we care about // *probably* equal here rather than actual equality fn probably_equal_for_proc_macro(&self, other: &Lit) -> bool { mem::discriminant(self) == mem::discriminant(other) } </ins> } pub(crate) fn ident_can_begin_expr(ident: ast::Ident, is_raw: bool) -> bool {

That PR does not, however, fix the regression from which is still reproducible with the example I gisted.
Any idea why my repro case above is fixed if you remove the tokens? It seems like should fall off the happy path just as much.
If you remove the tokens we're still on the stringification path (aka not the happy path). For whatever reason though the hygiene bug goes away. That's likely caused from a subtelty introduced in (or at least so I'm hoping). I don't know much about , so I'm hoping will be able to look at this and know what's going on!
I don't know much about , so I'm hoping will be able to look at this and know what's going on! I'll investigate.
is the commit causing the regression. Further investigation is in progress.
An issue recently popped up on Rocket () that appears to be identical to this one and is not resolved in any recent nightly. It's possible that the root cause is , however.


Question: impl Scalar { pub fn is_bool(&self) -> bool { <del> if let Int(I8, _) = self.value { self.valid_range == (0..=1) } else { false } </del> <ins> matches!(self.value, Int(I8, false)) && self.valid_range == (0..=1) </ins> } /// Returns the valid range as a `x..y` range.

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
modify labels: +regression-from-stable-to-stable This happens since rust
More minimal reproducer. Does not occur with just 1 variant. Or if one of the variants has a negative discriminant. Affects most targets if not all of them, despite the failure seemingly occurring inside the target-specific code.
Assigning P-medium as .20enum.20from.20an.20extern.20c.E2.80.A6) and removing I-prioritize.


Question: <ins> // check-pass struct Sqlite {} trait HasArguments<'q> { type Arguments; } impl<'q> HasArguments<'q> for Sqlite { type Arguments = std::marker::PhantomData<&'q ()>; } fn foo() { let _ = <Sqlite as HasArguments>::Arguments::default(); } fn main() {} </ins>

This code: compiles on stable but not on nightly. Error: I bisected it to and then refined it; reverting fixes the issue. This is the cause for
ping since you're the author of the commit
WG-prioritization assigning priority (). label -I-prioritize +P-critical
note: there's a fix in ready for review


Question: // Get the `hir::Param` to verify whether it already has any bounds. // We do this to avoid suggesting code that ends up as `T: FooBar`, // instead we suggest `T: Foo + Bar` in that case. <del> let mut has_bounds = None; let mut impl_trait = false; if let Node::GenericParam(ref param) = hir.get(id) { let kind = &param.kind; if let hir::GenericParamKind::Type { synthetic: Some(_), .. } = kind { // We've found `fn foo(x: impl Trait)` instead of // `fn foo<T>(x: T)`. We want to suggest the correct // `fn foo(x: impl Trait + TraitBound)` instead of // `fn foo<T: TraitBound>(x: T)`. (See #63706.) impl_trait = true; has_bounds = param.bounds.get(1); } else { has_bounds = param.bounds.get(0); </del> <ins> match hir.get(id) { Node::GenericParam(ref param) => { let mut impl_trait = false; let has_bounds = if let hir::GenericParamKind::Type { synthetic: Some(_), .. } = &param.kind { // We've found `fn foo(x: impl Trait)` instead of // `fn foo<T>(x: T)`. We want to suggest the correct // `fn foo(x: impl Trait + TraitBound)` instead of // `fn foo<T: TraitBound>(x: T)`. (#63706) impl_trait = true; param.bounds.get(1) } else { param.bounds.get(0) }; let sp = hir.span(id); let sp = if let Some(first_bound) = has_bounds { // `sp` only covers `T`, change it so that it covers // `T:` when appropriate sp.until(first_bound.span()) } else { sp }; // FIXME: contrast `t.def_id` against `param.bounds` to not suggest // traits already there. That can happen when the cause is that // we're in a const scope or associated function used as a method. err.span_suggestions( sp, &message(format!( "restrict type parameter `{}` with", param.name.ident().as_str(), )), candidates.iter().map(|t| format!( "{}{} {}{}", param.name.ident().as_str(), if impl_trait { " +" } else { ":" }, self.tcx.def_path_str(t.def_id), if has_bounds.is_some() { " + "} else { "" }, )), Applicability::MaybeIncorrect, ); suggested = true; } Node::Item(hir::Item { kind: hir::ItemKind::Trait(.., bounds, _), ident, .. }) => { let (sp, sep, article) = if bounds.is_empty() { (ident.span.shrink_to_hi(), ":", "a") } else { (bounds.last().unwrap().span().shrink_to_hi(), " +", "another") }; err.span_suggestions( sp, &message(format!("add {} supertrait for", article)), candidates.iter().map(|t| format!( "{} {}", sep, self.tcx.def_path_str(t.def_id), )), Applicability::MaybeIncorrect, ); suggested = true; </ins> } <ins> _ => {} </ins> } <del> let sp = hir.span(id); // `sp` only covers `T`, change it so that it covers `T:` when appropriate. let sp = if let Some(first_bound) = has_bounds { sp.until(first_bound.span()) } else { sp }; // FIXME: contrast `t.def_id` against `param.bounds` to not suggest traits // already there. That can happen when the cause is that we're in a const // scope or associated function used as a method. err.span_suggestions( sp, &msg[..], candidates.iter().map(|t| format!( "{}{} {}{}", param, if impl_trait { " +" } else { ":" }, self.tcx.def_path_str(t.def_id), if has_bounds.is_some() { " + " } else { "" }, )), Applicability::MaybeIncorrect, ); suggested = true; </del> } }; } if !suggested { <ins> let mut msg = message(if let Some(param) = param_type { format!("restrict type parameter `{}` with", param) } else { "implement".to_string() }); </ins> for (i, trait_info) in candidates.iter().enumerate() { msg.push_str(&format!( "ncandidate #{}: `{}`",

The following example code yields an error: It's unclear from this error message how to proceed - I'm not sure of the syntax, location, or where I should be putting the "GetString" trait bound. It should be shown with a better example or link when this error is presented, as the current message is not sufficient for a resolution to be arrived at.
cc
Fixing in . To fix your code write:
Thanks!


Question: fn get_or_create_type_parameter_def<'a,'tcx>(ccx: &CrateCtxt<'a,'tcx>, ast_generics: &hir::Generics, space: ParamSpace, <del> index: u32) </del> <ins> index: u32, allow_defaults: bool) </ins> -> ty::TypeParameterDef<'tcx> { let param = &ast_generics.ty_params[index as usize];

If I understand correctly, type parameter defaults have no effect in the block . Just like in PR , this should have a warning and then an error. Example cc
Argh, I guess I failed to cover those?
Nominating for triage.
triage: P-high


Question: <del> Subproject commit f5532b22b5d741f3ea207b5b07e3e1ca63476f9b </del> <ins> Subproject commit 02b3734a5ba6de984eb5a02c50860cc014e58d56 </ins>

nightly-2017-10-24 contains a libtest with bad DWARF: I can reproduce this if I recompile libtest locally: The problem can be fixed by disabling thinlto (and keeping the codegen units is ok). I noticed this with nightly-2017-10-24 because it is the first nightly compiled with thinlto, but the problem also occurs if I compile libtest with thinlto enabled using earlier compilers (eg nightly-2017-10-17). Inspecting the DWARF, a DIE at that local ref offset does exist in another codegen unit, so the problem seems to be that we should be using a global ref instead.
cc'ing since he's been poking around in LLVM's DWARF generation code recently.
Sorta smells like an LLVM bug -- but hard to say. Who should investigate?
triage: P-medium if you are able to investigate as part of ThinLTO work would be great.
It's likely that this is the cause of , which even if the underlying segfault were fixed would likely prevent backtraces from happening on OSX.
This is unfortunately not "automagically fixed" if we upgrade to LLVM 5
Making progress. First up, minimized Rust source code via creduce to get: Next up let's see if we can reduce it to one object file: Ok looks like only one object file is invalid! Let's take a look the LLVM IR: Ok let's see what's happening by minimizing the LLVM IR: yielding which I . I checked out LLVM trunk, , and looks like the error is still on LLVM trunk.
I'm not sure at this point if this is an LLVM bug, a rustc bug, or a ThinLTO bug. I've managed to extract what I believe is a for this which reproduces the error. I'm hoping fixing that IR will fix all other related issues to this at this point in time. For those of you more familiar with debug information (probably everyone other than me!) mind taking a look at that IR? Does it look "obviously wrong"? If it's "obviously wrong" I can try to work backwards to figure out what piece of the pipeline introduced such a wrong piece, but if it looks correct I can open an LLVM bug saying that we think it may be broken (and maybe they'll say it's "obviously wrong"!)


Question: <del> Subproject commit f5532b22b5d741f3ea207b5b07e3e1ca63476f9b </del> <ins> Subproject commit 02b3734a5ba6de984eb5a02c50860cc014e58d56 </ins>

cc
Er, I went ahead and to go ahead and broaden the search.
The DWARF is definitely badly formed: it's using a unit-relative offset to reference the parameter type, when it should be using a section-relative offset because the type is in a different unit. The bad offset is occurring for a parameter to subprogram in . The problem is that subprograms and share the same , but have different units ( and ). Based on some print debugging, it appears that LLVM doesn't handle this case. So and are constructed in unit , but when is constructed, it reuses the existing DIE as its parent, and so it also ends up in unit . So my guess is that when the parameter is constructed, it uses the unit that was specified to determine if the parameter and type are in the same unit, and thus gets it wrong.
thanks for the info! I know basically nothing about DWARF though and malformed whatnots, so the IR here is heavily edited by both machines (creduce/bugpoint) and me (to make it more readable). My assumption is that if LLVM accepts IR and generates an object file it shouldn't yield such a dwarfdump error, but are you thinking that given possibly valid LLVM IR the dwarfdump error is possible? If so that may make reduction far more difficult... Or do you think that this looks like upstream LLVM needs to get updated?
I don't think the editing of the IR caused the problem. I'll check later, but I think it's quite likely that the same problem occurs for the unedited IR. I don't know if the LLVM developers intend for this to be valid IR, or if they are missing a validation check somewhere. I think they may have never encountered this possibility. clang divides code into units based on files, so I don't think it ever splits code in the same scope across multiple units, whereas I think rust splits code into units quite differently. That's a bit of conjecture on my part though, it might be better to ask someone who knows more (I only know about DWARF, not LLVM or rustc). Reading the LLVM code a bit more, I think it will be possible to fix there by stopping it from sharing the scope (the scope creation is initiated and the sharing check is ). It's also worth reconsidering how rust splits code into units though.


Question: <del> Subproject commit f5532b22b5d741f3ea207b5b07e3e1ca63476f9b </del> <ins> Subproject commit 02b3734a5ba6de984eb5a02c50860cc014e58d56 </ins>

It might make sense to ensure all code for a given type is kept in the same unit.
Ah ok that all makes sense. Note though that rustc is very much like clang when it comes to debuginfo/codegen units. The major difference here is that LLVM is doing inlining across codegen units via ThinLTO, and that's likely where these new situations are arising from.
I see, yep my understanding of how rust partitions units was wrong. So when using ThinLTO, the additional units by ThinLTO only contain information needed for the additional inlined functions? Do these inlined functions always share scopes/types with unit , or can we determine when they do? If so, it'd be nice to add them to unit instead of creating additonal units. I think this would get us DWARF that looks the same as that generated for . eg dwarfdump is happy if I run:
interesting! I'd have to look into the internals of ThinLTO to know for sure though. It seems like LLVM isn't ready (maybe?) for multiple codegen units in debug info in one LLVM module (a codegen unit), but it makes sense to me what you're thinking about having all inlined debug info share the same codegen unit information. Now where that change would go in LLVM I'm not entirely sure...
Does firefox use fat LTO? There's been a couple of bugs that have some similarities to this ( and maybe ). Also note that absence of dwarfdump errors doesn't mean the offsets are all okay. dwarfdump is only complaining if the offset is larger than the unit length, but even if it's less it may still incorrectly be a local ref. So there may be more instances that are unnoticed.
cc ^
I can reproduce using normal LTO. Library crate is: Binary crate is: Also here's a thin LTO version that gives smaller IR than the previous Vec test case:
Thanks It definitely sounds like at this point this is an existing bug we've just never hit before. My inclination would be to paper over this if we can. Unfortunately though I don't know how to fix this at the LLVM IR layer. My naive idea would be to just point everything at one codegen unit for each LLVM module (debug-info-wise) but I don't know how to change existing debuginfo of a module.


Question: <del> Subproject commit f5532b22b5d741f3ea207b5b07e3e1ca63476f9b </del> <ins> Subproject commit 02b3734a5ba6de984eb5a02c50860cc014e58d56 </ins>

I'm not able to access currently, so not sure exactly what Adrian's suggestions were, but here's a that fixes LLVM to use a global ref when needed. It's not as simple as comparing parent DIEs, because the variable is initially , so the check . I don't have a lot of confidence in the patch, but maybe it's a useful starting point for someone who knows more about LLVM.
awesome thanks! I think LLVM's bugzilla is back now so indicating such.
I've confirmed that applying your patch to LLVM fixes having malformed debug information. Next up I'm confirming that it
Sure enough it fixes the issue! would you be interested in sending the patch upstream?
I prefer if someone who knows more about LLVM could upstream the patch.
Would this be something you could do, You can evaluate the changes to the generated DWARF best, I think.
We do use for Firefox builds, yes.
Sure, I will do this. I think the issue is more an LLVM thing than a DWARF thing, though; not certain I know enough there to say whether the patch is good, but I will at least do the shepherding. Also I wanted to point out that knows quite a bit about DWARF; he's one of the principals on
Actually maybe there's nothing to do here except merge this into rust-llvm?
Yes, I think so. I'll do that.
Cool, thanks!
oh no worries! I've tested it locally now and will submit a PR soon (with another change or two)
Ok, thanks
I've opened up which I think should close this out (and also re-enables ThinLTO in a few locations)
Hi, I get a Dwarf Error with GDB 8.0.1 on one of the files of Rust 1.23.0 that was built was Rust 1.23.0 on Fedora 27, in a build enabled with debuginfo. Is it related to this issue or should I open a new one? Relevant build flags:
yeah I believe that's this issue, it should be fixed in 1.24 though!


Question: /// # Examples /// /// ``` <del> /// # #![feature(duration_as_u128)] </del> /// use std::time::Duration; /// /// let duration = Duration::new(5, 730023852); /// assert_eq!(duration.as_nanos(), 5730023852); /// ``` <del> #[unstable(feature = "duration_as_u128", issue = "50202")] </del> <ins> #[stable(feature = "duration_as_u128", since = "1.33.0")] </ins> #[inline] pub const fn as_nanos(&self) -> u128 { self.secs as u128 * NANOS_PER_SEC as u128 + self.nanos as u128

Duration has historically lacked a way to get the actual number of nanoseconds it contained as a normal Rust type because u64 was of insufficient range, and f64 of insufficient precision. The u128 type solves both issues, so I propose adding an as_nanos function to expose the capability. CC:
I still don't understand why Duration is not allowed to be negative. It bugs me that the SystemTime difference returns a Result<Duration,Errorand returns and error if the time from is after the time to. To me, it should just return a negative Duration (Yes, the System Clock can go backwards). I find it odd that Duration does not support a negative amount.
I think it's about the way you think of . If it's a span of time (like described in the documentation) or an interval, then it must be positive. If it's the distance between two time points, it's negative. You're probably thinking of a distance instead of an interval. That's not necessarily a bad thing, but it's different from what the type is today, and it will never change due to compatibility concerns.
Here is what I take issue with: And....DING! DING! DING! know what, now that I've typed out that code, I can't think of any justifiable reason I would actually want that, so, once again, the thoughtfulness of Rust shows itself. You and the designers of Duration were correct. Negative Duration doesn't make sense (even though it feels like it should).
You can use if you want to measure a duration.
Yes, I'm aware. I guess I think there should be another thing called ClockTimeDifference (that can be neg/pos) and there should be methods on SystemTime that don't return Result<Duration,Error, but, instead return ClockTimeDifference. It could be as simple as:
It can, but the return type of will never change, so it's up to you (or a crate) to implement that.
This is the tracking issue for a feature that adds several specific methods to Duration, not a place to debate general concerns about the Duration type. Your discussion is probably better suited for the site.
Why can't as_millis return an i64?
large durations won't fit into that type.
Pardon my ignorance, but why is this unstable?


Question: /// # Examples /// /// ``` <del> /// # #![feature(duration_as_u128)] </del> /// use std::time::Duration; /// /// let duration = Duration::new(5, 730023852); /// assert_eq!(duration.as_nanos(), 5730023852); /// ``` <del> #[unstable(feature = "duration_as_u128", issue = "50202")] </del> <ins> #[stable(feature = "duration_as_u128", since = "1.33.0")] </ins> #[inline] pub const fn as_nanos(&self) -> u128 { self.secs as u128 * NANOS_PER_SEC as u128 + self.nanos as u128

For my usecase, I probably don't need more than a , and I really only need millis (though the code I'm porting happens to use microseconds). I'd rather have a , but I'm just not sure what to do here for my code which I'm trying to keep as close to fully stable as possible (I want it to be as portable and safe as I can make it). I know (I think?) I can use , but I'd rather not lose the precision and I think I can always use for all my platforms.
is there any reason not to move forward with stabilization on this? correctly observes that it has been unstable for quite a while
The stability of u128 was the blocker previously, but that's now no longer a problem. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [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.
I couldn’t find all the details in this issue, grepping through the code shows that this tracking issue is for:
This may be a stupid question, but is available on all platforms that Rust supports?
:bell: This is now entering its final comment period, as per the . :bell:
Yep, it should be available on all platforms.
The final comment period, with a disposition to merge, as per the , is now complete.
Now that final comment period has ended, can these methods be stabilized?
Yes, the next step is a stabilization PR.
Awesome! I've made a PR for stabilization here: Please let me know if it needs any adjustments. I can't wait for this to land! :tada: