Rollup merge of #71396 - DeeDeeG:improve-e0308-again, r=estebank
Improve E0308 error message wording again
Hello again,
I recently did this PR: #70242
I felt the error message could be further improved, so I made [a post on the Rust community forum](https://users.rust-lang.org/t/looking-for-feedback-on-an-improved-error-message-for-e0308/40004) to ask for feedback.
(Also, there were some comments on my original PR that I took into consideration as well.)
This PR is my attempt to take all the feedback into account and propose a better and simplified error message that should still be accurate. Its main benefit is having simpler grammar, and hopefully being easier to read and understand.
Thanks to everyone who commented and gave feedback, and thank you for taking a look at this PR.
Rollup merge of #71005 - jonas-schievink:no-place-like-return, r=oli-obk
Reading from the return place is fine
Const eval thinks that reading from local `_0` is UB, but it isn't. `_0` is just a normal local like any other, and codegen handles it that way too. The only special thing is that the `Return` terminator will read from it.
I've hit these errors while working on an NRVO pass that can merge other locals with `_0` in https://github.com/rust-lang/rust/pull/71003.
Rollup merge of #71400 - dtolnay:isavailable, r=petrochenkov
proc_macro::is_available()
This PR adds `proc_macro::is_available() -> bool` to determine whether proc_macro has been made accessible to the currently running program.
The proc_macro crate is only intended for use inside the implementation of procedural macros. All the functions in the crate panic if invoked from outside of a procedural macro, such as from a build script or unit test or ordinary Rust binary.
Unfortunately those panics made it impossible for libraries that are designed to support both macro and non-macro use cases (e.g. Syn) to be used from binaries that are compiled with panic=abort. In panic=unwind mode we're able to attempt a proc macro call inside catch_unwind and use libproc_macro's result if it succeeds, otherwise fall back to a non-macro alternative implementation. But in panic=abort there was no way to determine which implementation needs to be used.
Rollup merge of #71369 - ctaggart:wasm32_profiling, r=ecstatic-morse
allow wasm32 compilation of librustc_data_structures/profiling.rs
I'm trying to use rustfmt from a wasm app. I ran into this compilation problem https://github.com/rust-lang/rustfmt/issues/4132 and after investigating, it looked like just adjusting a few cfg's. I based it on how measureme added support in https://github.com/rust-lang/measureme/pull/43.
My testing on my macbook was just that librustc_data_structures builds now with both:
- cargo build
- cargo build --target wasm32-unknown-unknown
Rollup merge of #71256 - cuviper:must_use_replace, r=estebank
Lint must_use on mem::replace
This adds a hint on `mem::replace`, "if you don't need the old value,
you can just assign the new value directly". This is in similar spirit
to the `must_use` on `ManuallyDrop::take`.
Auto merge of #71044 - ecstatic-morse:body-predecessor-cache, r=oli-obk
Remove `BodyAndCache`
...returning to the original approach using interior mutability within `Body`. This simplifies the API at the cost of some uncontended mutex locks when the parallel compiler is enabled.
The current API requires you to either have a mutable reference to `Body` (`&mut BodyAndCache`), or to compute the predecessor graph ahead of time by creating a `ReadOnlyBodyAndCache`. This is not a good fit for, e.g., the dataflow framework, which
1. does not mutate the MIR
2. only sometimes needs the predecessor graph (for backward dataflow problems)
Auto merge of #71431 - Dylan-DPC:rollup-rvm6tfy, r=Dylan-DPC
Rollup of 4 pull requests
Successful merges:
- #71280 (Miri: mplace_access_checked: offer option to force different alignment on place)
- #71336 (Exhaustively match on `{Statement,Terminator}Kind` during const checking)
- #71370 (Added detailed error code explanation for issue E0696 in Rust compiler.)
- #71401 (visit_place_base is just visit_local)
Rollup merge of #71414 - phansch:more-diagnostic-items, r=Manishearth
More diagnostic items for Clippy usage
This adds a couple of more diagnostic items to be used in Clippy.
I chose these particular ones because they were the types which we seem
to check for the most in Clippy. I'm not sure if the `cfg_attr(not(test))`
is needed, but it was also used for `Vec` and a few other types.
cc https://github.com/rust-lang/rust-clippy/issues/5393
Rollup merge of #71412 - dtolnay:uselessdoc, r=Manishearth
Clarify unused_doc_comments note on macro invocations
The previous error message used to say:
<pre>
/// doc
^^^^^^^ rustdoc does not generate documentation for <b>macros</b>
</pre>
Obviously we do generate documentation for macros, such as https://docs.rs/bitflags/1.2.1/bitflags/macro.bitflags.html. It's only macro invocations that don't get their own docs. This PR updates the message to say "rustdoc does not generate documentation for <b>macro invocations</b>".
I observe that prior to #69084 this used to say "rustdoc does not generate documentation for **macro expansions**", as implemented originally in #57882. I don't have a preference between those but I made the commit before looking up the history.
Rollup merge of #70970 - eddyb:trait-vs-impl-mismatch, r=oli-obk
Detect mistyped associated consts in `Instance::resolve`.
*Based on #71049 to prevent redundant/misleading downstream errors.*
Fixes #70942 by refusing to resolve an associated `const` if it doesn't have the same type in the `impl` that it does in the `trait` (which we assume had errored, and `delay_span_bug` guards against bugs).
Philipp Hansch [Wed, 22 Apr 2020 05:47:31 +0000 (07:47 +0200)]
More diagnostic items for Clippy usage
This adds a couple of more diagnostic items to be used in Clippy.
I chose these particular ones because they were the types which we seem
to check for the most in Clippy. I'm not sure if the
`cfg_attr(not(test))` is needed, but it was also used for `Vec` and a
few other types.
Rollup merge of #71366 - faern:use-assoc-int-consts3, r=dtolnay
Use assoc int consts3
Define module level int consts with associated constants instead of `min_value()` and `max_value()`. So the code become consistent with what the docs recommend etc. Seems natural.
Also remove the last usages of the int module constants from this repo (except src/test/ directory which I have still not really done anything in). Some places were missed in the previous PRs because the code uses `crate::<IntTy>` to reach the constants.
Rollup merge of #70998 - estebank:suggest-impl-trait-empty-fn, r=varkor
Suggest `-> impl Trait` and `-> Box<dyn Trait>` on fn that doesn't return
During development, a function could have a return type set that is a
bare trait object by accident. We already suggest using either a boxed
trait object or `impl Trait` if the return paths will allow it. We now
do so too when there are *no* return paths or they all resolve to `!`.
We still don't handle cases where the trait object is *not* the entirety
of the return type gracefully.
Auto merge of #71402 - ehuss:update-cargo, r=ehuss
Update cargo, rls
## cargo
17 commits in ebda5065ee8a1e46801380abcbac21a25bc7e755..8751eb3010d4cdb5329b5a6bd2b6d765c95b0dca
2020-04-16 14:28:43 +0000 to 2020-04-21 18:04:35 +0000
- Uplift windows gnu DLL import libraries. (rust-lang/cargo#8141)
- Add windows-gnu CI and fix tests (rust-lang/cargo#8139)
- Several updates to token/index handling. (rust-lang/cargo#7973)
- Add `resolver` opt-in for new feature resolver. (rust-lang/cargo#8129)
- Improve error message when running `cargo install .` (rust-lang/cargo#8137)
- fix mem replace unused (rust-lang/cargo#8138)
- Change `-Cembed-bitcode=no` use to `-Cbitcode-in-rlib=no`. (rust-lang/cargo#8134)
- Refactor BuildContext (rust-lang/cargo#8068)
- Rename allows_underscores to allows_dashes. (rust-lang/cargo#8135)
- Fixed a needless borrow. (rust-lang/cargo#8130)
- Add link to changelog in the Cargo book. (rust-lang/cargo#8126)
- Fix target for doc test cross compilation (rust-lang/cargo#8094)
- Add note about .cargo/config support. (rust-lang/cargo#8125)
- Fix pdb uplift when executable has dashes. (rust-lang/cargo#8123)
- Hint upgrading for future edition keys (rust-lang/cargo#8122)
- Use some fs shorthand functions. (rust-lang/cargo#8124)
- Update documentation to mention "config.toml" instead of "config" (rust-lang/cargo#8121)
Auto merge of #71367 - Dylan-DPC:rollup-ysj4olr, r=Dylan-DPC
Rollup of 4 pull requests
Successful merges:
- #69362 (Stabilize most common subset of alloc_layout_extras)
- #71174 (Check that main/start is not async)
- #71285 (MIR: use HirId instead of NodeId to avoid cycles while inlining)
- #71346 (Do not build tools if user do not want them)
Rollup merge of #71285 - ljedrz:mir_inline_span_for_optimized_mir, r=ecstatic-morse
MIR: use HirId instead of NodeId to avoid cycles while inlining
I wanted to see if I could limit the number of uses of `NodeId` when `HirId` is available and I saw that some of the MIR `Inliner` code could use `Span` instead of `NodeId`, not unlike in https://github.com/rust-lang/rust/pull/71197.
~If I'm understanding the reason for not calling `optimized_mir` in incremental builds here correctly, this change could also allow us to do so.~
This change could affect performance, so if this approach makes sense, a perf run is probably a good idea.
projects / rust.git / log