| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
[beta] Do not accidentally treat multi-segment meta-items as single-segment
Partial backport of https://github.com/rust-lang/rust/pull/58899 to beta
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fix #58856.
|
|
Fix #58857.
|
|
|
|
|
|
cases.
|
|
|
|
Type annotations are shared between the MIR of a function and the
promoted constants for that function, so keep them in the type checker
when we check the promoted MIR.
|
|
Previously, a promoted that contains a function item wouldn't have the
function items bounds propagated to
the main function body.
|
|
Stabilize `unrestricted_attribute_tokens`
In accordance with a plan described in https://internals.rust-lang.org/t/unrestricted-attribute-tokens-feature-status/8561/3.
Delimited non-macro non-builtin attributes now support the same syntax as macro attributes:
```
PATH
PATH `(` TOKEN_STREAM `)`
PATH `[` TOKEN_STREAM `]`
PATH `{` TOKEN_STREAM `}`
```
Such attributes mostly serve as inert proc macro helpers or tool attributes.
To some extent these attributes are de-facto stable due to a hole in feature gate checking (feature gating is done too late - after macro expansion.)
So if macro *removes* such helper attributes during expansion (and it must remove them, unless it's a derive macro), then the code will work on stable.
Key-value non-macro non-builtin attributes are now restricted to bare minimum required to support what we support on stable - unsuffixed literals (https://github.com/rust-lang/rust/issues/34981).
```
PATH `=` LITERAL
```
(Key-value macro attributes are not supported at all right now.)
Crater run in https://github.com/rust-lang/rust/pull/57321 found no regressions for this change.
There are multiple possible ways to extend key-value attributes (https://github.com/rust-lang/rust/pull/57321#issuecomment-451574065), but I'd expect an RFC for that and it's not a pressing enough issue to block stabilization of delimited attributes.
Built-in attributes are still restricted to the "classic" meta-item syntax, nothing changes here.
https://github.com/rust-lang/rust/pull/57321 goes further and adds some additional restrictions (more consistent input checking) to built-in attributes.
Closes https://github.com/rust-lang/rust/issues/55208
|
|
Stabilize TryFrom and TryInto with a convert::Infallible empty enum
This is the plan proposed in https://github.com/rust-lang/rust/issues/33417#issuecomment-423073898
|
|
|
|
|
|
Deny the `overflowing_literals` lint for all editions
The `overflowing_literals` was made deny by default for the 2018 edition by #54507, however I'm not aware of any reason it can't be made deny by default for the 2015 edition as well.
|
|
Use normal mutable borrows in matches
`ref mut` borrows are currently two-phase with NLL enabled. This changes them to be proper mutable borrows. To accommodate this, first the position of fake borrows is changed:
```text
[ 1. Pre-match ]
|
[ (old create fake borrows) ]
[ 2. Discriminant testing -- check discriminants ] <-+
| |
| (once a specific arm is chosen) |
| |
[ (old read fake borrows) ] |
[ 3. Create "guard bindings" for arm ] |
[ (create fake borrows) ] |
| |
[ 4. Execute guard code ] |
[ (read fake borrows) ] --(guard is false)-----------+
|
| (guard results in true)
|
[ 5. Create real bindings and execute arm ]
|
[ Exit match ]
```
The following additional changes are made to accommodate `ref mut` bindings:
* We no longer create fake `Shared` borrows. These borrows are no longer needed for soundness, just to avoid some arguably strange cases.
* `Shallow` borrows no longer conflict with existing borrows, avoiding conflicting access between the guard borrow access and the `ref mut` borrow.
There is some further clean up done in this PR:
* Avoid the "later used here" note for Shallow borrows (since it's not relevant with the message provided)
* Make any use of a two-phase borrow activate it.
* Simplify the cleanup_post_borrowck passes into a single pass.
cc #56254
r? @nikomatsakis
|
|
Relax some Hash bounds on HashMap<K, V, S> and HashSet<T, S>
Notably, hash iterators don't require any trait bounds to be iterated.
|
|
Implement unstable ffi_return_twice attribute
This PR implements [RFC2633](https://github.com/rust-lang/rfcs/pull/2633)
r? @eddyb
|
|
Rollup of 6 pull requests
Successful merges:
- #57364 (Improve parsing diagnostic for negative supertrait bounds)
- #58183 (Clarify guarantees for `Box` allocation)
- #58442 (Simplify the unix `Weak` functionality)
- #58454 (Refactor Windows stdio and remove stdin double buffering )
- #58511 (Const to op simplification)
- #58642 (rustdoc: support methods on primitives in intra-doc links)
Failed merges:
r? @ghost
|
|
Improve parsing diagnostic for negative supertrait bounds
closes #33418
r? @estebank
|
|
Add generic simd saturated add/sub intrinsics
r? @eddyb
|
|
|
|
|
|
|
|
Add expected/provided byte alignments to validation error message
Fixes #58617
|
|
Update tests to account for cross-platform testing and miri.
Fix #23926
|
|
Special suggestion for illegal unicode curly quote pairs
Fixes #58436
Did not end up expanding the error message span to include the full string literal since I figured the start of the token was the issue, while the help suggestion span would include up to the closing quotation mark.
The look ahead logic does not affect the reader position, not sure if that is an issue (if eg it should still continue to parse after the closing quote without erroring out).
|
|
Check the Self-type of inherent associated constants
r? @arielb1
|
|
Add better error message for partial move
closes #56657
r? @davidtwco
|
|
|
|
|
|
|
|
|
|
|
|
AFAICT, we do not have the same const-eval issues that we used to when
rust-lang/rust#23926 was filed. (Probably because of the switch to
miri for const-evaluation.)
|
|
huge-array-simple.rs test.
(and now unignore the test since it shouldn't break tests of
cross-compiles anymore.)
|
