Aaron Hill [Wed, 20 Nov 2019 22:15:42 +0000 (17:15 -0500)]
Apply proper commit from PR #63934
While working on PR #63934, I accidentally reverted to an older version
of the PR while working on a rebase. The PR was then merged, not with
the later, approved changes, but with earlier, unapproved changes.
This PR applies the changes that were *suppoesd* to be mereged in
PR #63934. All of the proper tests appear to have been merged
in PR #63934, so this PR adds no new tests
Rollup merge of #66548 - lenary:riscv/disable-atomics-non-a, r=alexcrichton
[RISCV] Disable Atomics on all Non-A RISC-V targets
In a `TargetOptions` configuration, `max_atomic_width: None` causes `max_atomic_width()` to return `Some(target_pointer_width)`. So, contrary to assumptions, `max_atomic_width: None` means you do have atomic support!
RISC-V's rv32i and rv32imc do not have architectural support for atomic memory accesses of any size, because they do not include the `A` architecture extension. This means the values in the target definition should be `Some(0)`.
This bug has been observed via a build failure with oreboot/oreboot#191, where LLVM was still generating libcalls for atomic operations. According to rust-lang/compiler-builtins, "Rust only exposes atomic types on platforms that support them, and therefore does not need to fall back to software implementations." - so this PR tries to bring rustc inline with this decision.
This commit also removes the outdated bug link, which references a now irrelevant GCC bug.
I will likely also have to revisit the `min_atomic_width` of all the RISC-V targets so they are correct and match what the hardware is capable of (which is more restricted than one might imagine).
Rollup merge of #66532 - cuviper:dwarf-aranges, r=michaelwoerister
Generate DWARF address ranges for faster lookups
This adds a new option `-Zgenerate-arange-section`, enabled by default,
corresponding to LLVM's `-generate-arange-section`. This creates a
`.debug_aranges` section with DWARF address ranges, which some tools
depend on to optimize address lookups (elfutils [22288], [25173]).
This only has effect when debuginfo is enabled, and the additional data
is small compared to the other debug sections. For example, libstd.so
with full debuginfo is about 11MB, with just 61kB in aranges.
Rollup merge of #66497 - Nadrieril:fix-53820, r=varkor
Fix #53820
This fixes ICE #53820 by being more clever when matching large arrays with slice patterns.
In particular, it avoids treating large arrays like large tuples, and instead reuses the `VarLenSlice` constructor behaviour to only consider as little values as needed.
As a side-effect, such matches also get improved diagnostics, by reporting `[true, ..]` missing instead of `[true, _, _, _, _, _, _, _]`.
Rollup merge of #66478 - petrochenkov:rmplugin, r=davidtwco
rustc_plugin: Remove the compatibility shim
The compatibility crate was introduced in https://github.com/rust-lang/rust/pull/62727 to migrate Cargo and some other tools, but now it's no longer necessary.
Rollup merge of #65665 - tspiteri:italic-and-update-SourceCodePro, r=GuillaumeGomez
Update Source Code Pro and include italics
Fixes #65502.
A few notes:
* As stated in #65502, this does increase the download size.
* Since this PR changes the font set, I think docs.rs would have to be updated if this PR is merged.
* The fonts have a double extension (.ttf.woff); this is to keep the names consistent with the upstream font release which does that to distinguish these from the .otf.woff files ([Source Code Pro otf renders poorly on older Windows system apps](https://github.com/adobe-fonts/source-code-pro/issues/25#issuecomment-9019600)).
bors [Wed, 20 Nov 2019 03:07:39 +0000 (03:07 +0000)]
Auto merge of #66104 - yodaldevoid:generic-arg-disambiguation, r=petrochenkov
Generic arg disambiguation
Using the tactic suggested by @petrochenkov in https://github.com/rust-lang/rust/issues/60804#issuecomment-516769465 and on [zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/generic.20argument.20disambiguation), this change checks type arguments to see if they are really incorrectly-parsed const arguments.
it should be noted that `segments.len() == 1 && segments[0].arg.is_none()` was reduced to `segments.len() == 1` as suggested by @petrochenkov in [zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/generic.20argument.20disambiguation/near/177848002). This change allowed a few more existing tests to have their braces removed.
There are a couple of "problems" with these changes that I should note. First, there was a regression in the error messages found in "src/test/ui/privacy-ns1.rs" and "src/test/ui/privacy-ns1.rs". Second, some braces were unable to be removed from "src/test/ui/const-generics/fn-const-param-infer.rs". Those on line 24 caused the statement to stop equating when removed, and those on line 20 cause a statement that should not equate to produce no error when removed.
I have not looked further into any of these issues yet, though I would be willing to look into them before landing this. I simply wanted to get some other eyes on this before going further.
Rollup merge of #66529 - petrochenkov:reshelp2, r=davidtwco
resolve: Give derive helpers highest priority during resolution
So they just shadow everything else and don't create ambiguity errors.
This matches the old pre-#64694 behavior most closely.
---
The change doesn't apply to this "compatibility" case
```rust
#[trait_helper] // The helper attribute is used before it introduced.
// Sadly, compiles on stable, supported via hacks.
// I plan to make a compatibility warning for this.
#[derive(Trait)]
struct S;
```
, such attributes still create ambiguities, but #64694 didn't change anything for this case.
Rollup merge of #66431 - Aaron1011:fix/opaque-type-infer, r=varkor
Fix 'type annotations needed' error with opaque types
Related: #66426
This commit adds handling for opaque types during inference variable
fallback. Type variables generated from the instantiation of opaque
types now fallback to the opaque type itself.
Normally, the type variable for an instantiated opaque type is either
unified with the concrete type, or with the opaque type itself (e.g when
a function returns an opaque type by calling another function).
However, it's possible for the type variable to be left completely
unconstrained. This can occur in code like this:
Here, we'll instantatiate the `Foo` in `Option<Foo>` to a fresh type
variable, but we will never unify it with anything due to the fact
that we return a `None`.
This results in the error message:
```
type annotations needed: cannot resolve `_: std::marker::Copy
```
pointing at `pub type Foo = impl Copy`.
This message is not only confusing, it's incorrect. When an opaque type
inference variable is completely unconstrained, we can always fall back
to using the opaque type itself. This effectively turns that particular
use of the opaque type into a non-defining use, even if it appears in a
defining scope.
Rollup merge of #66090 - pietroalbini:ci-improvements, r=alexcrichton
Misc CI improvements
This PR contains some misc improvements to our CI configuration:
* The environment variables for MinGW builders were greatly simplified, with just `CUSTOM_MINGW=1` to tell the install scripts to install the vendored copy. All the others (`MINGW_URL`, `MINGW_DIR`, `MINGW_ARCHIVE` and `MSYS_BITS`) are detected either from the builder name or the environment.
* Collecting CPU stats and running the build were moved into scripts.
* Toolstate scripts validation was previously a separate step, ran just when `IMAGE=mingw-check`. This moves the validation code inside the actual image.
* Vendored copies are now fetched from https://ci-mirrors.rust-lang.org instead of directly from the bucket.
bors [Tue, 19 Nov 2019 07:49:54 +0000 (07:49 +0000)]
Auto merge of #66206 - PotHix:master, r=estebank
Suggest `#[repr(C)]` instead of `#[repr(C, packed, ...)]`
The code was previously suggesting `#[repr(C, packed, ...)]` for incorrect uses of `repr` (e.g. `#[repr = "C"]`). This change suggests the usage of `#[repr(C)]` instead.
bors [Tue, 19 Nov 2019 04:38:47 +0000 (04:38 +0000)]
Auto merge of #66074 - wesleywiser:test_run_const_prop, r=oli-obk
[mir-opt] Turn on the `ConstProp` pass by default
perf.rlo shows that running the `ConstProp` pass results in
across-the-board wins regardless of debug or opt complilation mode. As a
result, we're turning it on to get the compile time benefits.
Josh Stone [Mon, 18 Nov 2019 23:05:01 +0000 (15:05 -0800)]
Generate DWARF address ranges for faster lookups
This adds a new option `-Zgenerate-arange-section`, enabled by default,
corresponding to LLVM's `-generate-arange-section`. This creates a
`.debug_aranges` section with DWARF address ranges, which some tools
depend on to optimize address lookups (elfutils [22288], [25173]).
This only has effect when debuginfo is enabled, and the additional data
is small compared to the other debug sections. For example, libstd.so
with full debuginfo is about 11MB, with just 61kB in aranges.
Gabriel Smith [Mon, 18 Nov 2019 19:57:46 +0000 (14:57 -0500)]
test: Update tests with fallout of changes
The error messages of the two tests effected degraded in quality. The
errors no longer suggest types in other modules as they now assume that
the arguments are const args, not type args.
bors [Mon, 18 Nov 2019 22:08:31 +0000 (22:08 +0000)]
Auto merge of #58281 - mark-i-m:synthesis, r=estebank
Add outlives suggestions for some lifetime errors
This PR implements suggestion diagnostics for some lifetime mismatch errors. When the borrow checker finds that some lifetime 'a doesn't outlive some other lifetime 'b that it should outlive, then in addition to the current lifetime error, we also emit a suggestion for how to fix the problem by adding a bound:
- If a and b are normal named regions, suggest to add the bound `'a: 'b`
- If b is static, suggest to replace a with static
- If b also needs to outlive a, they must be the same, so suggest unifying them
We start with a simpler implementation that avoids diagnostic regression or implementation complexity:
- We only makes suggestions for lifetimes the user can already name (eg not closure regions or elided regions)
- For now, we only emit a help note, not an actually suggestion because it is significantly easier.
Finally, there is one hack: it seems that implicit regions in async fn are given the name '_ incorrectly. To avoid suggesting '_: 'x, we simply filter out such lifetimes by name.
TL;DR Make suggestions to add a `where 'a: 'b` constraint for some lifetime errors. Details are in the paper linked from the internals thread above.
r? @estebank
TODO
- [x] Clean up code
- [x] Only make idiomatic suggestions
- [x] don't suggest naming `&'a self`
- [x] rather than `'a: 'static`, suggest replacing `'a` with `'static`
- [x] rather than `'a: 'b, 'b: 'a`, suggest replacing `'a` with `'b` or vice versa
- [x] Performance (maybe need a perf run when this is closer to the finish line?)
- perf run was clean...
- EDIT: perf run seems to only check non-error performance... How do we check that error performance didn't regress?
- [x] Needs ui tests
- [x] Integrate the `help` message into the main lifetime `error`
Gabriel Smith [Mon, 18 Nov 2019 19:24:13 +0000 (14:24 -0500)]
resolve: late: Check if type arg is really a const arg
A path type argument could be a generic const argument due to
limitations as to what we can determine at parsing. We double check just
to be sure by trying to resolve in the type namespace first, and if that
fails we try again in the value namespace. If resolution in the value
namespace succeeds, we have a generic const argument on our hands.
bors [Mon, 18 Nov 2019 19:03:21 +0000 (19:03 +0000)]
Auto merge of #54733 - GuillaumeGomez:stabilize-rustdoc-theme, r=ollie27,Dylan-DPC
Stabilize rustdoc theme options
Closes #54730
This PR stabilizes the `--themes` (now `--theme`) and `--theme-checker` (now `--check-theme`) options, for allowing users to add custom themes to their documentation.
Rustdoc includes two themes by default: `light` and `dark`. Using the `--theme` option, you can give rustdoc a CSS file to include as an extra theme for that render. Themes are named after the CSS file used, so using `--theme /path/to/your/custom-theme.css` will add a theme called `custom-theme` to the documentation.
Even though the CLI flag to add a theme is getting stabilized, there's no guarantee that a theme file will always have the same effect on documentation generated with future versions of rustdoc. To aid in ensuring that a theme will work, the flag `--check-theme` is also available, which compares the CSS rules defined by a custom theme against the ones used in the `light` theme. If the `light` theme defines a CSS rule that the custom theme does not, rustdoc will report an error. (Rustdoc also performs this check for themes given to `--theme`, but only reports a warning when a difference is found.)
Aaron Hill [Fri, 15 Nov 2019 01:19:34 +0000 (20:19 -0500)]
Fix 'type annotations needed' error with opaque types
Related: #66426
This commit adds handling for opaque types during inference variable
fallback. Type variables generated from the instantiatino of opaque
types now fallback to the opque type itself.
Normally, the type variable for an instantiated opaque type is either
unified with the concrete type, or with the opaque type itself (e.g when
a function returns an opaque type by calling another function).
However, it's possible for the type variable to be left completely
unconstrained. This can occur in code like this:
Here, we'll instantatiate the `Foo` in `Option<Foo>` to a fresh type
variable, but we will never unify it with anything due to the fact
that we return a `None`.
This message is not only confusing, it's incorrect. When an opaque type
inference variable is completely unconstrained, we can always fall back
to using the opaque type itself. This effectively turns that particular
use of the opaque type into a non-defining use, even if it appears in a
defining scope.
bors [Mon, 18 Nov 2019 09:14:12 +0000 (09:14 +0000)]
Auto merge of #66459 - eddyb:update-llvm-wasm-dwarf, r=alexcrichton
Update src/llvm-project to include rust-lang/llvm-project#27.
See https://github.com/rust-lang/llvm-project/pull/27, which works around https://github.com/rust-lang/llvm-project/pull/20#discussion_r344425408 (where I stumbled over some UB in DWARF emission for WASM, resulting in non-deterministic output).
bors [Mon, 18 Nov 2019 06:09:04 +0000 (06:09 +0000)]
Auto merge of #66396 - smmalis37:pythontest, r=alexcrichton
Make a test compatible across python versions.
Progress on #65063
This PR allows this test to work on both python2 and python3, ~~and it also allows `./x.py test` to fully complete on my system without python2 installed at all.~~
bors [Mon, 18 Nov 2019 03:06:42 +0000 (03:06 +0000)]
Auto merge of #66238 - ehuss:stabilize-rustdoc-edition, r=GuillaumeGomez
rustdoc: Stabilize `edition` annotation.
The rustdoc `edition` annotation is currently ignored on stable. This means that the tests will be ignored, unless there is a `rust` annotation, then it will use the global edition. I suspect this was just an oversight during the edition stabilization, but I don't know. Example:
```rust
/// ```edition2018
/// // This code block was ignored on stable.
/// ```
/// ```rust,edition2018
/// // This code block would use whatever edition is passed on the command line.
/// ```
```
AFAIK, it is not possible to write a test that verifies stable behavior, as all tests appear to set RUSTC_BOOTSTRAP which forces all tests to run as "nightly", even on a stable release.
bors [Mon, 18 Nov 2019 00:05:38 +0000 (00:05 +0000)]
Auto merge of #65456 - estebank:trait-bound-borrow, r=matthewjasper
Suggest borrowing when it would satisfy an unmet trait bound
When there are multiple implementors for the same trait that is present
in an unmet binding, modify the E0277 error to refer to the parent
obligation and verify whether borrowing the argument being passed in
would satisfy the unmet bound. If it would, suggest it.
bors [Sun, 17 Nov 2019 18:38:15 +0000 (18:38 +0000)]
Auto merge of #66385 - ecstatic-morse:check-only-pass2, r=eddyb
Make dataflow-based const qualification the canonical one
For over a month, dataflow-based const qualification has been running in parallel with `qualify_consts` to check the bodies of `const` and `static`s. This PR removes the old qualification pass completely in favor of the dataflow-based one.
**edit:**
This PR also stops checking `QUALIF_ERROR_BIT` during promotion. This check appears to no longer serve a purpose now that the CTFE engine is more robust.