Being able to index into the bytes of a string encourages
poor UTF-8 hygiene. To get a view of `&[u8]` from either
a `String` or `&str` slice, use the `as_bytes()` method.
Closes#12710.
[breaking-change]
Part of #14248
Main authors:
- @Ryman: OK
- @TeXitoi: OK
- @pcwalton: OK
Minor authors:
- @brson: OK
- @alexcrichton: OK
- @kballard: OK
Remark: @tedhorst was a main contributor, but its contribution
disapear with @pcwalton rewrite at af4ea11
I ended up altering the semantics of Json's PartialOrd implementation.
It used to be the case that Null < Null, but I can't think of any reason
for an ordering other than the default one so I just switched it over to
using the derived implementation.
This also fixes broken `PartialOrd` implementations for `Vec` and
`TreeMap`.
RFC: 0028-partial-cmp
floating point numbers for real.
This will break code that looks like:
let mut x = 0;
while ... {
x += 1;
}
println!("{}", x);
Change that code to:
let mut x = 0i;
while ... {
x += 1;
}
println!("{}", x);
Closes#15201.
[breaking-change]
This change registers new snapshots, allowing `*T` to be removed from the language. This is a large breaking change, and it is recommended that if compiler errors are seen that any FFI calls are audited to determine whether they should be actually taking `*mut T`.
I believe that #5781 got fixed by the DST work. It duplicated the
variance inference work in #12828. Therefore, all that is left in #5781
is adding a test.
Closes#5781.
r? @huonw
This can break code that looked like:
impl Foo for Box<Any> {
fn f(&self) { ... }
}
let x: Box<Any + Send> = ...;
x.f();
Change such code to:
impl Foo for Box<Any> {
fn f(&self) { ... }
}
let x: Box<Any> = ...;
x.f();
That is, upcast before calling methods.
This is a conservative solution to #5781. A more proper treatment (see
the xfail'd `trait-contravariant-self.rs`) would take variance into
account. This change fixes the soundness hole.
Some library changes had to be made to make this work. In particular,
`Box<Any>` is no longer showable, and only `Box<Any+Send>` is showable.
Eventually, this restriction can be lifted; for now, it does not prove
too onerous, because `Any` is only used for propagating the result of
task failure.
This patch also adds a test for the variance inference work in #12828,
which accidentally landed as part of DST.
Closes#5781.
[breaking-change]
This PR includes two big things and a bunch of little ones.
1) It enables hygiene for variables bound by 'match' expressions.
2) It fixes a bug discovered indirectly (#15221), wherein fold traversal failed to visit nonterminal nodes.
3) It fixes a small bug in the macro tutorial.
It also adds tests for the first two, and makes a bunch of small comment improvements and cleanup.
... and possibly totally pointless. Specifically, fixing
these to make their macros hygienic may mean that they no
longer test the thing that they were supposed to test.
rustc: update the unnecessary parens lint for struct literals.
Things like `match X { x: 1 } { ... }` now need to be written with
parentheses, so the lint should avoid warning in cases like that.
Since procs do not have lifetime bounds, we must do this to maintain
safety.
This can break code that incorrectly captured references in procedure
types. Change such code to not do this, perhaps with a trait object
instead.
A better solution would be to add higher-rank lifetime support to procs.
However, this would be a lot of work for a feature we want to remove in
favor of unboxed closures. The corresponding "real fix" is #15067.
Closes#14036.
[breaking-change]
Most of the comments are available on the Task structure itself, but this commit
is aimed at making FFI-style usage of Rust tasks a little nicer.
Primarily, this commit enables re-use of tasks across multiple invocations. The
method `run` will no longer unconditionally destroy the task itself. Rather, the
task will be internally re-usable if the closure specified did not fail. Once a
task has failed once it is considered poisoned and it can never be used again.
Along the way I tried to document shortcomings of the current method of tearing
down a task, opening a few issues as well. For now none of the behavior is a
showstopper, but it's useful to acknowledge it. Also along the way I attempted
to remove as much `unsafe` code as possible, opting for safer abstractions.
Most of the comments are available on the Task structure itself, but this commit
is aimed at making FFI-style usage of Rust tasks a little nicer.
Primarily, this commit enables re-use of tasks across multiple invocations. The
method `run` will no longer unconditionally destroy the task itself. Rather, the
task will be internally re-usable if the closure specified did not fail. Once a
task has failed once it is considered poisoned and it can never be used again.
Along the way I tried to document shortcomings of the current method of tearing
down a task, opening a few issues as well. For now none of the behavior is a
showstopper, but it's useful to acknowledge it. Also along the way I attempted
to remove as much `unsafe` code as possible, opting for safer abstractions.
It turns out that bindings introduced by 'for' loops were not treated hygienically. The fix for this is to make the 'for' expansion more like a macro; rather than expanding sub-pieces and then assembling them, we need to rewrite the for and then call expand again on the whole thing.
This PR includes a test and the fix.
It also contains a number of other things:
- unit tests for other forms of hygiene (currently ignored)
- a fix for the isaac.rs macro that (it turned out) was relying on capturing
- other miscellaneous cleanup and comments
This will break code like:
fn f(x: &mut int) {}
let mut a = box 1i;
f(a);
Change it to:
fn f(x: &mut int) {}
let mut a = box 1i;
f(&mut *a);
RFC 33; issue #10504.
[breaking-change]
r? @brson
vector-reference-to-unsafe-pointer-to-element cast if the type to be
casted to is not fully specified.
This is a conservative change to fix the user-visible symptoms of the
issue. A more flexible treatment would delay cast checks to after
function typechecking.
This can break code that did:
let x: *u8 = &([0, 0]) as *_;
Change this code to:
let x: *u8 = &([0, 0]) as *u8;
Closes#14893.
[breaking-change]
This will break code like:
fn f(x: &mut int) {}
let mut a = box 1i;
f(a);
Change it to:
fn f(x: &mut int) {}
let mut a = box 1i;
f(&mut *a);
RFC 33; issue #10504.
[breaking-change]
The f128 type has very little support in the compiler and the feature is
basically unusable today. Supporting half-baked features in the compiler can be
detrimental to the long-term development of the compiler, and hence this feature
is being removed.
Closes#14482 (std: Bring back half of Add on String)
Closes#15026 (librustc: Remove the fallback to `int` from typechecking.)
Closes#15119 (Add more description to c_str::unwrap().)
Closes#15120 (Add tests for #12470 and #14285)
Closes#15122 (Remove the cheat sheet.)
Closes#15126 (rustc: Always include the morestack library)
Closes#15127 (Improve ambiguous pronoun.)
Closes#15130 (Fix#15129)
Closes#15131 (Add the Guide, add warning to tutorial.)
Closes#15134 (Xfailed tests for hygiene, etc.)
Closes#15135 (core: Add stability attributes to Clone)
Closes#15136 (Some minor improvements to core::bool)
Closes#15137 (std: Add stability attributes to primitive numeric modules)
Closes#15141 (Fix grammar in tutorial)
Closes#15143 (Remove few FIXMEs)
Closes#15145 (Avoid unnecessary temporary on assignments)
Closes#15147 (Small improvements for metaprogramming)
Closes#15153 (librustc: Check function argument patterns for legality of by-move)
Closes#15154 (test: Add a test for regions, traits, and variance.)
Closes#15159 (rustc: Don't register syntax crates twice)
Closes#13816 (Stabilize version output for rustc and rustdoc)
bindings.
This will break code that incorrectly did things like:
fn f(a @ box b: Box<String>) {}
Fix such code to not rely on undefined behavior.
Closes#12534.
[breaking-change]
It was previously assumed that the object file generated by LLVM would always
require the __morestack function, but that assumption appears to be incorrect,
as outlined in #15108. This commit forcibly tells the linker to include the
entire archive, regardless of whether it's currently necessary or not.
Closes#15108
The #14869 removed `TraitStore` from `ty_trait` and represented trait
reference as regular `ty_rptr`. An old bug of the missing constraint
upon lifetime parameter of trait reference then is fixed as a side
effect. Adds tests for affected bugs and closes them.
Closes#12470.
Closes#14285.
This breaks a fair amount of code. The typical patterns are:
* `for _ in range(0, 10)`: change to `for _ in range(0u, 10)`;
* `println!("{}", 3)`: change to `println!("{}", 3i)`;
* `[1, 2, 3].len()`: change to `[1i, 2, 3].len()`.
RFC #30. Closes#6023.
[breaking-change]
The f128 type has very little support in the compiler and the feature is
basically unusable today. Supporting half-baked features in the compiler can be
detrimental to the long-term development of the compiler, and hence this feature
is being removed.
This is a rebase of #14804 with two new commits on top to implement and test lint plugins.
r? @alexcrichton @huonw: Can you take a look at the new commits, and also weigh in about any issues from the old PR that you feel are still unresolved? I'm leaving the old branch alone to preserve discussion history.
It was accidentally removed in #15006 and that somehow got past the
build bots, causing `src/test/run-make/c-dynamic-dylib` to fail on at
least my linux system.
This resolves#15103 (thanks to @alexcrichton!).
Includes a bit more comments than usual for a regression test; I felt like documenting Niko's diagnosis of the original problem here.
Fix#15111
r? anyone.
If you define lang items in your crate, add `#[feature(lang_items)]`.
If you define intrinsics (`extern "rust-intrinsic"`), add
`#[feature(intrinsics)]`.
Closes#12858.
[breaking-change]
It was accidentally removed in #15006 and that somehow got past the
build bots, causing `src/test/run-make/c-dynamic-dylib` to fail on at
least my linux system.
This resolves#15103 (thanks to @alexcrichton!).
Unit-like structs are written as `struct Foo;`, but we erroneously
accepted `struct Foo();` and took it to mean the same thing. Now we
don't, so use the `struct Foo;` form!
[breaking-change]
When calling a foreign function, some arguments and/or return value
attributes are required to conform to the foreign ABI. Currently those
attributes are only added to the declaration of foreign functions. With
direct calls, this is no problem, because LLVM can see that those
attributes apply to the call. But with an indirect call, LLVM cannot do
that and the attribute is missing.
To fix that, we have to add those attribute to the calls to foreign
functions as well.
This also allows to remove the special handling of the SRet attribute,
which is ABI-dependent and will be set via the `attr` field of the
return type's `ArgType`.
This commit makes several changes to the stability index infrastructure:
* Stability levels are now inherited lexically, i.e., each item's
stability level becomes the default for any nested items.
* The computed stability level for an item is stored as part of the
metadata. When using an item from an external crate, this data is
looked up and cached.
* The stability lint works from the computed stability level, rather
than manual stability attribute annotations. However, the lint still
checks only a limited set of item uses (e.g., it does not check every
component of a path on import). This will be addressed in a later PR,
as part of issue #8962.
* The stability lint only applies to items originating from external
crates, since the stability index is intended as a promise to
downstream crates.
* The "experimental" lint is now _allow_ by default. This is because
almost all existing crates have been marked "experimental", pending
library stabilization. With inheritance in place, this would generate
a massive explosion of warnings for every Rust program.
The lint should be changed back to deny-by-default after library
stabilization is complete.
* The "deprecated" lint still warns by default.
The net result: we can begin tracking stability index for the standard
libraries as we stabilize, without impacting most clients.
Closes#13540.
This PR is changing the error messages for non-exhaustive pattern matching to include a more accurate witness, i.e. a pattern that is not covered by any of the ones provided by the user. Example:
```rust
fn main() {
match (true, (Some("foo"), [true, true]), Some(42u)) {
(false, _, _) => (),
(true, (None, [true, _]), None) => (),
(true, (None, [false, _]), Some(1u)) => ()
}
}
```
```sh
/tmp/witness.rs:2:2: 6:3 error: non-exhaustive patterns: (true, (core::option::Some(_), _), _) not covered
/tmp/witness.rs:2 match (true, (Some("foo"), [true, true]), Some(42u)) {
/tmp/witness.rs:3 (false, _, _) => (),
/tmp/witness.rs:4 (true, (None, [true, _]), None) => (),
/tmp/witness.rs:5 (true, (None, [false, _]), Some(1u)) => ()
/tmp/witness.rs:6 }
```
As part of that, I refactored some of the relevant code and carried over the changes to fixed vectors from the previous PR.
I'm putting it out there for now but the tests will be red.
Closes#8142.
This is not the semantics we want long-term. You can continue to use
`#[unsafe_destructor]`, but you'll need to add
`#![feature(unsafe_destructor)]` to the crate attributes.
[breaking-change]
r? @alexcrichton
Closes#8142.
This is not the semantics we want long-term. You can continue to use
`#[unsafe_destructor]`, but you'll need to add
`#![feature(unsafe_destructor)]` to the crate attributes.
[breaking-change]
The parser already has special logic for parsing `>` tokens from `>>`, and this
commit extends the logic to the acquiring a `>` from the `>=` and `>>=` tokens
as well.
Closes#15043
This test was added long time ago and marked as ignored.
The same test was added later in #8485 as run-fail/issue-3907.rs,
but the old one was not deleted.
