bors [Tue, 23 Jun 2020 00:13:50 +0000 (00:13 +0000)]
Auto merge of #73007 - yoshuawuyts:socketaddr-from-string-u16, r=sfackler
impl ToSocketAddrs for (String, u16)
This adds a convenience impl of `ToSocketAddrs for (String, u16)`. When authoring HTTP services it's common to take command line options for `host` and `port` and parse them into `String` and `u16` respectively. Consider the following program:
```rust
#[derive(Debug, StructOpt)]
struct Config {
host: String,
port: u16,
}
async fn main() -> io::Result<()> {
let config = Config::from_args();
let stream = TcpStream::connect((&*config.host, config.port))?; // &* is not ideal
// ...
}
```
Networking is a pretty common starting point for people new to Rust, and seeing `&*` in basic examples can be confusing. Even as someone that has experience with networking in Rust I tend to forget that `String` can't be passed directly there. Instead with this patch we can omit the `&*` conversion and pass `host` directly:
```rust
#[derive(Debug, StructOpt)]
struct Config {
host: String,
port: u16,
}
async fn main() -> io::Result<()> {
let config = Config::from_args();
let stream = TcpStream::connect((config.host, config.port))?; // no more conversions!
// ...
}
```
I think should be an easy and small ergonomics improvement for networking. Thanks!
Aaron Hill [Mon, 22 Jun 2020 17:29:04 +0000 (13:29 -0400)]
Stop using old version of `syn` in `rustc-workspace-hack`
None of the tools seem to need syn 0.15.35, so we can just build syn
1.0.
This was causing an issue with clippy's `compile-test` program: since
multiple versions of `syn` would exist in the build directory, we would
non-deterministically pick one based on filesystem iteration order. If
the pre-1.0 version of `syn` was picked, a strange build error would
occur (see
https://github.com/rust-lang/rust/pull/73594#issuecomment-647671463)
To prevent this kind of issue from happening again, we now panic if we
find multiple versions of a crate in the build directly, instead of
silently picking the first version we find.
bors [Mon, 22 Jun 2020 16:38:21 +0000 (16:38 +0000)]
Auto merge of #73415 - ehuss:update-cargo, r=ehuss
Update cargo
3 commits in 79c769c3d7b4c2cf6a93781575b7f592ef974255..089cbb80b73ba242efdcf5430e89f63fa3b5328d
2020-06-11 22:13:37 +0000 to 2020-06-15 14:38:34 +0000
- Support linker with -Zdoctest-xcompile. (rust-lang/cargo#8359)
- Fix doctests not running with --target=HOST. (rust-lang/cargo#8358)
- Allow passing a registry index url directly to `cargo install` (rust-lang/cargo#8344)
Dylan DPC [Mon, 22 Jun 2020 12:53:56 +0000 (14:53 +0200)]
Rollup merge of #73585 - LeSeulArtichaut:patch-3, r=Mark-Simulacrum
Do not send a notification for P-high stable regressions
This is kind of a hack to only match nightly and beta regressions, but not stable regressions. See my tests [on the playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6ff8a809162118aa2951f2ff12400067).
bors [Sun, 21 Jun 2020 21:05:57 +0000 (21:05 +0000)]
Auto merge of #73180 - matthewjasper:predicate-cache, r=nikomatsakis
Cache flags and escaping vars for predicates
With predicates becoming interned (rust-lang/compiler-team#285) this is now possible and could be a perf win. It would become an even larger win once we have recursive predicates.
bors [Sun, 21 Jun 2020 17:10:09 +0000 (17:10 +0000)]
Auto merge of #72936 - jackh726:chalk-more, r=nikomatsakis
Upgrade Chalk
Things done in this PR:
- Upgrade Chalk to `0.11.0`
- Added compare-mode=chalk
- Bump rustc-hash in `librustc_data_structures` to `1.1.0` to match Chalk
- Removed `RustDefId` since the builtin type support is there
- Add a few more `FIXME(chalk)`s for problem spots I hit when running all tests with chalk
- Added some more implementation code for some newer builtin Chalk types (e.g. `FnDef`, `Array`)
- Lower `RegionOutlives` and `ObjectSafe` predicates
- Lower `Dyn` without the region
- Handle `Int`/`Float` `CanonicalVarKind`s
- Uncomment some Chalk tests that actually work now
- Remove the revisions in `src/test/ui/coherence/coherence-subtyping.rs` since they aren't doing anything different
Dan Aloni [Sat, 13 Jun 2020 17:58:46 +0000 (20:58 +0300)]
Prefer accessible paths in 'use' suggestions
This fixes an issue with the following sample:
mod foo {
mod inaccessible {
pub struct X;
}
pub mod avail {
pub struct X;
}
}
fn main() { X; }
Instead of suggesting both `use crate::foo::inaccessible::X;` and `use
crate::foo::avail::X;`, it should only suggest the latter.
It is done by trimming the list of suggestions from inaccessible paths
if accessible paths are present.
Visibility is checked with `is_accessible_from` now instead of being
hard-coded.
-
Some tests fixes are trivial, and others require a bit more explaining,
here are my comments:
src/test/ui/issues/issue-35675.stderr: Only needs to make the enum
public to have the suggestion make sense.
src/test/ui/issues/issue-42944.stderr: Importing the tuple struct won't
help because its constructor is not visible, so the attempted
constructor does not work. In that case, it's better not to suggest it.
The case where the constructor is public is covered in `issue-26545.rs`.
bors [Sun, 21 Jun 2020 13:18:00 +0000 (13:18 +0000)]
Auto merge of #72696 - jethrogb:jb/llvm-zlib, r=Mark-Simulacrum
Enable LLVM zlib
Compilers may generate ELF objects with compressed sections (although rustc currently doesn't do this). Currently, when linking these with `rust-lld`, you'll get this error:
`rust-lld: error: ...: contains a compressed section, but zlib is not available`
bors [Sun, 21 Jun 2020 02:20:07 +0000 (02:20 +0000)]
Auto merge of #70946 - jumbatm:clashing-extern-decl, r=nagisa
Add a lint to catch clashing `extern` fn declarations.
Closes #69390.
Adds lint `clashing_extern_decl` to detect when, within a single crate, an extern function of the same name is declared with different types. Because two symbols of the same name cannot be resolved to two different functions at link time, and one function cannot possibly have two types, a clashing extern declaration is almost certainly a mistake.
This lint does not run between crates because a project may have dependencies which both rely on the same extern function, but declare it in a different (but valid) way. For example, they may both declare an opaque type for one or more of the arguments (which would end up distinct types), or use types that are valid conversions in the language the extern fn is defined in. In these cases, we can't say that the clashing declaration is incorrect.
Rollup merge of #73443 - pietroalbini:gha-auto-fallible, r=Mark-Simulacrum
ci: allow gating GHA on everything but macOS
In our GitHub Actions setup macOS is too unreliable to gate on it, but the other builders work fine. This commit splits the macOS builders into a separate job (called `auto-fallible`), allowing us to gate on the auto job without failing due to macOS spurious failures.
cc https://github.com/rust-lang/rust-central-station/issues/848
r? @Mark-Simulacrum
Rollup merge of #73287 - davidtwco:issue-73251-opaque-types-in-projections, r=estebank
lint: normalize projections using opaque types
Fixes #73251.
This PR normalizes projections which use opaque types (opaque types are otherwise linted against, which is would have previously made the test cases added in this PR fail).
Rollup merge of #72790 - jonhoo:duration-is-zero, r=LukasKalbertodt
core/time: Add Duration methods for zero
This patch adds two methods to `Duration`. The first, `Duration::zero`,
provides a `const` constructor for getting an zero-length duration. This
is also what `Default` provides (this was clarified in the docs), though
`default` is not `const`.
The second, `Duration::is_zero`, returns true if a `Duration` spans no
time (i.e., because its components are all zero). Previously, the way to
do this was either to compare both `as_secs` and `subsec_nanos` to 0, to
compare against `Duration::new(0, 0)`, or to use the `u128` method
`as_nanos`, none of which were particularly elegant.
Rollup merge of #72788 - matthewjasper:projection-bound-validation, r=nikomatsakis
Projection bound validation
During selection we use bounds declared on associated types (e.g. `type X: Copy`) to satisfy trait/projection bounds. This would be fine so long as those bounds are checked on any impls/trait objects. For simple cases they are because the bound `Self::X: Copy` gets normalized when we check the impl.
However, for default values with specialization and higher-ranked bounds from GATs or otherwise, we can't normalize when checking the impl, and so we use the bound from the trait to prove that the bound applies to the impl, which is clearly unsound.
This PR makes 2 fixes for this:
1. Requiring that the bounds on the trait apply to a projection type with the corresponding substs, so a bound `for<'a> <Self as X<'a>>::U: Copy` on the trait cannot be used to prove `<T as X<'_>>::U: Copy`.
2. Actually checking that the bounds that we still allow apply to generic/default associated types.
Rollup merge of #72456 - ldm0:dereftrait, r=estebank
Try to suggest dereferences on trait selection failed
Fixes #39029 Fixes #62530
This PR consists of two parts:
1. Decouple `Autoderef` with `FnCtxt` and move `Autoderef` to `librustc_trait_selection`.
2. Try to suggest dereferences when trait selection failed.
The first is needed because:
1. For suggesting dereferences, the struct `Autoderef` should be used. But before this PR, it is placed in `librustc_typeck`, which depends on `librustc_trait_selection`. But trait selection error emitting happens in `librustc_trait_selection`, if we want to use `Autoderef` in it, dependency loop is inevitable. So I moved the `Autoderef` to `librustc_trait_selection`.
2. Before this PR, `FnCtxt` is coupled to `Autoderef`, and `FnCtxt` only exists in `librustc_typeck`. So decoupling is needed.
After this PR, we can get suggestion like this:
```
error[E0277]: the trait bound `&Baz: Happy` is not satisfied
--> $DIR/trait-suggest-deferences-multiple.rs:34:9
|
LL | fn foo<T>(_: T) where T: Happy {}
| ----- required by this bound in `foo`
...
LL | foo(&baz);
| ^^^^
| |
| the trait `Happy` is not implemented for `&Baz`
| help: consider adding dereference here: `&***baz`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0277`.
```
bors [Sat, 20 Jun 2020 19:14:52 +0000 (19:14 +0000)]
Auto merge of #73550 - RalfJung:rollup-5huj1k1, r=RalfJung
Rollup of 9 pull requests
Successful merges:
- #72600 (Properly encode AnonConst into crate metadata)
- #73055 (remove leftover mentions of `skol` and `int` from the compiler)
- #73058 (Support sanitizers on aarch64-unknown-linux-gnu)
- #73171 (RISC-V Emulated Testing)
- #73404 (Update CFGuard syntax)
- #73444 (ci: disable alt build during try builds)
- #73471 (Prevent attacker from manipulating FPU tag word used in SGX enclave)
- #73539 (Deprecate `Vec::remove_item`)
- #73543 (Clean up E0695 explanation)
Jon Gjengset [Sat, 30 May 2020 18:55:38 +0000 (14:55 -0400)]
core/time: Add Duration methods for zero
This patch adds two methods to `Duration`. The first, `Duration::zero`,
provides a `const` constructor for getting an zero-length duration. This
is also what `Default` provides (this was clarified in the docs), though
`default` is not `const`.
The second, `Duration::is_zero`, returns true if a `Duration` spans no
time (i.e., because its components are all zero). Previously, the way to
do this was either to compare both `as_secs` and `subsec_nanos` to 0, to
compare against `Duration::new(0, 0)`, or to use the `u128` method
`as_nanos`, none of which were particularly elegant.
Ralf Jung [Sat, 20 Jun 2020 14:39:59 +0000 (16:39 +0200)]
Rollup merge of #73539 - LukasKalbertodt:deprecate-vec-remove-item, r=Mark-Simulacrum
Deprecate `Vec::remove_item`
In #40062 we decided to remove that method. In #71834 it was said that we want to deprecate it for a few cycles before removing it. That's what this PR does.
Ralf Jung [Sat, 20 Jun 2020 14:39:57 +0000 (16:39 +0200)]
Rollup merge of #73471 - raoulstrackx:raoul/fpu_tag_word, r=jethrogb
Prevent attacker from manipulating FPU tag word used in SGX enclave
Insufficient sanitization of the x87 FPU tag word in the trusted enclave runtime allowed unprivileged adversaries in the containing host application to induce incoherent or unexpected results for ABI-compliant compiled enclave application code that uses the x87 FPU.
Vulnerability was disclosed to us by Fritz Alder, Jo Van Bulck, David Oswald and Frank Piessens
Matthew Jasper [Thu, 11 Jun 2020 15:50:34 +0000 (16:50 +0100)]
Move bounds on associated types to the type
Given `trait X { type U; }` the bound `<Self as X>::U` now lives
on the type, rather than the trait. This is feature gated on
`feature(generic_associated_types)` for now until more testing can
be done.
The also enabled type-generic associated types since we no longer
need "implies bounds".
Matthew Jasper [Sat, 30 May 2020 16:19:31 +0000 (17:19 +0100)]
Consider fewer predicates for projection candidates
We now require that projection candidates are applicable with the
idenitity substs of the trait, rather than allowing predicates that are
only applicable for certain substs.
David Wood [Fri, 12 Jun 2020 16:42:08 +0000 (17:42 +0100)]
lint: normalize projections using opaque types
This commit normalizes projections which contain opaque types (opaque types
are otherwise linted against, which is would have previously made the
test cases added in this commit fail).
projects / rust.git / log