There is currently no way to specify the stability level for a trait
impl produced by `deriving`. This patch is a stopgap solution that:
* Turns of stability inheritance for trait impls, and
* Uses the stability level of the *trait* if no level is directly
specified.
That is, manual trait impls may still provide a directly stability
level, but `deriving` will use the level of the trait. While not a
perfect solution, it should be good enough for 1.0 API stabilization, as
we will like *remove* any unwanted impls outright.
r? @alexcrichton
#16081 fixed an issue where a nested return statement would cause incorrect behaviour due to the inner return writing over the return stack slot that had already been written too. However, the check was very broad and picked many cases that wouldn't ever be affected by this issue.
As a result, the number of allocas increased dramatically and therefore stack-size increased. LLVM is not able to remove all of the extraneous allocas. Any code that had multiple return values in a compound expression at the end of a function (including loops) would be hit by the issue.
The check now uses a control-flow graph to only consider the case when the inner return is executed conditionally. By itself, this narrowed definition causes #15763 to return, so the control-flow graph is also used to avoid passing the return slot as a destination when the result won't be used.
This change allows the stack-size of the main rustc task to be reduced to 8MB from 32MB.
read (`//!` is intrusive) and annoying to edit (must maintain a prefix
on every line). Since the only purpose of a `doc.rs` file is to have a
bunch of text, using `/*!` and `*/` without indentations seems
appropriate.
- The following operator traits now take their argument by value: `Neg`, `Not`. This breaks all existing implementations of these traits.
- The unary operation `OP a` now "desugars" to `OpTrait::op_method(a)` and consumes its argument.
[breaking-change]
---
r? @nikomatsakis This PR is very similar to the binops-by-value PR
cc @aturon
followed by a semicolon.
This allows code like `vec![1i, 2, 3].len();` to work.
This breaks code that uses macros as statements without putting
semicolons after them, such as:
fn main() {
...
assert!(a == b)
assert!(c == d)
println(...);
}
It also breaks code that uses macros as items without semicolons:
local_data_key!(foo)
fn main() {
println("hello world")
}
Add semicolons to fix this code. Those two examples can be fixed as
follows:
fn main() {
...
assert!(a == b);
assert!(c == d);
println(...);
}
local_data_key!(foo);
fn main() {
println("hello world")
}
RFC #378.
Closes#18635.
[breaking-change]
There is currently no way to specify the stability level for a trait
impl produced by `deriving`. This patch is a stopgap solution that:
* Turns of stability inheritance for trait impls, and
* Uses the stability level of the *trait* if no level is directly
specified.
That is, manual trait impls may still provide a directly stability
level, but `deriving` will use the level of the trait. While not a
perfect solution, it should be good enough for 1.0 API stabilization, as
we will like *remove* any unwanted impls outright.
