Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Change syntax of where clauses on type aliases #89122

Closed
nikomatsakis opened this issue Sep 20, 2021 · 47 comments · Fixed by #90076
Closed

Proposal: Change syntax of where clauses on type aliases #89122

nikomatsakis opened this issue Sep 20, 2021 · 47 comments · Fixed by #90076
Labels
F-generic_associated_types GATs-blocking GATs-triaged T-lang

Comments

@nikomatsakis
Copy link
Contributor

nikomatsakis commented Sep 20, 2021

Source

Summary

Proposed: to alter the syntax of where clauses on type aliases so that they appear after the value:

type StringMap<K> = BTreeMap<K, String>
where
    K: PartialOrd

This applies both in top-level modules and in trats (associated types, generic or otherwise).

Background

The current syntax for where to place the "where clause" of a generic associated types is awkward. Consider this example (playground):

trait Iterable {
    type Iter<'a> where Self: 'a;

    fn iter(&self) -> Self::Iter<'_>;
}

impl<T> Iterable for Vec<T> {
    type Iter<'a>
    where 
        Self: 'a = <&'a [T] as IntoIterator>::IntoIter;

    fn iter(&self) -> Self::Iter<'_> {
        self.iter()
    }
}

Note the impl. Most people expect the impl to be written as follows (indeed, the author wrote it this way in the first draft):

impl Iterable for Vec<T> {
    type Iter<'a>  = <&'a [T] as Iterator>::Iter
    where 
        Self: 'a;

    fn iter(&self) -> Self::Iter<'_> {
        self.iter()
    }
}

However, this placement of the where clause is in fact rather inconsistent, since the = <&'a [T] as Iterator>::Iter is in some sense the "body" of the item.

The same current syntax is used for where clauses on type aliases (playground):

type Foo<T> where T: Eq = Vec<T>;

fn main() { }

Top-level type aliases

Currently, we accept where clauses in top-level type aliases, but they are deprecated (warning) and semi-ignored:

type StringMap<K> where
    K: PartialOrd
= BTreeMap<K, String>

Under this proposal, this syntax remains, but is deprecated. The newer syntax for type aliases (with where coming after the type) would remain feature gated until such time as we enforce the expected semantics.

Alternatives

Keep the current syntax.

In this case, we must settle the question of how we expect it to be formatted (surely not as I have shown it above).

impl<T> Iterable for Vec<T> {
    type Iter<'a> where Self: 'a 
        = <&'a [T] as IntoIterator>::IntoIter;

    fn iter(&self) -> Self::Iter<'_> {
        self.iter()
    }
}

Accept either

What do we do if both are supplied?

@nikomatsakis nikomatsakis added T-lang F-generic_associated_types labels Sep 20, 2021
@nikomatsakis
Copy link
Contributor Author

nikomatsakis commented Sep 20, 2021

@rfcbot fcp merge

@jackh726 and I have discussed this issue and we both agree that changing the syntax here would be correct. I propose that we go ahead and do it.

@rfcbot
Copy link

rfcbot commented Sep 20, 2021

Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:

Concerns:

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@rfcbot rfcbot added proposed-final-comment-period disposition-merge labels Sep 20, 2021
@cramertj
Copy link
Member

cramertj commented Sep 20, 2021

Interesting! I can see why this would be desirable-- the formatting can work out a bit nicer in the new version, and it helps front-load the most important part of the alias (that is, it visually defers the bound until after the main part of the alias has been stated). However, I see two advantages to the previous approach:

  1. It's simpler to copy-paste bounds from the trait definition to the impl. trait Foo { type Bar where X: Y; } -> impl Foo for X { type Bar where X: Y = ...; } both match up visually, and one can create an impl by merely copy-pasting the trait definition and adding the appropriate = .... I appreciate this symmetry, and it would be surprising to me if this were not supported, or if I was given a warning.
  2. Conceptually, the bound is applying to the way the type alias may be used as stated in the trait definition. That is, the bound is not a property specific to the impl. This makes it more similar to the type signature of a trait method than the body of a trait method. Based on this, I'd expect it to belong on the left-hand side of the =. Trait definition / requirements first / on the left, followed by specifics of the impl is a useful pattern to keep, I think.

I don't think I feel particularly strongly either way, but the reasons above contribute to my initial preference for the old syntax.

@shepmaster
Copy link
Member

shepmaster commented Sep 20, 2021

@estebank pointed out to me that the parser might end up parsing both forms anyway, in order to provide useful diagnostics.

@nikomatsakis
Copy link
Contributor Author

nikomatsakis commented Sep 20, 2021

Yes, I expect the parser to parse both forms and offer useful tips for how to transform from one to the other.

@joshtriplett
Copy link
Member

joshtriplett commented Sep 20, 2021

FWIW, I can see why the type ... where ... = ... syntax would make sense as well, since it seems analogous to fn ...() where ... { ... }. I do think the proposed change feels more likely to produce readable code, though. On balance, I'd expect a where to get more complex than the RHS of the =.

@camelid
Copy link
Member

camelid commented Sep 20, 2021

Note also that trailing where clauses are supported for tuple structs:

// Compiles successfully.
pub struct Struct<T>(T)
where
    T: Eq;

@petrochenkov
Copy link
Contributor

petrochenkov commented Sep 20, 2021

@estebank pointed out to me that the parser might end up parsing both forms anyway, in order to provide useful diagnostics.

I think this is the way to go.
If this proposal is accepted, then we'll need to support where clauses in both positions anyway due to compatibility.
In that case why not return a non-fatal error in one of the cases, and normalize legal syntax to the single already existing form.

Most people expect the impl to be written as follows

What makes you think so?
In functions where clauses are between the header and the body, why in types it should be after the "body"?

In trait aliases, which have similar syntax with =, where is actually a part of the "body".
Will it use a second where for where clauses?

trait Alias = Body1 where Self: Body2 where NotABodyAnymore;

?

@nikomatsakis
Copy link
Contributor Author

nikomatsakis commented Sep 21, 2021

What makes you think so?

A fair question! Anecdotal reports. It's hard to quantify this, perhaps I should rewrite to "many people". We could try to get more precise about this, perhaps via a survey.

In that case why not return a non-fatal error in one of the cases, and normalize legal syntax to the single already existing form.

e.g., via rustfmt? That is an option, yes. We could simply union where clauses in the two positions.

@rfcbot rfcbot added final-comment-period and removed proposed-final-comment-period labels Sep 21, 2021
@rfcbot
Copy link

rfcbot commented Sep 21, 2021

🔔 This is now entering its final comment period, as per the review above. 🔔

@cramertj
Copy link
Member

cramertj commented Sep 21, 2021

Ah-- I made a procedural mistake and did not file a concern. I assume we're still considering this pending further discussion?

@rfcbot concern do-we-want-to-make-this-change

@rfcbot rfcbot added proposed-final-comment-period and removed final-comment-period labels Sep 21, 2021
@nikomatsakis
Copy link
Contributor Author

nikomatsakis commented Sep 21, 2021

We discussed this in our @rust-lang/lang meeting today. There wasn't a clear consensus one way or the other.

Some points we identified:

There are plenty of cases in Rust's existing grammar where where clauses follow types:

fn foo() -> T
where ...
{ }

impl Foo for Bar
where ...
{}

Therefore, there isn't really a concern about introducing new grammatical ambiguities (this was raised as a concern in the meeting).

One thing we did find is that, when reading type Foo = Bar where Baz, Some people mentally "group" the where clause with Bar, and some mentally group it with Foo. Note that, in all existing instances, where clauses are attached to the surrounding item.

We discussed whether changes to the formatting rules might help, but we didn't discuss that very much.

@estebank
Copy link
Contributor

estebank commented Sep 22, 2021

Third option: support both 😬

We have to support both in the parser for diagnostics, what if we just... accepted both ways?

@thorjelly
Copy link

thorjelly commented Sep 23, 2021

I personally feel as though type Foo<T> = Bar<T> where T: ... is semantically equivalent to fn foo<T>() -> Bar<T> where T: ... and impl Foo<T> for Bar<T> where T: ..., where in each case =, ->, and for sort of act as operators on Foo and Bar. Therefore, I feel like the new proposal is most consistent with the syntax people are most used to.

This is coming from someone who has barely used the current implementation of GATs, so I am unused to its syntax, I would find the new proposal a fair bit more intuitive.

@nikomatsakis
Copy link
Contributor Author

nikomatsakis commented Sep 23, 2021

@estebank I feel like supporting both without a real reason to support both is suboptimal. Then there will be confusion over whether there is a difference, for example, and perhaps two camps (one who prefers one, one who prefers the other). I don't mind more than one way to do things, but it feels like it needs strong justification to me.

One thing I would like is if rustfmt quietly changed from one to the other, though =) that would affect my opinion. But this isn't generally how rustfmt does things.

@dtolnay
Copy link
Member

dtolnay commented Sep 23, 2021

In the context of the FCP proposed in #89122 (comment), what behavior is proposed if where is given in both places?

type Thing<T> where T: IntoIterator = T::IntoIter
where
    T::Item: Clone;

Does this union the clauses, or does it reject? From the discussion above I'm unable to tell whether a concrete behavior was proposed. Asking as someone who will need to implement this in a Rust parser.

@dtolnay
Copy link
Member

dtolnay commented Sep 24, 2021

Separately, I feel that #89122 (comment) is going to require a response/consensus before completing the FCP.

Here is a concrete example to consider:

#![feature(trait_alias)]

trait Alias<T: Clone> = where T: Default;

// okay, equivalent to `where T: Clone + Default`
fn clone<T: Alias<T> + Clone>() {}

// ERROR, trait bound `T: Clone` not satisfied
fn default<T: Alias<T> + Default>() {}

In this situation, what is proposed to be the where equivalent of the T: Clone bound on Alias? Prior to this proposal, it's natural to expect that it would be:

trait Alias<T> where T: Clone = where T: Default;

This proposal throws a wrench in the works, as @petrochenkov called attention to. It would now seem to be the somewhat bizarre:

trait Alias<T> = where T: Default where T: Clone;

Relatedly, what does the following mean?

trait Alias<T> = Default
where
    T: Clone;

Is this equivalent to trait Alias<T: Clone> = Default, or to (the old interpretation of) trait Alias<T> = Default where T: Clone, which are not the same thing?

trait_alias is unstable (cc tracking issue #41517) but since the syntax is heavily inspired by type alias syntax, I think it's worth acknowledging the implications that type alias syntax changes would have on it, and maybe loop in people involved in that proposal if there are specific people.

@yasammez
Copy link

yasammez commented Sep 27, 2021

Third option: support both 😬

We have to support both in the parser for diagnostics, what if we just... accepted both ways?

This would be my least preferred option: if you support two variants for the same thing, any codebase of sufficient size will eventually contain both, no matter how strict you are trying to be. This increases the mental burden for developers trying to understand existing code and leads to needless discussions about which style to prefer within teams.

@nikomatsakis
Copy link
Contributor Author

nikomatsakis commented Sep 30, 2021

@petrochenkov

In trait aliases, which have similar syntax with =, where is actually a part of the "body".

Remind me, do trait aliases currently permit where clauses in both places?

@petrochenkov
Copy link
Contributor

petrochenkov commented Sep 30, 2021

do trait aliases currently permit where clauses in both places?

Not right now, but both positions have a well-defined meaning in theory, as @dtolnay describes in #89122 (comment).

@p-avital
Copy link

p-avital commented Feb 17, 2022

While I agree that where clause placement is sometimes a bit awkward, I really don't feel it's worth blocking GATs.

Shouldn't this wait for a later release, so that the decision can be given time without blocking GATs?

@jackh726
Copy link
Contributor

jackh726 commented Feb 17, 2022

I just noticed that the syntax is alreay arbitary

struct A<T> (bool, T) where T: Copy;
struct B<T> where T: Copy { a: T }
type C = A<String>;
type D = B<String>;

This was discussed in a lang design meeting a couple months back: https://github.com/rust-lang/lang-team/blob/master/design-meeting-minutes/2021-10-13-where-the-where.md#q-4

While I agree that where clause placement is sometimes a bit awkward, I really don't feel it's worth blocking GATs.

This 100% has to block, given that where clauses on associated types are currently unstable. It doesn't matter too much; this question is resolved and just waiting for the PR to be approved and merged.

bors added a commit to rust-lang-ci/rust that referenced this issue Mar 5, 2022
Change location of where clause on GATs

Closes rust-lang#89122

~Blocked on lang FCP~

r? `@nikomatsakis`
bors added a commit to rust-lang-ci/rust that referenced this issue Mar 6, 2022
Change location of where clause on GATs

Closes rust-lang#89122

~Blocked on lang FCP~

r? `@nikomatsakis`
@bors bors closed this as completed in ad0d1d7 Mar 6, 2022
MingweiSamuel added a commit to MingweiSamuel/hydroflow that referenced this issue Mar 7, 2022
cuishuang added a commit to cuishuang/rust that referenced this issue Mar 9, 2022
rustdoc: Stop textually replacing `Self` in doc links before resolving them

Resolve it directly to a type / def-id instead.

Also never pass `Self` to `Resolver`, it is useless because it's guaranteed that no resolution will be found.

rustdoc: Clean up `fn resolve_self_ty`

Do not display ~const in rustdoc

Do not display hidden `~const Drop` bounds

Bless rustdoc test

Add ui test

Address review comments

fs: Don't dereference a pointer to a too-small allocation

ptr::addr_of!((*ptr).field) still requires ptr to point to an
appropriate allocation for its type.  Since the pointer returned by
readdir() can be smaller than sizeof(struct dirent), we need to entirely
avoid dereferencing it as that type.

Link: rust-lang/miri#1981 (comment)
Link: rust-lang#93459 (comment)

Only count mutations with projections as borrows

Because bindings also count as a mutation, the previous behavior counted
all variables as borrowed, completely negating the effect of drop
tracking.

Enable drop-tracking tests behind -Zdrop-tracking

These were still disabled from the soft revert of drop tracking, which
meant we were not catching regressions that were introduced while trying
to fix drop tracking.

Fix formatting

add address sanitizer fo android

fix some typos

Signed-off-by: cuishuang <imcusg@gmail.com>

fix some typos

Signed-off-by: cuishuang <imcusg@gmail.com>

Merge branch 'master' of github.com:cuishuang/rust

remove_dir_all(): try recursing first instead of trying to unlink()

This only affects the `slow` code path, if there is no `dirent.d_type` or if
the type is `DT_UNKNOWN`.

POSIX specifies that calling `unlink()` or `unlinkat(..., 0)` on a directory can
succeed:
> "The _path_ argument shall not name a directory unless the process has
> appropriate privileges and the implementation supports using _unlink()_ on
> directories."
This however can cause orphaned directories requiring an fsck e.g. on Illumos
UFS, so we have to avoid that in the common case. We now just try to recurse
into it first and unlink() if we can't open it as a directory.

Integrate macos x86-64 remove_dir_all() impl. Step 1: remove

Integrate macos x86-64 remove_dir_all() impl. Step 2: readd

Inline SmallCStr::deref

Add SmallStr

Use SmallStr when building target-features LLVM attribute

Always include global target features in function attributes

This ensures that information about target features configured with
`-C target-feature=...` or detected with `-C target-cpu=native` is
retained for subsequent consumers of LLVM bitcode.

This is crucial for linker plugin LTO, since this information is not
conveyed to the plugin otherwise.

Update `itertools`

Update to 0.10.1

Support RelWithDebInfo for lld.

Distinguish binding assignments, use Ty::needs_drop

This better captures the actual behavior, rather than using hacks around
whether the assignment has any projections.

Edit docs on consistency of `PartialOrd` and `PartialEq`

Use ordered list to make the information about implementations more readable.

Downgrade `#[test]` on macro call to warning

Follow up to rust-lang#92959. Address rust-lang#94508.

Add known-bug directive to issue rust-lang#47511 test case

Fix typo in c-variadic
Do not point at whole file missing `fn main`

Only point at the end of the crate. We could try making it point at the
beginning of the crate, but that is confused with `DUMMY_SP`, causing
the output to be *worse*.

This change will make it so that VSCode will *not* underline the whole
file when `main` is missing, so other errors will be visible.

Auto merge of rust-lang#93142 - estebank:missing-main, r=wesleywiser

Do not point at whole file missing `fn main`

Only point at the end of the crate. We could try making it point at the
beginning of the crate, but that is confused with `DUMMY_SP`, causing
the output to be *worse*.

This change will make it so that VSCode will *not* underline the whole
file when `main` is missing, so other errors will be visible.

Clean up the std library's #![feature]s

Signed-off-by: JmPotato <ghzpotato@gmail.com>

Rollup merge of rust-lang#94446 - rusticstuff:remove_dir_all-illumos-fix, r=cuviper

UNIX `remove_dir_all()`: Try recursing first on the slow path

This only affects the _slow_ code path - if there is no `dirent.d_type` or if it is `DT_UNKNOWN`.

POSIX specifies that calling `unlink()` or `unlinkat(..., 0)` on a directory is allowed to succeed:
> The _path_ argument shall not name a directory unless the process has appropriate privileges and the implementation supports using _unlink()_ on directories.

This however can cause dangling inodes requiring an fsck e.g. on Illumos UFS, so we have to avoid that in the common case. We now just try to recurse into it first and unlink() if we can't open it as a directory.

The other two commits integrate the Macos x86-64 implementation reducing redundancy. Split into two commits for better reviewing.

Fixes rust-lang#94335.

Rollup merge of rust-lang#94460 - eholk:reenable-drop-tracking-tests, r=tmiasko

Reenable generator drop tracking tests and fix mutation handling

The previous PR, rust-lang#94068, was overly zealous in counting mutations as borrows, which effectively nullified drop tracking. We would have caught this except the drop tracking tests were still ignored, despite having the option of using the `-Zdrop-tracking` flag now.

This PR fixes the issue introduced by rust-lang#94068 by only counting mutations as borrows the mutated place has a project. This is sufficient to distinguish `x.y = 42` (which should count as a borrow of `x`) from `x = 42` (which is not a borrow of `x` because the whole variable is overwritten).

This PR also re-enables the drop tracking regression tests using the `-Zdrop-tracking` flag so we will avoid introducing these sorts of issues in the future.

Thanks to ``@tmiasko`` for noticing this problem and pointing it out!

r? ``@tmiasko``

Rollup merge of rust-lang#94620 - pierwill:partialord-constistency, r=yaahc

Edit docs on consistency of `PartialOrd` and `PartialEq`

Use ordered list to make the information about implementations more readable.

Rollup merge of rust-lang#94624 - estebank:regression-94508, r=Dylan-DPC

Downgrade `#[test]` on macro call to warning

Follow up to rust-lang#92959. Address rust-lang#94508.

Rollup merge of rust-lang#94626 - marmeladema:issue-47511-known-bug, r=jackh726

Add known-bug directive to issue rust-lang#47511 test case

Rollup merge of rust-lang#94631 - nebulatgs:patch-1, r=Dylan-DPC

Fix typo in c-variadic

Fixes a typo in the Unstable Book

fix some typos

Signed-off-by: cuishuang <imcusg@gmail.com>

Merge branch 'master' of github.com:cuishuang/rust

check extra args even if the function is not c_variadic

Auto merge of rust-lang#94634 - Dylan-DPC:rollup-8wx1yrj, r=Dylan-DPC

Rollup of 6 pull requests

Successful merges:

 - rust-lang#94446 (UNIX `remove_dir_all()`: Try recursing first on the slow path)
 - rust-lang#94460 (Reenable generator drop tracking tests and fix mutation handling)
 - rust-lang#94620 (Edit docs on consistency of `PartialOrd` and `PartialEq`)
 - rust-lang#94624 (Downgrade `#[test]` on macro call to warning)
 - rust-lang#94626 (Add known-bug directive to issue rust-lang#47511 test case)
 - rust-lang#94631 (Fix typo in c-variadic)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup

Auto merge of rust-lang#94546 - JmPotato:std-features-cleanup, r=m-ou-se

Clean up the std library's #![feature]s

Signed-off-by: JmPotato <ghzpotato@gmail.com>

This is part of rust-lang#87766.

r? `@m-ou-se`

Implement RFC 3184 - thread local cell methods.

Rename LocalKey's with_{ref,mut} to with_borrow{,_mut}.

Add tracking issue number for local_key_cell_methods.

Add debug asserts in thread local cell set methods.

Update documentation in thread/local.rs.

Small fixes in thread local code.

Update tests.

Improve unexpected_cfgs lint when their is no value expected

Auto merge of rust-lang#94561 - Urgau:check-cfg-lint-help-remove, r=petrochenkov

Improve unexpected_cfgs lint when their is no value expected

This pull-request improve the `unexpected_cfgs` when their is no value expected by suggesting to remove the value.

I also took the liberty to special case it for `feature` as it seems wrong to suggest to remove the value when the problem is most probably the absence of value(s) and also the fact that it doesn't make sense to only have `feature` without a value.

r? `@petrochenkov`

Remove build_helper

The majority of the code is only used by either rustbuild or
rustc_llvm's build script. Rust_build is compiled once for rustbuild and
once for every stage. This means that the majority of the code in this
crate is needlessly compiled multiple times. By moving only the code
actually used by the respective crates to rustbuild and rustc_llvm's
build script, this needless duplicate compilation is avoided.

Merge build_helper into util

Scroll when the anchor change and is linking outside of the displayed content

Auto merge of rust-lang#94480 - bjorn3:no_build_helper, r=Mark-Simulacrum

Remove build_helper

The majority of the code is only used by either rustbuild or
rustc_llvm's build script. Rust_build is compiled once for rustbuild and
once for every stage. This means that the majority of the code in this
crate is needlessly compiled multiple times. By moving only the code
actually used by the respective crates to rustbuild and rustc_llvm's
build script, this needless duplicate compilation is avoided.

Add GUI test for source code viewer scroll handling

Update note about tier 2 docs.

do not attempt to open cgroup files under Miri

suggest removing a semicolon after derive attributes

use current token span

Auto merge of rust-lang#92123 - m-ou-se:thread-local-cell-methods, r=joshtriplett

Implement RFC 3184 - thread local cell methods

This implements [RFC 3184](rust-lang/rfcs#3184), with `@danielhenrymantilla's` [suggestion](rust-lang/rfcs#3184 (comment)) for the `with_` method names.

Tracking issue: rust-lang#92122

Rollup merge of rust-lang#94630 - ehuss:remove-tier-2-docs-note, r=Mark-Simulacrum

Update note about tier 2 docs.

As of rust-lang#92800, docs are now available for tier-2 platforms.

Rollup merge of rust-lang#94633 - TaKO8Ki:suggest-removing-semicolon-after-derive-attribute, r=cjgillot

Suggest removing a semicolon after derive attributes

closes rust-lang#93942

Rollup merge of rust-lang#94642 - GuillaumeGomez:source-code-scroll, r=Urgau

Fix source code pages scroll

To reproduce the bug, go to https://doc.rust-lang.org/nightly/nightly-rustc/src/rustc_ast/ast.rs.html#537-541 and click on the `Path` link. The page won't scroll to the content.

r? `@Urgau`

Rollup merge of rust-lang#94645 - RalfJung:available-parallelism-miri, r=the8472

do not attempt to open cgroup files under Miri

Since rust-lang#92697, `cargo miri test` always fails under default flags, and one would have to use `MIRIFLAGS=-Zmiri-disable-isolation cargo miri test` instead. This PR fixes that problem.

Cc `@the8472` `@joshtriplett`

Unix `path::absolute`: Fix leading "." component

Testing leading `.` and `..` components were missing from the unix tests.

Use `as_os_str` to compare exact paths

Change syntax for TyAlias where clauses

Change to lint

Fallback to other where clause if preferred is missing

Review changes

Update new tests

Add commment covering the case with no where clause

Auto merge of rust-lang#94648 - RalfJung:rollup-4iorcrd, r=RalfJung

Rollup of 4 pull requests

Successful merges:

 - rust-lang#94630 (Update note about tier 2 docs.)
 - rust-lang#94633 (Suggest removing a semicolon after derive attributes)
 - rust-lang#94642 (Fix source code pages scroll)
 - rust-lang#94645 (do not attempt to open cgroup files under Miri)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup

Auto merge of rust-lang#94601 - csmoe:android-asan, r=nagisa

add address sanitizer fo android

We have been being using asan to debug the rust/cpp/c mixed android application in production for months: recompile the rust library with a patched rustc, everything just works fine. The patch is really small thanks to `@nagisa` 's refactoring in rust-lang#81866

r? `@nagisa`

doc: `Iterator::partition` use partial type hints

Auto merge of rust-lang#93805 - petrochenkov:doclinkself, r=camelid,GuillaumeGomez

rustdoc: Stop textually replacing `Self` in doc links before resolving them

Resolve it directly to a type / def-id instead.

Also never pass `Self` to `Resolver`, it is useless because it's guaranteed that no resolution will be found.

This is a pre-requisite for rust-lang#83761.

Ignore

update Miri

Auto merge of rust-lang#94658 - RalfJung:miri, r=RalfJung

update Miri

Fixes rust-lang#94562
r? `@ghost`

Auto merge of rust-lang#90076 - jackh726:wherethewhere, r=nikomatsakis

Change location of where clause on GATs

Closes rust-lang#89122

~Blocked on lang FCP~

r? `@nikomatsakis`

Rollup merge of rust-lang#92509 - Gentoli:partition-ex, r=camelid

doc: `Iterator::partition` use partial type hints

Switch to partial type hints to indicate only the collection type is needed.

Rollup merge of rust-lang#94621 - ridwanabdillahi:lld-rel-dbg, r=Mark-Simulacrum

rustbuild: support RelWithDebInfo for lld

r? ``@alexcrichton``

LLVM has flags that control the level of debuginfo generated when building via rustbuild. Since LLD is built separately, it currently has no way of generating any debuginfo. This change re-uses the same flags as LLVM for LLD to ensure it has the same level of debuginfo generated as LLVM.

Rollup merge of rust-lang#94649 - ChrisDenton:unix-absolute-fix, r=Dylan-DPC

Unix path::absolute: Fix leading "." component

Testing leading `.` and `..` components were missing from the unix tests.

This PR adds them and fixes the leading `.` case. It also fixes the test cases so that they do an exact comparison.

This problem reported by ``@axetroy``

Update -Z unpretty error message

Adds `thir-tree`, removes `everybody_loops`

Auto merge of rust-lang#94668 - fee1-dead:rollup-8e92bht, r=fee1-dead

Rollup of 3 pull requests

Successful merges:

 - rust-lang#92509 (doc: `Iterator::partition` use partial type hints)
 - rust-lang#94621 (rustbuild: support RelWithDebInfo for lld)
 - rust-lang#94649 (Unix path::absolute: Fix leading "." component)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup

fix pin doc typo

Improved error message for failed bitcode load

"bc" is an unnecessary shorthand that obfuscates the compilation error
Rollup merge of rust-lang#93412 - fee1-dead:improve-rustdoc-const-bounds, r=GuillaumeGomez

Improve rustdoc const bounds

 - Rustdoc no longer displays `~const` in trait bounds, because it currently means nothing for stable users, and because we still haven't decided on the final syntax yet.
 - Rustdoc will hide trait bounds where the trait is `Drop` AND it is `~const`, i.e. `~const Drop` bounds because it has no effect on stable users as well.
 - Because of additional logic that hides the whole `where` statement where it consists of `~const Drop` bounds (so it doesn't display `struct Foo<T>() where ;` like that), bounds that have no trait e.g. `where [T; N+1]: ;` are also hidden.

Cherry-picked from rust-lang#92433.

Rollup merge of rust-lang#94617 - pierwill:update-itertools, r=Mark-Simulacrum

Update `itertools`

Update to 0.10.1

Rollup merge of rust-lang#94669 - Alexendoo:unpretty-help, r=tmiasko

Update -Z unpretty error message

Adds `thir-tree`, removes `everybody_loops` (removed in rust-lang#93913)

Updated corresponding stderr
Auto merge of rust-lang#94673 - matthiaskrgr:rollup-2tnifg9, r=matthiaskrgr

Rollup of 3 pull requests

Successful merges:

 - rust-lang#93412 (Improve rustdoc const bounds)
 - rust-lang#94617 (Update `itertools`)
 - rust-lang#94669 (Update -Z unpretty error message)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup

explain why shift with signed offset works the way it does

remove unnecessary `..` patterns

cleanup: remove unused ability to have LLVM null-terminate const strings

Auto merge of rust-lang#94579 - tmiasko:target-features, r=nagisa

Always include global target features in function attributes

This ensures that information about target features configured with
`-C target-feature=...` or detected with `-C target-cpu=native` is
retained for subsequent consumers of LLVM bitcode.

This is crucial for linker plugin LTO, since this information is not
conveyed to the plugin otherwise.

<details><summary>Additional test case demonstrating the issue</summary>

```rust
extern crate core;

unsafe fn f(a: u128, b: u128) -> u128 {
    use core::arch::x86_64::*;
    use core::mem::transmute;
    transmute(_mm_aesenc_si128(transmute(a), transmute(b)))
}

pub fn g(a: u128, b: u128) -> u128 {
    unsafe { f(a, b) }
}

fn main() {
    let mut args = std::env::args();
    let _ = args.next().unwrap();
    let a: u128 = args.next().unwrap().parse().unwrap();
    let b: u128 = args.next().unwrap().parse().unwrap();
    println!("{}", g(a, b));
}
```

```console
$ rustc --edition=2021 a.rs -Clinker-plugin-lto -Clink-arg=-fuse-ld=lld  -Ctarget-feature=+aes -O
...
  = note: LLVM ERROR: Cannot select: intrinsic %llvm.x86.aesni.aesenc
```

</details>

r? `@nagisa`

Rollup merge of rust-lang#94659 - RalfJung:signed-shift, r=oli-obk

explain why shift with signed offset works the way it does

I was worried for a bit here that Miri/CTFE would be inconsistent with codegen, but I *think* everything is all right, actually.

Cc `@oli-obk` `@eddyb`

Rollup merge of rust-lang#94671 - csmoe:pin-typo, r=m-ou-se

fix pin doc typo

r? `@m-ou-se`

Rollup merge of rust-lang#94672 - joedeandev:master, r=Dylan-DPC

Improved error message for failed bitcode load

"bc" is an unnecessary shorthand that obfuscates the compilation error

CTFE engine: expose misc_cast to Miri

Auto merge of rust-lang#94679 - matthiaskrgr:rollup-9vd7w6a, r=matthiaskrgr

Rollup of 3 pull requests

Successful merges:

 - rust-lang#94659 (explain why shift with signed offset works the way it does)
 - rust-lang#94671 (fix pin doc typo)
 - rust-lang#94672 (Improved error message for failed bitcode load)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup

Introduce `ConstAllocation`.

Currently some `Allocation`s are interned, some are not, and it's very
hard to tell at a use point which is which.

This commit introduces `ConstAllocation` for the known-interned ones,
which makes the division much clearer. `ConstAllocation::inner()` is
used to get the underlying `Allocation`.

In some places it's natural to use an `Allocation`, in some it's natural
to use a `ConstAllocation`, and in some places there's no clear choice.
I've tried to make things look as nice as possible, while generally
favouring `ConstAllocation`, which is the type that embodies more
information. This does require quite a few calls to `inner()`.

The commit also tweaks how `PartialOrd` works for `Interned`. The
previous code was too clever by half, building on `T: Ord` to make the
code shorter. That caused problems with deriving `PartialOrd` and `Ord`
for `ConstAllocation`, so I changed it to build on `T: PartialOrd`,
which is slightly more verbose but much more standard and avoided the
problems.

Auto merge of rust-lang#94597 - nnethercote:ConstAllocation, r=fee1-dead

Introduce `ConstAllocation`.

Currently some `Allocation`s are interned, some are not, and it's very
hard to tell at a use point which is which.

This commit introduces `ConstAllocation` for the known-interned ones,
which makes the division much clearer. `ConstAllocation::inner()` is
used to get the underlying `Allocation`.

In some places it's natural to use an `Allocation`, in some it's natural
to use a `ConstAllocation`, and in some places there's no clear choice.
I've tried to make things look as nice as possible, while generally
favouring `ConstAllocation`, which is the type that embodies more
information. This does require quite a few calls to `inner()`.

The commit also tweaks how `PartialOrd` works for `Interned`. The
previous code was too clever by half, building on `T: Ord` to make the
code shorter. That caused problems with deriving `PartialOrd` and `Ord`
for `ConstAllocation`, so I changed it to build on `T: PartialOrd`,
which is slightly more verbose but much more standard and avoided the
problems.

r? `@fee1-dead`

Fix rustdoc for GATs with with anonymous bound regions

Auto merge of rust-lang#94638 - erikdesjardins:noextranull, r=nagisa

cleanup: remove unused ability to have LLVM null-terminate const strings

(and the copied function in rustc_codegen_gcc)

Noticed this while writing rust-lang#94450 (comment).

r? `@nagisa`

Auto merge of rust-lang#94272 - tavianator:readdir-reclen-for-real, r=cuviper

fs: Don't dereference a pointer to a too-small allocation

ptr::addr_of!((*ptr).field) still requires ptr to point to an
appropriate allocation for its type.  Since the pointer returned by
readdir() can be smaller than sizeof(struct dirent), we need to entirely
avoid dereferencing it as that type.

Link: rust-lang/miri#1981 (comment)
Link: rust-lang#93459 (comment)

Rollup merge of rust-lang#94636 - compiler-errors:issue-94599, r=davidtwco

Check extra function arg exprs even if the fn is not C-variadic

We should still call check_expr on the args that exceed the formal input ty count, so that we have expr types to emit during writeback.

Not sure where this regressed, but it wasn't due to the same root cause as rust-lang#94334 I think. I thought this might've regressed in rust-lang#92360, but I think that is in stable, ad the test I provided (which minimizes rust-lang#94599) passes on stable in playground. Maybe it regressed in rust-lang#93118.

Anywho, fixes rust-lang#94599.

Rollup merge of rust-lang#94676 - TaKO8Ki:remove-unnecessary-pattens-for-ignoring-remaining-parts, r=Dylan-DPC

Remove unnecessary `..` patterns

This patch removes unnecessary `..` patterns.

Rollup merge of rust-lang#94681 - RalfJung:miri-cast, r=oli-obk

CTFE engine: expose misc_cast to Miri

We need that to implement `simd_cast`/`simd_as` in Miri.

While at it, also change other code outside `cast.rs` to use `misc_cast` instead of lower-level methods.

r? `@oli-obk`

Rollup merge of rust-lang#94684 - compiler-errors:gat-anon-late-bound, r=notriddle

Fix rustdoc for GATs with with anonymous bound regions

Just use the logic that already worked for cleaning trait refs.

Fixes rust-lang#94683

Auto merge of rust-lang#94692 - matthiaskrgr:rollup-64p7ya7, r=matthiaskrgr

Rollup of 4 pull requests

Successful merges:

 - rust-lang#94636 (Check extra function arg exprs even if the fn is not C-variadic)
 - rust-lang#94676 (Remove unnecessary `..` patterns)
 - rust-lang#94681 (CTFE engine: expose misc_cast to Miri)
 - rust-lang#94684 (Fix rustdoc for GATs with with anonymous bound regions)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup

all: fix some typos

Signed-off-by: cuishuang <imcusg@gmail.com>
knutwalker added a commit to s1ck/graph that referenced this issue Mar 9, 2022
See rust-lang/rust#89122 for details

Co-Authored-By: Martin Junghanns <nerdfaktor42@mailbox.org>
knutwalker added a commit to s1ck/graph that referenced this issue Mar 9, 2022
See rust-lang/rust#89122 for details

Co-Authored-By: Martin Junghanns <nerdfaktor42@mailbox.org>
Dirbaio added a commit to embassy-rs/embedded-hal that referenced this issue Mar 10, 2022
Latest nightly changed the location of the `where` clause on impls with GATs:
rust-lang/rust#89122
yvt added a commit to r3-os/r3 that referenced this issue Mar 10, 2022
Addresses the `deprecated_where_clause_location` compiler lint.

This syntax change was introduced by [rust-lang/rust#89122][1].

[1]: rust-lang/rust#89122
bors bot added a commit to rust-embedded/embedded-hal that referenced this issue Mar 10, 2022
371: async: update to new location of where clause. r=eldruin a=Dirbaio

Latest nightly changed the location of the `where` clause on impls with GATs:
rust-lang/rust#89122

Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
Dirbaio added a commit to Dirbaio/rust-analyzer that referenced this issue Mar 10, 2022
A recent Rust nightly changed it: rust-lang/rust#89122

This allows both the old and new location.
Dirbaio added a commit to Dirbaio/rust-analyzer that referenced this issue Mar 10, 2022
A recent Rust nightly changed it: rust-lang/rust#89122

This allows both the old and new location.
bors bot added a commit to rust-lang/rust-analyzer that referenced this issue Mar 10, 2022
11672: Add support for new `where` clause location in associated types. r=Veykril a=Dirbaio

A recent Rust nightly changed it: rust-lang/rust#89122

This allows both the old and new location.

Fixes #11651

Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
bors bot added a commit to embassy-rs/embassy that referenced this issue Mar 10, 2022
627: Update Rust nightly, embedded-hal 1.0, embedded-hal-async. r=Dirbaio a=Dirbaio

Includes the SpiDevice/SpiBus split.  rust-embedded/embedded-hal#351
Includes the GAT where clause location change. rust-lang/rust#89122


Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
bors bot added a commit to embassy-rs/embassy that referenced this issue Mar 10, 2022
627: Update Rust nightly, embedded-hal 1.0, embedded-hal-async. r=Dirbaio a=Dirbaio

Includes the SpiDevice/SpiBus split.  rust-embedded/embedded-hal#351
Includes the GAT where clause location change. rust-lang/rust#89122


Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
MingweiSamuel added a commit to MingweiSamuel/hydroflow that referenced this issue Mar 11, 2022
MingweiSamuel added a commit to hydro-project/hydroflow that referenced this issue Mar 11, 2022
steven-joruk pushed a commit to steven-joruk/rust-analyzer that referenced this issue Mar 11, 2022
A recent Rust nightly changed it: rust-lang/rust#89122

This allows both the old and new location.
pnevyk added a commit to pnevyk/gryf that referenced this issue Apr 23, 2022
* Add Self: 'a bounds where newly necessary
  (rust-lang/rust#87479)
* Move the where clauses to follow established format
  (rust-lang/rust#89122)
* Changing bounds V: 'a, E: 'a and G: 'a into Self: 'a was not
  necessary, but it unifies the traits definition and their
  implementation and thus is more consistent.
@swfsql
Copy link

swfsql commented May 4, 2022

(removed my commend, I changed my mind)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
F-generic_associated_types GATs-blocking GATs-triaged T-lang
Projects
None yet
Development

Successfully merging a pull request may close this issue.