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]
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
