jiebi/CodeConvo huggingface dataset:
Code change:
ns: Namespace, binding: &'a NameBinding<'a>) -> Result<(), &'a NameBinding<'a>> { <del> let ident = ident.unhygienize(); </del> self.update_resolution(module, ident, ns, |this, resolution| { if let Some(old_binding) = resolution.binding { if binding.is_glob_import() {

Related discussion:
text: stack backtrace: 1: 0x7fc35e73fdf3 - std::sys::imp::backtrace::tracing::imp::write::hdfa3e34b856f69a3 2: 0x7fc35e74e5dd - std::panicking::defaulthook::{{closure}}::h20f8c1082e0ce86e 3: 0x7fc35e74e17b - std::panicking::defaulthook::hd31552ac08c2a241 4: 0x7fc35e74ea68 - std::panicking::rustpanicwithhook::h73969d230a072c1a 5: 0x7fc357eda667 - std::panicking::beginpanic::hb89a2261f4776ce3 6: 0x7fc357eef99f - rustcerrors::Handler::bug::h13b3b29154320abd 7: 0x7fc35bab053a - rustc::session::optspanbugfmt::{{closure}}::hfea18dd68f59976d 8: 0x7fc35baafff7 - rustc::session::optspanbugfmt::h7d370a0810dbdbbd 9: 0x7fc35baafce2 - rustc::session::bugfmt::hcde5f50c54004a4f 10: 0x7fc35b984552 - rustc::hir::def::Def::defid::h728c22aafbe84efc 11: 0x7fc35c6ddb3a - rustcprivacy::ObsoleteVisiblePrivateTypesVisitor::pathisprivatetype::h24756a49a68d1da9 12: 0x7fc35c6d53db - rustc::hir::intravisit::walkty::h64b13c0c45b7a09a 13: 0x7fc35c6d49ba - rustc::hir::intravisit::Visitor::visitfn::ha8ad665c42b1d643 14: 0x7fc35c6de7cf - <rustcprivacy::ObsoleteVisiblePrivateTypesVisitor<'a,
Code change:
ns: Namespace, binding: &'a NameBinding<'a>) -> Result<(), &'a NameBinding<'a>> { <del> let ident = ident.unhygienize(); </del> self.update_resolution(module, ident, ns, |this, resolution| { if let Some(old_binding) = resolution.binding { if binding.is_glob_import() {

Related discussion:
text: 'tcxas rustc::hir::intravisit::Visitor<'tcx::visititem::hae9f32c7942ccca1 15: 0x7fc35c6deab5 - <rustcprivacy::ObsoleteVisiblePrivateTypesVisitor<'a, 'tcxas rustc::hir::intravisit::Visitor<'tcx::visititem::hae9f32c7942ccca1 16: 0x7fc35c6e1b7a - rustcprivacy::checkcrate::h5ba75e3c4ebe0690 17: 0x7fc35eaef747 - rustcdriver::driver::phase3runanalysispasses::{{closure}}::h388b9236cf305089 18: 0x7fc35ead66d6 - rustcdriver::driver::phase3runanalysispasses::h080c1a734c4f2909 19: 0x7fc35eac5425 - rustcdriver::driver::compileinput::hab55539b85c4ceed 20: 0x7fc35eb0ea51 - rustcdriver::runcompiler::h128b89b79f649304 21: 0x7fc35ea236fb - std::panicking::try::docall::h15bca94dda232804 22: 0x7fc35e757b06 - rustmaybecatchpanic 23: 0x7fc35ea44d01 - <F as alloc::boxed::FnBox<A::callbox::h8832766c4bda585b 24: 0x7fc35e74d470 - std::sys::imp::thread::Thread::new::threadstart::h7d03d727f96da002 25: 0x7fc357684453 - startthread 26: 0x7fc35e4147de - GI__clone 27: 0x0 - <unknown
triage: P-high Seems bad. Assigning to based on bisection.
Fixed in .
Code change:
ns: Namespace, binding: &'a NameBinding<'a>) -> Result<(), &'a NameBinding<'a>> { <del> let ident = ident.unhygienize(); </del> self.update_resolution(module, ident, ns, |this, resolution| { if let Some(old_binding) = resolution.binding { if binding.is_glob_import() {

Related discussion:
text: Servo compiles with rustc 2016-12-18, but not with 2016-12-21. Diff: The crate fails to build with: The method being called here is: Its return type is which is . This call is in another impl of the same method of the same trait: Adding an explicit type annotation works around this error, but only to uncover another very similar one, then another. The third one was in code generated by serde’s , so I gave up that approach. So far I haven’t managed to reduce a test case smaller than "most of Servo", sorry. I’m suspicious of (which is part of ) because it’s commit message mentions inference. I’m not building a compiler to confirm.
CC
Also fails in , so is not to blame. New diff: I don’t have another guess, and doing a full bisect would take a very long time…
I can't find the cause in that range, at least nothing changed in the compiler AFAICT. Can you try (the commit before larger rollup)?
Expanding the macro: (Even simplifying it, this is not using ) gives:
Alright, that matches what I've seen from What about a couple more steps of bisecting? Or maybe compiling this crate with the "servo" feature off (which, AFAICT, turns off all the macros 1.1 - they might be responsible).
Swapping the order of the two arms: Changing the pattern to : Hacking to not use the stable version of the compiler (so effectively disabling the feature and enabling the one) also gives the same error.
New range, based on manual bisect: good, bad. Diff: , which leaves only in-between. CC Also found more clues. More context for the code where the error happens: is a module generated by a macro, that contains re-exports of other modules: If I add a similar not in a macro: or if I change the original code to use the real path without going through a , this seems to work around this issue completely. … only to uncover another one:
Found another ICE, I don’t know if it’s related: .
Code change:
ns: Namespace, binding: &'a NameBinding<'a>) -> Result<(), &'a NameBinding<'a>> { <del> let ident = ident.unhygienize(); </del> self.update_resolution(module, ident, ns, |this, resolution| { if let Some(old_binding) = resolution.binding { if binding.is_glob_import() {

Related discussion:
text: Found a smaller test case for the inference issue: rust fn main() {} pub mod a { pub struct FontFamily; impl FontFamily { pub fn tocss(&self) -::std::fmt::Result { Ok(()) } } } macrorules! reexport { () ={ mod b { pub use a; } } } reexport!(); pub mod c { use b::a::FontFamily; struct FontFace { family: FontFamily } impl FontFace { pub fn tocss(&self) -::std::fmt::Result { try!(()); Ok(()) } } }
That "other ICE" is actually a direct observation of the bug, whereas this inference issue is some weird side-effect of the way we handle errors that don't stop compilation.
never mind, apparently it fails locally
triage: P-high Seems bad. Assigning to based on bisection.
Does this affect beta ()?
At the moment the latest successful nightly build is 3 days old. I don’t know how often playpen’s nigthly is updated. merged 2 days ago. (This is the rollup PR that merged , which introduced this issue if I did my manual bisecting correctly.) As far as I can tell no, is not reachable from and so beta is not affected.
Fixed in .
Code change:
let cloned_shared = Rc::clone(&cx.shared); let cache = &cloned_shared.cache; let mut extern_crates = FxHashSet::default(); <ins> if !t.is_object_safe(cx.tcx()) { write_small_section_header( w, "object-safety", "Object Safety", &format!( "<div class="object-safety-info">This trait is <b>not</b>  <a href="{base}/reference/items/traits.html#object-safety"> object safe</a>.</div>", base = crate::clean::utils::DOC_RUST_LANG_ORG_CHANNEL ), ); } </ins> if let Some(implementors) = cache.implementors.get(&it.item_id.expect_def_id()) { // The DefId is for the first Type found with that name. The bool is // if any Types with the same name but different DefId have been found.

Related discussion:
text: So that it is easy for user to recognize object-safe traits. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
for the rustdoc side, just query the doc context with a given traitdef_id.
claim
Can you tell what are the relevant parts of rustdoc that needs to be changed?
sorry for late rely :) Add a field to , its value can be queried with like . Then you can append the object-safety info into the render part here I know little about the render code, could you leave some notes about that?
No, please do not add more fields to Trait. Query at the place it is used. I don't know much about render, may have suggestions.
I'm actually not sure what they want the end result to look like, so I don't know where to tell them to update the code. ;)
maybe it could be a cube icon to the right of the new button? On hover, there would be a tooltip saying or . I'm not sure where you get icons for rustdoc, but have a cube and cube-transparent icon that could be used for object-safe, and object-unsafe traits respectively. The could be reduced to fit in with the rest of the icons in rustdoc. If doesn't want to work on it I'd be happy to give it a go.
Following up from the PR with some UI discussion. I'd prefer not to add more icons up at the top of the page; we're already a bit crowded with icons. And there's no icon that has a broadly understood meaning of "object safe". I like the approach in , to write out "This trait is object-safe." But that PR puts it all the way at the top of the page, which is very high priority - and I would say object safety is more medium priority, so it should be lower on the page. One possibility would be to make an subheading in the top-doc docblock, but that results in using a lot of space for this. Our h2's are big! What about this: Under "Implementors", we could have at the very top "This trait is object safe. References to types that implement this trait can be automatically coerced to ".
Code change:
let cloned_shared = Rc::clone(&cx.shared); let cache = &cloned_shared.cache; let mut extern_crates = FxHashSet::default(); <ins> if !t.is_object_safe(cx.tcx()) { write_small_section_header( w, "object-safety", "Object Safety", &format!( "<div class="object-safety-info">This trait is <b>not</b>  <a href="{base}/reference/items/traits.html#object-safety"> object safe</a>.</div>", base = crate::clean::utils::DOC_RUST_LANG_ORG_CHANNEL ), ); } </ins> if let Some(implementors) = cache.implementors.get(&it.item_id.expect_def_id()) { // The DefId is for the first Type found with that name. The bool is // if any Types with the same name but different DefId have been found.

Related discussion:
text: My reasoning here is that conceptually, is somewhat like an implementor of the trait.
I don't think this is necessarily true, you can have a that doesn't implement . But putting the text under "implementors" seems as good a place as any
Just out of curiosity, how can I have a that doesn’t implement ?
I don't think that's actually true, I misremembered.
We have one on: Would anyone else like to weigh in? Good enough to proceed with implementation?
Any update on this? :)
I'm not sure if it's already been suggested, but what about only showing a note if the trait is not object-safe?
I like suggestion to only show when a trait is not object safe, since that's the more unusual condition. If we do that, it doesn't fit logically under "Implementors" anymore. If we proceed with only marking non-object-safe traits, here are a couple of ideas: Add a section after the top-doc, but before "Implementors", called "Object Safety", and put the text there. Add information to the documentation of any method that causes the trait to be not object-safe.
I think it’s still fine to mention under “Implementors” like “This trait is not object safe: doesn’t implement ”, but I also like the idea of the new section. I see this issue doesn’t have an assignee currently, can I claim this?
You can but since we didn't reach a consensus, any PR would hang around until we reach one.
Code change:
node_to_hir_id: IndexVec::new(), macro_def_scopes: FxHashMap(), expansions: FxHashMap(), <del> keys_created: FxHashSet(), </del> <ins> next_disambiguator: FxHashMap(), </ins> } }

Related discussion:
text: In investigating I was generating some source code, and using the shell script listed in we can see: That's a lot of time to expand a crate that doesn't have any macros in it!
cc you may be interested in this!
A looks like almost all the time is spent in In which case, cc
Apparently most time is spent
called ~38k times
Since we need to build the module graph and resolve imports during expansion for macros 2.0, we must construct node ids and def ids throughout expansion (i.e. interleaved arbitrarily many times until we hit fix-point). Ideally we'd keep running totals of the time spent assigning node ids, assigning def ids, etc. for more accurate profiling information within the expansion step.
in theory though isn't the fixed point for this crate the crate itself? (e.g. there's no macros here). Or are the def ids persisted for the rest of compilation, so "blaming" expansion isn't quite correct here?
Yeah, the def ids are persisted for the rest of compilation. We could move the "first round" of def id collection (in which we collect the raw, unexpanded source) outside of expansion, but that would introduce more code complexity and wouldn't count the time we spend collecting def ids for AST that comes from macro expansions.
Ah ok, nah it seems fine! I think there's a number of cases where is attributing time in the wrong place nowadays... Still it seems odd that 30-50k invocations of this function would take so long to execute?
Do I understand this correctly that all DefIds generated are actually used, right? There are no "temporary" DefIds? Each of these invocations creates a Blake2 hasher. I'd be interested how the performance looks with other hashing algorithms. I'd like to switch to something faster anyway:
Are you sure this isn't the other quadratic case fixed in ?
It may very well be! Feel free to close this w/ that PR landing, I'll verify to be sure but I'd imagine you're correct in that it's fixed by
er, didn't mean to close just yet
Code change:
node_to_hir_id: IndexVec::new(), macro_def_scopes: FxHashMap(), expansions: FxHashMap(), <del> keys_created: FxHashSet(), </del> <ins> next_disambiguator: FxHashMap(), </ins> } }

Related discussion:
text: A of Servo's crate shows a huge amount of time (46 seconds!) in name resolution. It turns out that is calling , specifically . That's a lot of unused imports! Sure enough if we create a synthetic file locally with this script: we find: That's a lot of time spent processing unused imports! The slowdown here isn't quite the same as the style crate, unfortunately. The style crate only has ~7k unused imports, which apparently takes it 48s in that profile. In any case the intent here is clear, lots of unused imports seem to slow down compilation, and the crate looks to have a lot of unused imports!
cc
We could address this quickly by just emitting the first 10 unused imports warnings and then warning that there are more unused imports not shown.
I can never deal with more than 10 lints at a time anyway myself, so seems like a reasonable solution to me!
Dumping out a ton of warnings is useful when you're hooked into an IDE and you can see them as e.g. green squiggles under the offending text as opposed to 10k lines on a terminal.
I think the reason is slow is because it calls , which does this: I don't think we want to read source files multiple times like that.
Thank you for looking into Servo compile times Alex, and great find here! Could you CC me or someone from the Servo team for Servo-related issues? Thanks.
Can do!
In general I've always wanted the lint system to avoid even running in blocks. Currently the lint system runs all lints in parallel on the tree. This is great since it means we only traverse it once, and the cost of the traversal is consolidated. We don't need to reduce that cost itself (which is nice because then we don't have to worry about inside ). Most lints do not maintain state. The lint framework has the capability to do so, and we use this a couple times in Clippy, but most lints are , so they won't notice if or whatever isn't called in a region of . The "allowness" of a lint is tied to where in the tree the lint traversal is, not the span emitted by the lint.
Code change:
node_to_hir_id: IndexVec::new(), macro_def_scopes: FxHashMap(), expansions: FxHashMap(), <del> keys_created: FxHashSet(), </del> <ins> next_disambiguator: FxHashMap(), </ins> } }

Related discussion:
text: It's perfectly possible to a block of code and have the lint still be emit there because a different block of code (where it is ) hit the lint but emitted a span it got from elsewhere. We've had trouble with this before in clipyp iirc. All of this enables this proposal: If we had a specialized trait for this, then when we have an we can turn off calling lint methods entirely, and when there's a turn it on again. It doesn't even have to be a trait, really, it could just be a defaulted fake-static method (until happens) on LateLintPass. I suspect this will get significant speedups for crates like Style. I may_ be able to take a crack at this if y'all think this is a good approach.
It occurs to me that a boolean check per lint each tree node might actually end up being more expensive? I'll have look at this code closer. Might be possible to make this fast by having a second array of trait objects which only contains the active lint passes.
It seems like we do a large enough amount of work that the whole "vector of active lints" stuff won't really be necessary. However, I just realized that this bug is not during the lint pass but during the resolution phase (which defers linting to the actual lint pass). This won't be able to help, though we can fix it by doing the spantosnippet in the actual lint and then making this optimization. So in that case I suspect this optimization is unnecessary. In general we've rarely had performance issues with lints in clippy (which has way more lints than rustc), and we've been pretty careful to measure impact there. Still, if folks think this optimization can help, let me know.
Code change:
v.iter().any(|&x| x == 0) } <del> #[inline(always)] fn from_utf8_with_replacement(mut v: &[u8]) -> ~str { // FIXME (#9516): Don't decode utf-8 manually here once we have a good way to do it in str // This is a truly horrifically bad implementation, done as a functionality stopgap until // we have a proper utf-8 decoder. I don't really want to write one here. static REPLACEMENT_CHAR: char = 'uFFFD'; let mut s = str::with_capacity(v.len()); while !v.is_empty() { let w = str::utf8_char_width(v[0]); if w == 0u { s.push_char(REPLACEMENT_CHAR); v = v.slice_from(1); } else if v.len() < w || !str::is_utf8(v.slice_to(w)) { s.push_char(REPLACEMENT_CHAR); v = v.slice_from(1); } else { s.push_str(unsafe { ::cast::transmute(v.slice_to(w)) }); v = v.slice_from(w); } } s } </del> #[cfg(test)] mod tests { use prelude::*;

Related discussion:
text: We need some way to interpret a as UTF-8, using the replacement character for invalid sequences instead of conditions. This would ideally be provided in the form of an .
Could we remove the current condition API in favour of this? It doesn't really seem to offer anything but failing, and we already have an API returning an .
I would be quite pleased if we could do that. Using the condition is rather awkward, and I would rather just have replacement chars myself.
This is a duplicate of , no?
And also the e-mail thread here I think is relevant:
This is an implementation of a mostly complete → UTF-8 decoder
It's only a duplicate if the intended resolution of is to use the replacement char instead of conditions, but it's unclear from the discussion if that's the plan.
I guess my thinking was that a maximally expressive condition-based solution would let one express a replacement char approach using conditions. But I don't actually favor doing that at this point. Or at least, I don't favor making that the only way to accomplish this, since I suspect a more specialized approach will be much nicer to use (both in terms of programmer convenience and in terms of efficiency). So okay, this is not a duplicate of .
Rust needs to support both fatal and replacement error handling modes, it should follow the WHATWG spec simonsapin has said (edit by is WHATWG spec.)
the fatal mode is already handled by the API
well, the current functions in str don't handle decoding buffers in chunks like the proposed encodings API. But yes, it does handle one-off decoding with 'fatal' error handling.
I think we need to improve/extend our API along the lines suggested here for 1.0. Nominating for P-backcompat-lang. (Arguably we could avoid the backwards compatibility hazard by offering a fail-only method for 1.0 and then adding an alternative entry point that provides the more flexible API supporting replacement characters in post 1.0. But I think this case is important enough that we should try to get the primary API method to provide both choices up front. That, or put dynamic fluid support in for representing the state of that choice.)
I submitted a PR for this last night, although I forgot there was an open issue too so I didn't link them. The PR is
Code change:
.map(|(item, renamed)| clean_maybe_renamed_foreign_item(cx, item, *renamed)), ); items.extend(self.mods.iter().map(|x| x.clean(cx))); <del> items.extend( self.items .iter() .flat_map(|(item, renamed)| clean_maybe_renamed_item(cx, item, *renamed)), ); </del> <ins> // Split up imports from all other items. // // This covers the case where somebody does an import which should pull in an item, // but there's already an item with the same namespace and same name. Rust gives // priority to the not-imported one, so we should, too. let mut inserted = FxHashSet::default(); items.extend(self.items.iter().flat_map(|(item, renamed)| { // First, lower everything other than imports. if matches!(item.kind, hir::ItemKind::Use(..)) { return Vec::new(); } let v = clean_maybe_renamed_item(cx, item, *renamed); for item in &v { if let Some(name) = item.name { inserted.insert((item.type_(), name)); } } v })); items.extend(self.items.iter().flat_map(|(item, renamed)| { // Now we actually lower the imports, skipping everything else. if !matches!(item.kind, hir::ItemKind::Use(..)) { return Vec::new(); } let mut v = clean_maybe_renamed_item(cx, item, *renamed); v.drain_filter(|item| { if let Some(name) = item.name { // If an item with the same type and name already exists, // it takes priority over the inlined stuff. !inserted.insert((item.type_(), name)) } else { false } }); v })); </ins> // determine if we should display the inner contents or // the outer `mod` item for the source code.

Related discussion:
text: I tried to create a minimum example from an issue we've seen in our project (). I tried running: On the following crate: : I expected to see this happen: The command should succeed. Instead, this happened: It crashed with an ICE <!-- 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<summaryBacktrace</summary<p</p</details
This issue may be related to , however I can only reproduce it on the nightly build. On the stable channel, rustdoc succeeds.
cc
does this reproduce on beta?
I know I'm not celinval, but I've been able to reduce this to a test case, and yeah, it reproduces on beta.
That was quick. Thank you!
Reopening to track beta breakage.
I was silly and nominated even though the PR has already been nominated, and that's really the thing that's supposed to be. Please ignore, and sorry for the noise.