| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
Use multiline note for trait suggestion
|
|
|
|
Change for-loop desugar to not borrow the iterator during the loop
This is enables the use of suspend points inside for-loops in movable generators. This is illegal in the current desugaring as `iter` is borrowed across the body.
|
|
Better suggestion for unknown method
r? @Manishearth
fixes #42386
|
|
Add E0603 error code
Part of #42229.
cc @Susurrus
|
|
Extend the unused macro lint to macros 2.0
Extends the unused macro lint (added in PR #41907) to macros 2.0 (added in PR #40847).
r? @jseyfried
|
|
rustc: remove temporary lifetime extension by borrow hint
closes #39283.
Thanks to @nikomatsakis for mentoring on this one.
r? @arielb1
|
|
Fixes #42386
|
|
|
|
|
|
|
|
now we grow the type-sizes info during execution, rather than walking
the cache after the fact
|
|
|
|
associated_consts: check trait obligations and regionck for associated consts
Closes #41323
r? @nikomatsakis
|
|
|
|
|
|
Closes #41323
|
|
|
|
|
|
|
|
Don't warn on lifetime generic no_mangle functions.
Fixes #40342.
|
|
New error codes
Part of #42229.
|
|
r=arielb1
Prohibit parenthesized params in more types.
Prohibit parenthesized parameters in primitive types, type parameters, `Self`, etc.
Fixes #32995.
|
|
Don't ICE with nested enums in missing docs lint.
Fixes #40350.
|
|
|
|
Allow variadic functions with cdecl calling convention.
Fixes #40244.
|
|
regression test for #39974
closes #39974
r? @Mark-Simulacrum
|
|
Remove all instances of fragment_infos and fragment sets
Remove unused fragment structs. This was suggested by @eddyb in IRC: [botbot link](https://botbot.me/mozilla/rustc/2017-05-23/?msg=86016574&page=2).
|
|
Stabilize non capturing closure to fn coercion
Stabilisation PR for non capturing closure to fn coercion.
closes #39817
|
|
|
|
This also simplifies the lint by not storing variant depth or the struct
def stack, because we no longer need them.
|
|
|
|
|
|
|
|
regression tests for ICEs
closes #36379
closes #37550
closes #37665
closes #38160
closes #38954
closes #39362
r? @Mark-Simulacrum
|
|
Fix 'associate type' typo
I came across an error message mentioning an 'associate type'.
Since this is the only instance of this term in rustc (it's 'associated type' everywhere else), I think this might be a typo.
|
|
|
|
Make assignments to `Copy` union fields safe
This is an accompanying PR to PR https://github.com/rust-lang/rust/pull/42068 stabilizing FFI unions.
This was first proposed in https://github.com/rust-lang/rust/issues/32836#issuecomment-281296416, see subsequent comments as well.
Assignments to `Copy` union fields do not read any data from the union and are [equivalent](https://github.com/rust-lang/rust/issues/32836#issuecomment-281660298) to whole union assignments, which are safe, so they should be safe as well. This removes a significant number of "false positive" unsafe blocks, in code dealing with FFI unions in particular.
It desirable to make this change now, together with stabilization of FFI unions, because now it affecfts only unstable code, but later it will cause warnings/errors caused by `unused_unsafe` lint in stable code.
cc #32836
r? @nikomatsakis
|
|
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.
|
|
|
|
regression test for #37550
|
|
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
|
|
|
|
|
|
|
|
|
|
closes #39974
r? @Mark-Simulacrum
|
