| Age | Commit message (Collapse) | Author | Lines |
|---|
|
llvm 16 finally reconizes some additional vec in-place conversions as noops
closes #79308
r? `@nikic`
|
|
diagnostics: account for glob shadowing when linting redundant imports
Fixes #92904
|
|
Add async-await test for #107414
fixes #107414
r? `@cjgillot`
|
|
Nilstrieb:integers-are-not-fn-ptrs-remember-this-dear-transmuter, r=compiler-errors
Never consider int and float vars for `FnPtr` candidates
This solves a regression where `0.0.cmp()` was ambiguous when a custom trait with a `cmp` method was in scope.
For integers it shouldn't be a problem in practice so I wasn't able to add a test.
I'm not sure whether there could be more issues hidden in the shadows as mentioned in the issue, but this should at least fix the problematic regression immediately.
fixes #109892
r? oli-obk
|
|
|
|
This solves a regression where `0.0.cmp()` was ambiguous when a custom
trait with a `cmp` method was in scope.
FOr integers it shouldn't be a problem in practice so I wasn't able to
add a test.
|
|
|
|
Move some UI tests into subdirectories
|
|
fix(middle): emit error rather than delay bug when reaching limit
close #109304
|
|
|
|
Move almost all run-make-fulldeps tests to run-make
They pass fine, and this avoids having to build the compiler twice.
There are few enough tests left that I think it should be possible to get rid of this test suite altogether, but I expect this PR to fail at least a few times in bors and want to get it merged before tackling further changes. cc https://github.com/rust-lang/rust/pull/83775
Fixes https://github.com/rust-lang/rust/issues/66085. Fixes https://github.com/rust-lang/rust/issues/83773.
|
|
to avoid going over the existing limit now that the ui-fulldeps tests have
been moved to ui.
|
|
|
|
Drop array patterns using subslices
Fixes #109004
Drops contiguous subslices of an array when moving elements out with a pattern, which improves perf for large arrays
r? `@compiler-errors`
|
|
|
|
Co-Authored-By: Vadim Petrochenkov <vadim.petrochenkov@gmail.com>
|
|
add test for normalization in implied bounds query
See https://github.com/rust-lang/rust/issues/109799.
|
|
allow ReError in CanonicalUserTypeAnnotation
Why not? we already allow `TyKind::Error`.
Fixes #109072.
|
|
Rollup of 7 pull requests
Successful merges:
- #109104 (rustdoc: Fix invalid suggestions on ambiguous intra doc links v2)
- #109443 (Move `doc(primitive)` future incompat warning to `invalid_doc_attributes`)
- #109680 (Fix subslice capture in closure)
- #109798 (fluent_messages macro: don't emit the OS error in a note)
- #109805 (Source map cleanups)
- #109818 (rustdoc: Add GUI test for jump to collapsed item)
- #109820 (rustdoc-search: update docs for comma in `?` help popover)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
rustdoc: Add GUI test for jump to collapsed item
Part of https://github.com/rust-lang/rust/issues/66181.
I updated `browser-ui-test` version because I needed to add a new command `property`: https://github.com/GuillaumeGomez/browser-UI-test/pull/452.
r? `@notriddle`
|
|
fluent_messages macro: don't emit the OS error in a note
This makes it possible to make the normalization of the error message precise, allowing us to not normalize all notes away. See https://github.com/rust-lang/rust/pull/109700#discussion_r1152489053
|
|
Fix subslice capture in closure
Fixes #109298 by refining captures in the same way for Subslices and Indexes. The comment `// we never capture this` seems to have been inaccurate, as changing it to an assert causes many test failures
`@rustbot` label +A-closures
|
|
Move `doc(primitive)` future incompat warning to `invalid_doc_attributes`
Fixes #88070.
It's been a while since this was turned into a "future incompatible lint" so I think we can now turn it into a hard error without problem.
r? `@jyn514`
|
|
GuillaumeGomez:fix-invalid-suggestion-ambiguous-intra-doc2, r=oli-obk,notriddle
rustdoc: Fix invalid suggestions on ambiguous intra doc links v2
Fixes https://github.com/rust-lang/rust/issues/108653.
This is another approach to fixing the same issue. This time, we keep the computed information around instead of re-computing it.
Strangely enough, the order for ambiguities seem to have been changed. Not an issue but it creates a lot of diff...
So which version do you prefer?
r? `@notriddle`
|
|
Initial support for return type notation (RTN)
See: https://smallcultfollowing.com/babysteps/blog/2023/02/13/return-type-notation-send-bounds-part-2/
1. Only supports `T: Trait<method(): Send>` style bounds, not `<T as Trait>::method(): Send`. Checking validity and injecting an implicit binder for all of the late-bound method generics is harder to do for the latter.
* I'd add this in a follow-up.
3. ~Doesn't support RTN in general type position, i.e. no `let x: <T as Trait>::method() = ...`~
* I don't think we actually want this.
5. Doesn't add syntax for "eliding" the function args -- i.e. for now, we write `method(): Send` instead of `method(..): Send`.
* May be a hazard if we try to add it in the future. I'll probably add it in a follow-up later, with a structured suggestion to change `method()` to `method(..)` once we add it.
7. ~I'm not in love with the feature gate name 😺~
* I renamed it to `return_type_notation` :heavy_check_mark:
Follow-up PRs will probably add support for `where T::method(): Send` bounds. I'm not sure if we ever want to support return-type-notation in arbitrary type positions. I may also make the bounds require `..` in the args list later.
r? `@ghost`
|
|
|
|
|
|
Insert alignment checks for pointer dereferences when debug assertions are enabled
Closes https://github.com/rust-lang/rust/issues/54915
- [x] Jake tells me this sounds like a place to use `MirPatch`, but I can't figure out how to insert a new basic block with a new terminator in the middle of an existing basic block, using `MirPatch`. (if nobody else backs up this point I'm checking this as "not actually a good idea" because the code looks pretty clean to me after rearranging it a bit)
- [x] Using `CastKind::PointerExposeAddress` is definitely wrong, we don't want to expose. Calling a function to get the pointer address seems quite excessive. ~I'll see if I can add a new `CastKind`.~ `CastKind::Transmute` to the rescue!
- [x] Implement a more helpful panic message like slice bounds checking.
r? `@oli-obk`
|
|
|
|
See https://github.com/rust-lang/rust/issues/109799.
|
|
This makes it possible to make the normalization of the error message
more precise, allowing us to not normalize all notes away.
|
|
Rollup of 6 pull requests
Successful merges:
- #109347 (Skip no_mangle if the item has no name.)
- #109522 (Implement current_dll_path for AIX)
- #109679 (Freshen normalizes-to hack goal RHS in the evaluate loop)
- #109704 (resolve: Minor improvements to effective visibilities)
- #109739 (Closures always implement `FnOnce` in new solver)
- #109758 (Parallel compiler cleanups)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
Closures always implement `FnOnce` in new solver
We should process `[closure]: FnOnce(Tys...) -> Ty` obligations *before* fallback and closure analysis. We can do this by taking advantage of the fact that `FnOnce` is always implemented by closures, even before we definitely know the closure kind.
Fixes compiler-errors/next-solver-hir-issues#15
r? ``@oli-obk`` (trying to spread the reviewer load for new trait solver prs, and this one is pretty self-contained, though feel free to reassign 😸)
|
|
resolve: Minor improvements to effective visibilities
See individual commits.
|
|
Skip no_mangle if the item has no name.
Fixes https://github.com/rust-lang/rust/issues/109305
|
|
compiler-errors:new-solver-deep-reject-placeholder-consts, r=lcnr
Don't ICE on placeholder consts in deep reject
Since we canonicalize const params into placeholder consts, we need to be able to handle them during deep reject.
r? `@lcnr` (though maybe `@oli-obk` can look at this one too, if he wants 😸)
Fixes compiler-errors/next-solver-hir-issues#10
|
|
megakorre:rustdock_additional_typecheck_before_clean, r=GuillaumeGomez
rustdoc: run more HIR validation to mirror rustc
# Explanation
While investigating these issues: https://github.com/rust-lang/rust/issues/107093, https://github.com/rust-lang/rust/issues/106079
I thought it maybe would be useful to test running `rustdoc` on all rust files under `tests/ui` grepping for files that causes any ICEs.
And these are the files I found would cause ICEs.
```
// These are handled by this fix.
tests/ui/late-bound-lifetimes/mismatched_arg_count.rs
tests/ui/associated-consts/issue-102335-const.rs
tests/ui/const-generics/generic_const_exprs/issue-102768.rs
tests/ui/const-generics/const-arg-type-arg-misordered.rs
tests/ui/generic-associated-types/parse/trait-path-type-error-once-implemented.rs
tests/ui/typeck/issue-88643.rs
tests/ui/typeck/issue-75889.rs
tests/ui/typeck/issue-83621-placeholder-static-in-extern.rs
// These are not they will still produce a ICE after this change
tests/ui/limits/issue-56762.rs
tests/ui/union/projection-as-union-type-error-2.rs
tests/ui/union/projection-as-union-type-error.rs
```
I reduces the issues handled by this PR down to the tests added in the PR. That includes the linked issues.
But the 3 files that are not handled I will leave for a future PR.
This PR adds the `type_collecting` step from `hir_analysis::check_crate` to the rustdoc typechecks.
It had the following comment on it.
```
// this ensures that later parts of type checking can assume that items
// have valid types and not error
```
Adding the check report the same errors as rustc does for these input.
And not ICE when the lint checker walks the HIR or when in the `rustdoc::clean` pass.
This PR updates the expected errors of some existing rustdoc-ui tests (some now report less errors).
These new reported errors does mirror the errors reported by rustc.
# Performance
It does more checking so it will probably regress. We should run ``@bors` try `@rust-timer` queue` and see.
# Discussion
Maybe instead of calling a subset of the checks in `hir_analysis::check_crate` and having comments that say they should be kept in sync. We could instead call `check_crate` directly and pass in some flag. Maybe `check_toplevel_signatures_only` or something like that. That flag would have to skip most of the checks in that function tough.
|
|
|
|
|
|
`run-make-fulldeps` is never cross-compiled, so a lot of these tests
never accounted for --target. Ignore them when cross-compiling for
now.
|
|
|
|
apparently I missed some tests in the last commit. Rather than having
dozens of tests use the long version, use the short version in
`run-make` and the long version in `run-make-fulldeps` (which is now
only three tests)
|
|
|
|
|
|
|
|
|
|
|
|
|
