| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
Add some inference-related regression tests about incorrect diagnostics
Closes #71732
Closes #72616
|
|
Add regression test of issue-77668
Closes #77668
|
|
Reduce diagram mess in 'match arms have incompatible types' error
I noticed this wild diagram in https://twitter.com/a_hoverbear/status/1318960787105353728 which I think does not benefit from the big outer vertical span.
This PR shrinks the outer span to cover just the `match` keyword and scrutinee expression *if* at least one of the highlighted match arms involved in the error is multiline.
**Before:**
<pre>
<b>error[E0308]: `match` arms have incompatible types</b>
<b>--></b> src/topology/builder.rs:141:35
<b>|</b>
<b>120 |</b> let transform = match transform {
<b>| _________________________-</b>
<b>121 | |</b> Transform::Function(t) => {
<b>| _|_______________________________________-</b>
<b>122 | | |</b> filter_event_type(input_rx, input_type).compat().flat_map(|v| {
<b>123 | | |</b> futures::stream::iter(match v {
<b>124 | | |</b> Err(e) => {
<b>... | |</b>
<b>139 | | |</b> .compat();
<b>140 | | |</b> }
<b>| |_|_____________- this is found to be of type `()`</b>
<b>141 | |</b> Transform::Task(t) => t
<b>| _|___________________________________^</b>
<b>142 | | |</b> .transform(filter_event_type(input_rx, input_type))
<b>143 | | |</b> .forward(output)
<b>144 | | |</b> .map(|_| debug!("Finished"))
<b>145 | | |</b> .compat(),
<b>| |_|_________________________^ expected `()`, found struct `futures::compat::Compat01As03`</b>
<b>146 | |</b> };
<b>| |_________- `match` arms have incompatible types</b>
<b>|</b>
<b>= note:</b> expected type `<b>()</b>`
found struct `<b>futures::compat::Compat01As03<futures::Map<futures::stream::Forward<std::boxed::Box<dyn futures::Stream<Error = (), Item = event::Event> + std::marker::Send>, topology::fanout::Fanout>, [closure@src/topology/builder.rs:144:22: 144:44]>></b>`
</pre>
**After:**
<pre>
<b>error[E0308]: `match` arms have incompatible types</b>
<b>--></b> src/topology/builder.rs:141:35
<b>|</b>
<b>120 |</b> let transform = match transform {
<b>| --------------- `match` arms have incompatible types</b>
<b>121 |</b> Transform::Function(t) => {
<b>| _________________________________________-</b>
<b>122 | |</b> filter_event_type(input_rx, input_type).compat().flat_map(|v| {
<b>123 | |</b> futures::stream::iter(match v {
<b>124 | |</b> Err(e) => {
<b>... |</b>
<b>139 | |</b> .compat();
<b>140 | |</b> }
<b>| |_______________- this is found to be of type `()`</b>
<b>141 |</b> Transform::Task(t) => t
<b>| _____________________________________^</b>
<b>142 | |</b> .transform(filter_event_type(input_rx, input_type))
<b>143 | |</b> .forward(output)
<b>144 | |</b> .map(|_| debug!("Finished"))
<b>145 | |</b> .compat(),
<b>| |___________________________^ expected `()`, found struct `futures::compat::Compat01As03`</b>
<b>|</b>
<b>= note:</b> expected type `<b>()</b>`
found struct `<b>futures::compat::Compat01As03<futures::Map<futures::stream::Forward<std::boxed::Box<dyn futures::Stream<Error = (), Item = event::Event> + std::marker::Send>, topology::fanout::Fanout>, [closure@src/topology/builder.rs:144:22: 144:44]>></b>`
</pre>
FYI @Hoverbear
|
|
Explain where the closure return type was inferred
Fixes #78193
|
|
Make closures inherit the parent function's target features
r? @ghost
Closes #73631
|
|
Update cargo
3 commits in 79b397d72c557eb6444a2ba0dc00a211a226a35a..dd83ae55c871d94f060524656abab62ec40b4c40
2020-10-15 14:41:21 +0000 to 2020-10-20 19:31:26 +0000
- Support glob patterns for package/target selection (rust-lang/cargo#8752)
- Update env_logger requirement from 0.7.0 to 0.8.1 (rust-lang/cargo#8795)
- Fix man page links inside `option` blocks. (rust-lang/cargo#8793)
|
|
Sync LLVM submodule if it has been initialized
Since having enabled the download-ci-llvm option,
and having rebased on top of #76864,
I've noticed that I had to update the llvm-project
submodule manually if it was checked out.
Orignally, the submodule update logic was
introduced to reduce the friction for contributors
to manage the submodules, or in other words, to prevent
getting PRs that have unwanted submodule rollbacks
because the contributors didn't run git submodule update.
This commit adds logic to ensure there is no inadvertent
LLVM submodule rollback in a PR if download-ci-llvm
(or llvm-config) is enabled. It will detect whether the
llvm-project submodule is initialized, and if so, update
it in any case. If it is not initialized, behaviour is
kept to not do any update/initialization.
An alternative to the chosen implementation would
be to not pass the --init command line arg to
`git submodule update` for the src/llvm-project
submodule. This would show a confusing error message
however on all builds with an uninitialized repo.
We could pass the --silent param, but we still want
it to print something if it is initialized and has
to update something.
So we just do a manual check for whether the
submodule is initialized.
|
|
Make inline const work in range patterns
Fixes #78108 which is a follow up of https://github.com/rust-lang/rust/pull/77124
r? @petrochenkov
|
|
Clean up and improve some docs
* compiler docs
* Don't format list as part of a code block
* Clean up some other formatting
* rustdoc book
* Update CommonMark spec version to latest (0.28 -> 0.29)
* Clean up some various wording and formatting
|
|
Avoid extraneous space between visibility kw and ident for statics
Today, given a static like `static mut FOO: usize = 1`, rustdoc would
emit `static mut FOO: usize = 1`, as it emits both the mutability kw
with a space and reserves a space after the mutability kw. This patch
fixes that misformatting.
This patch also adds some tests for emit of other statics, as I could
not find an existing test devoted to statics.
|
|
Mark `repr128` as `incomplete_features`
As mentioned in https://github.com/rust-lang/rust/issues/56071 and noticed in https://github.com/rust-lang/rust/issues/77457, `repr(u128)` and `repr(i128)` do not work properly due to lack of LLVM support. We should thus warn users trying to use the feature that they may encounter ICEs when using it.
Closes https://github.com/rust-lang/rust/issues/77457.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fixes #78193
|
|
Fix trait solving ICEs
- Selection candidates that are known to be applicable are preferred
over candidates that are not.
- Don't ICE if a projection/object candidate is no longer applicable
(this can happen due to cycles in normalization)
- Normalize supertraits when finding trait object candidates
Closes #77653
Closes #77656
r? `@nikomatsakis`
|
|
|
|
|
|
|
|
|
|
Package more llvm-* tools in the rust-dev component, for run-make-fulldeps tests
Fixes https://github.com/rust-lang/rust/issues/78110
|
|
Rollup of 10 pull requests
Successful merges:
- #77420 (Unify const-checking structured errors for `&mut` and `&raw mut`)
- #77554 (Support signed integers and `char` in v0 mangling)
- #77976 (Mark inout asm! operands as used in liveness pass)
- #78009 (Haiku: explicitly set CMAKE_SYSTEM_NAME when cross-compiling)
- #78084 (Greatly improve display for small mobile devices screens)
- #78155 (Fix two small issues in compiler/rustc_lint/src/types.rs)
- #78156 (Fixed build failure of `rustfmt`)
- #78172 (Add test case for #77062)
- #78188 (Add tracking issue number for pin_static_ref)
- #78200 (Add `ControlFlow::is_{break,continue}` methods)
Failed merges:
r? `@ghost`
|
|
* compiler docs
* Don't format list as part of a code block
* Clean up some other formatting
* rustdoc book
* Update CommonMark spec version to latest (0.28 -> 0.29)
* Clean up some various wording and formatting
|
|
Add test case for #77062
Closes #77062
|
|
Greatly improve display for small mobile devices screens
Fixes #78014.
The biggest change being the "search bar". Instead of having everything on one line, I decided to move the search input on its own:
Another change is that now, we "break words" in the listing so that they don't grow too big:
r? @jyn514
|
|
Haiku: explicitly set CMAKE_SYSTEM_NAME when cross-compiling
This resolves issues where the cross-build of LLVM fails because it tries to
link to the host's system libraries instead of the target's system libraries.
|
|
Mark inout asm! operands as used in liveness pass
Variables used in `inout` operands in inline assembly (that is, they're used as both input and output to some arbitrary assembly instruction) are being marked as read and written, but are not marked as being used in the RWU table during the liveness pass. This can result in such expressions triggering an unused variable lint warning. This is incorrect behavior- reads without uses are currently only used for compound assignments. We conservatively assume that an `inout` operand is being read and used in the context of the assembly instruction.
Closes #77915
|
|
Support signed integers and `char` in v0 mangling
Likely we want more tests, to check the output is correct too: however, I wasn't sure what kind of test we needed, so I just added one similar to that added in https://github.com/rust-lang/rust/pull/77452 for now.
r? @eddyb
|
|
Unify const-checking structured errors for `&mut` and `&raw mut`
Resolves #77414 as well as a FIXME.
|
|
Lift: take self by value
seems small enough to not warrant an MCP :shrug:
|
|
|
|
|
|
Calculate visibilities once in resolve
Then use them through a query based on resolver outputs.
Item visibilities were previously calculated in three places - initially in `rustc_resolve`, then in `rustc_privacy` during type privacy checkin, and then in `rustc_metadata` during metadata encoding.
The visibility logic is not entirely trivial, especially for things like constructors or enum variants, and all of it was duplicated.
This PR deduplicates all the visibility calculations, visibilities are determined once during early name resolution and then stored in `ResolverOutputs` and are later available through `tcx` as a query `tcx.visibility(def_id)`.
(This query existed previously, but only worked for other crates.)
Some special cases (e.g. visibilities for closure types, which are needed for type privacy checking) are not processed in resolve, but deferred and performed directly in the query instead.
|
|
|
|
|
|
|
|
Cycles in normalization can cause evaluations to change from Unknown to
Err. This means that some selection that were applicable no longer are.
To avoid this:
* Selection candidates that are known to be applicable are prefered
over candidates that are not.
* We don't ICE if a candidate is no longer applicable.
|
|
|
|
|
|
Inline const followups
r? @petrochenkov
Follow ups of #77124
|
|
fix static_ptr_ty for foreign statics
Cc https://github.com/rust-lang/rust/issues/74840
This does not fix that issue but fixes a problem in `static_ptr_ty` that we noticed while discussing that issue. I also added and updated a few comments. The one about `internal` locals being ignored does not seem to have been true [even in the commit that introduced it](https://github.com/rust-lang/rust/pull/44700/files#diff-ae2f3c7e2f9744f7ef43e96072b10e98d4e3fe74a3a399a3ad8a810fbe56c520R139).
r? @oli-obk
|
