Similar to the existing nullpointer and alignment checks, this checks
for valid enum discriminants on creation of enums through unsafe
transmutes. Essentially this sanitizes patterns like the following:
```rust
let val: MyEnum = unsafe { std::mem::transmute<u32, MyEnum>(42) };
```
An extension of this check will be done in a follow-up that explicitly
sanitizes for extern enum values that come into Rust from e.g. C/C++.
This check is similar to Miri's capabilities of checking for valid
construction of enum values.
This PR is inspired by saethlin@'s PR
https://github.com/rust-lang/rust/pull/104862. Thank you so much for
keeping this code up and the detailed comments!
I also pair-programmed large parts of this together with vabr-g@.
This centralizes the placeholder type error reporting in one location, but it also exposes the granularity at which we convert things from hir to ty more. E.g. previously infer types in where bounds were errored together with the function signature, but now they are independent.
Add caching layer to bootstrap
This PR adds a caching layer to the bootstrap command execution context. It is still a work in progress but introduces the initial infrastructure for it.
r? `@Kobzol`
After reviewing all tests with `?Sized` and discussing with lcnr, these
tests seem like they could probably benefit from
`#![rustc_no_implicit_bounds]`.
Fix some fixmes that were waiting for let chains
Was inspired by looking at rust-lang/rust#143066 and spotting two fixmes that were missed, so... r? `@compiler-errors` 😅
Yay, let chains!
Move an ACE test out of the GCI directory
In https://github.com/rust-lang/rust/pull/122988, a test pertaining to `associated_const_equality` was placed into the directory meant for `generic_const_items`. Let's move it where it belongs.
While at it, I took the time to further minimize the test and to add a description. You can use 1.67.1 (as reported in rust-lang/rust#108220) to verify that I didn't butcher it. For additional context, the issue was likely fixed in rust-lang/rust#112718 (but I'm also cc'ing rust-lang/rust#140467 which further fixed things up and has more context).
I only performed quick and dirty git/GitHub archeology, so I don't have the full picture here. For one, I'm not even sure if this regression test is worth it.
Anyway, I just want it gone from the GCI dir :)
Remove cache for citool
I'm not sure why, but after the citool cache is loaded, compiling just build_helper and citool takes ~30s, which is very slow. Combined with the fact that just loading the cache takes ~15s, and we have to run a hacky workflow on master, which results [in benign failures](https://github.com/rust-lang/rust/actions?query=branch%3Amaster), I don't think it's worth it to use the cache here anymore.
A fresh build, now that we don't run citool tests on PR CI, takes just ~35-40s, so it's actually faster now *not* to cache. The trade-offs change quite often :)
r? ``@ghost``
Rename run always
This PR renames run_always to run_to_dry_run for better clarity, making the field's purpose more explicit and avoiding confusion with command caching behavior.
r? ``````@Kobzol``````
Port `#[export_name]` to the new attribute parsing infrastructure
This PR contains two changes, in separate commits for reviewability:
- Ports `export_name` to the new attribute parsing infrastructure for https://github.com/rust-lang/rust/issues/131229#issuecomment-2971353197
- Moves the check for mixing export_name/no_mangle to check_attr.rs and improve the error message, which previously had a mix of 2021/2024 edition syntax
r? ``@jdonszelmann``
Fix RwLock::try_write documentation for WouldBlock condition
Fix RwLock::try_write documentation for WouldBlock condition
The documentation incorrectly stated that try_write only fails when
'already locked exclusively', but it actually fails when there are
either shared (read) or exclusive (write) locks.
Fixesrust-lang/rust#142852
Add note to `find_const_ty_from_env`
Add a note to `find_const_ty_from_env` to explain why it has an `unwrap` which "often" causes ICEs.
Also, uplift it into the new trait solver. This avoids needing to go through the interner to call this method which is otherwise an inherent method in the compiler. I can remove this part if desired.
r? `@boxyuwu`
Remove incorrect comments in `Weak`
It is currently possible to create a dangling `Weak` to a DST by calling `Weak::new()` for a sized type, then doing an unsized coercion. Therefore, the comments are wrong.
These comments were added in <https://github.com/rust-lang/rust/pull/73845>. As far as I can tell, the guarantee in the comment was only previously used in the `as_ptr` method. However, the current implementation of `as_ptr` no longer relies on this guarantee.
[perf] Compute hard errors without diagnostics in impl_intersection_has_impossible_obligation
First compute hard errors without diagnostics, then ambiguities with diagnostics since we need to know if any of them overflowed.
Remove some glob imports from the type system
Namely, remove the glob imports for `BoundRegionConversionTime`, `RegionVariableOrigin`, `SubregionOrigin`, `TyOrConstInferVar`, `RegionResolutionError`, `SelectionError`, `ProjectionCandidate`, `ProjectionCandidateSet`, and some more specific scoped globs (like `Inserted` in the impl overlap graph construction.
These glob imports are IMO very low value, since they're not used nearly as often as other globs (like `TyKind`).
small iter.intersperse.fold() optimization
No need to call into fold when the first item is already None, this avoids some redundant work for empty iterators.
"But it uses Fuse" one might want to protest, but Fuse is specialized and may call into the inner iterator anyway.
const-eval: allow constants to refer to mutable/external memory, but reject such constants as patterns
This fixes https://github.com/rust-lang/rust/issues/140653 by accepting code such as this:
```rust
static FOO: AtomicU32 = AtomicU32::new(0);
const C: &'static AtomicU32 = &FOO;
```
This can be written entirely in safe code, so there can't really be anything wrong with it.
We also accept the much more questionable following code, since it looks very similar to the interpreter:
```rust
static mut FOO2: u32 = 0;
const C2: &'static u32 = unsafe { &mut FOO2 };
```
Using this without causing UB is at least very hard (the details are unclear since it is related to how the aliasing model deals with the staging of const-eval vs runtime code).
If a constant like `C2` is used as a pattern, we emit an error:
```
error: constant BAD_PATTERN cannot be used as pattern
--> $DIR/const_refs_to_static_fail.rs:30:9
|
LL | BAD_PATTERN => {},
| ^^^^^^^^^^^
|
= note: constants that reference mutable or external memory cannot be used as pattern
```
(If you somehow manage to build a pattern with constant `C`, you'd get the same error, but that should be impossible: we don't have a type that can be used in patterns and that has interior mutability.)
The same treatment is afforded for shared references to `extern static`, for the same reason: the const evaluation is entirely fine with it, we just can't build a pattern for it -- and when using interior mutability, this can be totally sound.
We do still not accept anything where there is an `&mut` in the final value of the const, as that should always require unsafe code and it's hard to imagine a sound use-case that would require this.
make RefCell unstably const
Now that we can do interior mutability in `const`, most of the `RefCell` API can be `const fn`. The main exceptions are APIs which use `FnOnce` (`RefCell::replace_with` and `Ref[Mut]::[filter_]map[_split]`) and `RefCell::take` which calls `Default::default`.
Tracking issue: #137844
The `macro_rules!` parser was written to match the series of rules using
the macros-by-example (MBE) engine and a hand-written equivalent of the
left-hand side of a MBE macro. This was complex to read, difficult to
extend, and produced confusing error messages. Because it was using the
MBE engine, any parse failure would be reported as if some macro was
being applied to the `macro_rules!` invocation itself; for instance,
errors would talk about "macro invocation", "macro arguments", and
"macro call", when they were actually about the macro *definition*.
And in practice, the `macro_rules!` parser only used the MBE engine to
extract the left-hand side and right-hand side of each rule as a token
tree, and then parsed the rest using a separate parser.
Rewrite it to parse the series of rules using a simple loop, instead.
This makes it more extensible in the future, and improves error
messages. For instance, omitting a semicolon between rules will result
in "expected `;`" and "unexpected token", rather than the confusing "no
rules expected this token in macro call".
This work was greatly aided by pair programming with Vincenzo Palazzo
and Eric Holk.
