dc47a69ed9
MGCA: Syntactically distinguish anon const const args r? oli-obk tracking issue: rust-lang/rust#132980 This PR requires that when `feature(min_generic_const_args)` is enabled, anon const const args are *syntactically* distinguishable from other kinds of args. We use `const { ... }` in const argument position to denote an anon const: ```rust #![feature(min_generic_const_args)] // no longer allowed as `1 + 1` is represented via an anon const and // there is no syntactic marker type Foo = [(); 1 + 1]; // allowed, `const { ... }` indicates an anon const representation type Foo = [(); const { 1 + 1 }]; ``` This restriction is only placed when mgca is enabled. There should be no effect on stable. This restriction is not enforced for unbraced literals which we continue to implicitly wrap in an anon const: `tests/ui/const-generics/mgca/explicit_anon_consts_literals_hack.rs` This restriction allows us to create `DefId`s for anon consts only when actually required. When it is syntactically ambiguous whether a const argument is an anon const or not we are forced to conservatively create a `DefId` for every const argument even if it doesn't wind up needing one. This works fine on stable but under `mgca` we can wind up with anon consts nested inside non-anon-const const arguments resulting in a broken `DefId` tree. See rust-lang/rust#148838 where an anon const arg inside of a path arg winds up with a parent of a conservatively created `DefId` that doesn't actually correspond to an anon const, resulting in an ICE. With rust-lang/rust#149114 every field initialiser in a const argument would become a place where there could *possibly* be an anon const. This would also get worse once we support tuple constructors- now every function argument is a place where there could possibly be an anon const. We introduce this restriction to avoid creating massive amounts of unused `DefId`s that make the parent tree significantly more complicated, and to avoid having to paper over this issue in things like `generics_of`. Fixes rust-lang/rust#148838 It also must be syntactically clear from context whether `'_` means an inference lifetime or an elided lifetime parameter. This restriction will allow us to properly resolve `'_` in const arguments in mgca. This PR doesn't actually fix handle this, but we could do so trivially after this lands. |
||
|---|---|---|
| .github | ||
| compiler | ||
| library | ||
| LICENSES | ||
| src | ||
| tests | ||
| .clang-format | ||
| .editorconfig | ||
| .git-blame-ignore-revs | ||
| .gitattributes | ||
| .gitignore | ||
| .gitmodules | ||
| .ignore | ||
| .mailmap | ||
| bootstrap.example.toml | ||
| Cargo.lock | ||
| Cargo.toml | ||
| CODE_OF_CONDUCT.md | ||
| configure | ||
| CONTRIBUTING.md | ||
| COPYRIGHT | ||
| INSTALL.md | ||
| LICENSE-APACHE | ||
| license-metadata.json | ||
| LICENSE-MIT | ||
| package.json | ||
| README.md | ||
| RELEASES.md | ||
| REUSE.toml | ||
| rust-bors.toml | ||
| rustfmt.toml | ||
| triagebot.toml | ||
| typos.toml | ||
| x | ||
| x.ps1 | ||
| x.py | ||
| yarn.lock | ||
This is the main source code repository for Rust. It contains the compiler, standard library, and documentation.
Why Rust?
-
Performance: Fast and memory-efficient, suitable for critical services, embedded devices, and easily integrated with other languages.
-
Reliability: Our rich type system and ownership model ensure memory and thread safety, reducing bugs at compile-time.
-
Productivity: Comprehensive documentation, a compiler committed to providing great diagnostics, and advanced tooling including package manager and build tool (Cargo), auto-formatter (rustfmt), linter (Clippy) and editor support (rust-analyzer).
Quick Start
Read "Installation" from The Book.
Installing from Source
If you really want to install from source (though this is not recommended), see INSTALL.md.
Getting Help
See https://www.rust-lang.org/community for a list of chat platforms and forums.
Contributing
See CONTRIBUTING.md.
License
Rust is primarily distributed under the terms of both the MIT license and the Apache License (Version 2.0), with portions covered by various BSD-like licenses.
See LICENSE-APACHE, LICENSE-MIT, and COPYRIGHT for details.
Trademark
The Rust Foundation owns and protects the Rust and Cargo trademarks and logos (the "Rust Trademarks").
If you want to use these names or brands, please read the Rust language trademark policy.
Third-party logos may be subject to third-party copyrights and trademarks. See Licenses for details.