Rollup merge of #69766 - skade:make-point-copy-in-add-documentation, r=shepmaster
Make Point `Copy` in arithmetic documentation
Small composite types like `Point { x: i32, y: i32}` are plain
old data and we should encourage users to derive `Copy` on them.
This changes the semantics of the edited examples slightly: instead
of consuming the operands during addition, it will copy them. This
is desired behaviour.
Rollup merge of #69591 - matthewjasper:query-response-relate, r=nikomatsakis
Use TypeRelating for instantiating query responses
`eq` can add constraints to `RegionConstraintData`, which isn't allowed during borrow checking outside of a `CustomTypeOp`. Use `TypeRelating` instead to always push constraints to the obligations list.
Rollup merge of #69373 - tspiteri:const_int_conversion, r=oli-obk
Stabilize const for integer {to,from}_{be,le,ne}_bytes methods
All of these functions can be implemented simply and naturally as const functions, e.g. `u32::from_le_bytes` can be implemented as
```rust
(bytes[0] as u32)
| (bytes[1] as u32) << 8
| (bytes[2] as u32) << 16
| (bytes[3] as u32) << 24
```
So stabilizing the constness will not expose that internally they are implemented using transmute which is not const in stable.
bors [Tue, 10 Mar 2020 17:12:48 +0000 (17:12 +0000)]
Auto merge of #66364 - Centril:cleanup-macro-def, r=petrochenkov,eddyb
Cleanup `rmeta::MacroDef`
Avoid using rountrip parsing in the encoder and in `fn load_macro_untracked`.
The main reason I was interested in this was to remove `rustc_parse` as a dependency of `rustc_metadata` but it seems like this had other benefits as well.
Fixes #49511.
r? @eddyb
cc @matthewjasper @estebank @petrochenkov
Florian Gilcher [Fri, 6 Mar 2020 09:37:23 +0000 (10:37 +0100)]
Make Point `Copy` in arithmetic documentation
Small composite types like `Point { x: i32, y: i32}` are plain
old data and we should encourage users to derive `Copy` on them.
This changes the semantics of the edited examples slightly: instead
of consuming the operands during addition, it will copy them. This
is desired behaviour.
bors [Tue, 10 Mar 2020 05:48:27 +0000 (05:48 +0000)]
Auto merge of #69879 - Centril:rollup-ryea91j, r=Centril
Rollup of 10 pull requests
Successful merges:
- #69475 (Remove the `no_force` query attribute)
- #69514 (Remove spotlight)
- #69677 (rustc_metadata: Give decoder access to whole crate store)
- #69714 (Make PlaceRef take just one lifetime)
- #69799 (Allow ZSTs in `AllocRef`)
- #69817 (test(patterns): add patterns feature tests to borrowck test suite)
- #69836 (Check if output is immediate value)
- #69847 (clean up E0393 explanation)
- #69861 (Add note about localization to std::fmt docs)
- #69877 (Vec::new is const stable in 1.39 not 1.32)
This really surprised me when a MSRV check for 1.35 failed with `Vec::new is not yet stable as a const fn` and the docs said that it was const stabilized in 1.32.
Rollup merge of #69799 - TimDiekmann:zst, r=Amanieu
Allow ZSTs in `AllocRef`
Allows ZSTs in all `AllocRef` methods. The implementation of `AllocRef` for `Global` and `System` were adjusted to reflect those changes.
This is the second item on the roadmap to support ZSTs in `AllocRef`: https://github.com/rust-lang/wg-allocators/issues/38#issuecomment-595861542
After this has landed, I will adapt `RawVec`, but since this will be a pretty big overhaul, it makes sense to do a different PR for it.
Rollup merge of #69514 - GuillaumeGomez:remove-spotlight, r=kinnison
Remove spotlight
I had a few comments saying that this feature was at best misunderstood or not even used so I decided to organize a poll about on [twitter](https://twitter.com/imperioworld_/status/1232769353503956994). After 87 votes, the result is very clear: it's not useful. Considering the amount of code we have just to run it, I think it's definitely worth it to remove it.
Perform the "normalization" (renamed to "uninterpolation") on the fly when necessary.
The final part of https://github.com/rust-lang/rust/pull/69579 https://github.com/rust-lang/rust/pull/69384 https://github.com/rust-lang/rust/pull/69376 https://github.com/rust-lang/rust/pull/69211 https://github.com/rust-lang/rust/pull/69034 https://github.com/rust-lang/rust/pull/69006.
r? @Centril
Rollup merge of #69762 - RalfJung:validity-errors, r=oli-obk
Ensure that validity only raises validity errors
For now, only as a debug-assertion (similar to const-prop detecting errors that allocate).
Now includes https://github.com/rust-lang/rust/pull/69646.
[Relative diff](https://github.com/RalfJung/rust/compare/layout-visitor...RalfJung:validity-errors).
Although `stack_overflow::init` runs very early in the process, even
before `main`, there may already be signal handlers installed for things
like the address sanitizer. In that case, just leave it alone, and don't
bother trying to allocate our own signal stacks either.
Rollup merge of #69201 - Aaron1011:feature/permit-if-attr, r=Centril
Permit attributes on 'if' expressions
Previously, attributes on 'if' expressions (e.g. `#[attr] if true {}`)
were disallowed during parsing. This made it impossible for macros to
perform any custom handling of such attributes (e.g. stripping them
away), since a compilation error would be emitted before they ever had a
chance to run.
This PR permits attributes on 'if' expressions ('if-attrs' from here on).
Both built-in attributes (e.g. `#[allow]`, `#[cfg]`) and proc-macro attributes are supported.
We still do *not* accept attributes on 'other parts' of an if-else
chain. That is, the following code snippet still fails to parse:
```rust
if true {} #[attr] else if false {} else #[attr] if false {} #[attr]
else {}
```
Although `stack_overflow::init` runs very early in the process, even
before `main`, there may already be signal handlers installed for things
like the address sanitizer. In that case, just leave it alone, and don't
bother trying to allocate our own signal stacks either.
projects / rust.git / log