Fix return type notation associated type suggestion when -Zlower-impl-trait-in-trait-to-assoc-ty
This avoid suggesting the associated types generated for RPITITs when the one the code refers to doesn't exist and rustc looks for a suggestion.
r? `@compiler-errors`
Fix return type notation errors with -Zlower-impl-trait-in-trait-to-assoc-ty
This just adjust the way we check for RPITITs and uses the new helper method to do the "old" and "new" check at once.
r? `@compiler-errors`
Don't emit same goal as input during `wf::unnormalized_obligations`
r? `@aliemjay` cc `@lcnr`
I accidentally pruned the logic to handle `WF(?0)` when writing `wf::unnormalized_obligations`.
idk if you wanted to construct a test first, but this is an obvious fix. Copied the comment from above.
Fixesrust-lang/trait-system-refactor-initiative#36
Stop bubbling out hidden types from the eval obligation queries
r? `@compiler-errors`
I don't know why these were added, but they are not needed anymore. The relevant test is unaffected and I didn't see anything interesting in logging that would have justified it.
This PR has no effect on the new solver behaviour of cf2dff2b1e/tests/ui/impl-trait/issue-99642.rs (which is overflow) and cf2dff2b1e/tests/ui/impl-trait/issue-99642-2.rs (which is "unstable certainty ICE")
Implement `Sync` for `mpsc::Sender`
`mpsc::Sender` is currently `!Sync` because the previous implementation contained an optimization where the channel started out as single-producer and was dynamically upgraded on the first clone, which relied on a unique reference to the sender. This optimization is one of the main reasons the old implementation was so complex and was removed in #93563. `mpsc::Sender` can now soundly implement `Sync`.
Note for any potential confusion, this chance does *not* add MPMC behavior. This only affects the already `Send + Clone` *sender*, not *receiver*.
It's technically possible to rely on the `!Sync` behavior in the same way as a `PhantomData<*mut T>`, but that seems very unlikely in practice. Either way, this change is insta-stable and needs an FCP.
`@rustbot` label +T-libs-api -T-libs
This moves a lot of code around, but the logic itself is not too terribly complicated.
- Move almost all logic in `def bootstrap` to the `RustBuild` class, to avoid mixing setting configuration with running commands
- Update various doctests to the new (more complete) RustBuild config. In particular, don't pretend that `bin_root` supports `build` being unset.
- Change `parse_args` not to use a global, to allow testing it
- Set BUILD_DIR appropriately so bootstrap.py doesn't panic because cargo isn't found
Various impl trait in assoc tys cleanups
r? `@compiler-errors`
All commits except for the last are pure refactorings. 274dab5bd658c97886a8987340bf50ae57900c39 allows struct fields to participate in deciding whether a function has an opaque in its signature.
best reviewed commit by commit
This makes "existential type" look slightly cramped (though still
readable), but it makes all other typenames look better. Existential
types are currently very rare, and we can always tweak this later if
necessary.
Fix rustdoc gui tester
Problem was that the `main` was always exiting with `0`, whether or not there was an error. It led to failing GUI tests being ignored in the CI since no one saw them.
r? ````@klensy````
[tests/rustdoc] Add @files command
The ``````@!has`````` checks is very problematic as it wouldn't catch if the file scheme is updated and the file is generated again. ``````@files`````` allows to ensure that the given folder contains exactly the provided entries (files and folders).
I'm wondering if we should forbid the ``````@!has`````` for files. To be discussed after this PR I suppose.
r? `````@notriddle`````
Stop hiding const eval limit in external macros
fixes#112748
We don't emit a hard error if there was a previous deny lint triggering with the same message. If that lint ends up not being emitted, we ICE and don't emit an error either.
Migrate `item_bounds` to `ty::Clause`
Should be simpler than the next PR that's coming up. Last three commits are the relevant ones.
r? ``@oli-obk`` or ``@lcnr``
Don't ICE on unnormalized struct tail in layout computation
1. We try to compute a `SizeSkeleton` even if a layout error occurs, but we really only need to do this if we get `LayoutError::Unknown`, since that means our type is too polymorphic to actually compute the full layout. If we have other errors, like `LayoutError::NormalizationError` or `LayoutError::Cycle`, then we can't really make any progress, since this represents an actual error.
2. Avoid using `normalize_erasing_regions` and `struct_tail_erasing_lifetimes` since those ICE on normalization errors, and since we may call `layout_of` in HIR typeck, we don't know for certain that we're on the happy path.
Fixes#112736
Always register sized obligation for argument
Removes a "hack" that skips registering sized obligations for parameters that are simple identifiers. This doesn't seem to affect diagnostics because we're probably already being smart enough about deduplicating identical error messages anyways.
Fixes#112608
rustc_session: default to -Z plt=yes on non-x86_64
Per the discussion in #106380 plt=no isn't a great default, and rust-lang/compiler-team#581 decided that the default should be PLT=yes for everything except x86_64. Not everyone agrees about the x86_64 part of this change, but this at least is an improvement in the state of things without changing the x86_64 situation, so I've attempted making this change in the name of not letting the perfect be the enemy of the good.
Please let me know if I've messed this up somehow - I'm not wholly confident I got this right.
r? `@nikic`
