| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Implementation of RFC 2086 - Allow Irrefutable Let patterns
This is the set of changes for RFC2086. Tracking issue #44495. Rendered [here](https://github.com/rust-lang/rfcs/pull/2086)
|
|
r=nikomatsakis
`Self` in where clauses may not be object safe
Needs crater, virtually certain to cause regressions.
In #50781 it was discovered that our object safety rules are not sound because we allow `Self` in where clauses without restrain. This PR is a direct fix to the rules so that we disallow methods with unsound where clauses.
This currently uses hard error to measure impact, but we will want to downgrade it to a future compat error.
Part of #50781.
r? @nikomatsakis
|
|
This is virtually certain to cause regressions, needs crater.
In #50781 it was discovered that our object safety rules are not sound because we allow `Self` in where clauses without restrain. This PR is a direct fix to the rules so that we disallow methods with unsound where clauses.
This currently uses hard error to measure impact, but we will want to downgrade it to a future compat error.
Fixes #50781.
r? @nikomatsakis
|
|
The `dyn Trait` syntax was stabilized in 199ee327. Resolves #49277.
|
|
|
|
|
|
|
|
|
|
|
|
The acronym is not descriptive unless one has seen it before.
* Rename the `oom` function to `handle_alloc_error`. It was **stabilized in 1.28**, so if we do this at all we need to land it this cycle.
* Rename `set_oom_hook` to `set_alloc_error_hook`
* Rename `take_oom_hook` to `take_alloc_error_hook`
Bikeshed: `alloc` v.s. `allocator`, `error` v.s. `failure`
|
|
Add existential type definitions
Note: this does not allow creating named existential types, it just desugars `impl Trait` to a less (but still very) hacky version of actual `existential type` items.
r? @nikomatsakis
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Implement RFC 2421, 'Keyword unreservations (pure, sizeof, alignof, offsetof)
On my local machine I was getting failures in `test/ui-fulldeps`, but I was also getting them again after reverting the change, so I'm hoping that this works.
I removed the test because that's what the other PR that unreserved a keyword did and I feel that it doesn't make sense/keep value to keep a test for something removed years ago.
|
|
Stabilize Iterator::step_by
Fixes #27741
|
|
|
|
Increase number of usages of `u8` in weird expressions u8 test
|
|
Dedup auto traits in trait objects.
Fixes #47010
Note that the test file `run-pass/trait-object-auto-dedup.rs` passes before and after this change. It's the `ui` test that changed from compiling to not compiling. Which does make this a breaking change, but I cannot imagine anybody actually being broken by it.
|
|
Add deprecation lint for duplicated `macro_export`s
cc https://github.com/rust-lang/rust/issues/35896#issuecomment-381370556
|
|
|
|
|
|
|
|
This reverts commit d6ba1b9b021c408fcad60ee52acf8af5e1b2eb00, reversing
changes made to 8de5353f75dcde04abe947e0560dc5edd861cf3a.
|
|
Add Future and task system to the standard library
This adds preliminary versions of the `std::future` and `std::task` modules in order to unblock development of async/await (https://github.com/rust-lang/rust/issues/50547). These shouldn't be considered as final forms of these libraries-- design questions about the libraries should be left on https://github.com/rust-lang/rfcs/pull/2418. Once that RFC (or a successor) is merged, these APIs will be adjusted as necessary.
r? @aturon
|
|
|
|
|
|
Tests that #39963 is fixed on MIR borrowck
As title.
fixes #39963
|
|
|
|
|
|
|
|
Do not promote union field accesses
r? @eddyb
technically a breaking change, but the code errored on the previous stable and produces UB + a warning on the current stable. I don't think we need a crater run in that case.
|
|
|
|
|
|
Fixes #27741
|
|
|
|
|
|
|
|
Add std/core to prelude if extern_prelude enabled
Fixes #50605
|
|
|
|
Fixes #50605
|
|
|
|
|
|
OOM handling changes
As discussed in https://github.com/rust-lang/rust/issues/49668#issuecomment-384893456 and subsequent.
This does have codegen implications. Even without the hooks, and with a handler that ignores the arguments, the compiler doesn't eliminate calling `rust_oom` with the `Layout`. Even if it managed to eliminate that, with the hooks, I don't know if the compiler would be able to figure out it can skip it if the hook is never set.
A couple implementation notes:
- I went with explicit enums rather than bools because it makes it clearer in callers what is being requested.
- I didn't know what `feature` to put the hook setting functions behind. (and surprisingly, the compile went through without any annotation on the functions)
- There's probably some bikeshedding to do on the naming.
Cc: @Simonsapin, @sfackler
|
