| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
r=petrochenkov
Stabilize `type_alias_enum_variants` in Rust 1.37.0
Stabilize `#![feature(type_alias_enum_variants)]` which allows type-relative resolution with highest priority to `enum` variants in both expression and pattern contexts. For example, you may now write:
```rust
enum Option<T> {
None,
Some(T),
}
type OptAlias<T> = Option<T>;
fn work_on_alias(x: Option<u8>) -> u8 {
match x {
OptAlias::Some(y) => y + 1,
OptAlias::None => 0,
}
}
```
Closes https://github.com/rust-lang/rfcs/issues/2218
Closes https://github.com/rust-lang/rust/issues/52118
r? @petrochenkov
|
|
Add test for issue-38591
Closes #38591
r? @pnkfelix
|
|
Remove built-in derive macros `Send` and `Sync`
Closes https://github.com/rust-lang/rust/issues/62050
|
|
|
|
compiletest: Introduce `// {check,build,run}-pass` pass modes
Pass UI tests now have three modes
```
// check-pass
// build-pass
// run-pass
```
mirroring equivalent well-known `cargo` commands.
`// check-pass` will compile the test skipping codegen (which is expensive and isn't supposed to fail in most cases).
`// build-pass` will compile and link the test without running it.
`// run-pass` will compile, link and run the test.
Tests without a "pass" annotation are still considered "fail" tests.
Most UI tests would probably want to switch to `check-pass`.
Tests validating codegen would probably want to run the generated code as well and use `run-pass`.
`build-pass` should probably be rare (linking tests?).
https://github.com/rust-lang/rust/pull/61755 will provide a way to run the tests with any mode, e.g. bump `check-pass` tests to `run-pass` to satisfy especially suspicious people, and be able to make sure that codegen doesn't breaks in some entirely unexpected way.
Tests marked with any mode are expected to pass with any other mode, if that's not the case for some legitimate reason, then the test should be made a "fail" test rather than a "pass" test.
Perhaps some secondary CI can verify this invariant, but that's not super urgent.
`// compile-pass` still works and is equivalent to `build-pass`.
Why is `// compile-pass` bad - 1) it gives an impression that the test is only compiled, but not linked, 2) it doesn't mirror a cargo command.
It can be removed some time in the future in a separate PR.
cc https://github.com/rust-lang/rust/issues/61712
|
|
|
|
The errors are either:
- The meta-variable used in the right-hand side is not bound (or defined) in the
left-hand side.
- The meta-variable used in the right-hand side does not repeat with the same
kleene operator as its binder in the left-hand side. Either it does not repeat
enough, or it uses a different operator somewhere.
This change should have no semantic impact.
|
|
|
|
|
|
suggest tuple struct syntax
refs #57242
|
|
macos tlv workaround
fixes: #60141
Includes:
* remove dead code: `requires_move_before_drop`. This hasn't been needed for a while now (oops I should have removed it in #57655)
* redox had a copy of `fast::Key` (not sure why?). That has been removed.
* Perform a `read_volatile` on OSX to reduce `tlv_get_addr` calls per `__getit` from (4-2 depending on context) to 1.
`tlv_get_addr` is relatively expensive (~1.5ns on my machine).
Previously, in contexts where `__getit` was inlined, 4 calls to `tlv_get_addr` were performed per lookup. For some reason when `__getit` is not inlined this is reduced to 2x - and performance improves to match.
After this PR, I have only ever seen 1x call to `tlv_get_addr` per `__getit`, and macos now benefits from situations where `__getit` is inlined.
I'm not sure if the `read_volatile(&&__KEY)` trick is working around an LLVM bug, or a rustc bug, or neither.
r? @alexcrichton
|
|
Fix ICE involving mut references
Fix #61623, fix #61944, fix #61751.
|
|
|
|
Support `cfg` and `cfg_attr` on generic parameters
`cfg` attributes are supported in all other positions where attributes are accepted at all.
They were previously prohibited in https://github.com/rust-lang/rust/pull/51283 because they weren't implemented correctly before that and were simply ignored.
|
|
Improve the explicit_outlives_requirements lint
* Don't use Strings to compare parameters
* Extend the lint to lifetime bounds
* Extend the lint to enums and unions
* Use the correct span for where clauses in tuple structs
* Try to early-out where possible
* Remove unnecessary bounds in rustc crates
|
|
|
|
|
|
|
|
|
|
rustc_typeck: correctly compute `Substs` for `Res::SelfCtor`.
Fixes #61882.
r? @petrochenkov cc @varkor
|
|
Also give them a span in the HIR
|
|
|
|
Add explanation for E0592
This is a part of #61137
r? @GuillaumeGomez
|
|
|
|
|
|
Optimize matches
Attempt to fix or improve #60571
This is breaking some diagnostics because the MIR for match arms isn't in source order any more.
cc @centril
|
|
|
|
|
|
|
|
When suggesting borrow, remove useless clones
Fix #61106.
|
|
|
|
|
|
|
|
|
|
Tracking issue: #60405
|
|
|
|
Unlike other built-in attributes, this attribute accepts any input
|
|
r=matthewjasper
Remove asterisk suggestion for move errors in borrowck
As per the decision in #54985 completely removes the suggestion to add an asterisk when checking move errors. I believe I've preserved the correct behavior with the "consider borrowing here" branch of the original match arm, but I'm not positive on that.
This is my first PR to rustc so any feedback is greatly appreciated. Thanks.
|
|
Fix regression 61475
Addresses #61475.
|
|
As per issue #54985 removes the not useful suggestion to remove asterisk in
move errors. Includes minor changes to tests in the `ui` suite to account
for the removed suggestion.
|
|
Make cannot move errors more consistent with other borrowck errors
* Note the type of the place being moved in all cases.
* Note the place being moved from.
* Simplify the search for overloaded place operators
* Extend the note for move from overloaded deref apply to all types.
* Add a note for moves from overloaded index.
* Special case moves for closure captures.
r? @pnkfelix
|
|
Suggest using `as_ref` on `*const T`
Fix #21596.
|
|
|
|
|
|
Add more detail to type inference error
When encountering code where type inference fails, add more actionable
information:
```
fn main() {
let foo = Vec::new();
}
```
```
error[E0282]: type annotations needed in `std::vec::Vec<T>`
--> $DIR/vector-no-ann.rs:2:16
|
LL | let foo = Vec::new();
| --- ^^^^^^^^ cannot infer type for `T` in `std::vec::Vec<T>`
| |
| consider giving `foo` a type
```
Fix #25633.
|
|
Rollup of 6 pull requests
Successful merges:
- #61380 (Fix some issues with `unwrap_usize` instead of `assert_usize`)
- #61423 (codegen: change `$6d$` to `$u6d$`)
- #61438 (Point at individual type args on arg count mismatch)
- #61441 (Tweak wording when encountering `fn` call in pattern)
- #61451 (Fix missing semicolon in doc)
- #61458 (Fix typo in AsRef doc)
Failed merges:
r? @ghost
|
|
Tweak wording when encountering `fn` call in pattern
Fix #60642
|
|
Point at individual type args on arg count mismatch
- Point at individual type arguments on arg count mismatch
- Make generics always have a valid span, even when there are no args
- Explain that `impl Trait` introduces an implicit type argument
Fix #55991.
|
