bors [Sat, 10 Oct 2020 06:59:49 +0000 (06:59 +0000)]
Auto merge of #77336 - pietroalbini:pkgname, r=Mark-Simulacrum
Always use the Rust version in package names
The format of the tarballs produced by CI is roughly the following:
{component}-{release}-{target}.{ext}
While on the beta and nightly channels `{release}` is just the channel name, on the stable channel is either the Rust version or the version of the component we're shipping:
This makes it really hard to get the package URL without having access to the manifest (and there is no manifest on ci-artifacts.rlo), as there is no consistent version number to use.
This PR addresses the problem by always using the Rust version number as `{release}` for the stable channel, regardless of the version number of the component we're shipping. I chose that instead of "stable" to avoid breaking the URL scheme *that* much.
Rustup should not be affected by this change, as it fetches the URLs from the manifest. Unfortunately we don't have a way to test other clients before making a stable release, as this change only affects the stable channel.
bors [Fri, 9 Oct 2020 21:01:51 +0000 (21:01 +0000)]
Auto merge of #77276 - GuillaumeGomez:reexported-item-lints, r=jyn514,ollie27
Warn on broken intra-doc links added to cross-crate re-exports
This emits `broken_intra_doc_links` for docs applied to pub use statements that point to external items and are inlined.
Does not address #77200 - any existing broken links from the original crate will not show warnings.
bors [Fri, 9 Oct 2020 19:06:45 +0000 (19:06 +0000)]
Auto merge of #77674 - cuviper:direntry-diet, r=dtolnay
unix/vxworks: make DirEntry slightly smaller
`DirEntry` contains a `ReadDir` handle, which used to just be a wrapper
on `Arc<InnerReadDir>`. Commit af75314ecdbc5 added `end_of_stream: bool`
which is not needed by `DirEntry`, but adds 8 bytes after padding. We
can let `DirEntry` have an `Arc<InnerReadDir>` directly to avoid that.
Josh Stone [Wed, 7 Oct 2020 21:35:51 +0000 (14:35 -0700)]
unix/vxworks: make DirEntry slightly smaller
`DirEntry` contains a `ReadDir` handle, which used to just be a wrapper
on `Arc<InnerReadDir>`. Commit af75314ecdbc5 added `end_of_stream: bool`
which is not needed by `DirEntry`, but adds 8 bytes after padding. We
can let `DirEntry` have an `Arc<InnerReadDir>` directly to avoid that.
Pietro Albini [Tue, 29 Sep 2020 13:33:25 +0000 (15:33 +0200)]
bootstrap: always use the Rust version in package names
The format of the tarballs produced by CI is roughly the following:
{component}-{release}-{target}.{ext}
While on the beta and nightly channels `{release}` is just the channel
name, on the stable channel is either the Rust version or the version of
the component we're shipping:
This makes it really hard to get the package URL without having access
to the manifest (and there is no manifest on ci-artifacts.rlo), as there
is no consistent version number to use.
This commit addresses the problem by always using the Rust version
number as `{release}` for the stable channel, regardless of the version
number of the component we're shipping. I chose that instead of "stable"
to avoid breaking the URL scheme *that* much.
Rustup should not be affected by this change, as it fetches the URLs
from the manifest. Unfortunately we don't have a way to test other
clients before making a stable release, as this change only affects the
stable channel.
I've not added the PRs fixing `same_item_push` because those were backported, namely:
* [#5908](https://github.com/rust-lang/rust-clippy/pull/5908)
* [#5997](https://github.com/rust-lang/rust-clippy/pull/5997)
* [#6016](https://github.com/rust-lang/rust-clippy/pull/6016)
The following PR was reverted, so I've ignored it too:
* [#5984](https://github.com/rust-lang/rust-clippy/pull/5984)
~~Also, I took the liberty of adding a "Thanks" section, naming all the contributors to this release. I think they deserve visibility in the changelog. Please tell me if we want to add this or maybe it's redundant given we link to the PRs?~~
- Preserve the parent module of `DocFragment`s
+ Add `parent_module` to `DocFragment`
+ Require the `parent_module` of the item being inlined
+ Preserve the hir_id for ExternCrates so rustdoc can find the parent module later
+ Take an optional `parent_module` for `build_impl` and `merge_attrs`.
Preserve the difference between parent modules for each doc-comment.
+ Support a single additional re-exports in from_ast. Originally this took a vec but I ended up not using it.
+ Don't require the parent_module for all `impl`s, just inlined items
In particular, this will be `None` whenever the attribute is not on a
re-export.
+ Only store the parent_module, not the HirId
When re-exporting a re-export, the HirId is not available. Fortunately,
`collect_intra_doc_links` doesn't actually need all the info from a
HirId, just the parent module.
- Introduce `Divider`
This distinguishes between documentation on the original from docs on the re-export.
- Use the new module information for intra-doc links
+ Make the parent module conditional on whether the docs are on a re-export
+ Make `resolve_link` take `&Item` instead of `&mut Item`
Previously the borrow checker gave an error about multiple mutable
borrows, because `dox` borrowed from `item`.
+ Fix `crate::` for re-exports
`crate` means something different depending on where the attribute
came from.
+ Make it work for `#[doc]` attributes too
This required combining several attributes as one so they would keep
the links.
bors [Fri, 9 Oct 2020 00:29:47 +0000 (00:29 +0000)]
Auto merge of #76260 - xd009642:rfc/2867, r=jonas-schievink
Implementation of RFC2867
https://github.com/rust-lang/rust/issues/74727
So I've started work on this, I think my next steps are to make use of the `instruction_set` value in the llvm codegen but this is the point where I begin to get a bit lost. I'm looking at the code but it would be nice to have some guidance on what I've currently done and what I'm doing next :smile:
bors [Thu, 8 Oct 2020 22:50:29 +0000 (22:50 +0000)]
Auto merge of #6133 - JPTIZ:no-box-for-c-ffi, r=ebroto
clippy_lints: Do not warn against Box parameter in C FFI
changelog: [`boxed_local`]: don't lint in `extern fn` arguments
Fixes #5542.
When using C FFI, to handle pointers in parameters it is needed to
declare them as `Box` in its Rust-side signature. However, the current
linter warns against the usage of Box stating that "local variable
doesn't need to be boxed here".
This commit fixes it by ignoring functions whose Abi is C.
Tomasz Miąsko [Thu, 8 Oct 2020 00:00:00 +0000 (00:00 +0000)]
Check for non-zero return value from posix_spawn functions
The cvt function compares the argument with -1 and when equal returns a new
io::Error constructed from errno. It is used together posix_spawn_* functions.
This is incorrect. Those functions do not set errno. Instead they return
non-zero error code directly.
Check for non-zero return code and use it to construct a new io::Error.
bors [Thu, 8 Oct 2020 21:33:32 +0000 (21:33 +0000)]
Auto merge of #6117 - dtolnay:string_lit_as_bytes, r=ebroto
Downgrade string_lit_as_bytes to nursery
Between #1402 (regarding `to_owned`) and #4494 (regarding `impl Read`), as well as other confusion I've seen hit in my work codebase involving string_lit_as_bytes (`"...".as_bytes().into()`), I don't think this lint is at a quality to be enabled by default.
I would consider re-enabling this lint after it is updated to understand when the surrounding type information is sufficient to unsize `b"..."` to &\[u8\] without causing a type error.
As currently implemented, this lint is pushing people to write `&b"_"[..]` which is not an improvement over `"_".as_bytes()` as far as I am concerned.
---
changelog: Remove string_lit_as_bytes from default set of enabled lints
Jonas Schievink [Thu, 8 Oct 2020 21:23:19 +0000 (23:23 +0200)]
Rollup merge of #77710 - fortanix:raoul/bugfix-lvi, r=nikic
Update submodule llvm to get LVI bugfix
The LLVM LVI mitigations used register %rcs as a clobber register. This is problematic when rust uses this register to return (part of) function values. The problem was fixed upstream in:
Jonas Schievink [Thu, 8 Oct 2020 21:23:15 +0000 (23:23 +0200)]
Rollup merge of #77701 - jyn514:debug-logging, r=Mark-Simulacrum
Make `max_log_info` easily greppable (for figuring out why debug logging is disabled)
Follow-up to https://github.com/rust-lang/rust/pull/77678#issuecomment-705545608. I'll make a PR to the dev-guide shortly changing `debug = true` to `debug-logging = true` and using this text.
Ideally wouldn't be merged before https://github.com/rust-lang/rust/pull/77678, but it practice it won't hurt anything.
Jonas Schievink [Thu, 8 Oct 2020 21:23:12 +0000 (23:23 +0200)]
Rollup merge of #77663 - HeroicKatora:regression-tests-27675-object-safe, r=Aaron1011
Add compile fail test for issue 27675
A recently merged PR (#73905) strengthened the checks on bounds of associated items. This rejects the attack path of #27675 which consisted of constructing a `dyn Trait<Item=T>` where `T` would not fulfill the bounds required on `Item` of the `Trait` behind the dyn object.
This regression test, extracted from [the weaponized instance](https://github.com/rust-lang/rust/issues/27675#issuecomment-696956878), checks that this is rejected.
Jonas Schievink [Thu, 8 Oct 2020 21:23:10 +0000 (23:23 +0200)]
Rollup merge of #77660 - nilslice:patch-1, r=jyn514
(docs): make mutex error comment consistent with codebase
Although exceptionally minor, I found this stands out from other error reporting language used in doc comments. With the existence of the `failure` crate, I suppose this could be slightly ambiguous. In any case, this change brings the particular comment into a consistent state with other mentions of returning errors.
Jonas Schievink [Thu, 8 Oct 2020 21:23:08 +0000 (23:23 +0200)]
Rollup merge of #77449 - ssomers:btree_drain_filter_size_hint, r=Mark-Simulacrum
BTreeMap: comment why drain_filter's size_hint is somewhat pessimistic
The `size_hint` of the `DrainFilter` iterator doesn't adjust as you iterate. This hardly seems important to me, but there has been a comparable PR #64383 in the past. I guess a scenario is that you first iterate half the map manually and keep most of the key/value pairs in the map, and then tell the predicate to drain most of the key/value pairs and `.collect` the iterator over the remaining half of the map.
I am totally ambivalent whether this is better or not.
bors [Thu, 8 Oct 2020 16:56:14 +0000 (16:56 +0000)]
Auto merge of #6138 - giraffate:note_that_we_follow_rustc_no_merge_policy, r=Manishearth
Add note that we follow a rustc no merge-commit policy
I think it would be better to add a note that we follow a rustc no merge-commit policy. For example, it was mentioned at https://github.com/rust-lang/rust-clippy/pull/5694#issuecomment-641871096.
bors [Thu, 8 Oct 2020 13:38:29 +0000 (13:38 +0000)]
Auto merge of #77678 - jyn514:tracing, r=Mark-Simulacrum
Upgrade to tracing-subscriber 0.2.13
The primary motivation is to get the changes from
https://github.com/tokio-rs/tracing/pull/990. Example output:
```
$ RUSTDOC_LOG=debug rustdoc +rustc2
warning: some trace filter directives would enable traces that are disabled statically
| `debug` would enable the DEBUG level for all targets
= note: the static max level is `info`
= help: to enable DEBUG logging, remove the `max_level_info` feature
```
bors [Thu, 8 Oct 2020 11:42:24 +0000 (11:42 +0000)]
Auto merge of #77581 - ecstatic-morse:dataflow-dump-mir-graphviz, r=davidtwco
Use `pretty::create_dump_file` for dumping dataflow results
The old code wasn't incorporating promoteds into the path, meaning other `dot` files could get clobbered. Use the MIR dump infrastructure to generate paths so that this doesn't occur in the future.
Joshua Nelson [Sun, 4 Oct 2020 00:06:30 +0000 (20:06 -0400)]
Preserve the parent module of `DocFragment`s
- Add `parent_module` to `DocFragment`
- Require the `parent_module` of the item being inlined
- Preserve the hir_id for ExternCrates so rustdoc can find the parent module later
- Take an optional `parent_module` for `build_impl` and `merge_attrs`.
Preserve the difference between parent modules for each doc-comment.
- Support arbitrarily many re-exports in from_ast. In retrospect this is
probably not used and could be simplified to a single
`Option<(Attrs, DefId)>`.
- Don't require the parent_module for all `impl`s, just inlined items
In particular, this will be `None` whenever the attribute is not on a
re-export.
- Only store the parent_module, not the HirId
When re-exporting a re-export, the HirId is not available. Fortunately,
`collect_intra_doc_links` doesn't actually need all the info from a
HirId, just the parent module.
bors [Thu, 8 Oct 2020 03:58:55 +0000 (03:58 +0000)]
Auto merge of #77683 - jyn514:git-hook, r=Mark-Simulacrum
Unset GIT_DIR in pre-commit hook
Works around https://github.com/rust-lang/rust/issues/77620. This won't help any other hooks you write manually, but hopefully people won't feel the need to do that now there's an 'official' one.
bors [Thu, 8 Oct 2020 01:37:27 +0000 (01:37 +0000)]
Auto merge of #75470 - estebank:bare-type-expr, r=davidtwco
Detect blocks that could be struct expr bodies
This approach lives exclusively in the parser, so struct expr bodies
that are syntactically correct on their own but are otherwise incorrect
will still emit confusing errors, like in the following case:
```rust
fn foo() -> Foo {
bar: Vec::new()
}
```
```
error[E0425]: cannot find value `bar` in this scope
--> src/file.rs:5:5
|
5 | bar: Vec::new()
| ^^^ expecting a type here because of type ascription
error[E0214]: parenthesized type parameters may only be used with a `Fn` trait
--> src/file.rs:5:15
|
5 | bar: Vec::new()
| ^^^^^ only `Fn` traits may use parentheses
error[E0107]: wrong number of type arguments: expected 1, found 0
--> src/file.rs:5:10
|
5 | bar: Vec::new()
| ^^^^^^^^^^ expected 1 type argument
```
If that field had a trailing comma, that would be a parse error and it
would trigger the new, more targetted, error:
```
error: struct literal body without path
--> file.rs:4:17
|
4 | fn foo() -> Foo {
| _________________^
5 | | bar: Vec::new(),
6 | | }
| |_^
|
help: you might have forgotten to add the struct literal inside the block
|
4 | fn foo() -> Foo { Path {
5 | bar: Vec::new(),
6 | } }
|
```
clippy_lints: Do not warn against Box parameter in C FFI
Fixes #5542.
When using C FFI, to handle pointers in parameters it is needed to
declare them as `Box` in its Rust-side signature. However, the current
linter warns against the usage of Box stating that "local variable
doesn't need to be boxed here".
This commit fixes it by ignoring functions whose Abi is Cdecl.
Joshua Nelson [Wed, 7 Oct 2020 22:45:59 +0000 (18:45 -0400)]
Upgrade to tracing 0.2.13
The primary motivation is to get the changes from
https://github.com/tokio-rs/tracing/pull/990. Example output:
```
$ RUSTDOC_LOG=debug rustdoc +rustc2
warning: some trace filter directives would enable traces that are disabled statically
| `debug` would enable the DEBUG level for all targets
= note: the static max level is `info`
= help: to enable DEBUG logging, remove the `max_level_info` feature
```
- Remove useless test
This was testing for an ICE when passing `RUST_LOG=rustc_middle`. I
noticed it because it started giving the tracing warning (because tests
are not run with debug-logging enabled). Since this bug seems unlikely
to re-occur, I just removed it altogether.
bors [Wed, 7 Oct 2020 23:10:34 +0000 (23:10 +0000)]
Auto merge of #6128 - dtolnay:rc_buffer, r=yaahc
Downgrade rc_buffer to restriction
I think Arc\<Vec\<T\>\> and Arc\<String\> and similar are a totally reasonable data structure, as observed by others in the comments on [#6044](https://github.com/rust-lang/rust-clippy/pull/6044#event-3799579830) as well. Doing `Arc::make_mut(&mut self.vec).push(...)` or `Arc::make_mut(&mut self.string).push_str("...")` is a terrific and well performing copy-on-write pattern. Linting this with an enabled-by-default <kbd>performance</kbd> lint strikes me as an unacceptable false positive balance.
As of #6090 the documentation of this lint now contains:
> **Known problems:** This pattern can be desirable ...
which should indicate that we shouldn't be linting against correct, reasonable, well-performing patterns with an enabled-by-default lint.
Mentioning #6044, #6090.
r? `@yaahc,` who reviewed the lint.
---
changelog: Remove rc_buffer from default set of enabled lints
bors [Wed, 7 Oct 2020 21:51:12 +0000 (21:51 +0000)]
Auto merge of #76985 - hbina:clone_check, r=estebank
Prevent stack overflow in deeply nested types.
Related issue #75577 (?)
Unfortunately, I am unable to test whether this actually solves the problem because apparently, 12GB RAM + 2GB swap is not enough to compile the (admittedly toy) source file.
Esteban Küber [Wed, 12 Aug 2020 22:39:15 +0000 (15:39 -0700)]
Detect blocks that could be struct expr bodies
This approach lives exclusively in the parser, so struct expr bodies
that are syntactically correct on their own but are otherwise incorrect
will still emit confusing errors, like in the following case:
```rust
fn foo() -> Foo {
bar: Vec::new()
}
```
```
error[E0425]: cannot find value `bar` in this scope
--> src/file.rs:5:5
|
5 | bar: Vec::new()
| ^^^ expecting a type here because of type ascription
error[E0214]: parenthesized type parameters may only be used with a `Fn` trait
--> src/file.rs:5:15
|
5 | bar: Vec::new()
| ^^^^^ only `Fn` traits may use parentheses
error[E0107]: wrong number of type arguments: expected 1, found 0
--> src/file.rs:5:10
|
5 | bar: Vec::new()
| ^^^^^^^^^^ expected 1 type argument
```
If that field had a trailing comma, that would be a parse error and it
would trigger the new, more targetted, error:
```
error: struct literal body without path
--> file.rs:4:17
|
4 | fn foo() -> Foo {
| _________________^
5 | | bar: Vec::new(),
6 | | }
| |_^
|
help: you might have forgotten to add the struct literal inside the block
|
4 | fn foo() -> Foo { Path {
5 | bar: Vec::new(),
6 | } }
|
```
bors [Wed, 7 Oct 2020 19:59:52 +0000 (19:59 +0000)]
Auto merge of #77464 - ecstatic-morse:const-fn-impl-trait, r=oli-obk
Give `impl Trait` in a `const fn` its own feature gate
...previously it was gated under `#![feature(const_fn)]`.
I think we actually want to do this in all const-contexts? If so, this should be `#![feature(const_impl_trait)]` instead. I don't think there's any way to make use of `impl Trait` within a `const` initializer.
bors [Wed, 7 Oct 2020 17:31:56 +0000 (17:31 +0000)]
Auto merge of #77617 - AnthonyMikh:slice_windows_no_bounds_checking, r=lcnr
Eliminate bounds checking in slice::Windows
This is how `<core::slice::Windows as Iterator>::next` looks right now:
```rust
fn next(&mut self) -> Option<&'a [T]> {
if self.size > self.v.len() {
None
} else {
let ret = Some(&self.v[..self.size]);
self.v = &self.v[1..];
ret
}
}
```
The line with `self.v = &self.v[1..];` relies on assumption that `self.v` is definitely not empty at this point. Else branch is taken when `self.size <= self.v.len()`, so `self.v` can be empty if `self.size` is zero. In practice, since `Windows` is never created directly but rather trough `[T]::windows` which panics when `size` is zero, `self.size` is never zero. However, the compiler doesn't know about this check, so it keeps the code which checks bounds and panics.
Using `NonZeroUsize` lets the compiler know about this invariant and reliably eliminate bounds checking without `unsafe` on `-O2`. Here is assembly of `Windows<'a, u32>::next` before and after this change ([goldbolt](https://godbolt.org/z/xrefzx)):
bors [Wed, 7 Oct 2020 15:37:47 +0000 (15:37 +0000)]
Auto merge of #77341 - davidtwco:issue-73427-you-might-have-meant-variant, r=estebank
resolve: improve "try using the enum's variant"
Fixes #73427.
This PR improves the "try using the enum's variant" suggestion:
- Variants in suggestions would not result in more errors (e.g. use of a struct variant is only suggested if the suggestion can trivially construct that variant). Therefore, suggestions are only emitted for variants that have no fields (since the suggestion can't know what value fields would have).
- Suggestions include the syntax for constructing the variant. If a struct or tuple variant is suggested, then it is constructed in the suggestion - unless in pattern-matching or when arguments are already provided.
- A help message is added which mentions the variants which are no longer suggested.
All of the diagnostic logic introduced by this PR is separated from the normal code path for a successful compilation.
projects / rust.git / log