In the code, test, and docs, because it makes it much easier to find
things.
Other than adding the comments about alphabetical order, this commit
only moves things around.
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
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.
r? @Manishearth
attn: @yaahc @euclio
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).
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.
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.
This is a continuation of #70857
r? @dtolnay
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.
Closes#38376.
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)
## rls
1 commits in 2659cbf14bfb0929a16d7ce9b6858d0bb286ede7..7de2a1f299f8744ffe109139f9f1fdf28bfec909
2020-04-14 22:07:24 +0200 to 2020-04-19 22:41:55 +0000
- Update cargo (rust-lang-nursery/rls#1663)
attempt to recover perf by removing `exports_all_green`
attempt to recover perf by removing `exports_all_green` flag.
cc #71248
(My hypothesis is that my use of this flag was an overly conservative generalization of PR #67020.)
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)
Failed merges:
r? @ghost
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.
Check that main/start is not async
* Add new error code E0752
* Add span to hir::IsAsync::Yes
* Emit an error if main or the start function is marked as async
* Add two regression tests
This PR fixes#68523.
Stabilize most common subset of alloc_layout_extras
Tracking issue: https://github.com/rust-lang/rust/issues/55724
Specifically, this stabilizes:
```rust
pub fn Layout::align_to(&self, align: usize) -> Result<Layout, LayoutErr>;
pub fn Layout::pad_to_align(&self) -> Layout;
pub fn Layout::extend(&self, next: Layout) -> Result<(Layout, usize), LayoutErr>;
pub fn Layout::array<T>(n: usize) -> Result<Layout, LayoutErr>;
```
Methods that are tracked by #55724 but are not stabilized here:
```rust
pub fn Layout::padding_needed_for(&self, align: usize) -> usize;
pub fn Layout::repeat(&self, n: usize) -> Result<(Layout, usize), LayoutErr>;
pub fn Layout::repeat_packed(&self, n: usize) -> Result<Layout, LayoutErr>;
pub fn Layout::extend_packed(&self, next: Layout) -> Result<Layout, LayoutErr>;
```
Combined, these stabilized functions allow code to construct and manipulate `repr(C)` layouts while letting the standard library handle correctness in the face of edge cases. For example use cases, consider the usage in [hashbrown](https://github.com/Amanieu/hashbrown/blob/2f2af1d/src/raw/mod.rs#L143), [crossbeam-skiplist](https://github.com/crossbeam-rs/crossbeam-skiplist/blob/master/src/base.rs#L99), [pointer-utils/slice-dst](92aeefeed9/crates/slice-dst/src/layout_polyfill.rs), and of course the standard library itself.
Providing a higher-level API such as `Layout::repr_c<const N: usize>(fields: [Layout; N]) -> Result<(Layout, [usize; N]), LayoutErr>` is blocked on const generics, which are a ways off. Providing an API that doesn't provide offsets would be quite suboptimal, as the reason for calculating the layout like this rather than `Layout::new` is to get the field offsets.
The primary issue with the current API is having to call `.pad_to_align()` to match the layout of a `repr(C)` struct. However, I think this is not just a (failing? limitation?) of the API, but rather intrinsic complexity. While all Rust-defined types have size==stride, and probably will for the foreseeable future, there is no inherent reason why this is a limitation of all allocations. As such, the `Layout` manipulation APIs shouldn't impose this limitation, and instead the higher level api of `repr_c` (or just plain old using `Layout::new`) can make keeping it simple.
cc @matklad r? @rust-lang/libs
