Warn about ignored generic bounds in `for` #48326

RalfJung · 2018-02-18T18:56:05Z

This adds a new lint to fix #42181. For consistency and to avoid code duplication, I also moved the existing "bounds in type aliases are ignored" here.

Questions to the reviewer:

Is it okay to just remove a diagnostic error code like this? Should I instead keep the warning about type aliases where it is? The old code provided a detailed explanation of what's going on when asked, that information is now lost. On the other hand, span_warn! seems deprecated (after this patch, it has exactly one user left!).
Did I miss any syntactic construct that can appear as for in the surface syntax? I covered function types (for<'a> fn(...)), generic traits (for <'a> Fn(...), can appear both as bounds as as trait objects) and bounds (for<'a> F: ...).
For the sake of backwards compatibility, this adds a warning, not an error. @nikomatsakis suggested an error in Bounds in HRTB are ignored #42181 (comment), but I feel that can only happen in a new epoch -- right?

Cc @eddyb

rust-highfive · 2018-02-18T18:56:09Z

r? @petrochenkov

(rust_highfive has picked a reviewer for you, use r? to override)

petrochenkov · 2018-02-19T21:57:41Z

Is it okay to just remove a diagnostic error code like this?

It's okay. src/librustc_typeck/diagnostics.rs contains a list of commented out error codes at the very end of the file. E0122 can be added to that list as well with a short note on why it was removed.

On the other hand, span_warn! seems deprecated

Yes, hardcoded warnings should be avoided whenever possible (I don't think we should remove the mechanism itself though).

Did I miss any syntactic construct that can appear as for in the surface syntax?

Everything looks covered.

For the sake of backwards compatibility, this adds a warning, not an error. @nikomatsakis suggested an error in #42181 (comment), but I feel that can only happen in a new epoch -- right?

Crater can answer this! cc @aidanhs

petrochenkov · 2018-02-19T22:00:27Z

src/test/ui/param-bounds-ignored.rs

@@ -9,12 +9,14 @@
 // except according to those terms.

 // must-compile-successfully
+#![allow(dead_code, non_camel_case_types)]


Could you warn(ignored_generic_bounds) and add //~ WARN ... annotations to the file?
It's very hard to see what is tested, what should be reported, and what shouldn't be reported based on stderr file alone.

Ah, I didn't even know //~ WARN was a thing in ui tests. How do the two interact?

petrochenkov · 2018-02-19T22:01:48Z

src/test/ui/param-bounds-ignored.stderr

+  --> $DIR/param-bounds-ignored.rs:39:8
+   |
+39 |     f: for<'xa, 'xb: 'xa> fn(&'xa i32, &'xb i32) -> &'xa i32)
+   |        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


Spans could be more precise, AST has spans for generics and for the ignored bounds themselves.

I'm now changing this so the span points at the first ignored bound. Is there a way to "combine" spans? I found no span for all the bounds together, just the generic (which is the wrong place) and individual bounds.

petrochenkov · 2018-02-19T22:03:07Z

Crater can answer this!

The warning should be forbid-by-default for cratering though.

RalfJung · 2018-02-20T09:53:26Z

The warning should be forbid-by-default for cratering though.

So are you saying I should change this PR to make the warning err-by-default?

RalfJung · 2018-02-20T13:44:04Z

Turns out that even some of the compile-fail tests have these bounds in for. I'd be very surprised if crater wouldn't find tons of cases^^

RalfJung · 2018-02-20T13:53:20Z

E0122 can be added to that list as well with a short note on why it was removed.

Done.

RalfJung · 2018-02-20T13:54:16Z

There's a strange failure in compile-fail/enum-discrim-too-small2.rs: the compiler panics with the following backtrace:

thread 'rustc' panicked at 'Box<Any>', librustc_errors/lib.rs:535:9
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:206
   3: std::panicking::default_hook
             at libstd/panicking.rs:222
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:400
   5: std::panicking::begin_panic
             at ./src/libstd/panicking.rs:363
   6: rustc_errors::Handler::bug
             at librustc_errors/lib.rs:535
   7: <std::thread::local::LocalKey<T>>::with
             at librustc/session/mod.rs:1179
             at librustc/ty/context.rs:1600
             at librustc/ty/context.rs:1589
             at ./src/libstd/thread/local.rs:377
             at ./src/libstd/thread/local.rs:288
   8: rustc::ty::context::tls::with_opt
             at librustc/ty/context.rs:1585
             at librustc/ty/context.rs:1600
   9: rustc::session::opt_span_bug_fmt
             at librustc/session/mod.rs:1175
  10: rustc::session::bug_fmt
             at librustc/session/mod.rs:1159
  11: <rustc::ty::layout::LayoutCx<'tcx, rustc::ty::context::TyCtxt<'a, 'tcx, 'tcx>>>::layout_raw_uncached
             at librustc/ty/layout.rs:553
             at librustc/ty/layout.rs:1545
  12: rustc::ty::layout::layout_raw
             at librustc/ty/layout.rs:899
  13: rustc::ty::maps::<impl rustc::ty::maps::queries::layout_raw<'tcx>>::compute_result
             at librustc/ty/maps/plumbing.rs:396
  14: rustc::dep_graph::graph::DepGraph::with_task_impl
             at librustc/dep_graph/graph.rs:289
  15: rustc_errors::Handler::track_diagnostics
             at librustc/dep_graph/graph.rs:199
             at librustc/ty/maps/plumbing.rs:505
             at ./src/librustc_errors/lib.rs:598
  16: rustc::ty::maps::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::cycle_check
             at librustc/ty/maps/plumbing.rs:498
             at librustc/ty/maps/plumbing.rs:121
  17: rustc::ty::maps::<impl rustc::ty::maps::queries::layout_raw<'tcx>>::force
             at librustc/ty/maps/plumbing.rs:497
  18: rustc::ty::maps::<impl rustc::ty::maps::queries::layout_raw<'tcx>>::try_get
             at librustc/ty/maps/plumbing.rs:314
             at librustc/ty/maps/plumbing.rs:539
  19: rustc::ty::maps::TyCtxtAt::layout_raw
             at librustc/ty/maps/plumbing.rs:578
  20: <rustc::ty::layout::LayoutCx<'tcx, rustc::ty::context::TyCtxt<'a, 'tcx, 'tcx>> as rustc::ty::layout::LayoutOf<&'tcx rustc::ty::TyS<'tcx>>>::layout_of
             at librustc/ty/maps/plumbing.rs:571
             at librustc/ty/layout.rs:2052
  21: <&'a rustc::lint::context::LateContext<'a, 'tcx> as rustc::ty::layout::LayoutOf<&'tcx rustc::ty::TyS<'tcx>>>::layout_of
             at librustc/ty/layout.rs:2111
             at librustc/lint/context.rs:634
  22: <rustc_lint::types::VariantSizeDifferences as rustc::lint::LateLintPass<'a, 'tcx>>::check_item
             at librustc_lint/types.rs:781
  23: <rustc::lint::context::LateContext<'a, 'tcx> as rustc::lint::context::LintContext<'tcx>>::with_lint_attrs
             at librustc/lint/context.rs:665
             at librustc/lint/context.rs:625
             at librustc/lint/context.rs:664
             at librustc/lint/context.rs:560
  24: <rustc::lint::context::LateContext<'a, 'tcx> as rustc::hir::intravisit::Visitor<'tcx>>::visit_mod
             at librustc/lint/context.rs:663
             at librustc/hir/intravisit.rs:183
             at librustc/hir/intravisit.rs:391
             at librustc/lint/context.rs:759
  25: rustc::hir::intravisit::walk_crate
             at librustc/hir/intravisit.rs:377
  26: <rustc::lint::context::LateContext<'a, 'tcx> as rustc::lint::context::LintContext<'tcx>>::with_lint_attrs
             at librustc/lint/context.rs:1040
             at librustc/lint/context.rs:560
  27: rustc::lint::context::check_crate
             at librustc/lint/context.rs:1035
  28: <std::thread::local::LocalKey<T>>::with
             at librustc_driver/driver.rs:1092
             at ./src/librustc/ty/context.rs:1573
             at ./src/libstd/thread/local.rs:377
             at ./src/libstd/thread/local.rs:288
  29: <std::thread::local::LocalKey<T>>::with
             at ./src/librustc/ty/context.rs:1570
             at ./src/librustc/ty/context.rs:1557
             at ./src/libstd/thread/local.rs:377
             at ./src/libstd/thread/local.rs:288
  30: rustc::ty::context::TyCtxt::create_and_enter
             at ./src/librustc/ty/context.rs:1554
             at ./src/librustc/ty/context.rs:1197
  31: rustc_driver::driver::phase_3_run_analysis_passes
             at librustc_driver/driver.rs:1007
  32: rustc_driver::driver::compile_input
             at librustc_driver/driver.rs:214
  33: rustc_driver::run_compiler
             at librustc_driver/lib.rs:506

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.25.0-dev running on x86_64-unknown-linux-gnu


------------------------------------------

thread '[compile-fail] compile-fail/enum-discrim-too-small2.rs' panicked at 'explicit panic', tools/compiletest/src/runtest.rs:2892:9
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:206
   3: std::panicking::default_hook
             at libstd/panicking.rs:216
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:400
   5: std::panicking::begin_panic
   6: compiletest::runtest::ProcRes::fatal
   7: compiletest::runtest::TestCx::fatal_proc_rec
   8: compiletest::runtest::TestCx::check_no_compiler_crash
   9: compiletest::runtest::TestCx::run_cfail_test
  10: compiletest::runtest::run
  11: <F as alloc::boxed::FnBox<A>>::call_box
  12: <F as alloc::boxed::FnBox<A>>::call_box
             at libtest/lib.rs:1456
             at ./src/liballoc/boxed.rs:788
  13: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:102


failures:
    [compile-fail] compile-fail/enum-discrim-too-small2.rs

test result: FAILED. 1 passed; 1 failed; 2317 ignored; 0 measured; 0 filtered out

thread 'main' panicked at 'Some tests failed', tools/compiletest/src/main.rs:476:22
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:206
   3: std::panicking::default_hook
             at libstd/panicking.rs:222
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:400
   5: std::panicking::begin_panic
   6: compiletest::main
   7: std::rt::lang_start::{{closure}}
   8: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:305
   9: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:102
  10: std::rt::lang_start_internal
             at libstd/panicking.rs:284
             at libstd/panic.rs:361
             at libstd/rt.rs:58
  11: main
  12: __libc_start_main
  13: _start


command did not execute successfully: "/home/r/src/rust/rustc/build/x86_64-unknown-linux-gnu/stage0-tools-bin/compiletest" "--compile-lib-path" "/home/r/src/rust/rustc/build/x86_64-unknown-linux-gnu/stage1/lib" "--run-lib-path" "/home/r/src/rust/rustc/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib" "--rustc-path" "/home/r/src/rust/rustc/build/x86_64-unknown-linux-gnu/stage1/bin/rustc" "--src-base" "/home/r/src/rust/rustc/src/test/compile-fail" "--build-base" "/home/r/src/rust/rustc/build/x86_64-unknown-linux-gnu/test/compile-fail" "--stage-id" "stage1-x86_64-unknown-linux-gnu" "--mode" "compile-fail" "--target" "x86_64-unknown-linux-gnu" "--host" "x86_64-unknown-linux-gnu" "--llvm-filecheck" "/home/r/src/rust/rustc/build/x86_64-unknown-linux-gnu/llvm/build/bin/FileCheck" "--nodejs" "/usr/bin/node" "--host-rustcflags" "-Crpath -O -Zmiri -Zunstable-options " "--target-rustcflags" "-Crpath -O -Zmiri -Zunstable-options  -Lnative=/home/r/src/rust/rustc/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--docck-python" "/usr/bin/python" "--lldb-python" "/usr/bin/python" "--gdb" "/usr/bin/gdb" "--llvm-version" "6.0.0\n" "--cc" "" "--cxx" "" "--cflags" "" "--llvm-components" "" "--llvm-cxxflags" "" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" "--android-cross-path" ""
expected success, got: exit code: 101

I have no idea how my changes could cause that.

RalfJung · 2018-02-20T13:59:04Z

The backtrace points at

                bug!("Integer::repr_discr: `#[repr]` hint too small for \
                  discriminant range of enum `{}", ty)

which I did not see because it's JSON-ified:

{"message":"librustc/ty/layout.rs:553: Integer::repr_discr: `#[repr]` hint too small for discriminant range of enum `Ei64","code":null,"level":"error: internal compiler error","spans":[],"children":[],"rendered":"error: internal compiler error: librustc/ty/layout.rs:553: Integer::repr_discr: `#[repr]` hint too small for discriminant range of enum `Ei64\n\n"}

Since this did not happen on Travis, I assume it's a stage-1-only failure. I'm currently building stage 2 to verify. (EDIT: confirmed stage-1-only failure.)

RalfJung · 2018-02-20T16:07:36Z

I'm now changing this so the span points at the first ignored bound. Is there a way to "combine" spans? I found no span for all the bounds together, just the generic (which is the wrong place) and individual bounds.

I guess alternatively I could make it warn about every single bound, but that feels excessive?

hanna-kruppe · 2018-02-20T16:10:17Z

You can pass a MultiSpan (or a Vec<Span>, there's a From impl) instead of a single span to the span_* methods.

RalfJung · 2018-02-20T16:12:37Z

src/test/compile-fail/issue-39122.rs


-type Bar<T> where T: std::ops::Add = T; //~ WARNING E0122
+type Bar<T> where T: std::ops::Add = T; //~ WARNING where clauses are ignored


This test is now a strict subset of the new ui/param-bounds-ignored. Should I remove it?

Yeah, the less code the better!

RalfJung · 2018-02-20T16:31:42Z

You can pass a MultiSpan (or a Vec, there's a From impl) instead of a single span to the span_* methods.

Wow, fancy. Done :)

RalfJung · 2018-02-21T09:05:40Z

The warning should be forbid-by-default for cratering though.

I made it Deny-by-default. (There are some existing Deny-by-default lint and no Forbid-by-default lint, so I figured I'd stay consistent with them.)

petrochenkov · 2018-02-21T10:24:11Z

src/test/compile-fail/issue-23046.rs

@@ -10,15 +10,15 @@

 pub enum Expr<'var, VAR> {
    Let(Box<Expr<'var, VAR>>,
-        Box<for<'v: 'var> Fn(Expr<'v, VAR>) -> Expr<'v, VAR> + 'var>)


Looks like the use of bounds was intentional here (#23046).

Need to check whether they are totally ignored during lowering to ty representation or just not enforced properly (and still may cause ICEs or something).

Okay I will bring the bound back. So far I haven't observed anything that would react to these bounds, and AFAIK @eddyb also said they are ignored.

Are you saying I should check the lowering code whether they are ignored? I'm not familiar with that code at all, not even sure where it lives, but I can certainly try.^^

petrochenkov · 2018-02-21T10:31:36Z

@RalfJung

I made it Deny-by-default. (There are some existing Deny-by-default lint and no Forbid-by-default lint, so I figured I'd stay consistent with them.)

For running crater on existing lints forbid-by-default allows to still catch cases where the lint was allowed, but this is a new lint, so there's no difference.

petrochenkov · 2018-02-21T10:32:48Z

Travis found some failing run-pass tests that need to be updated.

Everything else looks good to me, only crater run is remaining.
ping @aidanhs again

aidanhs · 2018-02-21T22:33:43Z

Crater needs to be fed with a try build so it'll need to get through travis, which is unfortunately probably not going to happen with test failures.

(also, please ping @rust-lang/infra for crater runs rather than me directly!)

Manishearth · 2018-03-08T19:25:11Z

@bors p=1

segfaulty, not including in rollup, should be tested on its own when there's a slot

kennytm · 2018-03-08T19:27:51Z

@Manishearth The segfault is likely introduced by the miri PR, not this, thus the retry. I agree this (+324, -108) PR shouldn't be rolled up though 😄.

bors · 2018-03-09T06:29:21Z

⌛ Testing commit 780b544 with merge 50f2d3d3b6c75b4be1f4f44f1cf7555d2f4dba05...

bors · 2018-03-09T07:44:12Z

💔 Test failed - status-travis

oli-obk · 2018-03-09T07:50:06Z

@bors retry segfault on dist x86_64-apple-darwin xcode 7.3

RalfJung · 2018-03-09T08:39:30Z

Sent a PR against the only crate this should break (according to crater): rustgd/rhusics#62

62: Remove lifetime bounds in higher-ranked lifetimes r=Rhuagh a=RalfJung Those bounds are ignored by the compiler, and will trigger an error once rust-lang/rust#48326 lands. According to crater, this is the only crate using these bounds. This patch should make the crate work on nightly again. However, I have been unable to compile the crate even with nightly 2018-02-25, which does not include the change mentioned above. So, I couldn't compile-test this PR.  --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/rustgd/rhusics/62)

bors · 2018-03-09T10:45:37Z

⌛ Testing commit 780b544 with merge fedce67...

@nikomatsakis

Warn about ignored generic bounds in `for` This adds a new lint to fix #42181. For consistency and to avoid code duplication, I also moved the existing "bounds in type aliases are ignored" here. Questions to the reviewer: * Is it okay to just remove a diagnostic error code like this? Should I instead keep the warning about type aliases where it is? The old code provided a detailed explanation of what's going on when asked, that information is now lost. On the other hand, `span_warn!` seems deprecated (after this patch, it has exactly one user left!). * Did I miss any syntactic construct that can appear as `for` in the surface syntax? I covered function types (`for<'a> fn(...)`), generic traits (`for <'a> Fn(...)`, can appear both as bounds as as trait objects) and bounds (`for<'a> F: ...`). * For the sake of backwards compatibility, this adds a warning, not an error. @nikomatsakis suggested an error in #42181 (comment), but I feel that can only happen in a new epoch -- right? Cc @eddyb

bors · 2018-03-09T13:23:26Z

☀️ Test successful - status-appveyor, status-travis
Approved by: petrochenkov
Pushing fedce67 to master...

…chenkov Improve lint for type alias bounds First of all, I learned just today that I was wrong assuming that the bounds in type aliases are entirely ignored: It turns out they are used to resolve associated types in type aliases. So: ```rust type T1<U: Bound> = U::Assoc; // compiles type T2<U> = U::Assoc; // fails type T3<U> = <U as Bound>::Assoc; // "correct" way to write this, maybe? ``` I am sorry for creating this mess. This PR changes the wording of the lint accordingly. Moreover, since just removing the bound is no longer always a possible fix, I tried to detect cases like `T1` above and show a helpful message to the user: ``` warning: bounds on generic parameters are not enforced in type aliases --> $DIR/type-alias-bounds.rs:57:12 | LL | type T1<U: Bound> = U::Assoc; //~ WARN not enforced in type aliases | ^^^^^ | = help: the bound will not be checked when the type alias is used, and should be removed help: use absolute paths (i.e., <T as Trait>::Assoc) to refer to associated types in type aliases --> $DIR/type-alias-bounds.rs:57:21 | LL | type T1<U: Bound> = U::Assoc; //~ WARN not enforced in type aliases | ^^^^^^^^ ``` I am not sure if I got this entirely right. Ideally, we could provide a suggestion involving the correct trait and type name -- however, while I have access to the HIR in the lint, I do not know how to get access to the resolved name information, like which trait `Assoc` belongs to above. The lint does not even run if that resolution fails, so I assume that information is available *somewhere*... This is a follow-up for (parts of) rust-lang#48326. Also see rust-lang#21903. This changes the name of a lint, but that lint was just merged to master yesterday and has never even been on beta.

Generic param order restriction was changed in rust-lang/rust#58191. Generic argument order restriction was changed in rust-lang/rust#70261. `for` lifetime argument restriction was changed in rust-lang/rust#48326. Generic parameter parsing: https://github.com/rust-lang/rust/blob/206ee1eea3467fd1d7f1efdbeafe27880897bb2c/compiler/rustc_parse/src/parser/generics.rs#L83-L153 Generic argument parsing: https://github.com/rust-lang/rust/blob/17eec1433c69972844dd228b5fe801f218e118c3/compiler/rustc_parse/src/parser/path.rs#L395-L413 `for` argument parsing: https://github.com/rust-lang/rust/blob/206ee1eea3467fd1d7f1efdbeafe27880897bb2c/compiler/rustc_parse/src/parser/ty.rs#L724-L736 Fixes rust-lang#785

rust-highfive assigned petrochenkov Feb 18, 2018

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 18, 2018

RalfJung force-pushed the generic-bounds branch from 42b8ad3 to 0c5bc12 Compare February 18, 2018 18:57

petrochenkov reviewed Feb 19, 2018

View reviewed changes

RalfJung force-pushed the generic-bounds branch from 8657731 to 9410a67 Compare February 20, 2018 15:42

RalfJung commented Feb 20, 2018

View reviewed changes

RalfJung force-pushed the generic-bounds branch from e26c863 to c2a8e23 Compare February 20, 2018 16:32

petrochenkov added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Feb 21, 2018

petrochenkov reviewed Feb 21, 2018

View reviewed changes

petrochenkov removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 21, 2018

bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 9, 2018

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 9, 2018

kennytm mentioned this pull request Mar 9, 2018

segfault during stage2 build of dist x86_64-apple-darwin xcode 7.3 #48866

Closed

RalfJung mentioned this pull request Mar 9, 2018

Remove lifetime bounds in higher-ranked lifetimes rustgd/rhusics#62

Merged

bors merged commit 780b544 into rust-lang:master Mar 9, 2018

This was referenced Mar 10, 2018

Trait bounds are not yet enforced in type definitions #21903

Open

Improve lint for type alias bounds #48909

Merged

pnkfelix mentioned this pull request Mar 21, 2018

Compiler panic: unexpected unsized tail: TyProjection(ProjectionTy { substs: Slice([chrono::Utc]), ... #48336

Closed

RalfJung mentioned this pull request Mar 28, 2018

Reject bounds in type aliases with edition 2024 #49441

Open

RalfJung mentioned this pull request May 9, 2018

Rejecting higher-kinded lifetime bounds is a breaking change #50555

Closed

RalfJung deleted the generic-bounds branch July 10, 2018 09:05

ehuss mentioned this pull request Jan 6, 2021

Update grammar for order of parameters/arguments. rust-lang/reference#920

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Warn about ignored generic bounds in `for` #48326

Warn about ignored generic bounds in `for` #48326

RalfJung commented Feb 18, 2018

rust-highfive commented Feb 18, 2018

petrochenkov commented Feb 19, 2018

petrochenkov Feb 19, 2018

RalfJung Feb 20, 2018

RalfJung Feb 20, 2018

petrochenkov Feb 19, 2018

RalfJung Feb 20, 2018

petrochenkov commented Feb 19, 2018

RalfJung commented Feb 20, 2018

RalfJung commented Feb 20, 2018

RalfJung commented Feb 20, 2018

RalfJung commented Feb 20, 2018

RalfJung commented Feb 20, 2018 •

edited

Loading

RalfJung commented Feb 20, 2018

hanna-kruppe commented Feb 20, 2018

RalfJung Feb 20, 2018

petrochenkov Feb 21, 2018

RalfJung commented Feb 20, 2018

RalfJung commented Feb 21, 2018

petrochenkov Feb 21, 2018

petrochenkov Feb 21, 2018

RalfJung Feb 22, 2018

petrochenkov commented Feb 21, 2018

petrochenkov commented Feb 21, 2018

aidanhs commented Feb 21, 2018

Manishearth commented Mar 8, 2018

kennytm commented Mar 8, 2018

bors commented Mar 9, 2018

bors commented Mar 9, 2018

oli-obk commented Mar 9, 2018

RalfJung commented Mar 9, 2018

bors commented Mar 9, 2018

bors commented Mar 9, 2018


		type Bar<T> where T: std::ops::Add = T; //~ WARNING E0122
		type Bar<T> where T: std::ops::Add = T; //~ WARNING where clauses are ignored

Warn about ignored generic bounds in for #48326

Warn about ignored generic bounds in for #48326

Conversation

RalfJung commented Feb 18, 2018

rust-highfive commented Feb 18, 2018

petrochenkov commented Feb 19, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

petrochenkov commented Feb 19, 2018

RalfJung commented Feb 20, 2018

RalfJung commented Feb 20, 2018

RalfJung commented Feb 20, 2018

RalfJung commented Feb 20, 2018

RalfJung commented Feb 20, 2018 • edited Loading

RalfJung commented Feb 20, 2018

hanna-kruppe commented Feb 20, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

RalfJung commented Feb 20, 2018

RalfJung commented Feb 21, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

petrochenkov commented Feb 21, 2018

petrochenkov commented Feb 21, 2018

aidanhs commented Feb 21, 2018

Manishearth commented Mar 8, 2018

kennytm commented Mar 8, 2018

bors commented Mar 9, 2018

bors commented Mar 9, 2018

oli-obk commented Mar 9, 2018

RalfJung commented Mar 9, 2018

bors commented Mar 9, 2018

bors commented Mar 9, 2018

Warn about ignored generic bounds in `for` #48326

Warn about ignored generic bounds in `for` #48326

RalfJung commented Feb 20, 2018 •

edited

Loading