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.
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.
The lexer already ignores CRLF in between tokens, but it doesn't
properly handle carriage returns inside strings and doc comments. Teach
it to treat CRLF as LF inside these tokens, and to disallow carriage
returns that are not followed by linefeeds. This includes handling an
escaped CRLF inside a regular string token the same way it handles an
escaped LF.
This is technically a breaking change, as bare carriage returns are no
longer allowed, and CRLF sequences are now treated as LF inside strings
and doc comments, but it's very unlikely to actually affect any
real-world code.
This change is necessary to have Rust code compile on Windows the same
way it does on Unix. The mozilla/rust repository explicitly sets eol=lf
for Rust source files, but other Rust repositories don't. Notably,
rust-http cannot be compiled on Windows without converting the CRLF line
endings back to LF.
[breaking-change]
The lexer already ignores CRLF in between tokens, but it doesn't
properly handle carriage returns inside strings and doc comments. Teach
it to treat CRLF as LF inside these tokens, and to disallow carriage
returns that are not followed by linefeeds. This includes handling an
escaped CRLF inside a regular string token the same way it handles an
escaped LF.
This is technically a breaking change, as bare carriage returns are no
longer allowed, and CRLF sequences are now treated as LF inside strings
and doc comments, but it's very unlikely to actually affect any
real-world code.
This change is necessary to have Rust code compile on Windows the same
way it does on Unix. The mozilla/rust repository explicitly sets eol=lf
for Rust source files, but other Rust repositories don't. Notably,
rust-http cannot be compiled on Windows without converting the CRLF line
endings back to LF.
[breaking-change]
Replace its usage with byte string literals, except in `bytes!()` tests.
Also add a new snapshot, to be able to use the new b"foo" syntax.
The src/etc/2014-06-rewrite-bytes-macros.py script automatically
rewrites `bytes!()` invocations into byte string literals.
Pass it filenames as arguments to generate a diff that you can inspect,
or `--apply` followed by filenames to apply the changes in place.
Diffs can be piped into `tip` or `pygmentize -l diff` for coloring.
Fixes a codegen bug which generates illegal non-terminated LLVM block
when there are wildcard pattern with guard and enum patterns in a match
expression. Also refactors the code a little.
Closes#14865
This patch consolidates and cleans up the task spawning APIs:
* Removes the problematic `future_result` method from `std::task::TaskBuilder`,
and adds a `try_future` that both spawns the task and returns a future
representing its eventual result (or failure).
* Removes the public `opts` field from `TaskBuilder`, instead adding appropriate
builder methods to configure the task.
* Adds extension traits to libgreen and libnative that add methods to
`TaskBuilder` for spawning the task as a green or native thread.
Previously, there was no way to benefit from the `TaskBuilder` functionality and
also set the scheduler to spawn within.
With this change, all task spawning scenarios are supported through the
`TaskBuilder` interface.
Closes#3725.
[breaking-change]
The nightly builds on linux have been failing over the past few days due to a
malformed LD_LIBRARY_PATH. It appears that the underlying cause is that one of
the tests, dep-info-custom, recursively invokes make but the RUSTC variable
passed down has the string "$LD_LIBRARY_PATH". This is intended to read the
host's original LD_LIBRARY_PATH, but it appears that the makefile is eagerly
expanding the "$L" to nothing, causing the original host's LD_LIBRARY_PATH to be
ignored.
This fix removes passing the string "$LD_LIBRARY_PATH" and rather expands it
eagerly to ensure that escaping doesn't happen at a later stage. I'm still not
entirely sure why the makefile is interpreting the dollar as a variable, but
this seems to fix the issue.
The nightly builds on linux have been failing over the past few days due to a
malformed LD_LIBRARY_PATH. It appears that the underlying cause is that one of
the tests, dep-info-custom, recursively invokes make but the RUSTC variable
passed down has the string "$LD_LIBRARY_PATH". This is intended to read the
host's original LD_LIBRARY_PATH, but it appears that the makefile is eagerly
expanding the "$L" to nothing, causing the original host's LD_LIBRARY_PATH to be
ignored.
This fix removes passing the string "$LD_LIBRARY_PATH" and rather expands it
eagerly to ensure that escaping doesn't happen at a later stage. I'm still not
entirely sure why the makefile is interpreting the dollar as a variable, but
this seems to fix the issue.
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.
thereof.)
PR 14739 injected the new message that this removes from one test
case: borrowck-vec-pattern-loan-from-mut.rs
When reviewing the test case, I was not able to convince myself that
the error message was a legitimate thing to start emitting. Niko did
not see an obvious reason for it either, so I am going to remove it
and wait for someone (maybe Cameron Zwarich) to explain to me why we
should be emitting it.
See #14646 (tracking issue) and rust-lang/rfcs#69.
This does not close the tracking issue, as the `bytes!()` macro still needs to be removed. It will be later, after a snapshot is made with the changes in this PR, so that the new syntax can be used when bootstrapping the compiler.
`#[inline(never)]` is used.
Closes#8958.
This can break some code that relied on the addresses of statics
being distinct; add `#[inline(never)]` to the affected statics.
[breaking-change]
r? @brson
`#[inline(never)]` is used.
Closes#8958.
This can break some code that relied on the addresses of statics
being distinct; add `#[inline(never)]` to the affected statics.
[breaking-change]
This involved a few changes to the local build system:
* Makefiles now prefer our own LD_LIBRARY_PATH over the user's LD_LIBRARY_PATH
in order to support building rust with rust already installed.
* The compiletest program was taught to correctly pass through the aux dir as a
component of LD_LIBRARY_PATH in more situations.
This change was spliced out of #14832 to consist of just the fixes to running
tests without an rpath setting embedded in executables.
