| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Remove old RPITIT tests (revisions were removed)
These tests were not cleaned up after #112988.
r? `@spastorino`
|
|
fix: not insert missing lifetime for `ConstParamTy`
Fixes #113462
We should ignore the missing lifetime, as it's illegal to include a lifetime in a const param.
r? ``@compiler-errors``
|
|
pnkfelix:dont-export-no-mangle-from-proc-macros-issue-99978, r=bjorn3
Restrict linker version script of proc-macro crates to just its two symbols
Restrict linker version script of proc-macro crates to just the two symbols of each proc-macro crate.
The main known effect of doing this is to stop including `#[no_mangle]` symbols in the linker version script.
Background:
The combination of a proc-macro crate with an import of another crate that itself exports a no_mangle function was broken for a period of time, because:
* In PR #99944 we stopped exporting no_mangle symbols from proc-macro crates; proc-macro crates have a very limited interface and are meant to be treated as a blackbox to everything except rustc itself. However: he constructed linker version script still referred to them, but resolving that discrepancy was left as a FIXME in the code, tagged with issue #99978.
* In PR #108017 we started telling the linker to check (via the`--no-undefined-version` linker invocation flag) that every symbol referenced in the "linker version script" is provided as linker input. So the unresolved discrepancy from #99978 started surfacing as a compile-time error (e.g. #111888).
Fix #111888
Fix #99978.
|
|
Rollup of 11 pull requests
Successful merges:
- #106425 (Make ExitStatus implement Default)
- #113480 (add aarch64-unknown-teeos target)
- #113586 (Mention style for new syntax in tracking issue template)
- #113593 (CFI: Fix error compiling core with LLVM CFI enabled)
- #114612 (update llvm-wrapper include to silence deprecation warning)
- #114613 (Prevent constant rebuilds of `rustc-main` (and thus everything else))
- #114615 (interpret: remove incomplete protection against invalid where clauses)
- #114628 (Allowing re-implementation of mir_drops_elaborated query)
- #114629 (tests: Uncomment now valid GAT code behind FIXME)
- #114630 (Migrate GUI colors test to original CSS color format)
- #114631 (add provisional cache test for new solver)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
add provisional cache test for new solver
wrote it for chalk in https://github.com/rust-lang/chalk/pull/788 and never added it to the new solver.
r? ``@compiler-errors``
|
|
Migrate GUI colors test to original CSS color format
Follow-up of https://github.com/rust-lang/rust/pull/111459.
r? `@notriddle`
|
|
tests: Uncomment now valid GAT code behind FIXME
The code fails to parse with `nightly-2021-02-05`:
$ cargo +nightly-2021-02-05 build
error: generic associated types in trait paths are currently not implemented
--> src/main.rs:9:42
|
9 | fn _bar<T: for<'a> StreamingIterator<Item<'a> = &'a [i32]>>(_iter: T) { /* ... */
| ^^^^
but parses with `nightly-2021-02-06`:
$ cargo +nightly-2021-02-06 build
warning: the feature `generic_associated_types` is incomplete and may not be safe to use and/or cause compiler crashes
warning: 1 warning emitted
because it was (with high probability) fixed by #79554 which was merged within that nightly range.
This PR is part of #44366 which is E-help-wanted.
|
|
interpret: remove incomplete protection against invalid where clauses
Cc https://github.com/rust-lang/rust/issues/97477, https://github.com/rust-lang/project-const-generics/issues/37
r? ``@lcnr``
|
|
CFI: Fix error compiling core with LLVM CFI enabled
Fix #90546 by filtering out global value function pointer types from the type tests, and adding the LowerTypeTests pass to the rustc LTO optimization pipelines.
|
|
add aarch64-unknown-teeos target
TEEOS is a mini os run in TrustZone, for trusted/security apps. The libc of TEEOS is a part of musl. The kernel of TEEOS is micro kernel.
This MR is to add a target for teeos.
MRs for libc and rust-std are in progress.
Compiler team MCP: [MCP](https://github.com/rust-lang/compiler-team/issues/652)
|
|
correctly lower `impl const` to bind to host effect param
r? `@oli-obk`
|
|
|
|
|
|
Add hotness data to LLVM remarks
Slight improvement of https://github.com/rust-lang/rust/pull/113040. This makes sure that if PGO is used, remarks generated using `-Zremark-dir` will include the `Hotness` attribute.
r? `@tmiasko`
|
|
the host.
thus we should no longer see test failures for e.g. wasm32 target.
|
|
The code fails to parse with `nightly-2021-02-05`:
$ cargo +nightly-2021-02-05 build
error: generic associated types in trait paths are currently not implemented
--> src/main.rs:9:42
|
9 | fn _bar<T: for<'a> StreamingIterator<Item<'a> = &'a [i32]>>(_iter: T) { /* ... */
| ^^^^
but parses with `nightly-2021-02-06`:
$ cargo +nightly-2021-02-06 build
warning: the feature `generic_associated_types` is incomplete and may not be safe to use and/or cause compiler crashes
warning: 1 warning emitted
because it was (with high probability) fixed by PR 79554 which was merged
within that nightly range.
|
|
|
|
Map RPIT duplicated lifetimes back to fn captured lifetimes
Use the [`lifetime_mapping`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir/struct.OpaqueTy.html#structfield.lifetime_mapping) to map an RPIT's captured lifetimes back to the early- or late-bound lifetimes from its parent function. We may be going thru several layers of mapping, since opaques can be nested, so we introduce `TyCtxt::map_rpit_lifetime_to_fn_lifetime` to loop through several opaques worth of mapping, and handle turning it into a `ty::Region` as well.
We can then use this instead of the identity substs for RPITs in `check_opaque_meets_bounds` to address #114285.
We can then also use `map_rpit_lifetime_to_fn_lifetime` to properly install bidirectional-outlives predicates for both RPITs and RPITITs. This addresses #114601.
I based this on #114574, but I don't actually know how much of that PR we still need, so some code may be redundant now... :shrug:
---
Fixes #114597
Fixes #114579
Fixes #114285
Also fixes #114601, since it turns out we had other bugs with RPITITs and their duplicated lifetime params :sweat_smile:.
Supersedes #114574
r? `@oli-obk`
|
|
|
|
from the single use of a RPIT in its parent function's return type
|
|
|
|
|
|
simplify handling of valtrees for unsized types
|
|
|
|
Structurally normalize weak and inherent in new solver
It seems pretty obvious to me that we should be normalizing weak and inherent aliases too, since they can always be normalized. This PR still leaves open the question of what to do with opaques, though 💀
**Also**, we need to structurally resolve the target of a coercion, for the UI test to work.
r? `@lcnr`
|
|
r=oli-obk
Store the laziness of type aliases in their `DefKind`
Previously, we would treat paths referring to type aliases as *lazy* type aliases if the current crate had lazy type aliases enabled independently of whether the crate which the alias was defined in had the feature enabled or not.
With this PR, the laziness of a type alias depends on the crate it is defined in. This generally makes more sense to me especially if / once lazy type aliases become the default in a new edition and we need to think about *edition interoperability*:
Consider the hypothetical case where the dependency crate has an older edition (and thus eager type aliases), it exports a type alias with bounds & a where-clause (which are void but technically valid), the dependent crate has the latest edition (and thus lazy type aliases) and it uses that type alias. Arguably, the bounds should *not* be checked since at any time, the dependency crate should be allowed to change the bounds at will with a *non*-major version bump & without negatively affecting downstream crates.
As for the reverse case (dependency: lazy type aliases, dependent: eager type aliases), I guess it rules out anything from slight confusion to mild annoyance from upstream crate authors that would be caused by the compiler ignoring the bounds of their type aliases in downstream crates with older editions.
---
This fixes #114468 since before, my assumption that the type alias associated with a given weak projection was lazy (and therefore had its variances computed) did not necessarily hold in cross-crate scenarios (which [I kinda had a hunch about](https://github.com/rust-lang/rust/pull/114253#discussion_r1278608099)) as outlined above. Now it does hold.
`@rustbot` label F-lazy_type_alias
r? `@oli-obk`
|
|
Warn when #[macro_export] is applied on decl macros
The existing code checks if `#[macro_export]` is being applied to an item other than a macro, and warns in that case, but fails to take into account macros 2.0/decl macros, despite the attribute having no effect on these macros.
This PR adds a special case for decl macros with the aforementioned attribute, so that the warning is a bit more precise. Instead of just saying "this attribute has no effect", hint towards the fact that decl macros get exported and resolved like regular items.
It also removes a `#[macro_export]` attribute which was applied on one of `core`'s decl macros.
- core: Remove #[macro_export] from `debug_assert_matches`
- check_attrs: Warn when #[macro_export] is used on macros 2.0
|
|
Fix #90546 by filtering out global value function pointer types from the
type tests, and adding the LowerTypeTests pass to the rustc LTO
optimization pipelines.
|
|
The compiler should emit a more specific error when the `#[macro_export]`
attribute is present on a decl macro, instead of silently ignoring it.
This commit adds the required error message in rustc_passes/messages.ftl,
as well as a note. A new variant is added to the `errors::MacroExport`
enum, specifically for the case where the attribute is added to a macro
2.0.
|
|
|
|
Prevent fill from being (correctly) optimized away by passing the
address of the alloca to black_box.
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- #113568 (Fix spurious test failure with `panic=abort`)
- #114196 (Bubble up nested goals from equation in `predicates_for_object_candidate`)
- #114485 (Add trait decls to SMIR)
- #114495 (Set max_atomic_width for AVR to 16)
- #114496 (Set max_atomic_width for sparc-unknown-linux-gnu to 32)
- #114510 (llvm-wrapper: adapt for LLVM API changes)
- #114562 (stabilize abi_thiscall)
- #114570 ([miri][typo] Fix a typo in a vector_block comment.)
- #114573 (CI: do not hide error logs in a group)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
stabilize abi_thiscall
Closes https://github.com/rust-lang/rust/issues/42202, stabilizing the use of the "thiscall" ABI.
FCP was substituted by a poll, and the poll has been accepted.
|
|
Bubble up nested goals from equation in `predicates_for_object_candidate`
This used to be needed for https://github.com/rust-lang/rust/pull/114036#discussion_r1273987510, but since it's no longer, I'm opening this as a separate PR. This also fixes one ICEing UI test: (`tests/ui/unboxed-closures/issue-53448.rs`)
r? `@lcnr`
|
|
Fix spurious test failure with `panic=abort`
Description on why it happens and why the fix should work is in the code comments.
|
|
|
|
|
|
Make `unconditional_recursion` warning detect recursive drops
Closes #55388
Also closes #50049 unless we want to keep it for the second example which this PR does not solve, but I think it is better to track that work in #57965.
r? `@oli-obk` since you are the mentor for #55388
Unresolved questions:
- [x] There are two false positives that must be fixed before merging (see diff). I suspect the best way to solve them is to perform analysis after drop elaboration instead of before, as now, but I have not explored that any further yet. Could that be an option? **Answer:** Yes, that solved the problem.
`@rustbot` label +T-compiler +C-enhancement +A-lint
|
|
|
|
Add a new `compare_bytes` intrinsic instead of calling `memcmp` directly
As discussed in #113435, this lets the backends be the place that can have the "don't call the function if n == 0" logic, if it's needed for the target. (I didn't actually *add* those checks, though, since as I understood it we didn't actually need them on known targets?)
Doing this also let me make it `const` (unstable), which I don't think `extern "C" fn memcmp` can be.
cc `@RalfJung` `@Amanieu`
|
|
r=Mark-Simulacrum
Nest other codegen test topics
This PR is like rust-lang/rust#114229 in that it mostly pushes codegen tests around, shoving them into their own directories, but because all of the changes are very simple cleanups I pulled them into a separate PR. The other PR might involve actually evaluating the correctness of the test after changes, but here it is mostly a matter of taste. The only "functional" change is deleting a few tests that... hinge on a version of LLVM that we don't support (as of rust-lang/rust#114148 anyways).
I considered a few different ways to group other topics but I feel the question of whether `tests/codegen/{vec,array,slice}` should exist is more subtle than these choices, as it might be better to group such related tests by other topics like bounds check elision, thus I avoided making it.
|
|
Nest tests/codegen/sanitizer*.rs tests in sanitizer dir
The sanitizer tests are the largest and most meticulously tested set of tests in tests/codegen. That's good! They all clearly belong to a subject and thus could go in a directory, but are not, instead being placed simply in tests/codegen. That's bad! Fix this by placing them in their own directory and renaming them to be less repetitive after that move.
A few tests are brittle, and embed their filename in the test's checks. This is acceptable for the ones where it is used only two times, but one test embeds the test's mangled filename in the test *over 50 times*! This may have been one of the things discouraging anyone from moving it, and thus from moving the set. Fortunately, I have some knowledge of Itanium mangling (involuntarily), regex, and the FileCheck syntax. With a capturing variable, FileCheck allows us to now move this test around again without diffing it on ~50 lines, while still guaranteeing that the mangled substring is the same each time.
This also clarifies why the substring is repeated a zillion times, instead of being cryptic. They don't call it mangling because the result is pretty and easy to understand, but now it is slightly easier! Yay descriptive variables!
|
|
Add regression test for `echo 'mod unknown;' | rustc -`
Closes #65601
The bug is fixed since long ago, probably by #69838 (see https://github.com/rust-lang/rust/issues/65601#issuecomment-1650508071 for more details).
Add a regression test so we can close the issue.
|
|
|
|
Remove FIXME about NLL diagnostic that is already improved
The FIXME was added in #46984 when the diagnostic message looked like this:
// FIXME(#46983): error message should be better
&s.0 //~ ERROR free region `` does not outlive free region `'static`
The message was improved in #90667 and now looks like this:
&s.0 //~ ERROR lifetime may not live long enough
but the FIXME was not removed. The issue #46983 about that diagnostics should be improved has been closed. We can remove the FIXME now.
(This PR was made for #44366.)
|
|
add tests for some fixed ConstProp ICEs
Fixes https://github.com/rust-lang/rust/issues/96944
Fixes https://github.com/rust-lang/rust/issues/111353
|
|
Rollup of 5 pull requests
Successful merges:
- #114466 (Add Allocation to SMIR)
- #114505 (Add documentation to has_deref)
- #114519 (use offset_of! to calculate dirent64 field offsets)
- #114537 (Migrate GUI colors test to original CSS color format)
- #114539 (linkchecker: Remove unneeded FIXME about intra-doc links)
Failed merges:
- #114485 (Add trait decls to SMIR)
r? `@ghost`
`@rustbot` modify labels: rollup
|
