When encountering a unit or tuple pattern for a struct-like item, suggest
using the correct pattern.
Use `insert_field_names_local` when evaluating variants and store field
names even when the list is empty in order to produce accurate
structured suggestions.
Auto merge of #74330 - Manishearth:rollup-mrc09pb, r=Manishearth
Rollup of 15 pull requests
Successful merges:
- #71237 (Add Ayu theme to rustdoc)
- #73720 (Clean up E0704 error explanation)
- #73866 (Obviate #[allow(improper_ctypes_definitions)])
- #73965 (typeck: check for infer before type impls trait)
- #73986 (add (unchecked) indexing methods to raw (and NonNull) slices)
- #74173 (Detect tuple struct incorrectly used as struct pat)
- #74220 (Refactor Windows `parse_prefix`)
- #74227 (Remove an unwrap in layout computation)
- #74239 (Update llvm-project to latest origin/rustc/10.0-2020-05-05 commit )
- #74257 (don't mark linux kernel module targets as a unix environment)
- #74270 (typeck: report placeholder type error w/out span)
- #74296 (Clarify the description for rfind)
- #74310 (Use `ArrayVec` in `SparseBitSet`.)
- #74316 (Remove unnecessary type hints from Wake internals)
- #74324 (Update Clippy)
Rollup merge of #74324 - flip1995:clippyup, r=Manishearth
Update Clippy
~~I'm not sure, if we can/should land this before beta is branched.~~ (Nvm, beta is already branched) The last Clippy update was 3 weeks ago: #73660
This includes, besides other minor things:
- New lints
- One lint deprecation
- One lint was moved to pedantic
- Some FP fixes
- I think an ICE fix?
cc @Mark-Simulacrum
r? @Manishearth
---
We probably should also think of some process when and how often we should sync Clippy to the rust repo, so that we don't end up with those huge updates. Maybe every 2 weeks? Or even every week? cc @rust-lang/clippy
Rollup merge of #74316 - yoshuawuyts:no-wake-type-hints, r=Mark-Simulacrum
Remove unnecessary type hints from Wake internals
While working on https://github.com/rust-lang/rust/pull/74304 I noticed we were writing out the type signature twice in some internal `Wake` impl methods; this streamlines that. Thanks!
Rollup merge of #74270 - davidtwco:issue-74086-more-placeholder-type-error, r=estebank
typeck: report placeholder type error w/out span
Fixes #74086.
This PR fixes a regression introduced in rust-lang/rust#70369 which meant that an error was not being emitted for invalid placeholder types when there wasn't a span available.
Rollup merge of #73986 - RalfJung:raw-slice-as-ptr, r=sfackler
add (unchecked) indexing methods to raw (and NonNull) slices
This complements the existing (unstable) `len` method. Unfortunately, for non-null slices, we cannot call this method `as_ptr` as that overlaps with the existing method of the same name.
If this looks reasonable to accept, I propose to reuse the https://github.com/rust-lang/rust/issues/71146 tracking issue and rename the feature get to `slice_ptr_methods` or so.
Cc @SimonSapin
Fixes https://github.com/rust-lang/rust/issues/60639
Rollup merge of #73965 - davidtwco:issue-73886-non-primitive-slice-cast, r=estebank
typeck: check for infer before type impls trait
Fixes #73886.
This PR checks that the target type of the cast (an error related to which is being reported) does not have types to be inferred before checking if it implements the `From` trait.
Rollup merge of #73866 - Goirad:fix-entry-improper-ctypes, r=davidtwco
Obviate #[allow(improper_ctypes_definitions)]
Modifies the return type for `fn entry` so that allowing
improper_ctypes_definitions is no longer necessary. This change is
derived from a similar pattern in `libstd/sys/sgx/abi/usercalls/raw.rs`
with `UsercallReturn`.
Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme, r=GuilliaumeGomez
Add Ayu theme to rustdoc
This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments.
Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook).
Note that this pull request also makes some small code changes to allow for disabling theme stylesheets, preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.
Rollup merge of #74147 - dennis-hamester:fix/issue-74134, r=jyn514
rustdoc: Allow linking from private items to private types
Fixes #74134
After PR #72771 this would trigger an intra_doc_link_resolution_failure warning
when rustdoc is invoked without --document-private-items. Links from private
items to private types are however never actually generated in that case and
thus shouldn't produce a warning. These links are in fact a very useful tool to
document crate internals.
Tests are added for all 4 combinations of public/private items and link
targets. Test 1 is the case mentioned above and fails without this commit. Tests
2 - 4 passed before already but are added nonetheless to prevent regressions.
Rollup merge of #74046 - ehuss:deny-warnings-caching, r=Mark-Simulacrum
Fix caching issue when building tools.
This fixes a problem with tool builds not being cached properly.
#73297 changed it so that Clippy will participate in the "deny warnings" setting. Unfortunately this causes a problem because Clippy shares the build directory with other tools which do not participate in "deny warnings". Because Cargo does not independently cache artifacts based on different RUSTFLAGS settings, it causes all the shared dependencies to get rebuilt if Clippy ever gets built.
The solution here is to stop using RUSTFLAGS, and just sneak the settings in through the rustc wrapper. Cargo won't know about the different settings, so it will not bust the cache. This should be safe since lint settings on dependencies are ignored. This is how things used to work in the past before #64316.
Alternate solutions:
* Treat Clippy as a "submodule" and don't enforce warnings on it. This was the behavior before #73297. The consequence is that if a warning sneaks into clippy, that the clippy maintainers will need to fix it when they sync clippy back to the clippy repo.
* Just deny warnings on all tools (removing the in-tree/submodule distinction). This is tempting, but with some issues (cc #52336):
* Adding or changing warnings in rustc can be difficult to land because tools have to be updated if they trip the warning. In practice, this isn't too bad. Cargo (and rustfmt) already runs with `deny(warnings)`, so this has been the de-facto standard already (although they do not use the extra lints like `unused_lifetimes`).
* Teach Cargo to add flags to the workspace members, but not dependencies.
* Teach Cargo to add flags without fingerprinting them?
* Teach Cargo to independently cache different RUSTFLAGS artifacts (this was [reverted](https://github.com/rust-lang/cargo/pull/7417) due to complications). This would also unnecessarily rebuild dependencies, but would avoid cache thrashing.
* Teach Cargo about lint settings.
Auto merge of #5792 - flip1995:rollup-torc1we, r=flip1995
Rollup of 5 pull requests
Successful merges:
- #5443 (Some accuracy lints for floating point operations)
- #5752 (Move range_minus_one to pedantic)
- #5756 (unnecessary_sort_by: avoid linting if key borrows)
- #5784 (Fix out of bounds access by checking length equality BEFORE accessing by index.)
- #5786 (fix phrase in new_lint issue template)
Philipp Krones [Mon, 13 Jul 2020 13:59:42 +0000 (15:59 +0200)]
Rollup merge of #5752 - chrisduerr:pedantic_ranges, r=flip1995
Move range_minus_one to pedantic
This moves the range_minus_one lint to the pedantic category, so there
will not be any warnings emitted by default. This should work around
problems where the suggestion is impossible to resolve due to the range
consumer only accepting a specific range implementation, rather than the
`RangeBounds` trait (see #3307).
While it is possible to work around this by extracting the boundary into
a variable, I don't think clippy should encourage people to disable or
work around lints, but instead the lints should be fixable. So hopefully
this will help until a proper implementation checks what the range is
used for.
*Please keep the line below*
changelog: move [`range_minus_one`] to pedantic
When running a command like `DESTDIR=foo x.py install` in a completely
clean build directory, this will cause LLVM to be installed into
`DESTDIR`, which then causes the build to fail later when it attempts
to *use* those LLVM files.
David Wood [Sun, 12 Jul 2020 15:40:22 +0000 (16:40 +0100)]
typeck: report placeholder type error w/out span
This commit fixes a regression introduced in rust-lang/rust#70369 which
meant that an error was not being emitted for invalid placeholder types
when there wasn't a span available.
Auto merge of #74245 - Manishearth:rollup-r0xq9dn, r=Manishearth
Rollup of 10 pull requests
Successful merges:
- #72920 (Stabilize `transmute` in constants and statics but not const fn)
- #73715 (debuginfo: Mangle tuples to be natvis friendly, typedef basic types)
- #74066 (Optimize is_ascii for str and [u8].)
- #74116 (Fix cross compilation of LLVM to aarch64 Windows targets)
- #74167 (linker: illumos ld does not support --eh-frame-hdr)
- #74168 (Add a help to use `in_band_lifetimes` in nightly)
- #74197 (Reword incorrect `self` token suggestion)
- #74213 (Minor refactor for rustc_resolve diagnostics match)
- #74240 (Fix #74081 and add the test case from #74236)
- #74241 (update miri)
Rollup merge of #74241 - RalfJung:miri, r=RalfJung
update miri
This incorporates https://github.com/rust-lang/miri/pull/1474. [Last time](https://github.com/rust-lang/rust/pull/74146) that change caused trouble but I fixed xargo since then and [now it should work](https://github.com/rust-lang/rust/pull/74146#issuecomment-657051446).
Rollup merge of #74167 - jclulow:illumos-linker-eh-frame-hdr-fix, r=petrochenkov
linker: illumos ld does not support --eh-frame-hdr
As of rust-lang/rust#73564, the --eh-frame-hdr flag is unconditionally
passed to linkers on many platforms. The illumos link editor does not
currently support this flag.
The linker machinery in the Rust toolchain currently seems to use the
(potentially cross-compiled) target to choose linker flags, rather than
looking at what might be running on the build system. Disabling the
flag for all illumos/Solaris targets seems like the best we can do for
now without more serious surgery.
Rollup merge of #74116 - arlosi:aarch64build, r=pietroalbini
Fix cross compilation of LLVM to aarch64 Windows targets
When cross-compiling, the LLVM build system recurses to build tools that need to run on the host system. However, since we pass cmake defines to set the compiler and target, LLVM still compiles these tools for the target system, rather than the host. The tools then fail to execute during the LLVM build.
This change sets defines for the tools that need to run on the host (llvm-nm, llvm-tablegen, and llvm-config), so that the LLVM build does not attempt to build them, and instead relies on the tools already built.
If compiling with clang-cl, adds the `--target` option to specify the target triple. MSVC compilers do not require this, since there is a separate compiler binary for each cross-compilation target.
Related issue: #72881
Requires LLVM change: rust-lang/llvm-project#67
(Taken on a x86_64 macbook 2.9 GHz Intel Core i9 with 6 cores)
Where `is_ascii_slice_iter_all` is the old version, and `is_ascii_slice_libcore` is the new.
I tried to document the code well, so hopefully it's understandable. It has fairly exhaustive tests ensuring size/align doesn't get violated -- because `miri` doesn't really help a lot for this sort of code right now, I tried to `debug_assert` all the safety invariants I'm depending on. (Of course, none of them are required for correctness or soundness -- just allows us to test that this sort of pointer manipulation is sound and such).
Anyway, thanks. Let me know if you have questions/desired changes.
Rollup merge of #73715 - MaulingMonkey:pr-natvis-tuples, r=Amanieu
debuginfo: Mangle tuples to be natvis friendly, typedef basic types
These changes are meant to unblock rust-lang/rust#70052 "Update hashbrown to 0.8.0" by allowing the use of `tuple<u64, u64>` as a .natvis expression in MSVC style debuggers (MSVC, WinDbg, CDB, etc.)
* f8eb81b does the actual mangling of `(u64, u64)` -> `tuple<u64, 64>`
* 24a728a allows `u64` to resolve (fixing `$T1` / `$T2` when used to visualize `HashMap<u64, u64, ...>`)
projects / rust.git / log