| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Turn sufficiently old compatibility lints into hard errors
It's been almost 7 months since https://github.com/rust-lang/rust/pull/36894 was merged, so it's time to take the next step.
[breaking-change], needs crater run.
PRs/issues submitted to affected crates:
https://github.com/alexcrichton/ctest/pull/17
https://github.com/Sean1708/rusty-cheddar/pull/55
https://github.com/m-r-r/helianto/pull/3
https://github.com/azdle/virgil/pull/1
https://github.com/rust-locale/rust-locale/issues/24
https://github.com/mneumann/acyclic-network-rs/pull/1
https://github.com/reem/rust-typemap/pull/38
cc https://internals.rust-lang.org/t/moving-forward-on-forward-compatibility-lints/4204
cc https://github.com/rust-lang/rust/issues/34537 https://github.com/rust-lang/rust/issues/36887
Closes https://github.com/rust-lang/rust/issues/36886
Closes https://github.com/rust-lang/rust/issues/36888
Closes https://github.com/rust-lang/rust/issues/36890
Closes https://github.com/rust-lang/rust/issues/36891
Closes https://github.com/rust-lang/rust/issues/36892
r? @nikomatsakis
|
|
|
|
|
|
Translate array drop glue using MIR
I was a bit lazy here and used a usize-based index instead of a pointer iteration. Do you think this is important @eddyb?
r? @eddyb
|
|
|
|
Fixes #41888.
|
|
This fixes leakage on panic with arrays & slices. I am using a C-style
for-loop instead of a pointer-based loop because that would be ugly-er
to implement.
|
|
extend `struct_tail` to operate over tuples
Not 100% sure why this got exposed when it wasn't before, but this struct definitely seems wrong.
Fixes #42110
r? @eddyb
|
|
Stabilize non capturing closure to fn coercion
Stabilisation PR for non capturing closure to fn coercion.
closes #39817
|
|
|
|
|
|
|
|
Remove superfluous `;;` sequences
Ran across a doubled `;;` in the docstring for `str::split`. Grep found a few more. :)
|
|
add thiscall calling convention support
This support is needed for bindgen to work well on 32-bit Windows, and also enables people to begin experimenting with C++ FFI support on that platform.
Fixes #42044.
|
|
Initial implementation of declarative macros 2.0
Implement declarative macros 2.0 (rust-lang/rfcs#1584) behind `#![feature(decl_macro)]`.
Differences from `macro_rules!` include:
- new syntax: `macro m(..) { .. }` instead of `macro_rules! m { (..) => { .. } }`
- declarative macros are items:
```rust
// crate A:
pub mod foo {
m!(); // use before definition; declaration order is irrelevant
pub macro m() {} // `pub`, `pub(super)`, etc. work
}
fn main() {
foo::m!(); // named like other items
{ use foo::m as n; n!(); } // imported like other items
}
pub use foo::m; // re-exported like other items
// crate B:
extern crate A; // no need for `#[macro_use]`
A::foo::m!(); A::m!();
```
- Racket-like hygiene for items, imports, methods, fields, type parameters, privacy, etc.
- Intuitively, names in a macro definition are resolved in the macro definition's scope, not the scope in which the macro is used.
- This [explaination](http://beautifulracket.com/explainer/hygiene.html) of hygiene for Racket applies here (except for the "Breaking Hygiene" section). I wrote a similar [explanation](https://github.com/jseyfried/rfcs/blob/hygiene/text/0000-hygiene.md) for Rust.
- Generally speaking, if `fn f() { <body> }` resolves, `pub macro m() { <body> } ... m!()` also resolves, even if `m!()` is in a separate crate.
- `::foo::bar` in a `macro` behaves like `$crate::foo::bar` in a `macro_rules!`, except it can access everything visible from the `macro` (thus more permissive).
- See [`src/test/{run-pass, compile-fail}/hygiene`](https://github.com/rust-lang/rust/pull/40847/commits/afe7d89858fd72b983e24727d6f4058293153c19) for examples. Small example:
```rust
mod foo {
fn f() { println!("hello world"); }
pub macro m() { f(); }
}
fn main() { foo::m!(); }
```
Limitations:
- This does not address planned changes to matchers (`expr`,`ty`, etc.), c.f. #26361.
- Lints (including stability and deprecation) and `unsafe` are not hygienic.
- adding hygiene here will be mostly or entirely backwards compatible
- Nested macro definitions (a `macro` inside another `macro`) don't always work correctly when invoked from external crates.
- pending improvements in how we encode macro definitions in crate metadata
- There is no way to "escape" hygiene without using a procedural macro.
r? @nrc
|
|
Refactor: Move the mutable parts out of LintStore. Fix #42007.
* #42007 happens because the `Session` `LintStore` is emptied when linting.
* The `Session` `LintStore` is emptied because the checker (`Early`/`LateContext`) wants ownership.
* The checker wants ownership because it wants to mutate the pass objects and lint levels.
The ownership of the whole store is not essential, only the lint levels and pass objects need to be owned. Therefore, these parts are extracted out of the `LintStore` into a separate structure `LintSession`. The "check crates" methods can operate on `&mut LintSession` instead of `&mut LintStore`.
This is a minor *breaking change* for lint writers since the `LintContext` trait is changed: the `mut_lints` and `level_stack` methods are removed. But no one outside of `librustc/lint/context.rs` is using these functions, so it should be safe.
|
|
|
|
The easy parts of RFC 1859. (Just the trait and the lowering, none of
the error message improvements nor the insta-stable impl for Option.)
|
|
Stabilize rfc 1506 - Clarified ADT Kinds
Closes #35626
Documentation:
- [ ] Reference rust-lang-nursery/reference#37
- [ ] Book?
- [ ] Rust by example?
|
|
|
|
|
|
|
|
Make RangeInclusive just a two-field struct
Not being an enum improves ergonomics and consistency, especially since NonEmpty variant wasn't prevented from being empty. It can still be iterable without an extra "done" bit by making the range have !(start <= end), which is even possible without changing the Step trait.
Implements merged https://github.com/rust-lang/rfcs/pull/1980; tracking issue https://github.com/rust-lang/rust/issues/28237.
This is definitely a breaking change to anything consuming `RangeInclusive` directly (not as an Iterator) or constructing it without using the sugar. Is there some change that would make sense before this so compilation failures could be compatibly fixed ahead of time?
r? @aturon (as FCP proposer on the RFC)
|
|
This support is needed for bindgen to work well on 32-bit Windows, and
also enables people to begin experimenting with C++ FFI support on that
platform.
Fixes #42044.
|
|
|
|
Stabilize the loop_break_value feature
Tracking issue: #37339.
Documentation PRs already sent to the various repositories.
|
|
withoutboats:run-pass-test-for-static-in-assoc-const-ty-refs, r=eddyb
Remove 'static bound in assoc const test.
Types do not have to be `'static` to be referenced in
associated consts.
Fixes #33573.
|
|
Types do not have to be `'static` to be referenced in
associated consts.
|
|
Fixes https://github.com/rust-lang/rust/issues/42135
Found while fixing run-pass/range_inclusive test failure.
|
|
Remove interior mutability from TraitDef by turning fields into queries
This PR gets rid of anything `std::cell` in `TraitDef` by
- moving the global list of trait impls from `TraitDef` into a query,
- moving the list of trait impls relevent for some self-type from `TraitDef` into a query
- moving the specialization graph of trait impls into a query, and
- moving `TraitDef::object_safety` into a query.
I really like how querifying things not only helps with incremental compilation and on-demand, but also just plain makes the code cleaner `:)`
There are also some smaller fixes in the PR. Commits can be reviewed separately.
r? @eddyb or @nikomatsakis
|
|
|
|
* #42007 happens because the Session LintStore is emptied when linting.
* The Session LintStore is emptied because the checker (Early/LateContext)
wants ownership.
* The checker wants ownership because it wants to mutate the pass objects
and lint levels.
The ownership of the whole store is not essential, only the lint levels and
pass objects need to be owned. Therefore, these parts are extracted out of
the LintStore into a separate structure `LintSession`. The "check crates"
methods can operate on `&mut LintSession` instead of `&mut LintStore`.
This is a minor BREAKING CHANGE for lint writers since the `LintContext`
trait is changed: the `mut_lints` and `level_stack` methods are removed.
But no one outside of `librustc/lint/context.rs` is using these functions,
so it should be safe.
|
|
avoid cycles in mir-dump, take 2
This fixes #41697, for real this time, but I'm not sure how best to add a regression test. I was considering maybe adding some flag so that the MIR dumping doesn't actually get written to files (e.g., overloading the directory flag so you can specify nil or something).
cc @dwrensha @oli-obk
|
|
nikomatsakis:issue-41936-variance-coerce-unsized-cycle, r=eddyb
use equality in the coerce-unsized check
This seems both to be a safe, conservative choice, and it sidesteps the cycle in #41849. Note that, before I converted variance into proper queries, we were using a hybrid of subtyping and equality, due to the presence of a flag that forced invariance if variance had not yet been computed. (Also, Coerce Unsized is unstable.)
Fixes #41936.
r? @eddyb
|
|
Fix regression in `macro_rules!` name matching
Fixes #41803.
r? @nrc
|
|
|
|
|
|
This seems both to be a safe, conservative choice,
and it sidesteps the cycle in #41936.
Fixes #41936.
|
|
|
|
Disallow ._ in float literal.
This patch makes lexer stop parsing number literals before `._`, as well as before `.a`. Underscore itself is still allowed like in `4_000_000.000_000_`.
Fixes a half part of #41723. The other is `""_`.
|
|
rustc_resolve: don't deny outer type parameters in embedded constants.
This solves a problem noted at https://github.com/rust-lang/rust/issues/29646#issuecomment-300929548, where an associated const default in a trait couldn't refer to `Self` or type parameters, due to inaccuracies in lexical scoping.
I've also allowed "embedded expressions" (`[T; expr]`, `[x; expr]`, `typeof expr`) to refer to type parameters in scope. *However*, the typesystem still doesn't handle #34344.
Fully resolving that issue requires breaking cycles more aggressively (e.g. lazy evaluation), *even* in when the expression doesn't depend on type parameters, to type-check it at all, and then also type-level "constant projections" (in the vein of `{expr}` from const generics).
|
|
|
|
remove the #[inline] attribute from drop_in_place
Apparently LLVM has exponential code growth while inlining landing pads
if that attribute is present.
Fixes #41696.
beta-nominating because regression.
r? @eddyb
|
|
|
|
rustc_trans: do not attempt to truncate an i1 const to i1.
Fixes #41744 by skipping the truncation when it'd be a noop anyway.
|
|
|
|
enforce WF conditions after generalizing
Add a `WF(T')` obligation after generalizing `T` to `T'`, if `T'` contains an unconstrained type variable in a bivariant context.
Fixes #41677.
Beta nominating -- regression.
r? @arielb1
|
|
|
|
Apparently LLVM has exponential code growth while inlining landing pads
if that attribute is present.
Fixes #41696.
|
|
|
