Recently in a russian rust begginers telegram chat a newbie asked (translated):
> Are there any methods for these conversions:
>
> 1. `(Option<A>, Option<B>) -> Option<(A, B)>`
> 2. `Vec<Option<T>> -> Option<Vec<T>>`
>
> ?
While second (2.) is clearly `vec.into_iter().collect::<Option<Vec<_>>()`, the
first one isn't that clear.
I couldn't find anything similar in the `core` and I've come to this solution:
```rust
let tuple: (Option<A>, Option<B>) = ...;
let res: Option<(A, B)> = tuple.0.and_then(|a| tuple.1.map(|b| (a, b)));
```
However this solution isn't "nice" (same for just `match`/`if let`), so I thought
that this functionality should be in `core`.
I'm not confident the HIR lowering is completely correct, there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.
Make std::sync::Arc compatible with ThreadSanitizer
The memory fences used previously in Arc implementation are not properly
understood by thread sanitizer as synchronization primitives. This had
unfortunate effect where running any non-trivial program compiled with
`-Z sanitizer=thread` would result in numerous false positives.
Replace acquire fences with acquire loads to address the issue.
bors [Fri, 20 Mar 2020 19:02:32 +0000 (19:02 +0000)]
Auto merge of #69509 - RalfJung:debug-assert-write, r=eddyb
debug-assert ptr sanity in ptr::write
This is a re-submission of the parts that we removed from https://github.com/rust-lang/rust/pull/69208 due to ["interesting" test failures](https://github.com/rust-lang/rust/pull/69208#issuecomment-591310437).
Yuki Okushi [Fri, 20 Mar 2020 08:02:05 +0000 (17:02 +0900)]
Rollup merge of #69935 - davidtwco:issue-69925, r=eddyb
codegen/mir: support polymorphic `InstanceDef`s
cc #69925
This PR modifies the use of `subst_and_normalize_erasing_regions` on parts of the MIR bodies returned from `instance_mir`, so that `InstanceDef::CloneShim` and `InstanceDef::DropGlue` (where there is a type) do not perform substitutions. This avoids double substitutions and enables polymorphic `InstanceDef`s.
Yuki Okushi [Fri, 20 Mar 2020 08:02:01 +0000 (17:02 +0900)]
Rollup merge of #69618 - hniksic:mem-forget-doc-fix, r=RalfJung
Clarify the relationship between `forget()` and `ManuallyDrop`.
As discussed on reddit, this commit addresses two issues with the
documentation of `mem::forget()`:
* The documentation of `mem::forget()` can confuse the reader because of the
discrepancy between usage examples that show correct usage and the
accompanying text which speaks of the possibility of double-free. The
text that says "if the panic occurs before `mem::forget` was called"
refers to a variant of the second example that was never shown, modified
to use `mem::forget` instead of `ManuallyDrop`. Ideally the documentation
should show both variants, so it's clear what it's talking about.
Also, the double free could be fixed just by placing `mem::forget(v)`
before the construction of `s`. Since the lifetimes of `s` and `v`
wouldn't overlap, there would be no point where panic could cause a double
free. This could be mentioned, and contrasted against the more robust fix
of using `ManuallyDrop`.
* This sentence seems unjustified: "For some types, operations such as
passing ownership (to a funcion like `mem::forget`) requires them to
actually be fully owned right now [...]". Unlike C++, Rust has no move
constructors, its moves are (possibly elided) bitwise copies. Even if you
pass an invalid object to `mem::forget`, no harm should come to pass
because `mem::forget` consumes the object and exists solely to prevent
drop, so there no one left to observe the invalid state state.
Tomasz Miąsko [Fri, 20 Mar 2020 00:00:00 +0000 (00:00 +0000)]
Make std::sync::Arc compatible with ThreadSanitizer
The memory fences used previously in Arc implementation are not properly
understood by ThreadSanitizer as synchronization primitives. This had
unfortunate effect where running any non-trivial program compiled with
`-Z sanitizer=thread` would result in numerous false positives.
Replace acquire fences with acquire loads when using ThreadSanitizer to
address the issue.
bors [Thu, 19 Mar 2020 16:07:59 +0000 (16:07 +0000)]
Auto merge of #69402 - GuillaumeGomez:extend-search, r=kinnison
Extend search
I realized that when looking for "struct:String" in the rustdoc search for example, the "in arguments" and "returned" tabs were always empty. After some investigation, I realized it was because we only provided the name, and not the type, making it impossible to pass the "type filtering" check.
To resolve this, I added the type alongside the name. Note for the future: we could improve this by instead only registering the path id and use the path dictionary directly. The only problem with that solution (which I already tested) is that it becomes complicated for types in other crates. It'd force us to handle both case with an id and a case with `(name, type)`. I found the current PR big enough to not want to provide it directly. However, I think this is definitely worth it to make it work this way in the future.
About the two tests I added: they don't have much interest except checking that we actually have something returned in the search in the cases of a type filtering with and without literal search.
I also had to update a bit the test script to add the new locally global (haha) variable I created (`NO_TYPE_FILTER`). I added this variable to make the code easier to read than just "-1".
Hrvoje Niksic [Wed, 4 Mar 2020 21:12:53 +0000 (22:12 +0100)]
Restore (and reword) the warning against passing invalid values to mem::forget.
As pointed out by Ralf Jung, dangling references and boxes are
undefined behavior as per
https://doc.rust-lang.org/reference/behavior-considered-undefined.html
and the Miri checker.
Hrvoje Niksic [Sun, 1 Mar 2020 20:31:08 +0000 (21:31 +0100)]
Clarify the relationship between `forget()` and `ManuallyDrop`.
As discussed on reddit, this commit addresses two issues with the
documentation of `mem::forget()`:
* The documentation of `mem::forget()` can confuse the reader because of the
discrepancy between usage examples that show correct usage and the
accompanying text which speaks of the possibility of double-free. The
text that says "if the panic occurs before `mem::forget` was called"
refers to a variant of the second example that was never shown, modified
to use `mem::forget` instead of `ManuallyDrop`. Ideally the documentation
should show both variants, so it's clear what it's talking about.
Also, the double free could be fixed just by placing `mem::forget(v)`
before the construction of `s`. Since the lifetimes of `s` and `v`
wouldn't overlap, there would be no point where panic could cause a double
free. This could be mentioned, and contrasted against the more robust fix
of using `ManuallyDrop`.
* This sentence seems unjustified: "For some types, operations such as
passing ownership (to a funcion like `mem::forget`) requires them to
actually be fully owned right now [...]". Unlike C++, Rust has no move
constructors, its moves are (possibly elided) bitwise copies. Even if you
pass an invalid object to `mem::forget`, no harm should come to pass
because `mem::forget` consumes the object and exists solely to prevent
drop, so there no one left to observe the invalid state state.
bors [Thu, 19 Mar 2020 09:18:49 +0000 (09:18 +0000)]
Auto merge of #66131 - eddyb:local-def-id, r=petrochenkov
rustc: use LocalDefId instead of DefIndex where possible.
That is, wherever `DefIndex` always referred to a "def" in the local crate, I replaced it with `LocalDefId`.
While `LocalDefId` already existed, it wasn't used a lot, but I hope I'm on the right track.
Unresolved questions:
* [x] ~~should `LocalDefId` implement `rustc_index::Idx`?~~
* ~~this would get rid of a couple more `DefIndex` uses~~
* [x] ~~should `LocalDefId` be encoded/decoded as just a `DefIndex`?~~
* ~~right now it's a bit messy, `LocalDefId` encodes/decodes like `DefId`~~
* [x] ~~should `DefId::assert_local` be named something else, like `expect_local`?~~
A future PR should change `tcx.hir().local_def_id(...)` to return `LocalDefId` instead of `DefId`, as changing it in this PR would be too noisy.
r? @michaelwoerister cc @nikomatsakis @petrochenkov @Zoxc
bors [Thu, 19 Mar 2020 05:57:57 +0000 (05:57 +0000)]
Auto merge of #70132 - Centril:rollup-oe8unsn, r=Centril
Rollup of 9 pull requests
Successful merges:
- #68941 (Properly handle Spans that reference imported SourceFiles)
- #69036 (rustc: don't resolve Instances which would produce malformed shims.)
- #69443 (tidy: Better license checks.)
- #69814 (Smaller and more correct generator codegen)
- #69929 (Regenerate tables for Unicode 13.0.0)
- #69959 (std: Don't abort process when printing panics in tests)
- #69969 (unix: Set a guard page at the end of signal stacks)
- #70005 ([rustdoc] Improve visibility for code blocks warnings)
- #70088 (Use copy bound in atomic operations to generate simpler MIR)
Rollup merge of #70005 - GuillaumeGomez:code-block-signs, r=kinnison
[rustdoc] Improve visibility for code blocks warnings
It appeared that a lot of people didn't notice when a code block was meant to fail compilation or wasn't tested at all. The changes here make the colors less transparent and the icon bigger. So before it looked like this:
Rollup merge of #69969 - iximeow:sigstack-guard-page, r=cuviper
unix: Set a guard page at the end of signal stacks
This mitigates possible issues when signal stacks overflow, which could
manifest as segfaults or in unlucky circumstances possible clobbering of
other memory values as stack overflows tend to enable.
I went ahead and made a PR for this because it's a pretty small change, though if I should open an issue/RFC for this and discuss there first I'll happily do so. I've also added some example programs that demonstrate the uncomfortably clobber-happy behavior we currently have, and the segfaults that could/should result instead, [here](https://github.com/iximeow/jubilant-train).
Rollup merge of #69959 - alexcrichton:fix-panic-in-print, r=Mark-Simulacrum
std: Don't abort process when printing panics in tests
This commit fixes an issue when using `set_print` and friends, notably
used by libtest, to avoid aborting the process if printing panics. This
previously panicked due to borrowing a mutable `RefCell` twice, and this
is worked around by borrowing these cells for less time, instead
taking out and removing contents temporarily.
It also addresses the correctness concerns wrt poisoning on unwind. These are not currently a soundness issue because any operation *inside* a generator that could possibly unwind will result in a cleanup path for dropping it, ultimately reaching a `Resume` terminator, which we already handled correctly. Future MIR optimizations might optimize that out, though.
Rollup merge of #69443 - ehuss:tidy-license, r=skade,Mark-Simulacrum
tidy: Better license checks.
This implements some improvements to the license checks in tidy:
* Use `cargo_metadata` instead of parsing vendored crates. This allows license checks to run without vendoring enabled, and allows the checks to run on PR builds.
* Check for stale entries.
* Check that the licenses for exceptions are what we think they are.
* Verify exceptions do not leak into the runtime.
Closes #62618
Closes #62619
Closes #63238 (I think)
There are some substantive changes here. The follow licenses have changed from the original comments:
* openssl BSD+advertising clause to Apache-2.0
* pest MPL2 to MIT/Apache-2.0
* smallvec MPL2 to MIT/Apache-2.0
* clippy lints MPL2 to MIT OR Apache-2.0
Rollup merge of #69036 - eddyb:monoshim, r=nikomatsakis
rustc: don't resolve Instances which would produce malformed shims.
There are some `InstanceDef` variants (shims and drop "glue") which contain a `Ty`, and that `Ty` is used in generating the shim MIR. But if that `Ty` mentions any generic parameters, the generated shim would refer to them (but they won't match the `Substs` of the `Instance`), or worse, generating the shim would fail because not enough of the type is known.
Ideally we would always produce a "skeleton" of the type, e.g. `(_, _)` for dropping any tuples with two elements, or `Vec<_>` for dropping any `Vec` value, but that's a lot of work, and they would still not match the `Substs` of the `Instance` as it exists today, so `Instance` would probably need to change.
By making `Instance::resolve` return `None` in the still-generic cases, we get behavior similar to specialization, where a default can only be used if there are no more generic parameters which would allow a more specialized `impl` to match.
<hr/>
This was found while testing the MIR inliner with #68965, because it was trying to inline shims.
Rollup merge of #68941 - Aaron1011:fix/imported-span, r=petrochenkov
Properly handle Spans that reference imported SourceFiles
Previously, metadata encoding used DUMMY_SP to represent any spans that
referenced an 'imported' SourceFile - e.g. a SourceFile from an upstream
dependency. This currently has no visible consequences, since these
kinds of spans don't currently seem to be emitted anywhere. However,
there's no reason that we couldn't start using such spans in
diagnostics.
This PR changes how we encode and decode spans in crate metadata. We
encode spans in one of two ways:
* 'Local' spans, which reference non-imported SourceFiles, are encoded
exactly as before.
* 'Foreign' spans, which reference imported SourceFiles, are encoded
with the CrateNum of their 'originating' crate. Additionally, their
'lo' and 'high' values are rebased on top of the 'originating' crate,
which allows them to be used with the SourceMap data encoded for that
crate.
To support this change, I've also made the following modifications:
* `DefId` and related structs are now moved to `rustc_span`. This allows
us to use a `CrateNum` inside `SourceFile`. `CrateNum` has special
handling during deserialization (it gets remapped to be the proper
`CrateNum` from the point of view of the current compilation session),
so using a `CrateNum` instead of a plain integer 'workaround type' helps
to simplify deserialization.
* The `ExternalSource` enum is renamed to `ExternalSourceKind`. There is
now a struct called `ExternalSource`, which holds an
`ExternalSourceKind` along with the original line number information for
the file. This is used during `Span` serialization to rebase spans onto
their 'owning' crate.
Aaron Hill [Fri, 7 Feb 2020 19:02:24 +0000 (14:02 -0500)]
Properly handle Spans that reference imported SourceFiles
Previously, metadata encoding used DUMMY_SP to represent any spans that
referenced an 'imported' SourceFile - e.g. a SourceFile from an upstream
dependency. These leads to sub-optimal error messages in certain cases
(see the included test).
This PR changes how we encode and decode spans in crate metadata. We
encode spans in one of two ways:
* 'Local' spans, which reference non-imported SourceFiles, are encoded
exactly as before.
* 'Foreign' spans, which reference imported SourceFiles, are encoded
with the CrateNum of their 'originating' crate. Additionally, their
'lo' and 'high' values are rebased on top of the 'originating' crate,
which allows them to be used with the SourceMap data encoded for that
crate.
The `ExternalSource` enum is renamed to `ExternalSourceKind`. There is
now a struct called `ExternalSource`, which holds an
`ExternalSourceKind` along with the original line number information for
the file. This is used during `Span` serialization to rebase spans onto
their 'owning' crate.
Pietro Albini [Wed, 18 Mar 2020 20:11:11 +0000 (21:11 +0100)]
Rollup merge of #70116 - pietroalbini:ci-fix-windows-python-path, r=Mark-Simulacrum
ci: use python from the correct path
Apparently the old path we were using for Python 2 on Windows was not documented, and eventually got removed. This switches our CI to use the correct path.
See https://github.com/rust-lang/rust/pull/70112#issuecomment-600760786 for the actual failure.
Pietro Albini [Wed, 18 Mar 2020 17:57:37 +0000 (18:57 +0100)]
ci: use python from the correct path
Apparently the old path we were using for Python 2 on Windows was not
documented, and eventually got removed. This switches our CI to use the
correct path.
Rollup merge of #70106 - ehuss:fix-tidy-fmt-twice, r=Mark-Simulacrum
Tidy: fix running rustfmt twice
`./x.py test tidy` runs rustfmt twice. This is because `Build::build` runs `execute_cli` twice (once dry, once not). This can be quite slow (and prints a bunch of things twice).
I'm not sure if this is really the best place to check the dry_run status.
Rollup merge of #69920 - Centril:hir-cleanup, r=Zoxc
Remove some imports to the rustc crate
- When we have `NestedVisitorMap::None`, we use `type Map = dyn intravisit::Map<'v>;` instead of the actual map. This doesn't actually result in dynamic dispatch (in the future we may want to use an associated type default to simplify the code).
- Use `rustc_session::` imports instead of `rustc::{session, lint}`.
Rollup merge of #69839 - RalfJung:miri-error-cleanup, r=oli-obk
Miri error reform
Some time ago we started moving Miri errors into a few distinct categories, but we never classified all the old errors. That's what this PR does.
~~This is on top of https://github.com/rust-lang/rust/pull/69762; [relative diff](https://github.com/RalfJung/rust/compare/validity-errors...RalfJung:miri-error-cleanup).~~
Rollup merge of #69838 - Centril:expand-module, r=petrochenkov
Expansion-driven outline module parsing
After this PR, the parser will not do any conditional compilation or loading of external module files when `mod foo;` is encountered. Instead, the parser only leaves `mod foo;` in place in the AST, with no items filled in. Expansion later kicks in and will load the actual files and do the parsing. This entails that the following is now valid:
```rust
#[cfg(FALSE)]
mod foo {
mod bar {
mod baz; // `foo/bar/baz.rs` doesn't exist, but no error!
}
}
```
I'm not yet sure about the runtime performance impact of this, so I'll try running this on some benchmarks (if I can find any). (Update: No impact on the benchmarks I've measured on)
* [x] Add test with a generator that has exactly 256 total states
* [x] Add test with a generator that has more than 256 states so that it needs to use a u16 discriminant
* [x] Add tests for the size of `Option<[generator]>`
* [x] Add tests for the `discriminant_value` intrinsic in all cases
Rollup merge of #69189 - matthewjasper:erase-the-world, r=nikomatsakis
Erase regions in writeback
Regions in `TypeckTables` (except canonicalized user annotations) are now erased. Further, we no longer do lexical region solving on item bodies with `-Zborrowck=mir`.
Alex Crichton [Thu, 12 Mar 2020 20:03:48 +0000 (13:03 -0700)]
std: Don't abort process when printing panics in tests
This commit fixes an issue when using `set_print` and friends, notably
used by libtest, to avoid aborting the process if printing panics. This
previously panicked due to borrowing a mutable `RefCell` twice, and this
is worked around by borrowing these cells for less time, instead
taking out and removing contents temporarily.
Waffle [Wed, 18 Mar 2020 08:02:29 +0000 (11:02 +0300)]
fixes to `Option::{zip,zip_with}`
- remove `#[inline]` attributes (see https://github.com/rust-lang/rust/pull/69997#discussion_r393942617)
- fill tracking issue in `#[unstable]` attributes
- slightly improve the docs
Recently in a russian rust begginers telegram chat a newbie asked (translated):
> Are there any methods for these conversions:
>
> 1. `(Option<A>, Option<B>) -> Option<(A, B)>`
> 2. `Vec<Option<T>> -> Option<Vec<T>>`
>
> ?
While second (2.) is clearly `vec.into_iter().collect::<Option<Vec<_>>()`, the
first one isn't that clear.
I couldn't find anything similar in the `core` and I've come to this solution:
```rust
let tuple: (Option<A>, Option<B>) = ...;
let res: Option<(A, B)> = tuple.0.and_then(|a| tuple.1.map(|b| (a, b)));
```
However this solution isn't "nice" (same for just `match`/`if let`), so I thought
that this functionality should be in `core`.
bors [Wed, 18 Mar 2020 06:31:24 +0000 (06:31 +0000)]
Auto merge of #69907 - ehuss:update-cargo, r=ehuss
Update cargo
Update cargo
21 commits in bda50510d1daf6e9c53ad6ccf603da6e0fa8103f..7019b3ed3d539db7429d10a343b69be8c426b576
2020-03-02 18:05:34 +0000 to 2020-03-17 21:02:00 +0000
- Run through clippy (rust-lang/cargo#8015)
- Fix config profiles using "dev" in `cargo test`. (rust-lang/cargo#8012)
- Run CI on all PRs. (rust-lang/cargo#8011)
- Add unit-graph JSON output. (rust-lang/cargo#7977)
- Split workspace/validate() into multiple functions (rust-lang/cargo#8008)
- Use Option::as_deref (rust-lang/cargo#8005)
- De-duplicate edges (rust-lang/cargo#7993)
- Revert "Disable preserving mtimes on archives" (rust-lang/cargo#7935)
- Close the front door for clippy but open the back (rust-lang/cargo#7533)
- Fix CHANGELOG.md typos (rust-lang/cargo#7999)
- Update changelog note about crate-versions flag. (rust-lang/cargo#7998)
- Bump to 0.45.0, update changelog (rust-lang/cargo#7997)
- Bump libgit2 dependencies (rust-lang/cargo#7996)
- Avoid buffering large amounts of rustc output. (rust-lang/cargo#7838)
- Add "Updating" status for git submodules. (rust-lang/cargo#7989)
- WorkspaceResolve: Use descriptive lifetime label. (rust-lang/cargo#7990)
- Support old html anchors in manifest chapter. (rust-lang/cargo#7983)
- Don't create hardlink for library test and integrations tests, fixing rust-lang/cargo#7960 (rust-lang/cargo#7965)
- Partially revert change to filter debug_assertions. (rust-lang/cargo#7970)
- Try to better handle restricted crate names. (rust-lang/cargo#7959)
- Fix bug with new feature resolver and required-features. (rust-lang/cargo#7962)
projects / rust.git / log