Auto merge of #64272 - Mark-Simulacrum:parallel-handler, r=estebank
Refactor librustc_errors::Handler API
This should be reviewed by-commit.
The last commit moves all fields into an inner struct behind a single lock; this is done to prevent possible deadlocks in a multi-threaded compiler, as well as inconsistent state observation.
Auto merge of #64695 - Centril:rollup-t1xnl2c, r=Centril
Rollup of 7 pull requests
Successful merges:
- #64294 (Fix `Stdio::piped` example code and lint)
- #64670 (Cleanup syntax::ext::build)
- #64674 (Propagate `types.err` in locals further to avoid spurious knock-down errors)
- #64676 (Parse assoc type bounds in generic params and provide custom diagnostic)
- #64677 (remove outdated comment)
- #64679 (Infer consts more consistently)
- #64688 (Clarify the "since" tidy check)
Rollup merge of #64679 - skinny121:const-infer, r=varkor
Infer consts more consistently
Moved some duplicated logic in `TypeRelation` methods into `super_combined_consts`. Before some `TypeRelation`s like `Lub` wasn't using `replace_if_possible`, meaning some inference types were staying around longer than they should be.
Rollup merge of #64670 - Mark-Simulacrum:ext-build-simplify, r=petrochenkov
Cleanup syntax::ext::build
I suspect most of this code could be inlined but I only removed the bits where the inlining didn't really hurt readability (i.e., method call -> function call) or the completely unused code.
Rollup merge of #64294 - wchargin:wchargin-stdio-piped-docs, r=Dylan-DPC
Fix `Stdio::piped` example code and lint
Summary:
Invoking `rev` does not add a trailing newline when none is present in
the input (at least on my Debian). Nearby examples use `echo` rather
than `rev`, which probably explains the source of the discrepancy.
Also, a `mut` qualifier is unused.
Test Plan:
Copy the code block into <https://play.rust-lang.org> with a `fn main`
wrapper, and run it. Note that it compiles and runs cleanly; prior to
this commit, it would emit an `unused_mut` warning and then panic.
Auto merge of #64666 - Centril:rollup-tp98vlr, r=Centril
Rollup of 9 pull requests
Successful merges:
- #63907 (Add explanation to type mismatch involving type params and assoc types)
- #64615 (rustbuild: Turn down compression on exe installers)
- #64617 (rustbuild: Turn down compression on msi installers)
- #64618 (rustbuild: Improve output of `dist` step)
- #64619 (Fixes #63962. Hint about missing tuple parentheses in patterns)
- #64634 (Update to LLVM 9.0.0)
- #64635 (Allow using fn pointers in const fn with unleash miri)
- #64660 (unify errors for tuple/struct variants)
- #64664 (fully remove AstBuilder)
let x: i32 = foo(non_const_fn_ptr); // OK
let y: i32 = foo(const_fn_ptr); // OK
const X: i32 = foo(non_const_fn_ptr); // ERROR: `non_const_fn` is not `const fn`
const Y: i32 = foo(const_fn_ptr); // OK
```
Rollup merge of #64618 - alexcrichton:improve-dist-output, r=Mark-Simulacrum
rustbuild: Improve output of `dist` step
* Pass `/Q` to `iscc` on Windows to supress the thousands of lines of
output about compressing documentation.
* Print out what's happening before long steps
* Use `timeit` to print out timing information for long-running
installer assemblies.
* Try to scope output of `Dist ...` to not also encompass actual build steps
Rollup merge of #64617 - alexcrichton:smaller-msi, r=Mark-Simulacrum
rustbuild: Turn down compression on msi installers
This is the same as #64615 except applied to our MSI installers. The
same fix is applied effectively bringing these installers in line with
the gz tarball installers, which are about 3x faster to produce locally
and likely much faster to produce on CI.
Rollup merge of #64615 - alexcrichton:smaller-exe, r=Mark-Simulacrum
rustbuild: Turn down compression on exe installers
The Windows dist builders are the slowest builders right now, and the
distribution phase of them is enormously slow clocking in at around 20
minutes to build all the related installers. This commit starts to
optimize these by turning down the compression level in the `exe`
installers. These aren't super heavily used so there's no great need for
them to be so ultra-compressed, so let's dial back the compression
parameters to get closer to the rest of our xz archives. This brings the
installer in line with the gz tarball installer locally, and also brings
the compression settings on par with the rest of our xz installers.
Auto merge of #64658 - Centril:rollup-9s3raz6, r=Centril
Rollup of 9 pull requests
Successful merges:
- #64010 (Stabilize `param_attrs` in Rust 1.39.0)
- #64136 (Document From trait for LhsExpr in parser)
- #64342 (factor out pluralisation remains after #64280)
- #64347 (Add long error explanation for E0312)
- #64621 (Add Compatibility Notes to RELEASES.md for 1.38.0)
- #64632 (remove the extra comma after the match arm)
- #64640 (No home directory on vxWorks)
- #64641 (Exempt extern "Rust" from improper_ctypes)
- #64642 (Fix the span used to suggest avoiding for-loop moves)
Rollup merge of #64642 - cuviper:move-for-loop-snippet, r=varkor
Fix the span used to suggest avoiding for-loop moves
It was using the snippet from the "use" span, which often renders the
same, but with closures that snippet is on the start of the closure
where the value is captured. We should be using the snippet from the
span where it was moved into the `for` loop, which is `move_span`.
there are two case that doesn't not match the original macro pattern at [here](https://github.com/rust-lang/rust/blob/master/src/librustc_lint/unused.rs#L146) and [here](https://github.com/rust-lang/rust/blob/master/src/libsyntax/parse/diagnostics.rs#L539) as the provided param is already a bool or the check condition is not `x != 1`, so I change the macro accept a boolean expr instead of number to fit all the cases.
Rollup merge of #64136 - crgl:doc-from-parser-lhs, r=Centril
Document From trait for LhsExpr in parser
Add doc for From trait for converting P<Expr> and Option<ThinVec<Attribute>> to LhsExpr
As part of issue rust-lang#51430 (cc @skade).
Both of these should just be moving an address and setting a discriminant in an enum. The main thing I'm not sure about is whether it's worth documenting the branch in the From<Option<ThinVec<Attribute>>. As far as I can tell it doesn't seem like it is optimized away (although if the discriminant happened to work out you could just copy the pointer and the discriminant which might be cheaper, but that's not guaranteed). So it seems like if it's being called often, it's doubling the number of possible branch mispredictions on this Option, which could be a significant cost.
Let me know if there's anything that needs fixing and I'll get to it as soon as possible!
* Documentation comments like `/// Doc` on parameters.
* Code expansion of a user-defined `#[proc_macro_attribute]` macro used on parameters.
* Built-in attributes other than `cfg`, `cfg_attr`, `allow`, `warn`, `deny`, and `forbid`. Currently, only the lints `unused_variables` and `unused_mut` have effect and may be controlled on parameters.
## Motivation
The chief motivations for stabilizing `param_attrs` include:
* Finer conditional compilation with `#[cfg(..)]` and linting control of variables.
* Richer macro DSLs created by users.
* External tools and compiler internals can take advantage of the additional information that the parameters provide.
For more examples, see the [RFC][rfc motivation].
## Reference guide
In the grammar of function and function pointer, the grammar of variadic tails (`...`) and parameters are changed respectively from:
More generally, where there's a list of formal (value) parameters separated or terminated by `,` and delimited by `(` and `)`. Each parameter in that list may optionally be prefixed by `OuterAttr+`.
Note that in all cases, `OuterAttr*` applies to the whole parameter and not just the pattern. This distinction matters in pretty printing and in turn for macros.
## History
* On 2018-10-15, @Robbepop proposes [RFC 2565][rfc], "Attributes in formal function parameter position".
* On 2019-04-30, [RFC 2565][rfc] is merged and the tracking issue is made.
* On 2019-06-12, a partial implementation was completed. The implementation was done in [#60669][60669] by @c410-f3r and the PR was reviewed by @petrochenkov and @Centril.
* On 2019-07-29, [#61238][61238] was fixed in [#61856][61856]. The issue fixed was that lint attributes on function args had no effect. The PR was written by @c410-f3r and reviewed by @matthewjasper, @petrochenkov, and @oli-obk.
* On 2019-08-02, a bug [#63210][63210] was filed wherein the attributes on formal parameters would not be passed to macros. The issue was about forgetting to call the relevant method in `fn print_arg` in the pretty printer. In [#63212][63212], written by @Centril on 2019-08-02 and reviewed by @davidtwco, the issue aforementioned was fixed.
* This PR stabilizes `param_attrs`.
## Tests
* [On Rust 2018, attributes aren't permitted on function parameters without a pattern in trait definitions.](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-2018.rs)
* [All attributes that should be allowed. This includes `cfg`, `cfg_attr`, and lints check attributes.](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-allowed.rs)
* [Built-in attributes, which should be forbidden, e.g., `#[test]`, are.](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-builtin-attrs.rs)
* [`cfg` and `cfg_attr` are properly evaluated.](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-cfg.rs)
* [`unused_mut`](https://github.com/rust-lang/rust/blob/46f405ec4d7c6bf16fc2eaafe7541019f1da2996/src/test/ui/rfc-2565-param-attrs/param-attrs-cfg.rs) and [`unused_variables`](https://github.com/rust-lang/rust/blob/master/src/test/ui/lint/lint-unused-variables.rs) are correctly applied to parameter patterns.
* [Pretty printing takes formal parameter attributes into account.](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-pretty.rs)
## Possible future work
* Custom attributes inside function parameters aren't currently supported but it is something being worked on internally.
* Since documentation comments are syntactic sugar for `#[doc(...)]`, it is possible to allow literal `/// Foo` comments on function parameters.
`min_by` and `max_by` are somewhat trivial to implement, but not entirely because `min_by` returns the first value in case the two are equal (and `max_by` the second). `min` and `max` can be implemented in terms of `min_by` and `max_by`, but not as easily the other way around.
To give an example of why I think these functions could be useful: the `Iterator::{min_by, min_by_key, max_by, max_by_key}` methods all currently hard-code the behavior mentioned above which is an ever so small duplication of logic. If we delegate them to `cmp::{min_by, max_by}` methods instead, we get the correct behavior for free. (edit: this is now included in the PR)
I added `min_by_key` / `max_by_key` for consistency's sake but I wouldn't mind removing them. I don't have a particular use case in mind for them, and `min_by` / `max_by` seem to be more useful.
Josh Stone [Fri, 20 Sep 2019 23:06:32 +0000 (16:06 -0700)]
Fix the span used to suggest avoiding for-loop moves
It was using the snippet from the "use" span, which often renders the
same, but with closures that snippet is on the start of the closure
where the value is captured. We should be using the snippet from the
span where it was moved into the `for` loop, which is `move_span`.
Auto merge of #64584 - nikomatsakis:issue-64477-generator-capture-types, r=eddyb
record fewer adjustment types in generator witnesses, avoid spurious drops in MIR construction
Don't record all intermediate adjustment types -- That's way more than is needed, and winds up recording types that will never appear in MIR.
Note: I'm like 90% sure that this logic is correct, but this stuff is subtle and can be hard to keep straight. However, the risk of this PR is fairly low -- if we miss types here, I believe the most common outcome is an ICE.
This fixes the original issue cited by #64477, but I'm leaving the issue open for now since there may be other cases we can detect and improve in a targeted way.
Auto merge of #64553 - alexcrichton:windows-bash-install-scripts, r=Mark-Simulacrum
azure: Convert Windows installations scripts to `bash`
Looks like `script`, which uses `cmd.exe`, doesn't have fail-fast
behavior and if a leading command fails the script doesn't actually fail
so long as the last command succeeds. We instead want the opposite
behavior where if any step fails the whole script fails.
I don't really know `cmd.exe` that well, nor powershell, so I've opted
to move everything to `bash` which should be a good common denominator
amongst all platforms to work with. Additionally I know that `set -e`
works to cause scripts to fail fast.
Auto merge of #64576 - pietroalbini:split-aws-tokens, r=alexcrichton
ci: split aws credentials in two separate users with scoped perms
This commit changes our CI to use two separate IAM users to authenticate with AWS:
* `ci--rust-lang--rust--sccache`: has access to the `rust-lang-ci-sccache2` S3 bucket and its credentials are available during the whole build.
* `ci--rust-lang--rust--upload`: has access to the `rust-lang-ci2` S3 bucket and its credentials are available just during the upload step.
The new tokens are available in the `prod-credentials` library.
Alex Crichton [Thu, 19 Sep 2019 18:22:55 +0000 (11:22 -0700)]
rustbuild: Improve output of `dist` step
* Pass `/Q` to `iscc` on Windows to supress the thousands of lines of
output about compressing documentation.
* Print out what's happening before long steps
* Use `timeit` to print out timing information for long-running
installer assemblies.
Alex Crichton [Thu, 19 Sep 2019 16:24:42 +0000 (09:24 -0700)]
rustbuild: Turn down compression on msi installers
This is the same as #64615 except applied to our MSI installers. The
same fix is applied effectively bringing these installers in line with
the gz tarball installers, which are about 3x faster to produce locally
and likely much faster to produce on CI.
Rollup merge of #64613 - alexcrichton:less-doc-copies, r=Mark-Simulacrum
rustbuild: Copy crate doc files fewer times
Previously when building documentation for the standard library we'd
copy all the files 5 times, and these files include libcore/libstd docs
which are huge! This commit instead only copies the files after rustdoc
has been run for each crate, reducing the number of redundant copies
we're making.
Rollup merge of #64611 - alexcrichton:no-libstd-twice, r=Mark-Simulacrum
rustbuild: Don't package libstd twice
Looks like the packaging step for the standard library was happening
twice on CI, but it only needs to happen once! The `Analysis` packaging
step accidentally packaged `Std` instead of relying on compiling `Std`,
which meant that we ended up packaging it twice erroneously.
Rollup merge of #64592 - Aaron1011:feature/unreachable-span, r=Centril
Point at original span when emitting unreachable lint
Fixes #64590
When we emit an 'unreachable' lint, we now add a note pointing at the
expression that actually causes the code to be unreachable (e.g.
`return`, `break`, `panic`).
This is especially useful when macros are involved, since a diverging
expression might be hidden inside of a macro invocation.
projects / rust.git / log