Stefan Lankes [Tue, 6 Oct 2020 09:39:59 +0000 (11:39 +0200)]
revise Hermit's mutex interface to support the behaviour of StaticMutex
rust-lang/rust#77147 simplifies things by splitting this Mutex type
into two types matching the two use cases: StaticMutex and MovableMutex.
To support the behavior of StaticMutex, we move part of the mutex
implementation into libstd.
bors [Sun, 11 Oct 2020 07:55:20 +0000 (07:55 +0000)]
Auto merge of #77769 - camelid:regression-untriaged, r=jyn514
Auto-prioritize issues with `regression-untriaged`
This auto-prioritizes issues with the `regression-untriaged` label. (I just added it per <https://github.com/rust-lang/rust/pull/77725#discussion_r502135703>.)
bors [Sun, 11 Oct 2020 06:03:23 +0000 (06:03 +0000)]
Auto merge of #77565 - khyperia:codegen-backend-dep, r=ecstatic-morse
Add -Z codegen-backend dylib to deps
When the codegen-backend dylib changes, the program should be rebuilt.
---
Unfortunately I was unable to test this works locally due to running into a TLS issue when running the custom backend, `thread 'rustc' panicked at 'no ImplicitCtxt stored in tls', compiler/rustc_middle/src/ty/context.rs:1750:54`, which seems similar to https://github.com/rust-lang/rust/issues/62717 but has a completely different cause and backtrace.
`@eddyb` said to ping `@Mark-Simulacrum` about what they think about this, so, ping!
bors [Sat, 10 Oct 2020 23:27:28 +0000 (23:27 +0000)]
Auto merge of #77087 - estebank:issue-45817, r=matthewjasper
Provide structured suggestions when finding structs when expecting a trait
When finding an ADT in a trait object definition provide some solutions. Fix #45817.
Given `<Param as Trait>::Assoc: Ty` suggest `Param: Trait<Assoc = Ty>`. Fix #75829.
bors [Sat, 10 Oct 2020 21:19:50 +0000 (21:19 +0000)]
Auto merge of #76934 - camelid:rustdoc-allow-generic-params, r=jyn514
Allow generic parameters in intra-doc links
Fixes #62834.
---
The contents of the generics will be mostly ignored (except for warning
if fully-qualified syntax is used, which is currently unsupported in
intra-doc links - see issue #74563).
* Allow links like `Vec<T>`, `Result<T, E>`, and `Option<Box<T>>`
* Allow links like `Vec::<T>::new()`
* Warn on
* Unbalanced angle brackets (e.g. `Vec<T` or `Vec<T>>`)
* Missing type to apply generics to (`<T>` or `<Box<T>>`)
* Use of fully-qualified syntax (`<Vec as IntoIterator>::into_iter`)
* Invalid path separator (`Vec:<T>:new`)
* Too many angle brackets (`Vec<<T>>`)
* Empty angle brackets (`Vec<>`)
Note that this implementation *does* allow some constructs that aren't
valid in the actual Rust syntax, for example `Box::<T>new()`. That may
not be supported in rustdoc in the future; it is an implementation
detail.
Camelid [Sat, 10 Oct 2020 19:49:31 +0000 (12:49 -0700)]
Fix query docs
They were not formatted correctly, so rustdoc was interpreting some
parts as code. Also cleaned up some other query docs that weren't
causing issues, but were formatted incorrectly.
Yuki Okushi [Sat, 10 Oct 2020 18:19:21 +0000 (03:19 +0900)]
Rollup merge of #77787 - jyn514:consistent-versions, r=spastorino
Update `changelog-seen` in config.toml.example
This got out of sync when the version was bumped last time in #77133
Long-term we may want to find an easier way to maintain this that
doesn't require bumping the version in three different places. Off the
top of my head I can't think of anything, though. It _is_ documented in src/bootstrap/README.md, although I don't know how many people read that.
Yuki Okushi [Sat, 10 Oct 2020 18:19:18 +0000 (03:19 +0900)]
Rollup merge of #77777 - cuviper:doc-stat, r=jonas-schievink
doc: disambiguate stat in MetadataExt::as_raw_stat
A few architectures in `os::linux::raw` import `libc::stat`, rather than
defining that type directly. However, that also imports the _function_
called `stat`, which makes this doc link ambiguous:
error: `crate::os::linux::raw::stat` is both a struct and a function
--> library/std/src/os/linux/fs.rs:21:19
|
21 | /// [`stat`]: crate::os::linux::raw::stat
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^ ambiguous link
|
= note: `-D broken-intra-doc-links` implied by `-D warnings`
help: to link to the struct, prefix with the item type
|
21 | /// [`stat`]: struct@crate::os::linux::raw::stat
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
help: to link to the function, add parentheses
|
21 | /// [`stat`]: crate::os::linux::raw::stat()
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
We want the `struct`, so it's now prefixed accordingly.
Yuki Okushi [Sat, 10 Oct 2020 18:19:14 +0000 (03:19 +0900)]
Rollup merge of #77754 - bugadani:find_map_relevant_impl, r=matthewjasper
Add TraitDef::find_map_relevant_impl
This PR adds a method to `TraitDef`. While `for_each_relevant_impl` covers the general use case, sometimes it's not necessary to scan through all the relevant implementations, so this PR introduces a new method, `find_map_relevant_impl`. I've also replaced the `for_each_relevant_impl` calls where possible.
I'm hoping for a tiny bit of efficiency gain here and there.
Yuki Okushi [Sat, 10 Oct 2020 18:19:10 +0000 (03:19 +0900)]
Rollup merge of #77738 - RalfJung:alloc-error-handler-comment, r=Amanieu
fix __rust_alloc_error_handler comment
`__rust_alloc_error_handler` was added in the same `extern` block as the allocator functions, but the comment there was not actually correct for `__rust_alloc_error_handler`. So move it down to the rest of the default allocator handling with a fixed comment. At least the comment reflects my understanding of what happens, please check carefully. :)
Yuki Okushi [Sat, 10 Oct 2020 18:19:07 +0000 (03:19 +0900)]
Rollup merge of #77629 - Julian-Wollersberger:recomputeRawStrError, r=varkor
Cleanup of `eat_while()` in lexer
The size of a lexer Token was inflated by the largest `TokenKind` variants `LiteralKind::RawStr` and `RawByteStr`, because
* it used `usize` although `u32` is sufficient in rustc, since crates must be smaller than 4GB,
* and it stored the 20 bytes big `RawStrError` enum for error reporting.
If a raw string is invalid, it now needs to be reparsed to get the `RawStrError` data, but that is a very cold code path.
Technically this breaks other tools that depend on rustc_lexer because they are now also restricted to a max file size of 4GB. But this shouldn't matter in practice, and rustc_lexer isn't stable anyway.
Can I also get a perf run?
Edit: This makes no difference in performance. The PR now only contains a small cleanup.
Yuki Okushi [Sat, 10 Oct 2020 18:19:05 +0000 (03:19 +0900)]
Rollup merge of #77195 - follower:patch-2, r=jyn514
Link to documentation-specific guidelines.
Changed contribution information URL because it's not obvious how to get from the current URL to the documentation-specific content.
The current URL points to this "Getting Started" page, which contains nothing specific about documentation[*] and instead launches into how to *build* `rustc` which is not a strict prerequisite for contributing documentation fixes:
[*] The most specific content is a "Writing documentation" bullet point which is not itself a link to anything (I guess a patch for that might be helpful too).
### Why?
Making this change will make it easier for people who wish to make small "drive by" documentation fixes (and read contribution guidelines ;) ) which I find are often how I start contributing to a project. (Exhibit A: https://github.com/rust-lang/rust/pull/77050 :) )
### Background
My impression is the change of content linked is an unintentional change due to a couple of other changes:
* Originally, the link pointed to `contributing.md` which started with a "table of contents" linking to each section. But the content in `contributing.md` was removed and replaced with a link to the "Getting Started" section here:
(If the "Guide to Rustc Development" is now considered the canonical location of "How to Contribute" content it might be a good idea to merge some of the "Contributing" Introduction section into the "Getting Started" section.)
* This was then compounded by changing the link from `contributing.md` to `contributing.html` here:
In order to even find the new location of the previous `contributing.md` content I ended up needing to do a GitHub search of the `rust-lang` org for the phrase "Documentation improvements are very welcome". :D
Joshua Nelson [Sat, 10 Oct 2020 14:08:36 +0000 (10:08 -0400)]
Update `changelog-seen` in config.toml.example
This got out of sync when the version was bumped last time.
Long-term we may want to find an easier way to maintain this that
doesn't require bumping the version in three different places. Off the
top of my head I can't think of anything, though.
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.
Josh Stone [Sat, 10 Oct 2020 03:12:26 +0000 (20:12 -0700)]
doc: disambiguate stat in MetadataExt::as_raw_stat
A few architectures in `os::linux::raw` import `libc::stat`, rather than
defining that type directly. However, that also imports the _function_
called `stat`, which makes this doc link ambiguous:
error: `crate::os::linux::raw::stat` is both a struct and a function
--> library/std/src/os/linux/fs.rs:21:19
|
21 | /// [`stat`]: crate::os::linux::raw::stat
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^ ambiguous link
|
= note: `-D broken-intra-doc-links` implied by `-D warnings`
help: to link to the struct, prefix with the item type
|
21 | /// [`stat`]: struct@crate::os::linux::raw::stat
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
help: to link to the function, add parentheses
|
21 | /// [`stat`]: crate::os::linux::raw::stat()
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
We want the `struct`, so it's now prefixed accordingly.
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.
Noticed a potential bug in `eat_while()`: it doesn't account for number of UTF8 bytes.
Fixed it by inlining it in the two places where the count is used and simplified the logic there.
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?~~
Camelid [Fri, 9 Oct 2020 05:24:34 +0000 (22:24 -0700)]
Allow generic parameters in intra-doc links
The contents of the generics will be mostly ignored (except for warning
if fully-qualified syntax is used, which is currently unsupported in
intra-doc links - see issue #74563).
* Allow links like `Vec<T>`, `Result<T, E>`, and `Option<Box<T>>`
* Allow links like `Vec::<T>::new()`
* Warn on
* Unbalanced angle brackets (e.g. `Vec<T` or `Vec<T>>`)
* Missing type to apply generics to (`<T>` or `<Box<T>>`)
* Use of fully-qualified syntax (`<Vec as IntoIterator>::into_iter`)
* Invalid path separator (`Vec:<T>:new`)
* Too many angle brackets (`Vec<<T>>`)
* Empty angle brackets (`Vec<>`)
Note that this implementation *does* allow some constructs that aren't
valid in the actual Rust syntax, for example `Box::<T>new()`. That may
not be supported in rustdoc in the future; it is an implementation
detail.
- 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: