I forgot that --stage 0 is the default; I have it set to --stage 1 by default locally and forgot that it was my specific configuration.

cc @pickfire

@Davester47 if you can come up with an MCVE for the hang, that would be extremely helpful. Right now all the examples we have require actix.

This is already documented: https://rustc-dev-guide.rust-lang.org/building/bootstrapping.html#default-stages

I forgot that --stage 0 is the default; I have it set to --stage 1 by default locally and forgot that it was my specific configuration.

cc @pickfire

It builds with stage 1 by default.

r? @jyn514 for correctness

This looks like a duplicate of https://github.com/rust-lang/rust/issues/75992.

Should be ready to go :)

If this is called after free(), then one of two things happened:

1. rewriter.0 was None when dropped, so end() was called in the past, so the error message is correct (free() is irrelevant to the panic).
2. rewriter.0 was Some when dropped, so this value has already been dropped, so this is UB. In practice, I think the bytes will not be zeroed, so this panic won't execute.

In either case, I don't think there's a need to change the message.

I think 'seems fine' is good for now, I did test locally that this works. We can always fix issues in follow-ups.

@bors r=mark-simulacrum

Got it, thanks, I didn't realize this was fixing an omission. Looks good to me then :)

Also, wow, Range being an Iterator is very confusing.

I don't know why the end should be treated specially. If you think this is useful, shouldn't it apply to all parts of iteration equally, and let mut iter = 0..5; iter.next(); iter.contains(0) return false?

Closing since this is a duplicate.

Apologies in advance for not being able to provide a minimal snippet of the code. I'll be willing to give more info, if necessary. Bear in mind that the codebase is not open-source.

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

http://blog.pnkfx.org/blog/2019/11/18/rust-bug-minimization-patterns/

-->

Code

<code>

Meta

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

rustc --version --verbose:

rustc 1.49.0-nightly (b1496c6e6 2020-10-18)
binary: rustc
commit-hash: b1496c6e606dd908dd651ac2cce89815e10d7fc5
commit-date: 2020-10-18
host: x86_64-unknown-linux-gnu
release: 1.49.0-nightly
LLVM version: 11.0

Error output

error[E0658]: use of unstable library feature 'entry_insert'
   --> api/src/node_actor.rs:147:49
    |
147 |                         m.entry(symbol.clone()).insert(price_ticker);
    |                                                 ^^^^^^
    |
    = note: see issue #65225 <https://github.com/rust-lang/rust/issues/65225> for more information
    = help: add `#![feature(entry_insert)]` to the crate attributes to enable

error[E0061]: this function takes 5 arguments but 4 arguments were supplied
   --> api/src/lib.rs:162:22
    |
162 |         tokio::spawn(NodeActor::start(pixie_channel, rx, sub, Arc::clone(&re_state)));
    |                      ^^^^^^^^^^^^^^^^ -------------  --  ---  --------------------- supplied 4 arguments
    |                      |
    |                      expected 5 arguments
    |
note: associated function defined here
   --> api/src/node_actor.rs:30:18
    |
30  |     pub async fn start(
    |                  ^^^^^
31  |         (node_tx, node_rx): (ZmqSocket, Receiver<RawMessage>),
    |         -----------------------------------------------------
32  |         mut rx: mpsc::Receiver<Envelope>,
    |         --------------------------------
33  |         sub: ZmqSocket,
    |         --------------
34  |         re_state: Arc<AtomicBool>,
    |         -------------------------
35  |         shared_tickers: crate::SharedTickers,
    |         ------------------------------------

error: internal compiler error: compiler/rustc_middle/src/ty/sty.rs:2138:18: tuple_fields called on non-tuple

note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.49.0-nightly (b1496c6e6 2020-10-18) running on x86_64-unknown-linux-gnu

note: compiler flags: -C embed-bitcode=no -C codegen-units=96 -C debuginfo=2 -C incremental --crate-type lib

note: some of the compiler flags provided by cargo are hidden

query stack during panic:
#0 [evaluate_obligation] evaluating trait selection obligation `[closure@api/src/lib.rs:171:34: 209:6]: std::clone::Clone`
#1 [typeck] type-checking `start`
#2 [typeck_item_bodies] type-checking all item bodies
#3 [analysis] running analysis passes on this crate
end of query stack
error: aborting due to 3 previous errors; 2 warnings emitted

Some errors have detailed explanations: E0061, E0658.
For more information about an error, try `rustc --explain E0061`.
error: could not compile `api`

<!-- Include a backtrace in the code block by setting RUST_BACKTRACE=1 in your environment. E.g. RUST_BACKTRACE=1 cargo build. --> <details><summary><strong> <strong></summary> <p>

thread 'rustc' panicked at 'Box<Any>', compiler/rustc_errors/src/lib.rs:945:9
stack backtrace:
   0: std::panicking::begin_panic
   1: rustc_errors::HandlerInner::bug
   2: rustc_errors::Handler::bug
   3: rustc_middle::util::bug::opt_span_bug_fmt::{{closure}}
   4: rustc_middle::ty::context::tls::with_opt::{{closure}}
   5: rustc_middle::ty::context::tls::with_opt
   6: rustc_middle::util::bug::opt_span_bug_fmt
   7: rustc_middle::util::bug::bug_fmt
   8: rustc_middle::ty::sty::<impl rustc_middle::ty::TyS>::tuple_fields
   9: rustc_trait_selection::traits::select::SelectionContext::copy_clone_conditions
  10: rustc_trait_selection::traits::select::candidate_assembly::<impl rustc_trait_selection::traits::select::SelectionContext>::assemble_candidates
  11: rustc_trait_selection::traits::select::candidate_assembly::<impl rustc_trait_selection::traits::select::SelectionContext>::candidate_from_obligation_no_cache
  12: rustc_middle::dep_graph::<impl rustc_query_system::dep_graph::DepKind for rustc_middle::dep_graph::dep_node::DepKind>::with_deps
  13: rustc_query_system::dep_graph::graph::DepGraph<K>::with_anon_task
  14: rustc_trait_selection::traits::select::candidate_assembly::<impl rustc_trait_selection::traits::select::SelectionContext>::candidate_from_obligation
  15: rustc_trait_selection::traits::select::SelectionContext::evaluate_stack
  16: rustc_middle::dep_graph::<impl rustc_query_system::dep_graph::DepKind for rustc_middle::dep_graph::dep_node::DepKind>::with_deps
  17: rustc_query_system::dep_graph::graph::DepGraph<K>::with_anon_task
  18: rustc_trait_selection::traits::select::SelectionContext::evaluate_trait_predicate_recursively
  19: rustc_trait_selection::traits::select::SelectionContext::evaluate_predicate_recursively::{{closure}}
  20: rustc_trait_selection::traits::select::SelectionContext::evaluate_predicate_recursively
  21: rustc_infer::infer::InferCtxt::probe
  22: rustc_trait_selection::traits::select::SelectionContext::evaluate_root_obligation
  23: rustc_infer::infer::InferCtxtBuilder::enter_with_canonical
  24: rustc_traits::evaluate_obligation::evaluate_obligation
  25: rustc_middle::ty::query::<impl rustc_query_system::query::config::QueryAccessors<rustc_middle::ty::context::TyCtxt> for rustc_middle::ty::query::queries::evaluate_obligation>::compute
  26: rustc_middle::dep_graph::<impl rustc_query_system::dep_graph::DepKind for rustc_middle::dep_graph::dep_node::DepKind>::with_deps
  27: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
  28: rustc_middle::ty::query::plumbing::<impl rustc_query_system::query::QueryContext for rustc_middle::ty::context::TyCtxt>::start_query::{{closure}}::{{closure}}::{{closure}}
  29: rustc_query_system::query::plumbing::get_query_impl
  30: <rustc_infer::infer::InferCtxt as rustc_trait_selection::traits::query::evaluate_obligation::InferCtxtExt>::evaluate_obligation
  31: <rustc_infer::infer::InferCtxt as rustc_trait_selection::traits::query::evaluate_obligation::InferCtxtExt>::evaluate_obligation_no_overflow
  32: rustc_trait_selection::traits::fulfill::FulfillProcessor::process_trait_obligation
  33: rustc_trait_selection::traits::fulfill::FulfillProcessor::progress_changed_obligations
  34: rustc_data_structures::obligation_forest::ObligationForest<O>::process_obligations
  35: <rustc_trait_selection::traits::fulfill::FulfillmentContext as rustc_infer::traits::engine::TraitEngine>::select_where_possible
  36: rustc_typeck::check::fn_ctxt::_impl::<impl rustc_typeck::check::fn_ctxt::FnCtxt>::select_obligations_where_possible
  37: rustc_infer::infer::InferCtxtBuilder::enter
  38: rustc_typeck::check::typeck
  39: rustc_middle::ty::query::<impl rustc_query_system::query::config::QueryAccessors<rustc_middle::ty::context::TyCtxt> for rustc_middle::ty::query::queries::typeck>::compute
  40: rustc_middle::dep_graph::<impl rustc_query_system::dep_graph::DepKind for rustc_middle::dep_graph::dep_node::DepKind>::with_deps
  41: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
  42: rustc_data_structures::stack::ensure_sufficient_stack
  43: rustc_query_system::query::plumbing::get_query_impl
  44: rustc_query_system::query::plumbing::ensure_query_impl
  45: rustc_typeck::check::typeck_item_bodies
  46: rustc_middle::ty::query::<impl rustc_query_system::query::config::QueryAccessors<rustc_middle::ty::context::TyCtxt> for rustc_middle::ty::query::queries::typeck_item_bodies>::compute
  47: rustc_middle::dep_graph::<impl rustc_query_system::dep_graph::DepKind for rustc_middle::dep_graph::dep_node::DepKind>::with_deps
  48: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
  49: rustc_data_structures::stack::ensure_sufficient_stack
  50: rustc_query_system::query::plumbing::get_query_impl
  51: rustc_typeck::check_crate
  52: rustc_interface::passes::analysis
  53: rustc_middle::ty::query::<impl rustc_query_system::query::config::QueryAccessors<rustc_middle::ty::context::TyCtxt> for rustc_middle::ty::query::queries::analysis>::compute
  54: rustc_middle::dep_graph::<impl rustc_query_system::dep_graph::DepKind for rustc_middle::dep_graph::dep_node::DepKind>::with_deps
  55: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
  56: rustc_data_structures::stack::ensure_sufficient_stack
  57: rustc_query_system::query::plumbing::get_query_impl
  58: rustc_interface::passes::QueryContext::enter
  59: rustc_interface::queries::<impl rustc_interface::interface::Compiler>::enter
  60: rustc_span::with_source_map
  61: scoped_tls::ScopedKey<T>::set
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

</p> </details>

This was the exact use case:

    // on stable
    match delta {
        (days, ..) if days > 5 => format!("{}", tm.strftime("%b %d, %Y").unwrap()),
        (days @ 2..=5, ..) => format!("{} days ago", days),
        (1, ..) => "one day ago".to_string(),

        (0, hours, ..) if hours > 1 => format!("{} hours ago", hours),
        (0, 1, ..) => "an hour ago".to_string(),

        (0, 0, minutes, _) if minutes > 1 => format!("{} minutes ago", minutes),
        (0, 0, 1, _) => "one minute ago".to_string(),

        (0, 0, 0, seconds) if seconds > 0 => format!("{} seconds ago", seconds),
        _ => "just now".to_string(),
    };
    // on nightly
    match delta {
        (6.., ..) => format!("{}", tm.strftime("%b %d, %Y").unwrap()),
        (days @ 2..=5, ..) => format!("{} days ago", days),
        (1, ..) => "one day ago".to_string(),

        (0, hours @ 2.., ..) => format!("{} hours ago", hours),
        (0, 1, ..) => "an hour ago".to_string(),

        (0, 0, minutes @ 2.., _) => format!("{} minutes ago", minutes),
        (0, 0, 1, _) => "one minute ago".to_string(),

        (0, 0, 0, seconds @ 1..) => format!("{} seconds ago", seconds),
        _ => "just now".to_string(),
    }

Personally I feel like explicitly adding u/iN::MAX/MIN is probably not too much more writing in practice...

I guess the main difference is that requires you to know what type delta is ... with X.. you'd only have to know {integer}. I'd prefer not to have to think about whether seconds are i32 or i64 or something else. The stable version I posted uses if-guards instead which have the downside you no longer get exhaustiveness checking.

they may have thought of the value as unsigned and not realized it was signed, for example

right - I realized when trying to make this an exhaustive match that this was actually a signed integer when I thought it was unsigned. Actually I think we don't handle the negative case in docs.rs ...

Well, in any case, this isn't a rustdoc issue, it's a mdbook issue. Can someone move it there?

Personally this doesn't seem like a giant loss to me; the point of these examples is the markdown syntax, not the Rust code itself. I wouldn't mind having the rust highlighted, but if it's hard to do like ehuss mentioned, I'm not sure it's worth it.

Previously, trying to allow this would give another error!

warning: unknown lint: `private_intra_doc_links`
 --> private.rs:1:10
  |
1 | #![allow(private_intra_doc_links)]
  |          ^^^^^^^^^^^^^^^^^^^^^^^ help: did you mean: `broken_intra_doc_links`
  |
  = note: `#[warn(unknown_lints)]` on by default

warning: public documentation for `DocMe` links to private item `DontDocMe`
 --> private.rs:2:11
  |
2 | /// docs [DontDocMe]
  |           ^^^^^^^^^ this item is private
  |
  = note: `#[warn(private_intra_doc_links)]` on by default
  = note: this link will resolve properly if you pass `--document-private-items`

Fixes the issue found in https://github.com/rust-lang/rust/pull/77249#issuecomment-712339227.

r? @Manishearth

Does anyone know why this additional step is necessary? It seems weird this has to be declared in 3 different places.

warning: unknown lint: `private_intra_doc_links`
 --> private.rs:1:10
  |
1 | #![allow(private_intra_doc_links)]
  |          ^^^^^^^^^^^^^^^^^^^^^^^ help: did you mean: `broken_intra_doc_links`
  |
  = note: `#[warn(unknown_lints)]` on by default

warning: public documentation for `DocMe` links to private item `DontDocMe`
 --> private.rs:2:11
  |
2 | /// docs [DontDocMe]
  |           ^^^^^^^^^ this item is private
  |
  = note: `#[warn(private_intra_doc_links)]` on by default
  = note: this link will resolve properly if you pass `--document-private-items`

Well that's odd.

@bors r+ rollup

nit: this could be more consice

        book_info.innerHTML = "You can find more information in
            <a href=\"https://doc.rust-lang.org/rustdoc/\">the rustdoc book</a>.";

As an aside, it looks like encoding_rs has been very stable recently, especially since 0.8.11. Have you considered publishing a 1.0 release?

• ..= was stabilized in 1.26: https://github.com/rust-lang/rust/pull/47813/commits/92d1f8d8e4be62e6f4dc32bc57f9d44f53117ec9d
• MaybeUninit was stabilized in 1.36: https://doc.rust-lang.org/std/mem/union.MaybeUninit.html
• Removing the loop labels shouldn't affect MSRV.

It looks like encoding_rs currently supports up to 1.29: https://github.com/hsivonen/encoding_rs#0811. So either I can remove the switch to MaybeUninit or the next release should be 0.9 to reflect the breaking change.

I couldn't find documentation on the MSRV, but the only code change in 1.0 was a small change to a macro parameter: https://github.com/alexcrichton/cfg-if/compare/0.1.10...1.0.0

In that case someone should r- before bors merges 😆

In that case, could we stabilize X.. without stabilizing the others? That seems both more clear and more useful than the other alternatives, since the current stable version is an if guard, while the others can be written with 0..

Current status: this is blocked on https://github.com/rust-lang/rust/pull/78082 to get the param context, since otherwise the API is different enough from rustc I wouldn't be convinced it had consistent behavior.

@bors rollup

@bors r+

Again, I'm not sure I'm the best person to review this ... maybe @ollie27 would be a better choice?

That said, the screeenshots do look a lot better :)

I managed to reproduce the original issue on master (I was on the wrong commit before 🤦) and it does seem to be fixed with this branch. This has no output for me with the changes from this MR:

$ cargo deadlinks 2>a.txt
$ cargo deadlinks 2>b.txt
$ sort a.txt | diff - <(sort b.txt)

Can you try it locally and make sure the only thing different is the ordering? Non-determinism in the ordering doesn't seem exactly a bug to me, just a future enhancement.

This prints a lot more but i still get different results on different computers.

Parallelism/non-determinism in the files ordering is expected, I can make that an optional feature though. When you say different results, do you mean it's not always catching everything? Or just that it's in a non-deterministic order?

I also noticed now it prints broken links within a single file in a different order each time - not sure it used to do that.

That's strange ... the only parallelism is on the files themselves, not within a file (AFAIK). Unless Handle.children.iter() returns things in a random order? I don't know what deadlinks could do about that if so - maybe I could sort the output before printing it?

There's nothing this does that clean can't do. Moving the transformations into clean directly makes it more clear what's going on, and less likely to have data that's inconsistent compared to rustc. It also means that there's no need to have 15 different impl Clean for doctree::X blocks, making it easier to add data to clean::Item (https://github.com/rust-lang/rust/issues/76998).

This will probably end up obsoleting https://github.com/rust-lang/rust/pull/77820, but I haven't actually finished impl Clean for hir::Item 😇 so I won't know until that's done.

Changes from doctree:

• renamed was always None, so no need to carry over

• visit_local_macro <- maybe_inline <- visit_item <- maybe_inline

• imported_from was always None, no need to carry over
• (planned) Crate name should never have been None; use tcx.sess.crate_name instead.

r? @ghost

Looks good to me.

r? @ollie27

This is fixable by adding a new error type

Done, I realized I could reuse the existing EncodingError.

This already has conflicts 😅 Otherwise looks fine to me but I don't work in this part of the compiler.

Is this change in the diagnostic intentional?

Are these changes intentional?

@njasm can you open an issue? I agree it's less than ideal, but this PR didn't change very much in that area; it actually made it less crowded because ? no longer shows up.

What we can do instead is consume self on Rust side. But for C API use HtmlRewriterWrapper(Option<HtmlRewriter>) which derefs to rewriter. We'll keep free() which will free the rewriter if it's not None at this point (end() hasn't be called) or will be noop otherwise. And for end() we'll do self.0.take().

I like this! Done :)

Gotcha, thanks for trying to contribute :) I'll close this then but if you're interested in working in something else I'm happy to help!

GitHub Actions has encountered an internal error when running your job.

@bors retry

So, after all that, https://github.com/rust-lang/rust/pull/77972 just landed. Maybe we no longer need to sound the alarm on this?

@camelid this is a feature that may have a perf impact, as opposed to a PR that's only for reducing compile time.

@jackh726 FYI you can modify labels yourself with rustbot modify labels: https://forge.rust-lang.org/platforms/zulip/triagebot.html#apply-labels-to-issues

Looks like no impact.

@bors delegate=bjorn3

weird-exprs does strange things like this intentionally; just because we can doesn't necessarily mean it's a useful change. Can you explain why this is better than previous behavior?

rebind was added that should significantly reduce the work we do

@bors try @rust-timer queue

Do you need this new test case? This is tested in plenty of other places.

This is currently broken because unwrap_or_ret_err (unstandably) requires a reasonable error to store in LAST_ERROR and right now I'm only giving it (). This is fixable by adding a new error type but I'm probably not going to get around to it any time soon.

A better idea @cuviper thought of is to have write(self) -> Self instead of taking &mut self; that way whenever you have a Rewriter it will be a fresh expression, so you'll always get the must_use lint. That's a pretty invasive change though and will require lots more ptr::read(), so probably not worth it, but still worth considering.

The closest thing I found was an abandoned discussion on internals.rlo https://internals.rust-lang.org/t/idea-attributes-to-warn-if-value-is-dropped-without-being-acted-upon/10485/19 which suggests a 'proof of work' to make sure end() is actually called. That seems like a pretty big burden to force to the user though, really I just want a lint.

Ooh, I can make this must_use too, that way the compiler warns you if you forget to call end().

Hmm, this didn't actually work because .write() counts as a 'use'. I wish there was something like must_consume.

• Add AsciiCompatibleEncoding wrapper type
• Provide ways to convert between Ascii... and Encoding
• Make new infallible
• Fix tests, examples, and benches

This turned out very well - you only have to worry about fallible conversions if you use an encoding other than the default, which is fairly rare.

This is a breaking change.

Closes https://github.com/cloudflare/lol-html/issues/46.

Ooh, I can make this must_use too, that way the compiler warns you if you forget to call end().

Closes https://github.com/cloudflare/lol-html/issues/55. This is a breaking change.

This commit combines end() and free() into the same function for the C API.

Note that free() still causes memory unsafety if called twice on the same pointer, so if there was anywhere calling end() twice before, it will now have UB instead of causing a panic. All the call sites should be audited to make sure they call free() exactly once. This is only relevant for C, since in Rust calling end() twice will be a compile error.

IIRC there were some problems with C API because of that. Need to check.

This was the error:

error[E0507]: cannot move out of `*rewriter` which is behind a mutable reference
  --> src/rewriter.rs:80:31
   |
80 |     unwrap_or_ret_err_code! { rewriter.end() };
   |                               ^^^^^^^^ move occurs because `*rewriter` has type `lol_html::HtmlRewriter<'_, rewriter::ExternOutputSink>`, which does not implement the `Copy` trait

This commit combines end() and free() into the same function for the C API. It also removes tests that end() panics when call twice, and that write() panics when called after read(), because they no longer compile:

error[E0382]: borrow of moved value: `rewriter`
   --> src/rewriter/mod.rs:610:13
    |
607 |             let mut rewriter = create_rewriter(512, |_: &[u8]| {});
    |                 ------------ move occurs because `rewriter` has type `rewriter::HtmlRewriter<'_, [closure@src/rewriter/mod.rs:607:53: 607:66]>`, which does not implement the `Copy` trait
608 |
609 |             rewriter.end().unwrap();
    |                      ----- `rewriter` moved due to this method call
610 |             rewriter.write(b"foo").unwrap();
    |             ^^^^^^^^ value borrowed here after move

error[E0382]: use of moved value: `rewriter`
   --> src/rewriter/mod.rs:619:13
    |
616 |             let mut rewriter = create_rewriter(512, |_: &[u8]| {});
    |                 ------------ move occurs because `rewriter` has type `rewriter::HtmlRewriter<'_, [closure@src/rewriter/mod.rs:616:53: 616:66]>`, which does not implement the `Copy` trait
617 |
618 |             rewriter.end().unwrap();
    |                      ----- `rewriter` moved due to this method call
619 |             rewriter.end().unwrap();
    |             ^^^^^^^^ value used here after move

As a small performance benefit, finished can be removed, making the rewriter take up slightly less memory.

Closes https://github.com/cloudflare/lol-html/issues/59. I didn't run the Rust tests because of https://github.com/rustation/pre-commit/issues/2, but the C tests all pass.

This is a breaking change.