| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Mark .rmeta files as /SAFESEH on x86 Windows.
Chrome links .rlibs with /WHOLEARCHIVE or -Wl,--whole-archive to prevent the linker from discarding static initializers. This works well, except on Windows x86, where lld complains:
error: /safeseh: lib.rmeta is not compatible with SEH
The fix is simply to mark the .rmeta as SAFESEH aware. This is trivially true, since the metadata file does not contain any executable code.
|
|
Stop telling people to submit bugs for internal feature ICEs
This keeps track of usage of internal features, and changes the message to instead tell them that using internal features is not supported.
I thought about several ways to do this but now used the explicit threading of an `Arc<AtomicBool>` through `Session`. This is not exactly incremental-safe, but this is fine, as this is set during macro expansion, which is pre-incremental, and also only affects the output of ICEs, at which point incremental correctness doesn't matter much anyways.
See [MCP 620.](https://github.com/rust-lang/compiler-team/issues/596)
|
|
Remap Cargo dependencies to /rust/deps
:warning: **This doesn't affect user-compiled programs, it only affects building the Rust compiler itself.** :warning:
Right now, `rust.remap-debuginfo = true` doesn't completely remap all paths: while LLVM and rustc sources are properly remapped (respectively to `/rust/llvm` and `/rust/$commit`), Cargo dependencies still use absolute paths from the Cargo home.
This never affected builds from CI much, because `CARGO_HOME=/cargo` in CI, so users see paths like this included in the precompiled binaries and libraries:
```
/cargo/registry/src/index.crates.io-6f17d22bba15001f/gimli-0.26.2/src/read/line.rs
```
Builds outside CI don't have remapping though, and it's confusing that the config flag doesn't fully do what it advertises.
This PR fixes it by adding remapping for dependencies too. *All registries's* source directory are remapped to `/rust/deps`, to account for multiple registries being able to contain crates.io crates (sparse index vs git, and source replacement mirrors). This results in paths like this being included:
```
/rust/deps/gimli-0.26.2/src/read/line.rs
```
|
|
Rollup of 6 pull requests
Successful merges:
- #116401 (Return multiple object-safety violation errors and code improvements to the object-safety check)
- #116553 (Do not suggest 'Trait<Assoc=arg>' when in trait impl)
- #116931 (Improve the warning messages for the `#[diagnostic::on_unimplemented]`)
- #117008 (Uplift `Canonical` to `rustc_type_ir`)
- #117009 (On unresolved imports, suggest a disambiguated path if necessary to avoid collision with local items)
- #117175 (Rename AsyncCoroutineKind to CoroutineSource)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Rename AsyncCoroutineKind to CoroutineSource
pulled out of https://github.com/rust-lang/rust/pull/116447
Also refactors the printing infra of `CoroutineSource` to be ready for easily extending it with a `Gen` variant for `gen` blocks
|
|
On unresolved imports, suggest a disambiguated path if necessary to avoid collision with local items
Fixes #116970.
|
|
Uplift `Canonical` to `rustc_type_ir`
I plan on moving the new trait solver's canonicalizer into either `rustc_type_ir` or a child crate. One dependency on this is lifting `Canonical<V>` to `rustc_type_ir` so we can actually name the canonicalized values.
I may also later lift `CanonicalVarInfo` into the new trait solver. I can't really tell what other changes need to be done, but I'm just putting this up sooner than later since I'm almost certain it'll need to be done regardless of other design choices.
There are a couple of warts introduced by this PR, since we no longer can define inherent `Canonical` impls in `rustc_middle` -- see the changes to:
* `compiler/rustc_trait_selection/src/traits/query/normalize.rs`
* `compiler/rustc_hir_typeck/src/fn_ctxt/_impl.rs`
r? lcnr
|
|
weiznich:improve_diagnostic_on_unimplemented_warnings, r=compiler-errors
Improve the warning messages for the `#[diagnostic::on_unimplemented]`
This commit improves warnings emitted for malformed on unimplemented attributes by:
* Improving the span of the warnings
* Adding a label message to them
* Separating the messages for missing and unexpected options
* Adding a help message that says which options are supported
r? `@compiler-errors`
I'm happy to work on further improvements, so feel free to make suggestions.
|
|
r=compiler-errors
Do not suggest 'Trait<Assoc=arg>' when in trait impl
Fixes #116464
We now skip the suggestion if we're in an impl of the trait.
|
|
Return multiple object-safety violation errors and code improvements to the object-safety check
See individual commits for more information. Split off of #114260, since it turned out that the main intent of that PR was wrong.
r? oli-obk
|
|
This keeps track of usage of internal features, and changes the message
to instead tell them that using internal features is not supported.
See MCP 620.
|
|
|
|
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #117111 (Remove support for alias `-Z instrument-coverage`)
- #117141 (Require target features to match exactly during inlining)
- #117152 (Fix unwrap suggestion for async fn)
- #117154 (implement C ABI lowering for CSKY)
- #117159 (Work around the fact that `check_mod_type_wf` may spuriously return `ErrorGuaranteed`)
- #117163 (compiletest: Display compilation errors in mir-opt tests)
- #117173 (Make `Iterator` a lang item)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Make `Iterator` a lang item
r? `@compiler-errors`
pulled out of https://github.com/rust-lang/rust/pull/116447
We're doing this change on its own, because iterator was the one diagnostic item that was load bearing on us correctly emitting errors about `diagnostic_item` mis-uses. It was used in some diagnostics as an early abort, before the actual checks of the diagnostic, so effectively the compiler was *unconditionally* checking for the iterator diagnostic item, even if it didn't emit any diagnostics. Changing those uses to use the lang item, caused us not to invoke the `all_diagnostic_items` query anymore, which then caused us to miss some issues around diagnostic items until they were actually used.
The reason we keep the diagnostic item around is that clippy uses it a lot and having `Iterator` be a lang item and a diagnostic item at the same time doesn't cost us anything, but makes clippy's internal code simpler
|
|
compiletest: Display compilation errors in mir-opt tests
Previously when compilation failed the `check_mir_dump` would panic first, so we would never display the compiler output.
|
|
Work around the fact that `check_mod_type_wf` may spuriously return `ErrorGuaranteed`
Even if that error is only emitted by `check_mod_item_types`.
fixes https://github.com/rust-lang/rust/issues/117153
A cleaner refactoring would merge/chain these queries in ways that ensure we only actually get an `ErrorGuaranteed` if there was an error emitted.
|
|
implement C ABI lowering for CSKY
fix https://github.com/rust-lang/compiler-builtins/issues/551
Reference: [CSKY ABI Manual](https://occ-oss-prod.oss-cn-hangzhou.aliyuncs.com/resource//1695027452256/T-HEAD_800_Series_ABI_Standards_Manual.pdf)
Reference: [Clang CSKY lowering code](https://github.com/llvm/llvm-project/blob/4a074f32a6914f2a8d7215d78758c24942dddc3d/clang/lib/CodeGen/Targets/CSKY.cpp#L76-L162)
r? `@bjorn3`
|
|
Fix unwrap suggestion for async fn
Use `body_fn_sig` to get the expected return type of the function instead of `ret_coercion` in `FnCtxt`. This avoids accessing the `ret_coercion` when it's already mutably borrowed (e.g. when checking `return` expressions).
Fixes #117144
r? `@chenyukang`
|
|
Require target features to match exactly during inlining
In general it is not correct to inline a callee with a target features
that are subset of the callee. Require target features to match exactly
during inlining.
The exact match could be potentially relaxed, but this would require
identifying specific feature that are allowed to differ, those that need
to match, and those that can be present in caller but not in callee.
This resolves MIR part of #116573. For other concerns with respect to
the previous implementation also see areInlineCompatible in LLVM.
|
|
Remove support for alias `-Z instrument-coverage`
This flag was stabilized in rustc 1.60.0 (2022-04-07) as `-C instrument-coverage`, but the old unstable flag was kept around (with a warning) as an alias to ease migration.
It should now be reasonable to remove the somewhat tricky code that implemented that alias.
Fixes #116980.
|
|
Rollup of 7 pull requests
Successful merges:
- #116801 (Add test for 113326)
- #117133 (Merge `impl_wf_inference` (`check_mod_impl_wf`) check into coherence checking)
- #117136 (Intern `LocalDefId` list from `opaque_types_defined_by` query)
- #117150 (Update cargo)
- #117158 (Update THIR unused_unsafe lint)
- #117160 (Fix typo in test comment)
- #117168 (Fix some coroutine sentences that don't make sense anymore.)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Instead we use `Display` impls and their `alternate` render scheme to
decide whether we want backticks or not.
|
|
|
|
|
|
|
|
|
|
similar to how we have `MatchSource`, it explains where the desugaring came from.
|
|
Fix some coroutine sentences that don't make sense anymore.
These happened during the `generator` -> `coroutine` rename.
Found thanks to `@pthariensflame` for their thorough review of the `generator` -> `coroutine` rename https://github.com/rust-lang/rust/pull/116958#issuecomment-1777756937
|
|
Fix typo in test comment
|
|
Update THIR unused_unsafe lint
Updates THIR unsafeck behaviour to match the changes from #93678
|
|
Update cargo
2 commits in d2f6a048529eb8e9ebc55d793abd63456c98fac2..df3509237935f9418351b77803df7bc05c009b3d
2023-10-20 18:25:30 +0000 to 2023-10-24 23:09:01 +0000
- Fix unused_imports warning (rust-lang/cargo#12876)
- Warn about crate name's format when creating new crate (rust-lang/cargo#12766)
r? ghost
|
|
Intern `LocalDefId` list from `opaque_types_defined_by` query
r? oli-obk
|
|
Merge `impl_wf_inference` (`check_mod_impl_wf`) check into coherence checking
Problem here is that we call `collect_impl_trait_in_trait_types` when checking `check_mod_impl_wf` which is performed before coherence. Due to the `tcx.sess.track_errors`, since we end up reporting an error, we never actually proceed to coherence checking, where we would be emitting a more useful impl overlap error.
This change means that we may report more errors in some cases, but can at least proceed far enough to leave a useful message for overlapping traits with RPITITs in them.
Fixes #116982
r? types
|
|
Add test for 113326
Closes #113326
Bisecting points to #113636 as the fix
|
|
Miri subtree update
r? `@ghost`
|
|
These happened during the `generator` -> `coroutine` rename.
|
|
Remove fold code and add `Const::internal()` to StableMIR
We are not planning to support user generated constant in the foreseeable future, so we are cleaning up the fold logic and user created type for now. Users should use `Instance::resolve` in order to trigger monomorphization.
The Instance::resolve was however incomplete, since we weren't handling internalizing constants yet. Thus, I added that.
I decided to keep the `Const` fields private in case we decide to translate them lazily.
|
|
|
|
|
|
`ErrorGuaranteed`, even if that error is only emitted by `check_modwitem_types`
|
|
Signed-off-by: cui fliter <imcusg@gmail.com>
|
