Never regard macro rules with compile_error! invocations as unused
The very point of compile_error! is to never be reached, and one of
the use cases of the macro, currently also listed as examples in the
documentation of compile_error, is to create nicer errors for wrong
macro invocations. Thus, we should never warn about unused macro arms
that contain invocations of compile_error.
See also https://github.com/rust-lang/rust/pull/96150#issuecomment-1126599107 and the discussion after that.
Furthermore, the PR also contains two commits to silence `unused_macro_rules` when a macro has an invalid rule, and to add a test that `unused_macros` does not behave badly in the same situation.
r? `@petrochenkov` as I've talked to them about this
Update #[doc(html_playground_url)] documentation to mention what the request will be
The [documentation for `#![doc(html_playground_url = "_")]`](https://doc.rust-lang.org/rustdoc/write-documentation/the-doc-attribute.html#html_playground_url) specifies that a request will be made to the given URL but does specify what the contents of the request will be. This PR updates the documentation to include the query parameters through which the code is provided to the playground.
Mention `infer::Trace` methods on `infer::At` methods' docs
I missed that you could do `infcx.at(...).trace(...).eq(a, b)` when `a` and `b` dont implement `ToTrace` but does implement `Relate` these docs would have helped see that 😅
Revert part of #94372 to improve performance
#94732 was supposed to give small but widespread performance improvements, as judged from three per-merge performance runs. But the performance run that occurred after merging included a roughly equal number of improvements and regressions, for unclear reasons.
This PR is for a test run reverting those changes, to see what happens.
r? `@ghost`
cleanup bound variable handling
each commit should be pretty self-contained and hopefully straightforward to review.
I've added 677ec23a8dbf8ff5f1c03ccebd46f8b85e5ec1fc so that we can stop returning the region map from `replace_bound_vars_with_fresh_vars` in the following commit.
r? `@nikomatsakis` or `@jackh726`
Rollup of 6 pull requests
Successful merges:
- #93331 (refactor write_output_file to merge two invocation paths into one.)
- #97928 (Removes debug settings from wasm32_unknown_emscripten default link args)
- #97940 (Use relative links instead of linking to doc.rust-lang.org when possible)
- #97941 (nit: Fixed several error_codes/Exxxx.md messages which used UpperCamelCase…)
- #97953 (Add regression test for #54378)
- #97957 (Make `std::` prefix suggestion test `run-rustfix`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Removes debug settings from wasm32_unknown_emscripten default link args
This is a debug setting. We should only make debug builds if user requests
a debug build. Currently this is inserted in release builds.
Furthermore, it would be better to insert these settings in --pre-link-args
because then it would be possible to override them if appropriate. Because
these are inserted at the end, it is necessary to patch emscripten to remove
them.
``@sbc100``
Use `fcntl(fd, F_GETFD)` to detect if standard streams are open
In the previous implementation, if the standard streams were open,
but the RLIMIT_NOFILE value was below three, the poll would fail
with EINVAL:
> ERRORS: EINVAL The nfds value exceeds the RLIMIT_NOFILE value.
Switch to the existing fcntl based implementation to avoid the issue.
Fixes#96621.
Rollup of 6 pull requests
Successful merges:
- #97718 (Fix `delayed_good_path_bug` ice for expected diagnostics (RFC 2383))
- #97876 (update docs for `std::future::IntoFuture`)
- #97888 (Don't use __gxx_personality_v0 in panic_unwind on emscripten target)
- #97922 (Remove redundant calls to reserve in impl Write for VecDeque)
- #97927 (Do not introduce bindings for types and consts in HRTB.)
- #97937 (Fix a typo in `test/ui/hrtb/hrtb-just-for-static.rs`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Don't use __gxx_personality_v0 in panic_unwind on emscripten target
This resolves#85821. See also the discussion here:
https://github.com/emscripten-core/emscripten/issues/17128
The consensus seems to be that rust_eh_personality is never invoked.
I patched __gxx_personality_v0 to log invocations and then ran
various panic tests and it was never called, so this analysis matches
what seems to happen in practice. This replaces the definition with
an abort, modeled on the structured exception handling implementation.
update docs for `std::future::IntoFuture`
Ref https://github.com/rust-lang/rust/issues/67644.
This updates the docs for `IntoFuture` providing a bit more guidance on how to use it. Thanks!
Fix `delayed_good_path_bug` ice for expected diagnostics (RFC 2383)
Fixes a small ICE with the `delayed_good_path_bug` check.
---
r? ``@wesleywiser``
cc: ``@eddyb`` this might be interesting, since you've added a `FIXME` comment above the modified check which kind of discusses a case like this
closes: https://github.com/rust-lang/rust/issues/95540
cc: https://github.com/rust-lang/rust/issues/85549
std::io: Modify some ReadBuf method signatures to return `&mut Self`
This allows using `ReadBuf` in a builder-like style and to setup a `ReadBuf` and
pass it to `read_buf` in a single expression, e.g.,
```
// With this PR:
reader.read_buf(ReadBuf::uninit(buf).assume_init(init_len))?;
// Previously:
let mut buf = ReadBuf::uninit(buf);
buf.assume_init(init_len);
reader.read_buf(&mut buf)?;
```
r? `@sfackler`
cc https://github.com/rust-lang/rust/issues/78485, https://github.com/rust-lang/rust/issues/94741
Add the Provider api to core::any
This is an implementation of [RFC 3192](https://github.com/rust-lang/rfcs/pull/3192) ~~(which is yet to be merged, thus why this is a draft PR)~~. It adds an API for type-driven requests and provision of data from trait objects. A primary use case is for the `Error` trait, though that is not implemented in this PR. The only major difference to the RFC is that the functionality is added to the `any` module, rather than being in a sibling `provide_any` module (as discussed in the RFC thread).
~~Still todo: improve documentation on items, including adding examples.~~
cc `@yaahc`
