Diagnostics for struct path resolution errors in resolve and typeck are unified.
Self type is treated as a type alias in few places (not reachable yet).
Unsafe cell is seen in constants even through type aliases.
All checks for struct paths in typeck work on type level.
Implement field shorthands in struct literal expressions.
Implements #37340 in a straight-forward way: `Foo { x, y: f() }` parses as `Foo { x: x, y: f() }`.
Because of the added `is_shorthand` to `ast::Field`, this is `[syntax-breaking]` (cc @Manishearth).
* [x] Mark the fields as being a shorthand (the exact same way we do it in patterns), for pretty-printing.
* [x] Gate the shorthand syntax with `#![feature(field_init_shorthand)]`.
* [x] Don't parse numeric field as identifiers.
* [x] Arbitrary field order tests.
Convert byte literal pattern to byte array patterns when they are both
used together. so matching them is properly handled. I could've done the
conversion eagerly, but that could have caused a bad worst-case for
massive byte-array matches.
Fixes#18027.
Fixes#25051.
Fixes#26510.
check target abi support
This PR checks for each extern function / block whether the ABI / calling convention used is supported by the current target.
This was achieved by adding an `abi_blacklist` field to the target specifications, listing the calling conventions unsupported for that target.
remove keys w/ skolemized regions from proj cache when popping skolemized regions
This addresses #37154 (a regression). The projection cache was incorrectly caching the results for skolemized regions -- when we pop skolemized regions, we are supposed to drop cache keys for them (just as we remove those skolemized regions from the region inference graph). This is because those skolemized region numbers will be reused later with different meaning (and we have determined that the old ones don't leak out in any meaningful way).
I did a *somewhat* aggressive fix here of only removing keys that mention the skolemized regions. One could imagine just removing all keys added since we started the skolemization (as indeed I did in my initial commit). This more aggressive fix required fixing a latent bug in `TypeFlags`, as an aside.
I believe the more aggressive fix is correct; clearly there can be entries that are unrelated to the skoelemized region, and it's a shame to remove them. My one concern was that it *is* possible I believe to have some region variables that are created and related to skolemized regions, and maybe some of them could end up in the cache. However, that seems harmless enough to me-- those relations will be removed, and couldn't have impacted how trait resolution proceeded anyway (iow, the cache entry is not wrong, though it is kind of useless).
r? @pnkfelix
cc @arielb1
Expand .zip() specialization to .map() and .cloned()
Implement .zip() specialization for Map and Cloned.
The crucial thing for transparent specialization is that we want to
preserve the potential side effects.
The simplest example is that in this code snippet:
`(0..6).map(f).zip((0..4).map(g)).count()`
`f` will be called five times, and `g` four times. The last time for `f`
is when the other iterator is at its end, so this element is unused.
This side effect can be preserved without disturbing code generation for
simple uses of `.map()`.
The `Zip::next_back()` case is even more complicated, unfortunately.
macros: fix partially consumed tokens in macro matchers
Fixes#37175.
This PR also avoids re-transcribing the tokens consumed by a matcher (and cloning the `TtReader` once per matcher), which improves expansion performance of the test case from #34630 by ~8%.
r? @nrc
Fix some pretty printing tests
Many pretty-printing tests are un-ignored.
Some issues in classification of comments (trailing/isolated) and blank line counting are fixed.
Some comments are printed more carefully.
Some minor refactoring in pprust.rs
`no-pretty-expanded` annotations are removed because this is the default now.
`pretty-expanded` annotations are removed from compile-fail tests, they are not tested with pretty-printer.
Closes https://github.com/rust-lang/rust/issues/23623 in favor of more specific https://github.com/rust-lang/rust/issues/37201 and https://github.com/rust-lang/rust/issues/37199
r? @nrc
`#[may_dangle]` attribute
`#[may_dangle]` attribute
Second step of #34761. Last big hurdle before we can work in earnest towards Allocator integration (#32838)
Note: I am not clear if this is *also* a syntax-breaking change that needs to be part of a breaking-batch.
This addresses issue pointed out by niko that prior code would break
if the declaration order for generics does not match how they are fed
into the instantiation of the type itself. (Added some tests
exercising this scenario.)
Implement .zip() specialization for Map and Cloned.
The crucial thing for transparent specialization is that we want to
preserve the potential side effects.
The simplest example is that in this code snippet:
`(0..6).map(f).zip((0..4).map(g)).count()`
`f` will be called five times, and `g` four times. The last time for `f`
is when the other iterator is at its end, so this element is unused.
This side effect can be preserved without disturbing code generation for
simple uses of `.map()`.
The `Zip::next_back()` case is even more complicated, unfortunately.
Add comparison operators to boolean const eval.
I think it might be worth adding tests here, but since I don't know how or where to do that, I have not done so yet. Willing to do so if asked and given an explanation as to how.
Fixes#37047.
Turn compatibility lint `match_of_unit_variant_via_paren_dotdot` into a hard error
The lint was introduced 10 months ago and made deny-by-default 7 months ago.
In case someone is still using it, https://github.com/rust-lang/rust/pull/36868 contains a stable replacement.
r? @nikomatsakis
stop having identity casts be lexprs
that made no sense (see test), and was incompatible with borrowck.
Fixes#36936.
beta-nominated since (bad) regression.
r? @eddyb
loosen assertion against proj in collector
The collector was asserting a total absence of projections, but some projections are expected, even in trans: in particular, projections containing higher-ranked regions, which we don't currently normalize.
r? @pnkfelix
Fixes#36381
The collector was asserting a total absence of projections, but some
projections are expected, even in trans: in particular, projections
containing higher-ranked regions, which we don't currently normalize.
Enforce the shadowing restrictions from RFC 1560 for today's macros
This PR enforces a weakened version of the shadowing restrictions from RFC 1560. More specifically,
- If a macro expansion contains a `macro_rules!` macro definition that is used outside of the expansion, the defined macro may not shadow an existing macro.
- If a macro expansion contains a `#[macro_use] extern crate` macro import that is used outside of the expansion, the imported macro may not shadow an existing macro.
This is a [breaking-change]. For example,
```rust
macro_rules! m { () => {} }
macro_rules! n { () => {
macro_rules! m { () => {} } //< This shadows an existing macro.
m!(); //< This is inside the expansion that generated `m`'s definition, so it is OK.
} }
n!();
m!(); //< This use of `m` is outside the expansion, so it causes the shadowing to be an error.
```
r? @nrc
