The two altered expectation messages both seem like improvements:
- `coerce-expect-unsized-ascribed.stderr` says you can go
`Box<char> -> Box<dyn Debug>`, which you can.
- `upcast_soundness_bug.stderr` used to say that you could go
`Box<dyn Trait<u8, u8>> -> Box<dyn Trait>`, which you can't,
because the type parameters are missing in the destination
and the only ones that work aren't what's needed.
Fix ICE Caused by Incorrectly Delaying E0107
Fixes #128249
For the following code:
```rust
trait Foo<T> {}
impl Foo<T: Default> for u8 {}
```
#126054 added some logic to delay emitting E0107 as the names of associated type `T` in the impl header and generic parameter `T` in `trait Foo` match.
But it failed to ensure whether such unexpected associated type bounds are coming from a impl block header. This caused an ICE as the compiler was delaying E0107 for code like:
```rust
trait Trait<Type> {
type Type;
fn method(&self) -> impl Trait<Type: '_>;
}
```
because it assumed the associated type bound `Type: '_` is for the generic parameter `Type` in `trait Trait` since the names are same.
This PR adds a check to ensure that E0107 is delayed only in the context of impl block header.
Instead of saying to "consider adding a `#[repr(C)]` or
`#[repr(transparent)]` attribute to this struct", we now tell users to
"Use `*const ffi::c_char` instead, and pass the value from
`CStr::as_ptr()`" when the type involved is a `CStr` or a `CString`.
Co-authored-by: Jieyou Xu <jieyouxu@outlook.com>
On short error format, append primary span label to message
The `error-format=short` output only displays the path, error code and main error message all in the same line. We now add the primary span label as well after the error message, to provide more context.
The `error-format=short` output only displays the path, error code and
main error message all in the same line. We now add the primary span label
as well after the error message, to provide more context.
Tweak type inference for `const` operands in inline asm
Previously these would be treated like integer literals and default to `i32` if a type could not be determined. To allow for forward-compatibility with `str` constants in the future, this PR changes type inference to use an unbound type variable instead.
The actual type checking is deferred until after typeck where we still ensure that the final type for the `const` operand is an integer type.
<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.
This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using
r? <reviewer name>
-->
Rustc of course already WF-checked the field types at the definition
site, but for error tainting of consts to work properly, there needs to
be an error emitted at the use site. Previously, with no use-site error,
we proceeded with CTFE and ran into ICEs since we are running code with
type errors.
Emitting use-site errors also brings struct-like constructors more in
line with fn-like constructors since they already emit use-site errors
for WF issues.
Note that the test output is currently *incorrect*. We should be
emitting an error at the use site too, not just at the definition. This
is partly for UI reasons, but mainly to fix a related ICE where a const
generic body is not tainted with an error since no usage error is
reported.
interpret: move nullary-op evaluation into operator.rs
We call it an operator, so we might as well treat it like one. :)
Also use more consistent naming for the "evaluate intrinsic" functions. "emulate" is really the wrong term, this *is* a genuine implementation of the intrinsic semantics after all.
Use `ParamEnv::reveal_all` in CFI
I left a huge comment for why this ICEs in the test I committed.
`typeid_for_instance` should only be called on monomorphic instances during codegen, and we should just be using `ParamEnv::reveal_all()` rather than the param-env of the instance itself. I added an assertion to ensure that we only do this for fully substituted instances (this may break with polymorphization, but I kinda don't care lol).
Fixes#114160
cc `@rcvalle`
Do not fire unhandled attribute assertion on multi-segment `AttributeType::Normal` attributes with builtin attribute as first segment
### The Problem
In #128581 I introduced an assertion to check that all builtin attributes are actually checked via
`CheckAttrVisitor` and aren't accidentally usable on completely unrelated HIR nodes.
Unfortunately, the assertion had correctness problems as revealed in #128622.
The match on attribute path segments looked like
```rs,ignore
// Normal handler
[sym::should_panic] => /* check is implemented */
// Fallback handler
[name, ..] => match BUILTIN_ATTRIBUTE_MAP.get(name) {
// checked below
Some(BuiltinAttribute { type_: AttributeType::CrateLevel, .. }) => {}
Some(_) => {
if !name.as_str().starts_with("rustc_") {
span_bug!(
attr.span,
"builtin attribute {name:?} not handled by `CheckAttrVisitor`"
)
}
}
None => (),
}
```
However, it failed to account for edge cases such as an attribute whose:
1. path segments *starts* with a segment matching the name of a builtin attribute such as `should_panic`, and
2. the first segment's symbol does not start with `rustc_`, and
3. the matched builtin attribute is also of `AttributeType::Normal` attribute type upon registration with the builtin attribute map.
These conditions when all satisfied cause the span bug to be issued for e.g.
`#[should_panic::skip]` because the `[sym::should_panic]` arm is not matched (since it's
`[sym::should_panic, sym::skip]`).
### Proposed Solution
This PR tries to remedy that by adjusting all normal/specific handlers to not match exactly on a single segment, but instead match a prefix segment.
i.e.
```rs,ignore
// Normal handler, notice the `, ..` rest pattern
[sym::should_panic, ..] => /* check is implemented */
// Fallback handler
[name, ..] => match BUILTIN_ATTRIBUTE_MAP.get(name) {
// checked below
Some(BuiltinAttribute { type_: AttributeType::CrateLevel, .. }) => {}
Some(_) => {
if !name.as_str().starts_with("rustc_") {
span_bug!(
attr.span,
"builtin attribute {name:?} not handled by `CheckAttrVisitor`"
)
}
}
None => (),
}
```
### Review Remarks
This PR contains 2 commits:
1. The first commit adds a regression test. This will ICE without the `CheckAttrVisitor` changes.
2. The second commit adjusts `CheckAttrVisitor` assertion logic. Once this commit is applied, the test should no longer ICE and produce the expected bless stderr.
Fixes#128622.
r? ``@nnethercote`` (since you reviewed #128581)
turn `invalid_type_param_default` into a `FutureReleaseErrorReportInDeps`
`````@rust-lang/types````` I assume the plan is still to disallow this? It has been a future-compat lint for a long time, seems ripe to go for hard error.
However, turns out that outright removing it right now would lead to [tons of crater regressions](https://github.com/rust-lang/rust/pull/127655#issuecomment-2228285460), so for now this PR just makes this future-compat lint show up in cargo's reports, so people are warned when they use a dependency that is affected by this.
Fixes https://github.com/rust-lang/rust/issues/27336 by removing the feature gate (so there's no way to silence the lint even on nightly)
CC https://github.com/rust-lang/rust/issues/36887
Move the standard library to a separate workspace
This ensures that the Cargo.lock packaged for it in the rust-src component is up-to-date, allowing rust-analyzer to run cargo metadata on the standard library even when the rust-src component is stored in a read-only location as is necessary for loading crates.io dependencies of the standard library.
This also simplifies tidy's license check for runtime dependencies as it can now look at all entries in library/Cargo.lock without having to filter for just the dependencies of runtime crates. In addition this allows removing an exception in check_runtime_license_exceptions that was necessary due to the compiler enabling a feature on the object crate which pulls in a dependency not allowed for the standard library.
While cargo workspaces normally enable dependencies of multiple targets to be reused, for the standard library we do not want this reusing to prevent conflicts between dependencies of the sysroot and of tools that are built using this sysroot. For this reason we already use an unstable cargo feature to ensure that any dependencies which would otherwise be shared get a different -Cmetadata argument as well as using separate build dirs.
This doesn't change the situation around vendoring. We already have several cargo workspaces that need to be vendored. Adding another one doesn't change much.
There are also no cargo profiles that are shared between the root workspace and the library workspace anyway, so it doesn't add any extra work when changing cargo profiles.
Rollup of 7 pull requests
Successful merges:
- #128305 (improve error message when `global_asm!` uses `asm!` operands)
- #128526 (time.rs: remove "Basic usage text")
- #128531 (Miri: add a flag to do recursive validity checking)
- #128578 (rustdoc: Cleanup `CacheBuilder` code for building search index)
- #128589 (allow setting `link-shared` and `static-libstdcpp` with CI LLVM)
- #128615 (rustdoc: make the hover trail for doc anchors a bit bigger)
- #128620 (Update rinja version to 0.3.0)
r? `@ghost`
`@rustbot` modify labels: rollup
improve error message when `global_asm!` uses `asm!` operands
follow-up to https://github.com/rust-lang/rust/pull/128207
what was
```
error: expected expression, found keyword `in`
--> src/lib.rs:1:31
|
1 | core::arch::global_asm!("{}", in(reg));
| ^^ expected expression
```
becomes
```
error: the `in` operand cannot be used with `global_asm!`
--> $DIR/parse-error.rs:150:19
|
LL | global_asm!("{}", in(reg));
| ^^ the `in` operand is not meaningful for global-scoped inline assembly, remove it
```
the span of the error is just the keyword, which means that we can't create a machine-applicable suggestion here. The alternative would be to attempt to parse the full operand, but then if there are syntax errors in the operand those would be presented to the user, even though the parser already knows that the output won't be valid. Also that would require more complexity in the parser.
So I think this is a nice improvement at very low cost.
Assert that all attributes are actually checked via `CheckAttrVisitor` and aren't accidentally usable on completely unrelated HIR nodes
``@oli-obk's`` #128444 with unreachable case removed to avoid that PR bitrotting away.
Based on #128402.
This PR will make adding a new attribute ICE on any use of that attribute unless it gets a handler added in `rustc_passes::CheckAttrVisitor`.
r? ``@nnethercote`` (since you were the reviewer of the original PR)
Revert recent changes to dead code analysis
This is a revert to recent changes to dead code analysis, namely:
* efdf219 Rollup merge of #128104 - mu001999-contrib:fix/128053, r=petrochenkov
* a70dc297a8 Rollup merge of #127017 - mu001999-contrib:dead/enhance, r=pnkfelix
* 31fe9628cf Rollup merge of #127107 - mu001999-contrib:dead/enhance-2, r=pnkfelix
* 2724aeaaeb Rollup merge of #126618 - mu001999-contrib:dead/enhance, r=pnkfelix
* 977c5fd419 Rollup merge of #126315 - mu001999-contrib:fix/126289, r=petrochenkov
* 13314df21b Rollup merge of #125572 - mu001999-contrib:dead/enhance, r=pnkfelix
There is an additional change stacked on top, which suppresses false-negatives that were masked by this work. I believe the functions that are touched in that code are legitimately unused functions and the types are not reachable since this `AnonPipe` type is not publically reachable -- please correct me if I'm wrong cc `@NobodyXu` who added these in ##127153.
Some of these reverts (#126315 and #126618) are only included because it makes the revert apply cleanly, and I think these changes were only done to fix follow-ups from the other PRs?
I apologize for the size of the PR and the churn that it has on the codebase (and for reverting `@mu001999's` work here), but I'm putting this PR up because I am concerned that we're making ad-hoc changes to fix bugs that are fallout of these PRs, and I'd like to see these changes reimplemented in a way that's more separable from the existing dead code pass. I am happy to review any code to reapply these changes in a more separable way.
cc `@mu001999`
r? `@pnkfelix`
Fixes#128272Fixes#126169
Added SHA512, SM3, SM4 target-features and `sha512_sm_x86` feature gate
This is an effort towards #126624. This adds support for these 3 target-features and introduces the feature flag `sha512_sm_x86`, which would gate these target-features and the yet-to-be-implemented detection and intrinsics in stdarch.
