bors [Mon, 26 Aug 2019 04:10:54 +0000 (04:10 +0000)]
Auto merge of #62891 - vext01:improve-black-box-docs, r=RalfJung,Centril,gnzlbg
Improve the documentation for std::hint::black_box.
The other day a colleague was reviewing some of my code which was using `black_box` to block constant propogation. There was a little confusion because the documentation kind of implies that `black_box` is only useful for dead code elimination, and only in benchmarking scenarios.
The docs currently say:
> A function that is opaque to the optimizer, to allow benchmarks to pretend to use outputs to assist in avoiding dead-code elimination.
Here is our discussion, in which I show (using godbolt) that a black box can also block constant propagation:
https://github.com/softdevteam/yk/pull/21#discussion_r302985038
This change makes the docstring for `black_box` a little more general, and while we are here, I've added an example (the same one from our discussion).
bors [Mon, 26 Aug 2019 00:27:17 +0000 (00:27 +0000)]
Auto merge of #62603 - cuviper:no-unwind-abort, r=joshtriplett
Permit unwinding through FFI by default
This repeats #62505 for master (Rust 1.38+), as #58794 is not yet resolved. This is a stopgap until a stable alternative is available, like [RFC 2699](https://github.com/rust-lang/rfcs/pull/2699), as long as progress is being made to that end.
bors [Sun, 25 Aug 2019 19:20:20 +0000 (19:20 +0000)]
Auto merge of #61613 - sinkuu:impl_trait_inline, r=ollie27
Support `impl Trait` in inlined documentation
`impl Trait` in argument position was not properly rendered when inlined from other crates. ([a live example on docs.rs](https://docs.rs/libp2p/0.8.1/libp2p/floodsub/struct.Floodsub.html#method.unsubscribe))
bors [Sun, 25 Aug 2019 04:26:26 +0000 (04:26 +0000)]
Auto merge of #63862 - Centril:match-cleanup, r=oli-obk
typeck: refactor patterns => `pat.rs` + make the `def_bm` algo more declarative
Spurred by the relative difficulty I had in working up an explanation of how default match bindings work in https://github.com/rust-lang/rust/pull/63118#issuecomment-524161584, this PR refactors the type checking of patterns into `pat.rs`.
The PR is probably best read commit-by-commit and includes various changes beyond the following, which are the most important highlights:
- The algorithm for determining `def_bm` is encoded in a more declarative fashion now with important sub-steps divided into functions that make sense as logical units (and as described in the reference). This is done starting with *"extract `is_no_ref_pat`."* to *"extract `calc_default_binding_mode`"*.
- Dedicated functions like `check_pat_{lit,range,ident,tuple,box,ref,slice}` are then introduced for the various kinds of patterns to make things overall more readable.
- `fn check_pat_top(...)` becomes the sole entry point to type checking patterns.
This will take care of initializing the default binding mode (hence: `def_bm`) to `BindByValue` and is called by all contexts that have a pattern that needs to be type checked (functions, `match`, `if let`, `let`, ...). The overall result is that the notion of `def_bm` is internal to checking patterns.
- Various diagnostics are extracted to dedicated functions to disturb the flow of type checking logic less.
bors [Sun, 25 Aug 2019 00:47:28 +0000 (00:47 +0000)]
Auto merge of #63873 - Centril:rollup-jgglypd, r=Centril
Rollup of 6 pull requests
Successful merges:
- #62744 (Refactor `TinyList::contains` and `len` to iterate instead of recurse)
- #63813 (Do not suggest `.try_into()` on `i32::from(x)`)
- #63833 (Suggest calling closure with resolved return type when appropriate)
- #63839 (Ensure miri can do bit ops on pointer values)
- #63854 (Modifies how Arg, Arm, Field, FieldPattern and Variant are visited)
- #63859 (Don't unwrap the result of `span_to_snippet`)
Rollup merge of #63833 - estebank:suggest-closure-call, r=petrochenkov
Suggest calling closure with resolved return type when appropriate
Follow up to #63337. CC #63100.
```
error[E0308]: mismatched types
--> $DIR/fn-or-tuple-struct-without-args.rs:46:20
|
LL | let closure = || 42;
| -- closure defined here
LL | let _: usize = closure;
| ^^^^^^^
| |
| expected usize, found closure
| help: use parentheses to call this closure: `closure()`
|
= note: expected type `usize`
found type `[closure@$DIR/fn-or-tuple-struct-without-args.rs:45:19: 45:24]`
```
typeck/pat.rs: `check_pat_top` is the entry point.
This clarifies the fact that type checking patterns unconditionally
starts with `BindByValue` as the default binding mode making the
notion of a default binding mode internal to type checking patterns.
Changes:
````
Refactor some minor things
Use more if-chains
Refactor 'lint_or_fun_call'
Refactor 'check_unwrap_or_default'
Refactor 'check_impl_item'
Add missing field to LitKind::Str
Run update_lints for Unicode lint
Re-add false positive check
Add raw string regression test for useless_format lint
Re-factor useless_format lint
Update Unicode lint tests
Add two more tests, allow 2 other lints.
Fix `temporary_cstring_as_ptr` false negative
Add more testcases for redundant_pattern_matching
Fix suggestions for redundant_pattern_matching
Add note on how to find the latest beta commit
Remove feature gate for async_await
Update if_chain doc link
Requested test cleanup
Requested changes
Ignore lines starting with '#'
run-rustfix for unseparated-prefix-literals
Add autofixable suggestion for unseparated integer literal suffices
Further text improvements
Add image
docs: Explain how to update the changelog
````
Changes:
````
Refactor some minor things
Use more if-chains
Refactor 'lint_or_fun_call'
Refactor 'check_unwrap_or_default'
Refactor 'check_impl_item'
Add missing field to LitKind::Str
Run update_lints for Unicode lint
Re-add false positive check
Add raw string regression test for useless_format lint
Re-factor useless_format lint
Update Unicode lint tests
Add two more tests, allow 2 other lints.
Fix `temporary_cstring_as_ptr` false negative
Add more testcases for redundant_pattern_matching
Fix suggestions for redundant_pattern_matching
Add note on how to find the latest beta commit
Remove feature gate for async_await
Update if_chain doc link
Requested test cleanup
Requested changes
Ignore lines starting with '#'
run-rustfix for unseparated-prefix-literals
Add autofixable suggestion for unseparated integer literal suffices
Further text improvements
Add image
docs: Explain how to update the changelog
````
bors [Sat, 24 Aug 2019 14:07:06 +0000 (14:07 +0000)]
Auto merge of #63823 - petrochenkov:noapply2, r=matthewjasper
Audit uses of `apply_mark` in built-in macros + Remove default macro transparencies
Every use of `apply_mark` in a built-in or procedural macro is supposed to look like this
```rust
location.with_ctxt(SyntaxContext::root().apply_mark(ecx.current_expansion.id))
```
where `SyntaxContext::root()` means that the built-in/procedural macro is defined directly, rather than expanded from some other macro.
However, few people understood what `apply_mark` does, so we had a lot of copy-pasted uses of it looking e.g. like
```rust
span = span.apply_mark(ecx.current_expansion.id);
```
, which doesn't really make sense for procedural macros, but at the same time is not too harmful, if the macros use the traditional `macro_rules` hygiene.
So, to fight this, we stop using `apply_mark` directly in built-in macro implementations, and follow the example of regular proc macros instead and use analogues of `Span::def_site()` and `Span::call_site()`, which are much more intuitive and less error-prone.
- `ecx.with_def_site_ctxt(span)` takes the `span`'s location and combines it with a def-site context.
- `ecx.with_call_site_ctxt(span)` takes the `span`'s location and combines it with a call-site context.
Even if called multiple times (which sometimes happens due to some historical messiness of the built-in macro code) these functions will produce the same result, unlike `apply_mark` which will grow the mark chain further in this case.
---
After `apply_mark`s in built-in macros are eliminated, the remaining `apply_mark`s are very few in number, so we can start passing the previously implicit `Transparency` argument to them explicitly, thus eliminating the need in `default_transparency` fields in hygiene structures and `#[rustc_macro_transparency]` annotations on built-in macros.
So, the task of making built-in macros opaque can now be formulated as "eliminate `with_legacy_ctxt` in favor of `with_def_site_ctxt`" rather than "replace `#[rustc_macro_transparency = "semitransparent"]` with `#[rustc_macro_transparency = "opaque"]`".
bors [Sat, 24 Aug 2019 05:39:52 +0000 (05:39 +0000)]
Auto merge of #63637 - alexcrichton:remove-libtest-step, r=Mark-Simulacrum
bootstrap: Merge the libtest build step with libstd
Since its inception rustbuild has always worked in three stages: one for
libstd, one for libtest, and one for rustc. These three stages were
architected around crates.io dependencies, where rustc wants to depend
on crates.io crates but said crates don't explicitly depend on libstd,
requiring a sysroot assembly step in the middle. This same logic was
applied for libtest where libtest wants to depend on crates.io crates
(`getopts`) but `getopts` didn't say that it depended on std, so it
needed `std` built ahead of time.
Lots of time has passed since the inception of rustbuild, however,
and we've since gotten to the point where even `std` itself is depending
on crates.io crates (albeit with some wonky configuration). This
commit applies the same logic to the two dependencies that the `test`
crate pulls in from crates.io, `getopts` and `unicode-width`. Over the
many years since rustbuild's inception `unicode-width` was the only
dependency picked up by the `test` crate, so the extra configuration
necessary to get crates building in this crate graph is unlikely to be
too much of a burden on developers.
After this patch it means that there are now only two build phasese of
rustbuild, one for libstd and one for rustc. The libtest/libproc_macro
build phase is all lumped into one now with `std`.
This was originally motivated by rust-lang/cargo#7216 where Cargo was
having to deal with synthesizing dependency edges but this commit makes
them explicit in this repository.
bors [Sat, 24 Aug 2019 01:50:03 +0000 (01:50 +0000)]
Auto merge of #63824 - Centril:split-feature_gate, r=oli-obk
Refactor `feature_gate.rs` into modules & cleanup
Split `src/libsyntax/feature_gate.rs` into `src/libsyntax/feature_gate/` with files:
- `accepted.rs` (accepted feature gates)
- `removed.rs` (...)
- `active.rs` (...)
- `builtin_attrs.rs` (definition of builtin attributes and their gates as well as gating `cfg` flags)
- `check.rs` (post expansion checking of feature gates)
- `mod.rs` (just reexports)
Additionally, `tidy.rs` is adjusted to respect the new scheme.
Also, `builtin_attrs.rs` sees some cleanup, organization, and DSL-ification to reduce repetition.
This is probably best read commit-by-commit I think.
Alex Crichton [Fri, 16 Aug 2019 15:29:08 +0000 (08:29 -0700)]
bootstrap: Merge the libtest build step with libstd
Since its inception rustbuild has always worked in three stages: one for
libstd, one for libtest, and one for rustc. These three stages were
architected around crates.io dependencies, where rustc wants to depend
on crates.io crates but said crates don't explicitly depend on libstd,
requiring a sysroot assembly step in the middle. This same logic was
applied for libtest where libtest wants to depend on crates.io crates
(`getopts`) but `getopts` didn't say that it depended on std, so it
needed `std` built ahead of time.
Lots of time has passed since the inception of rustbuild, however,
and we've since gotten to the point where even `std` itself is depending
on crates.io crates (albeit with some wonky configuration). This
commit applies the same logic to the two dependencies that the `test`
crate pulls in from crates.io, `getopts` and `unicode-width`. Over the
many years since rustbuild's inception `unicode-width` was the only
dependency picked up by the `test` crate, so the extra configuration
necessary to get crates building in this crate graph is unlikely to be
too much of a burden on developers.
After this patch it means that there are now only two build phasese of
rustbuild, one for libstd and one for rustc. The libtest/libproc_macro
build phase is all lumped into one now with `std`.
This was originally motivated by rust-lang/cargo#7216 where Cargo was
having to deal with synthesizing dependency edges but this commit makes
them explicit in this repository.
All transparancies are passed explicitly now.
Also remove `#[rustc_macro_transparency]` annotations from built-in macros, they are no longer used.
`#[rustc_macro_transparency]` only makes sense for declarative macros now.
Replace them with equivalents of `Span::{def_site,call_site}` from proc macro API.
The new API is much less error prone and doesn't rely on macros having default transparency.
Rollup merge of #63796 - estebank:opaque_future, r=Centril
Tweak E0308 on opaque types
```
error[E0308]: if and else have incompatible types
--> file.rs:21:9
|
18 | / if true {
19 | | thing_one()
| | ----------- expected because of this
20 | | } else {
21 | | thing_two()
| | ^^^^^^^^^^^ expected opaque type, found a different opaque type
22 | | }.await
| |_____- if and else have incompatible types
|
= note: expected type `impl std::future::Future` (opaque type)
found type `impl std::future::Future` (opaque type)
= note: distinct uses of `impl Trait` result in different opaque types
= help: if both futures resolve to the same type, consider `await`ing on both of them
```
Rollup merge of #63782 - GuillaumeGomez:theme-switch-fix, r=kinnison
Fix confusion in theme picker functions
To reproduce the bug currently: click on the theme picker button twice (to show it then hide it). Then click anywhere else: the dropdown menu appears again.
The problem was coming from a confusion of what the `hideThemeButtonState` and `showThemeButtonState` were supposed to do. I switched their codes and updated the `switchThemeButtonState` function. It now works as expected.
projects / rust.git / log