profile
viewpoint
varkor varkor https://varkor.github.io/blog/ Type theorist and Rust compiler developer.

varkor/DISTORT 3

A small game demonstrating a grid distortion effect

varkor/Epilog 3

A toy Prolog compiler

ocrawford555/teamOscarSSE 2

Simulated Stock Exchange for Part IB Group Project

varkor/blog 1

A small blog about type theory and mathematics

varkor/chalk 1

A PROLOG-ish interpreter written in Rust, intended eventually for use in the compiler

varkor/acs-category-theory-notes-2017 0

Cambridge ACS Category Theory, Type Theory, and Logic - lecture notes 2017.

varkor/bitflags 0

A macro to generate structures which behave like bitflags

varkor/book 0

The Rust Programming Language

push eventvarkor/quiver

varkor

commit sha bede94308c15471ec7fe3208688a876cbcaf2484

Start to get the new arrows working

view details

push time in a day

push eventvarkor/quiver

varkor

commit sha 49dba237e84f6289d3d8c1b5b254d755d7437f6c

Fix direction of pullback corner

view details

push time in a day

pull request commentrust-lang/rust

New MIR optimization pass to reduce branches on match of tuples of enums

This looks great, but unfortunately I don't have time to review something of this size at the moment.

r? @eddyb

@bors try @rust-timer queue

simonvandel

comment created time in a day

push eventvarkor/quiver

varkor

commit sha 197b93da8218c8ed4d0c72de65b59d1e0b0bd30d

Redraw arrow parts more conservatively

view details

push time in 2 days

push eventvarkor/quiver

varkor

commit sha 255254471c53bd957bcefb3c259206e109dc4b71

Add toolbar button for toggling grid Previously this was possible by pressing "H", but this wasn't very discoverable.

view details

varkor

commit sha 5822143524a505b5b40d17a8707f4960ee01a03d

Start implementing curves from scratch

view details

varkor

commit sha 4d508acb2bbf68d09170e08f9e9791cbe2945bc1

Draw n-cells and arrow heads

view details

varkor

commit sha 3fccd516b8c1de20126c513ee90d4677cacd7b01

Special-case flat Bézier curves

view details

varkor

commit sha b934b3263483f6a4762cede351543b3a8da055ac

Resize SVG appropriately

view details

varkor

commit sha c452ab3c5c8ef2ede94b1dde546236428a39d55f

Make a start on different arrow styles

view details

varkor

commit sha c204d5eca3317a6bb463996216be54c446f670d3

Add explicit namespace to SVGs

view details

varkor

commit sha f8847c690d23b5e03f54649d4266de91210a02c2

Preliminary work on squiggly arrows

view details

varkor

commit sha 2cfa0e6d8ac1c48fcefc9356e9c877ca36c88463

Add a preliminary label

view details

varkor

commit sha 8ad85d2aa767efffa6a133e8648296e5139a78ee

Add background to curve

view details

varkor

commit sha d36d3c73db1e3a99e95c4a4ea8036c48d9c8b1f0

Use `DOM.SVGElement` in `arrow.html`

view details

varkor

commit sha ba88e0ac7cdb9cb26d1b8eb232d80d0a9273d0d9

Refactor arrow head drawing

view details

varkor

commit sha 8b9d4fb2a6bf63b4e03a9a2960124ffcf5bace19

Fix drawing of multiple epi heads

view details

varkor

commit sha e4d9ceb2d83c7921ad7a3397a7e777d66847d390

Combine epi and mono drawing

view details

varkor

commit sha fa38ed0d0a901cd094896b84d5dcd0eeb1895e17

Combine `maps to` and `arrowhead` with others

view details

varkor

commit sha ade68ef99b550da5c4908e4ead154225f8cc00f2

Allow multiple heterogeneous heads

view details

varkor

commit sha d9d3611592051ae931f9b263eb47418e03c16669

Add slider for curves

view details

varkor

commit sha 92e60344ed9a17ed2bb5171fd9baf3c7cf49c394

Add note

view details

varkor

commit sha 218c61fc7885aecbf249010a24c9bdd0bd160cd7

Fix intersections with labels

view details

varkor

commit sha 4af6949729ada05fd2747d9f63ddd424438580bf

Move those labels!

view details

push time in 2 days

push eventvarkor/quiver

varkor

commit sha c0b42e1af28bf1f731f4aaf2e130fb2758b65814

Rebuild GitHub Pages

view details

push time in 2 days

push eventvarkor/quiver

varkor

commit sha 260405dba218da3a98c376c89a150353d1cdaab7

Add toolbar button for toggling grid Previously this was possible by pressing "H", but this wasn't very discoverable.

view details

varkor

commit sha 0dc262e14ab5cbeb9714ec3ce84406c9b5fd2ebb

Build dependencies

view details

varkor

commit sha cef61006a63a8dc6f1a67bae9e443920183d0bfc

Add the dev branch

view details

push time in 2 days

push eventvarkor/quiver

varkor

commit sha 255254471c53bd957bcefb3c259206e109dc4b71

Add toolbar button for toggling grid Previously this was possible by pressing "H", but this wasn't very discoverable.

view details

push time in 2 days

push eventvarkor/quiver

varkor

commit sha c8e604436581313f304247ca3e2b21451bef231a

Remove logs

view details

push time in 2 days

push eventvarkor/quiver

varkor

commit sha 43708e28ebefdc35017f59b4dd6140b5a6f460a0

Add nonfunctional endpoint handles

view details

push time in 2 days

push eventvarkor/quiver

varkor

commit sha 249d9635f8a122e3d7dba1f3350837b0af27c375

Make some progress on rendering labels

view details

push time in 3 days

push eventvarkor/quiver

varkor

commit sha aecf8dba3e286c20eddb9b96439ee143fa5a4ace

Resolve some issues with hovering

view details

push time in 3 days

push eventvarkor/quiver

varkor

commit sha b6e88b71ea12df97d80b60c311c56081fc1f4a67

Fix precedence issue with shortening

view details

push time in 3 days

push eventvarkor/quiver

varkor

commit sha 19e802c819cfaa23a4744d90f569c94b899649b3

Fix issue with clipping masks

view details

push time in 3 days

push eventvarkor/quiver

varkor

commit sha f6995089a9cc754d0da2d40568fcc454ed899d15

Integrate arrow styles

view details

push time in 4 days

push eventvarkor/quiver

varkor

commit sha 8bb95a847e67a0c9b3574cb1d38dedbf52d09160

Make some progress

view details

push time in 4 days

push eventvarkor/quiver

varkor

commit sha a2b72f02ef7edf728d5333896ef4a58d7de83805

Preliminary integration

view details

push time in 4 days

push eventvarkor/quiver

varkor

commit sha b10ea359ae71b890830542e6fee93e764cb0d011

Add proarrow style

view details

push time in 4 days

push eventvarkor/quiver

varkor

commit sha 80295c4a31bba5eee5f5910b623de3da1fcde49a

Update to-do list

view details

push time in 4 days

push eventvarkor/quiver

varkor

commit sha 0be1a8a3b9336437ac23ce4f377a597c92ae3c32

Clip arrow by label mask

view details

push time in 4 days

issue commentvarkor/quiver

SVG export

SVG export for arrows should become possible with #5. However, since KaTeX doesn't SVG export yet (https://github.com/KaTeX/KaTeX/issues/375), to support text, another solution will be required (such as using MathJax only for SVG rendering).

varkor

comment created time in 4 days

issue openedvarkor/quiver

Loops

Loops are useful for endomorphisms, like identity morphisms.

#5 is a prerequisite for this feature.

created time in 4 days

push eventvarkor/quiver

varkor

commit sha 6e97400f873f4c759e194dae1fd1909604948e4b

Update the README

view details

push time in 4 days

push eventvarkor/quiver

varkor

commit sha d915715ebe41b4e62262e43f79bbebcd02a05ef0

Fix tikz-cd export bug

view details

varkor

commit sha bc4399bd227e673ab6222c94f8d3b6f51cab4f6e

Buffer column and row layout when loading

view details

varkor

commit sha ec0da99969fd1e0d77516fe242ba3f472b05dfdc

Fix bug with selecting label alignment when multiple edges were selected

view details

varkor

commit sha e35490891a6ab3276556910af0ae4f3dc6797c24

Add zooming This is especially useful on very large diagrams.

view details

varkor

commit sha 81f96a711ad6774fcc9bdf2d42fb4cdb9a860843

Stop buffering updates after loading a diagram

view details

varkor

commit sha 831abcf17dabe3c538cb42ba996f2ffb40d7e7c9

Output edges on their own lines in tikz-cd code This makes the output code slightly more readable.

view details

varkor

commit sha c2ef700b3a33153e7653f426beeeebfb6e545037

Fix an issue with 2-cells between offset edges not being visible

view details

varkor

commit sha 58a1da7ffcfd016ca90fac35730187c842daf08c

Fix arrow offset issue

view details

varkor

commit sha f5f55bbcc913b5dd5df34fc03e8d5a2e1ff06518

Increase the maximum absolute offset to 5

view details

varkor

commit sha 200866a975b27878651de4e5d41288971a610aa2

Take target into account for the edge level whilst dragging

view details

varkor

commit sha ba1b13909c2d7dadd33e4b24d4d4e3a88e9ffc54

Add support for barred arrows This could previously be faked using the description style, but could not be combined with labels.

view details

varkor

commit sha 27e4a3ec1b6b16e86252c146b3e1f2e98d4551bd

Add button to flip arrows

view details

varkor

commit sha 0391e9a2f1c7b986ac018549d9dbde3c02add5dc

Preload fonts as `crossorigin`

view details

varkor

commit sha 8b41caef7acee3016735ca4fd28d5045c9aa3568

Start implementing curves from scratch

view details

varkor

commit sha 7867f5d3a09383f7a4cfd5644fffb2d73929da6a

Draw n-cells and arrow heads

view details

varkor

commit sha 038f43d6b7a1e2dfb430fa40d4cc7b59671fa2b4

Special-case flat Bézier curves

view details

varkor

commit sha ce0dafb7ec2452ffbf6cb6ecc7f4b288e28f3216

Resize SVG appropriately

view details

varkor

commit sha 922bcf66e3ac8f035459ec9796ba76e305ff6a2e

Make a start on different arrow styles

view details

varkor

commit sha 31f189f3240b725cc2c8f74eae49f2986d0b3f49

Add explicit namespace to SVGs

view details

varkor

commit sha 9cfbfbf1affc161f01d2c5f7bfc57b84e4ef4a7d

Preliminary work on squiggly arrows

view details

push time in 4 days

push eventvarkor/quiver

varkor

commit sha b1df2fa7cc9f88c3d96b094b7a25e298ba74c85d

Rebuild GitHub Pages

view details

push time in 4 days

push eventvarkor/quiver

varkor

commit sha 525b1b8e5aa0bb5fff9fde062ab08784771e53cc

Build dependencies

view details

varkor

commit sha 3721947dd79291e7a9d6ebf97a57395997578fe1

Add the dev branch

view details

push time in 4 days

push eventvarkor/quiver

varkor

commit sha bde2dec704ae31dc7752efef662d28185a745a76

Rebuild GitHub Pages

view details

push time in 4 days

push eventvarkor/quiver

varkor

commit sha fe3218b0b5a846b0ca69c45d854dd709a450f857

Preload fonts as `crossorigin`

view details

varkor

commit sha 5a48eb2f60002ccbe5b695980af2ed182cdbd94a

Build dependencies

view details

varkor

commit sha 4c322afdec69deb918b9b9bc6d454f7e33203e2a

Add the dev branch

view details

push time in 4 days

push eventvarkor/quiver

varkor

commit sha 0391e9a2f1c7b986ac018549d9dbde3c02add5dc

Preload fonts as `crossorigin`

view details

push time in 4 days

push eventvarkor/quiver

varkor

commit sha 4ae8a9a49b030d65d0a31a672545f23508573c31

Rebuild GitHub Pages

view details

push time in 4 days

push eventvarkor/quiver

varkor

commit sha e6e64faac838fc86419dd6b5eb2e6f95973f4ec7

Add button to flip arrows

view details

varkor

commit sha 57a38d807c356dda1c09c2aa699d9c284fd8ff8c

Build dependencies

view details

varkor

commit sha 48cdbbcbd8fb30ce8e17a84269f516cbce2c6af7

Add the dev branch

view details

push time in 4 days

push eventvarkor/quiver

varkor

commit sha 27e4a3ec1b6b16e86252c146b3e1f2e98d4551bd

Add button to flip arrows

view details

push time in 4 days

issue commentvarkor/quiver

Curved arrows

I have to admit, I've had curved arrows working almost entirely for months now (I completely rewrote it since the original comment to make it more flexible). Really it just requires me to dedicate a weekend to completing it. I'll try to prioritise this.

varkor

comment created time in 5 days

pull request commentrust-lang/rust

handle ConstEquate in rustdoc

@bors r+ rollup

lcnr

comment created time in 7 days

pull request commentrust-lang/rust

Forbid generic parameters in anon consts inside of type defaults

@bors r+

lcnr

comment created time in 8 days

pull request commentrust-lang/rust

Stability annotations on generic parameters (take 2)

@Avi-D-coder: just noticed that the tests don't cover unstable type defaults on enums or type aliases. Could you add a couple of those, and rebase, and then I'll approve!

Avi-D-coder

comment created time in 11 days

pull request commentrust-lang/rust

correctly deal with unsorted generic parameters

Thanks for figuring out what was going on here — it's been a longstanding annoyance!

@bors r+

lcnr

comment created time in 12 days

issue commentrust-lang/rust

Tracking Issue for RFC 213: Default Type Parameter Fallback

one of the biggest use cases is adding a new type parameter to an existing type, without breaking semver compatibility.

Presumably there's some overlap here with https://github.com/rust-lang/wg-allocators/issues/2, though I haven't been following this issue closely.

jroesch

comment created time in 12 days

issue openedrust-dev-tools/fmt-rfcs

Underscores in numeric literals

There appears to be no guideline for underscores at the moment. Perhaps it is intended to be left to the programmer, but in particular, I think specifying whether or not underscores are encouraged between a literal and its type, e.g. 5u32 vs 5_u32 could be helpful (or specifically excluded).

created time in 12 days

Pull request review commentrust-lang/rust

Show the values and computation that would overflow a const evaluation or propagation

+use crate::mir::interpret::truncate;+use rustc_target::abi::Size;++#[derive(Copy, Clone)]+/// A type for representing any integer. Only used for printing.+// FIXME: Use this for the integer-tree representation needed for type level ints and+// const generics?+pub struct ConstInt {+    /// Number of bytes of the integer. Only 1, 2, 4, 8, 16 are legal values.+    size: u8,+    /// Whether the value is of a signed integer type.+    signed: bool,+    /// Whether the value is a `usize` or `isize` type.+    is_ptr_sized_integral: bool,+    /// Raw memory of the integer. All bytes beyond the `size` are unused and must be zero.+    raw: u128,+}++impl ConstInt {+    pub fn new(raw: u128, size: Size, signed: bool, is_ptr_sized_integral: bool) -> Self {+        assert!(raw <= truncate(u128::MAX, size));+        Self { raw, size: size.bytes() as u8, signed, is_ptr_sized_integral }+    }+}++impl std::fmt::Debug for ConstInt {+    fn fmt(&self, fmt: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {+        let Self { size, signed, raw, is_ptr_sized_integral } = *self;+        if signed {+            let bit_size = size * 8;+            let min = 1u128 << (bit_size - 1);+            let max = min - 1;+            if raw == min {+                match (size, is_ptr_sized_integral) {+                    (_, true) => write!(fmt, "isize::MIN"),+                    (1, _) => write!(fmt, "i8::MIN"),+                    (2, _) => write!(fmt, "i16::MIN"),+                    (4, _) => write!(fmt, "i32::MIN"),+                    (8, _) => write!(fmt, "i64::MIN"),+                    (16, _) => write!(fmt, "i128::MIN"),+                    _ => bug!("ConstInt 0x{:x} with size = {} and signed = {}", raw, size, signed),+                }+            } else if raw == max {+                match (size, is_ptr_sized_integral) {+                    (_, true) => write!(fmt, "isize::MAX"),+                    (1, _) => write!(fmt, "i8::MAX"),+                    (2, _) => write!(fmt, "i16::MAX"),+                    (4, _) => write!(fmt, "i32::MAX"),+                    (8, _) => write!(fmt, "i64::MAX"),+                    (16, _) => write!(fmt, "i128::MAX"),+                    _ => bug!("ConstInt 0x{:x} with size = {} and signed = {}", raw, size, signed),+                }+            } else {+                match size {+                    1 => write!(fmt, "{}", raw as i8)?,+                    2 => write!(fmt, "{}", raw as i16)?,+                    4 => write!(fmt, "{}", raw as i32)?,+                    8 => write!(fmt, "{}", raw as i64)?,+                    16 => write!(fmt, "{}", raw as i128)?,+                    _ => bug!("ConstInt 0x{:x} with size = {} and signed = {}", raw, size, signed),+                }+                if fmt.alternate() {+                    match (size, is_ptr_sized_integral) {+                        (_, true) => write!(fmt, "_isize")?,+                        (1, _) => write!(fmt, "_i8")?,+                        (2, _) => write!(fmt, "_i16")?,+                        (4, _) => write!(fmt, "_i32")?,+                        (8, _) => write!(fmt, "_i64")?,+                        (16, _) => write!(fmt, "_i128")?,+                        _ => bug!(),+                    }+                }+                Ok(())+            }+        } else {+            let max = truncate(u128::MAX, Size::from_bytes(size));+            if raw == max {+                match (size, is_ptr_sized_integral) {+                    (_, true) => write!(fmt, "usize::MAX"),+                    (1, _) => write!(fmt, "u8::MAX"),+                    (2, _) => write!(fmt, "u16::MAX"),+                    (4, _) => write!(fmt, "u32::MAX"),+                    (8, _) => write!(fmt, "u64::MAX"),+                    (16, _) => write!(fmt, "u128::MAX"),+                    _ => bug!("ConstInt 0x{:x} with size = {} and signed = {}", raw, size, signed),+                }+            } else {+                match size {+                    1 => write!(fmt, "{}", raw as u8)?,+                    2 => write!(fmt, "{}", raw as u16)?,+                    4 => write!(fmt, "{}", raw as u32)?,+                    8 => write!(fmt, "{}", raw as u64)?,+                    16 => write!(fmt, "{}", raw as u128)?,+                    _ => bug!("ConstInt 0x{:x} with size = {} and signed = {}", raw, size, signed),+                }+                if fmt.alternate() {+                    match (size, is_ptr_sized_integral) {+                        (_, true) => write!(fmt, "_usize")?,+                        (1, _) => write!(fmt, "_u8")?,+                        (2, _) => write!(fmt, "_u16")?,+                        (4, _) => write!(fmt, "_u32")?,+                        (8, _) => write!(fmt, "_u64")?,+                        (16, _) => write!(fmt, "_u128")?,

Are we emitting any other diagnostics in rustc like this? I haven't seen any either, but I could be out of touch.

oli-obk

comment created time in 12 days

pull request commentzulip/zulip

Offer sorting streams by most recent activity.

What's the status on this PR? Does it just need a rebase? Looking forward to seeing this in Zulip, thanks @hashirsarwar!

hashirsarwar

comment created time in 12 days

pull request commentrust-lang/rust

Improve codegen for unchecked float casts on wasm

@bors r+ rollup

alexcrichton

comment created time in 13 days

pull request commentrust-lang/rust

require type defaults to be after const generic parameters

r=me after wording tweak for consistency.

lcnr

comment created time in 13 days

Pull request review commentrust-lang/rust

require type defaults to be after const generic parameters

 impl<'a> Visitor<'a> for AstValidator<'a> {     fn visit_generics(&mut self, generics: &'a Generics) {         let mut prev_ty_default = None;         for param in &generics.params {-            if let GenericParamKind::Type { ref default, .. } = param.kind {-                if default.is_some() {+            match param.kind {+                GenericParamKind::Lifetime => (),+                GenericParamKind::Type { default: Some(_), .. } => {                     prev_ty_default = Some(param.ident.span);-                } else if let Some(span) = prev_ty_default {-                    self.err_handler()-                        .span_err(span, "type parameters with a default must be trailing");-                    break;+                }+                GenericParamKind::Type { .. } | GenericParamKind::Const { .. } => {+                    if let Some(span) = prev_ty_default {+                        let mut err = self.err_handler().struct_span_err(+                            span,+                            "type parameters with a default must be trailing",+                        );+                        if matches!(param.kind, GenericParamKind::Const { .. }) {+                            err.note(+                                "using type defaults and const parameters \+                                 in the same parameter listing is currently not possible",
                                 in the same parameter list is currently not permitted",
lcnr

comment created time in 13 days

issue commentrust-lang/rust

Tracking issue for RFC 2535, 2530, 2175, "Or patterns, i.e `Foo(Bar(x) | Baz(x))`"

The most pressing blocking issue is the remaining ICE: https://github.com/rust-lang/rust/issues/72680, though there appear to be a couple of outstanding design questions. I would have thought it would be close to ready for stabilisation apart from that.

Centril

comment created time in 13 days

issue commentrust-lang/rust

save-analysis: adjust `process_formals` wrt. or-patterns

@Xanewok: do you know if is this still an issue?

Centril

comment created time in 13 days

issue commentrust-lang/rust

Tracking issue for const generics (RFC 2000)

We're now more than halfway through the year, so I'll briefly summarise the work that has been going on. There have been lots of people involved in improving const generics support in the last 6 months, so thank you to everyone who's helped in some way! I especially want to thank @skinny121 and @lcnr, who have both tackled some large features that const generics has been lacking for a while: lazy normalisation for constants and const argument support in method calls, as well as fixing numerous difficult bugs. Their efforts are evident from the summary below.

Const generics is now being used in several places throughout the compiler, and there's already experimentation with traits and functions making use of const generics, e.g. slice::array_chunks and IntoIterator and FromIterator for [T; N] (https://github.com/rust-lang/rust/pull/65819, https://github.com/rust-lang/rust/pull/69985). The length 32 restriction for array trait implementations is also finally being prepped for removal.

We're currently discussing stabilising a subset of const generics that should cover a wide range of use cases (though there are still some issues left to address before const generics can be fully stabilised).


  • @skinny121:
    • Implemented the first version of lazy normalisation (https://github.com/rust-lang/rust/pull/68505, https://github.com/rust-lang/rust/pull/69181, https://github.com/rust-lang/rust/pull/67717, https://github.com/rust-lang/rust/pull/67890)
    • Improved performance (https://github.com/rust-lang/rust/pull/68118)
    • Fixed various errors (https://github.com/rust-lang/rust/pull/68143)
  • @lcnr:
    • Added support for explicit const generics in type arguments for methods (https://github.com/rust-lang/rust/pull/74113)
    • Completed the first implementation of lazy normalisation for constants (https://github.com/rust-lang/rust/pull/71973) with @skinny121
    • Added a lint for unused_braces (https://github.com/rust-lang/rust/pull/70081)
    • Fixed issue with const generics in patterns (https://github.com/rust-lang/rust/pull/70562)
    • Forbade dyn Trait for const generic parameters (https://github.com/rust-lang/rust/pull/71038)
    • Improved pretty-printing (https://github.com/rust-lang/rust/pull/72052)
    • Fixed various errors (https://github.com/rust-lang/rust/pull/70032, https://github.com/rust-lang/rust/pull/70107, https://github.com/rust-lang/rust/pull/70223, https://github.com/rust-lang/rust/pull/70249, https://github.com/rust-lang/rust/pull/70284, https://github.com/rust-lang/rust/pull/70319, https://github.com/rust-lang/rust/pull/70541, https://github.com/rust-lang/rust/pull/72066, https://github.com/rust-lang/rust/pull/74159)
    • Refactoring (https://github.com/rust-lang/rust/pull/70478)
    • Added tests (https://github.com/rust-lang/rust/pull/74392, https://github.com/rust-lang/rust/pull/74445)
  • @eddyb:
    • Fixed issues with const generics in array lengths (https://github.com/rust-lang/rust/pull/70452)
    • Improved pretty-printing (https://github.com/rust-lang/rust/pull/71232)
    • Improved error handling (https://github.com/rust-lang/rust/pull/71049)
    • Refactoring (https://github.com/rust-lang/rust/pull/70164)
  • @Aaron1011: fixed error with cross-crate const generics usage (https://github.com/rust-lang/rust/pull/72600)
  • @petrochenkov: fixed issues with name resolution and const generics (https://github.com/rust-lang/rust/pull/70006)
  • @yodaldevoid: fixed an issue with lifetime use in const generic parameters (https://github.com/rust-lang/rust/pull/74051)
  • @contrun: fixed an ICE (https://github.com/rust-lang/rust/pull/69859)
  • @oli-obk: refactoring (https://github.com/rust-lang/rust/pull/69981)
  • @Centril: improved diagnostics (https://github.com/rust-lang/rust/pull/70261)
  • @DutchGhost: added a test (https://github.com/rust-lang/rust/pull/70539)
  • @varkor:
    • Improved pretty-printing (https://github.com/rust-lang/rust/pull/67909, https://github.com/rust-lang/rust/pull/68111)
    • Fixed various errors (https://github.com/rust-lang/rust/pull/67906, https://github.com/rust-lang/rust/pull/68388, https://github.com/rust-lang/rust/pull/68434)
    • Improved diagnostics (https://github.com/rust-lang/rust/pull/70845)
    • Added tests (https://github.com/rust-lang/rust/pull/68312, https://github.com/rust-lang/rust/pull/70939)

While const generics has already come a long way, there are still bugs and sharp edges. If you're interested in tackling any of the remaining issues, feel free to ping me, @lcnr or @eddyb on the issue, or on Zulip, for pointers on getting started. Thank you!

withoutboats

comment created time in 13 days

issue closedrust-lang/rust

ICE with const generics with explicit lifetime argument

This is a very slight modification of an example in #60813, but filing as a separate bug, since the error message is very different.

The following code

#![feature(const_generics)]

pub fn function_with_str<'a, const STRING: &'a str>() {
}

pub fn use_it() {
    function_with_str::<"Hello, world!">()
}

results in the following ICE:

   Compiling playground v0.0.1 (/playground)
warning: the feature `const_generics` is incomplete and may cause the compiler to crash
 --> src/lib.rs:1:12
  |
1 | #![feature(const_generics)]
  |            ^^^^^^^^^^^^^^

error: internal compiler error: src/librustc/ty/subst.rs:489: Region parameter out of range when substituting in region 'a (root type=Some(&'a str)) (index=0)

thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:572: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 src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
   1: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at src/libstd/sys_common/backtrace.rs:59
             at src/libstd/panicking.rs:197
   3: std::panicking::default_hook
             at src/libstd/panicking.rs:211
   4: rustc::util::common::panic_hook
   5: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:478
   6: std::panicking::begin_panic
   7: rustc_errors::Handler::span_bug
   8: rustc::util::bug::opt_span_bug_fmt::{{closure}}
   9: rustc::ty::context::tls::with_opt::{{closure}}
  10: rustc::ty::context::tls::with_context_opt
  11: rustc::ty::context::tls::with_opt
  12: rustc::util::bug::opt_span_bug_fmt
  13: rustc::util::bug::span_bug_fmt
  14: <rustc::ty::subst::SubstFolder as rustc::ty::fold::TypeFolder>::fold_region
  15: rustc::ty::structural_impls::<impl rustc::ty::fold::TypeFoldable for &rustc::ty::TyS>::super_fold_with
  16: <rustc::ty::subst::SubstFolder as rustc::ty::fold::TypeFolder>::fold_ty
  17: rustc::ty::instance::Instance::resolve
  18: <rustc::traits::project::AssociatedTypeNormalizer as rustc::ty::fold::TypeFolder>::fold_const
  19: <smallvec::SmallVec<A> as core::iter::traits::collect::FromIterator<<A as smallvec::Array>::Item>>::from_iter
  20: rustc::ty::fold::TypeFoldable::fold_with
  21: rustc::ty::structural_impls::<impl rustc::ty::fold::TypeFoldable for &rustc::ty::TyS>::super_fold_with
  22: <rustc::traits::project::AssociatedTypeNormalizer as rustc::ty::fold::TypeFolder>::fold_ty
  23: rustc::traits::project::normalize
  24: rustc_typeck::check::FnCtxt::instantiate_value_path
  25: rustc_typeck::check::FnCtxt::check_expr_kind
  26: rustc_typeck::check::FnCtxt::check_expr_with_expectation_and_needs
  27: rustc_typeck::check::callee::<impl rustc_typeck::check::FnCtxt>::check_call
  28: rustc_typeck::check::FnCtxt::check_expr_kind
  29: rustc_typeck::check::FnCtxt::check_expr_with_expectation_and_needs
  30: rustc_typeck::check::FnCtxt::check_block_with_expected
  31: rustc_typeck::check::FnCtxt::check_expr_kind
  32: rustc_typeck::check::FnCtxt::check_expr_with_expectation_and_needs
  33: rustc_typeck::check::FnCtxt::check_return_expr
  34: rustc_typeck::check::check_fn
  35: rustc::ty::context::GlobalCtxt::enter_local
  36: rustc_typeck::check::typeck_tables_of
  37: rustc::ty::query::__query_compute::typeck_tables_of
  38: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors for rustc::ty::query::queries::typeck_tables_of>::compute
  39: rustc::dep_graph::graph::DepGraph::with_task_impl
  40: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::get_query
  41: rustc::ty::<impl rustc::ty::context::TyCtxt>::par_body_owners
  42: rustc_typeck::check::typeck_item_bodies
  43: rustc::ty::query::__query_compute::typeck_item_bodies
  44: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors for rustc::ty::query::queries::typeck_item_bodies>::compute
  45: rustc::dep_graph::graph::DepGraph::with_task_impl
  46: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::get_query
  47: rustc::util::common::time
  48: rustc_typeck::check_crate
  49: rustc_interface::passes::analysis
  50: rustc::ty::query::__query_compute::analysis
  51: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors for rustc::ty::query::queries::analysis>::compute
  52: rustc::dep_graph::graph::DepGraph::with_task_impl
  53: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::get_query
  54: rustc::ty::context::tls::enter_global
  55: rustc_interface::passes::BoxedGlobalCtxt::access::{{closure}}
  56: rustc_interface::passes::create_global_ctxt::{{closure}}
  57: rustc_interface::interface::run_compiler_in_existing_thread_pool
  58: std::thread::local::LocalKey<T>::with
  59: scoped_tls::ScopedKey<T>::set
  60: syntax::with_globals
query stack during panic:
#0 [typeck_tables_of] processing `use_it`
#1 [typeck_item_bodies] type-checking all item bodies
#2 [analysis] running analysis passes on this crate
end of query stack
error: aborting due to previous error


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.36.0-nightly (a9ec99f42 2019-05-13) running on x86_64-unknown-linux-gnu

note: compiler flags: -C codegen-units=1 -C debuginfo=2 --crate-type lib

note: some of the compiler flags provided by cargo are hidden

error: Could not compile `playground`.

To learn more, run the command again with --verbose.

Playground link

cc @Serentty

closed time in 13 days

moxian

issue commentrust-lang/rust

ICE with const generics with explicit lifetime argument

Fixed by https://github.com/rust-lang/rust/pull/74051.

moxian

comment created time in 13 days

issue commentrust-lang/wg-allocators

Unstable type parameters on stable types

Now that I think about it, it seems harder to accidentally allow this than I thought. The sort of example I had in mind was the following.

// Library code.
pub struct SomeType<#[unstable(feature = "test_feature")] T = ()>(T);

// User code.
SomeType(0u8) // Works, even though a non-default is not specified, because the default is inferred.

There could be a similar problem if existing methods are extended to support different type parameters, but that's not going to happen, in which case @TimDiekmann's comment is the main point to keep in mind: if you stabilise any method that allows the default to be changed (even implicitly, e.g. taking a type that can be inferred as non-default), you've effectively stabilised the type parameter itself (even if the user can't mention it explicitly). I think due to the way the APIs are designed, this won't be a problem in practice, though.

SimonSapin

comment created time in 13 days

pull request commentrust-lang/rust

Stability annotations on generic parameters (take 2)

I've commented on https://github.com/rust-lang/wg-allocators/issues/2#issuecomment-661245601. If there are no concerns raised, I'll approve this PR in a couple of days (to give people time to respond). I think all of my concerns have been addressed now, and that this is a workable design.

Avi-D-coder

comment created time in 15 days

issue commentrust-lang/wg-allocators

Unstable type parameters on stable types

I think https://github.com/rust-lang/rust/pull/72314 is ready to merge now, which adds support for unstable type parameters. That is, type parameters with defaults can be marked unstable, which means an explicit type argument will only be permitted if the corresponding feature flag is enabled. However, as a note of warning to API implementers: a non-default type can still be inferred for an unstable type parameter. (This appears to be necessary to prevent code breaking when a type parameter is stabilised.) That means that you must be careful not to allow the type parameter to be inferred outside of library code, e.g. by having custom constructors for the non-default type parameter, at least until the type parameter is stabilised. I think that this is the most reasonable design, but let me know if you have any concerns. It may be helpful for those interested to take a look at the tests on https://github.com/rust-lang/rust/pull/72314 to check it matches their intuition. If there are no concerns, I'll approve it in a few days.

SimonSapin

comment created time in 15 days

Pull request review commentrust-lang/rust

Stability annotations on generic parameters (take 2)

+// ignore-tidy-linelength+// aux-build:unstable_generic_param.rs++extern crate unstable_generic_param;++use unstable_generic_param::*;++struct R;++impl Trait1 for S {+    fn foo() -> () { () } // ok+}++struct S;++impl Trait1<usize> for S { //~ ERROR use of unstable library feature 'unstable_default'+    fn foo() -> usize { 0 }+}++impl Trait1<isize> for S { //~ ERROR use of unstable library feature 'unstable_default'+    fn foo() -> isize { 0 }+}++impl Trait2<usize> for S { //~ ERROR use of unstable library feature 'unstable_default'+    fn foo() -> usize { 0 }+}++impl Trait3<usize> for S {+    fn foo() -> usize { 0 } // ok+}++fn main() {+    let _ = S;++    let _: Struct1<isize> = Struct1 { field: 1 }; //~ ERROR use of unstable library feature 'unstable_default'++    let _ = STRUCT1; // ok+    let _: Struct1 = STRUCT1; // ok+    let _: Struct1<usize> = STRUCT1; //~ ERROR use of unstable library feature 'unstable_default'+    let _: Struct1<isize> = Struct1 { field: 0 }; //~ ERROR use of unstable library feature 'unstable_default'++    // Instability is not enforced for generic type parameters used in public fields.+    // Note how the unstable type default `usize` leaks,+    // and can be used without the 'unstable_default' feature.+    let _ = STRUCT1.field;+    let _ = Struct1 { field: 1 };

Yes, I agree. I think a complete fix is looking quite implausible. It might be best to leave this to the API designers and make it very clear that they are responsible for not allowing leakage. I think it should be straightforward to avoid once they're aware of the limitations. I shall write a summary post on https://github.com/rust-lang/wg-allocators/issues/2, and then I think we're probably good to go on this PR.

Avi-D-coder

comment created time in 19 days

pull request commentrust-lang/rust

forbid generic params in the type of const params

@bors r+

Thanks!

lcnr

comment created time in 19 days

issue commentrust-lang/rust

Check existing uses of `unwrap_usize` for `ty::Array`

I don't think anyone did a formal triage, but I skimmed through at some point, and there weren't any more worrying uses. It might be safe to close this, and reopen if we hit the same ICE again.

varkor

comment created time in 19 days

pull request commentrust-lang/rust

const generics triage

r=me when CI passes.

lcnr

comment created time in 19 days

pull request commentrust-lang/rust

forbid generic params in the type of const params

I'm happy with the implementation: I just want to tweak that error message a little bit.

lcnr

comment created time in 20 days

Pull request review commentrust-lang/rust

forbid generic params in the type of const params

+error[E0769]: the type of const parameters must not depend on other generic parameters+  --> $DIR/const-param-type-depends-on-const-param.rs:9:52+   |+LL | pub struct Dependent<const N: usize, const X: [u8; N]>([(); N]);+   |                                                    ^ const parameters must have a concrete type

Perhaps it would make more sense to make this something like:

^ the type must not depend on the parameter `N`

so it's clear why N is being pointed to here. ("const parameters must have a concrete type" sounds fine, but I would expect the span to be on X in that case, or the entire type of X.)

lcnr

comment created time in 20 days

pull request commentrust-lang/rust

Handle case of incomplete local ty more gracefully

@bors r+ rollup

estebank

comment created time in 20 days

pull request commentrust-lang/rust

add `slice::array_chunks` to std

Presumably this fixes https://github.com/rust-lang/rust/issues/60735.

lcnr

comment created time in 20 days

Pull request review commentrust-lang/rust

Stability annotations on generic parameters (take 2)

+// ignore-tidy-linelength+// aux-build:unstable_generic_param.rs++extern crate unstable_generic_param;++use unstable_generic_param::*;++struct R;++impl Trait1 for S {+    fn foo() -> () { () } // ok+}++struct S;++impl Trait1<usize> for S { //~ ERROR use of unstable library feature 'unstable_default'+    fn foo() -> usize { 0 }+}++impl Trait1<isize> for S { //~ ERROR use of unstable library feature 'unstable_default'+    fn foo() -> isize { 0 }+}++impl Trait2<usize> for S { //~ ERROR use of unstable library feature 'unstable_default'+    fn foo() -> usize { 0 }+}++impl Trait3<usize> for S {+    fn foo() -> usize { 0 } // ok+}++fn main() {+    let _ = S;++    let _: Struct1<isize> = Struct1 { field: 1 }; //~ ERROR use of unstable library feature 'unstable_default'++    let _ = STRUCT1; // ok+    let _: Struct1 = STRUCT1; // ok+    let _: Struct1<usize> = STRUCT1; //~ ERROR use of unstable library feature 'unstable_default'+    let _: Struct1<isize> = Struct1 { field: 0 }; //~ ERROR use of unstable library feature 'unstable_default'++    // Instability is not enforced for generic type parameters used in public fields.+    // Note how the unstable type default `usize` leaks,+    // and can be used without the 'unstable_default' feature.+    let _ = STRUCT1.field;+    let _ = Struct1 { field: 1 };

The most important thing is to ensure that removing the stability attribute doesn't break any code, and that removing an unstable defaulted type parameter doesn't break anyone who didn't opt into the feature gate. Maybe what you have already is the best we can do. I think observing the concrete type is okay, but changing it (without the feature flag) should not be possible. I don't see how we could forbid that, though.

Avi-D-coder

comment created time in 23 days

Pull request review commentrust-lang/rust

Stability annotations on generic parameters (take 2)

+// ignore-tidy-linelength+// aux-build:unstable_generic_param.rs++extern crate unstable_generic_param;++use unstable_generic_param::*;++struct R;++impl Trait1 for S {+    fn foo() -> () { () } // ok+}++struct S;++impl Trait1<usize> for S { //~ ERROR use of unstable library feature 'unstable_default'+    fn foo() -> usize { 0 }+}++impl Trait1<isize> for S { //~ ERROR use of unstable library feature 'unstable_default'+    fn foo() -> isize { 0 }+}++impl Trait2<usize> for S { //~ ERROR use of unstable library feature 'unstable_default'+    fn foo() -> usize { 0 }+}++impl Trait3<usize> for S {+    fn foo() -> usize { 0 } // ok+}++fn main() {+    let _ = S;++    let _: Struct1<isize> = Struct1 { field: 1 }; //~ ERROR use of unstable library feature 'unstable_default'++    let _ = STRUCT1; // ok+    let _: Struct1 = STRUCT1; // ok+    let _: Struct1<usize> = STRUCT1; //~ ERROR use of unstable library feature 'unstable_default'+    let _: Struct1<isize> = Struct1 { field: 0 }; //~ ERROR use of unstable library feature 'unstable_default'++    // Instability is not enforced for generic type parameters used in public fields.+    // Note how the unstable type default `usize` leaks,+    // and can be used without the 'unstable_default' feature.+    let _ = STRUCT1.field;+    let _ = Struct1 { field: 1 };

The goal is to hide the possibility that one of the types in a definition is actually a parameter. To the user, it should just look like a fixed type. It doesn't matter if they use the concrete type, because nothing breaks if it's technically a parameter: the user has to opt in to changing the type parameter. However, now that I think about it, if we change inference, then something could break when a type parameter default is stabilised… So maybe we need to leave it up to the API designer to make sure that the type doesn't leak.

Avi-D-coder

comment created time in 23 days

Pull request review commentrust-lang/rust

Stability annotations on generic parameters (take 2)

+// ignore-tidy-linelength+// aux-build:unstable_generic_param.rs++extern crate unstable_generic_param;++use unstable_generic_param::*;++struct R;++impl Trait1 for S {+    fn foo() -> () { () } // ok+}++struct S;++impl Trait1<usize> for S { //~ ERROR use of unstable library feature 'unstable_default'+    fn foo() -> usize { 0 }+}++impl Trait1<isize> for S { //~ ERROR use of unstable library feature 'unstable_default'+    fn foo() -> isize { 0 }+}++impl Trait2<usize> for S { //~ ERROR use of unstable library feature 'unstable_default'+    fn foo() -> usize { 0 }+}++impl Trait3<usize> for S {+    fn foo() -> usize { 0 } // ok+}++fn main() {+    let _ = S;++    let _: Struct1<isize> = Struct1 { field: 1 }; //~ ERROR use of unstable library feature 'unstable_default'++    let _ = STRUCT1; // ok+    let _: Struct1 = STRUCT1; // ok+    let _: Struct1<usize> = STRUCT1; //~ ERROR use of unstable library feature 'unstable_default'+    let _: Struct1<isize> = Struct1 { field: 0 }; //~ ERROR use of unstable library feature 'unstable_default'++    // Instability is not enforced for generic type parameters used in public fields.+    // Note how the unstable type default `usize` leaks,+    // and can be used without the 'unstable_default' feature.+    let _ = STRUCT1.field;+    let _ = Struct1 { field: 1 };

I think we want these to error. Probably you should only be able to use a non-default type if you've opted into the feature flag. I'll try to point you in the right direction for this tomorrow.

Avi-D-coder

comment created time in 24 days

Pull request review commentrust-lang/rust

Stability annotations on generic parameters (take 2)

+// ignore-tidy-linelength+// aux-build:unstable_generic_param.rs++extern crate unstable_generic_param;++use unstable_generic_param::*;++struct R;++impl Trait1 for S {+    fn foo() -> () { () } // ok+}++struct S;++impl Trait1<usize> for S { //~ ERROR use of unstable library feature 'unstable_default'+    fn foo() -> usize { 0 }+}++impl Trait1<isize> for S { //~ ERROR use of unstable library feature 'unstable_default'+    fn foo() -> isize { 0 }+}++impl Trait2<usize> for S { //~ ERROR use of unstable library feature 'unstable_default'+    fn foo() -> usize { 0 }+}++impl Trait3<usize> for S {+    fn foo() -> usize { 0 } // ok+}++fn main() {+    let _ = S;++    let _: Struct1<isize> = Struct1 { field: 1 }; //~ ERROR use of unstable library feature 'unstable_default'++    let _ = STRUCT1; // ok+    let _: Struct1 = STRUCT1; // ok+    let _: Struct1<usize> = STRUCT1; //~ ERROR use of unstable library feature 'unstable_default'+    let _: Struct1<isize> = Struct1 { field: 0 }; //~ ERROR use of unstable library feature 'unstable_default'++    // Instability is not enforced for generic type parameters used in public fields.+    // Note how the unstable type default `usize` leaks,+    // and can be used without the 'unstable_default' feature.+    let _ = STRUCT1.field;+    let _ = Struct1 { field: 1 };

What happens if we do:

let _ = Struct1 { field: () };

i.e. try to use a type that's not the default, implicitly?

Avi-D-coder

comment created time in 24 days

pull request commentrust-lang/rust

forbid generic params in the type of const params

I think it'd help to discuss this on Zulip, because there were objections previously to blocking this in name resolution. I also want to figure out where the previous error went missing, because I would have thought it would have been sufficient if it had stayed around. I'll try to look, but I don't have time immediately.

lcnr

comment created time in 24 days

issue openedzulip/zulip

Alert words are not shown in @ Mentions

The description for alert words says:

Alert words allow you to be notified as if you were @-mentioned when certain words or phrases are used in Zulip. Alert words are not case sensitive.

I take this to mean that they appear in the @ Mentions panel, but it appears that they are only highlighted. I'm not sure if this is expected behaviour or not, but it's only a helpful feature if I can see mentions in one place, as there's often too many messages to keep track of manually.

created time in 24 days

issue commentrust-lang/rust

Forbid generic parameters in the type of const generic parameters

I believe we already forbade generic type parameters in const generic types, but may have forgotten about other const generics. I'll review the PR soon.

lcnr

comment created time in 25 days

pull request commentrust-lang/rust

Stability annotations on generic parameters (take 2)

Will get to this either today or this weekend.

Avi-D-coder

comment created time in 25 days

pull request commentrust-lang/rust

take self by value in ToPredicate

@bors r+ rollup

lcnr

comment created time in 25 days

Pull request review commentrust-lang/rust

Stability annotations on generic parameters (take 2)

 impl<'o, 'tcx> dyn AstConv<'tcx> + 'o {                 (GenericParamDefKind::Lifetime, GenericArg::Lifetime(lt)) => {                     self.ast_region_to_region(&lt, Some(param)).into()                 }-                (GenericParamDefKind::Type { .. }, GenericArg::Type(ty)) => {+                (GenericParamDefKind::Type { has_default, .. }, GenericArg::Type(ty)) => {+                    if *has_default {+                        tcx.check_optional_stability(+                            param.def_id,+                            Some(arg.id()),+                            arg.span(),+                            |_, _| (),
                            |_, _| {
                                // Default generic parameters may not be marked
                                // with stability attributes, i.e. when the
                                // default parameter was defined at the same time
                                // as the rest of the type. As such, we ignore missing
                                // stability attributes.
                            },
Avi-D-coder

comment created time in a month

Pull request review commentrust-lang/rust

Stability annotations on generic parameters (take 2)

 enum AnnotationKind {     Container, } +/// Inheriting deprecations Nested items causes duplicate warnings.+/// Inheriting the deprecation of `Foo<T>` onto the parameter `T`, would cause a duplicate warnings.
/// Whether to inherit deprecation flags for nested items. In most cases, we do want to inherit
/// deprecation, because nested items rarely have individual deprecation attributes, and so
/// should be treated as deprecated if their parent is. However, default generic parameters
/// have separate deprecation attributes from their parents, so we do not wish to inherit
/// deprecation in this case. For example, inheriting deprecation for `T` in `Foo<T>`
/// would cause a duplicate warning arising from both `Foo` and `T` being deprecated.
Avi-D-coder

comment created time in a month

Pull request review commentrust-lang/rust

Stability annotations on generic parameters (take 2)

 enum AnnotationKind {     Container, } +/// Inheriting deprecations Nested items causes duplicate warnings.+/// Inheriting the deprecation of `Foo<T>` onto the parameter `T`, would cause a duplicate warnings.+#[derive(PartialEq, Copy, Clone)]+enum InheritDeprecation {+    Yes,+    No,+}++impl InheritDeprecation {+    fn yes(&self) -> bool {+        *self == InheritDeprecation::Yes
        matches!(self, InheritDeprecation::Yes)

Actually, using matches!, it might be cleaner simply to inline this and get rid of PartialEq on InheritDeprecation.

Avi-D-coder

comment created time in a month

Pull request review commentrust-lang/rust

Stability annotations on generic parameters (take 2)

 impl<'tcx> TyCtxt<'tcx> {     /// If the item defined by `def_id` is unstable and the corresponding `#![feature]` does not     /// exist, emits an error.     ///-    /// Additionally, this function will also check if the item is deprecated. If so, and `id` is-    /// not `None`, a deprecated lint attached to `id` will be emitted.+    /// This function will also check if the item is deprecated.+    /// If so, and `id` is not `None`, a deprecated lint attached to `id` will be emitted.     pub fn check_stability(self, def_id: DefId, id: Option<HirId>, span: Span) {+        self.check_optional_stability(def_id, id, span, |span, def_id| {+            // The API could be uncallable for other reasons, for example when a private module+            // was referenced.+            self.sess.delay_span_bug(span, &format!("encountered unmarked API: {:?}", def_id));+        })+    }++    /// Checks if an item is stable or error out.+    ///+    /// If the item defined by `def_id` is unstable and the corresponding `#![feature]` does not+    /// exist, emits an error.+    ///+    /// This function will also check if the item is deprecated.+    /// If so, and `id` is not `None`, a deprecated lint attached to `id` will be emitted.+    ///+    /// The `unmarked` closure is called definitions without a stability annotation.+    /// This is needed for generic parameters, since they may not be marked when used in a staged_api crate.

This is mostly a repetition of the above comment so far.

    /// Like `check_stability`, except that we permit items to have custom behaviour for
    /// missing stability attributes (not necessarily just emit a `bug!`). This is necessary
    /// for default generic parameters, which only have stability attributes if they were
    /// added after the type on which they're defined.
Avi-D-coder

comment created time in a month

pull request commentrust-lang/rust

Explain exhaustive matching on {usize,isize} maximum values

Thanks!

@bors r+ rollup

JohnTitor

comment created time in a month

Pull request review commentrust-lang/rust

Convert more `DefId`s to `LocalDefId`s

 pub fn check_live_drops(tcx: TyCtxt<'tcx>, def_id: LocalDefId, body: &mir::Body<         return;     } -    let ccx = ConstCx {-        body,-        tcx,-        def_id: def_id.to_def_id(),-        const_kind,-        param_env: tcx.param_env(def_id),-    };+    let ccx = ConstCx { body, tcx, def_id: def_id, const_kind, param_env: tcx.param_env(def_id) };
    let ccx = ConstCx { body, tcx, def_id, const_kind, param_env: tcx.param_env(def_id) };
lcnr

comment created time in a month

pull request commentrust-lang/rust

Stability annotations on generic parameters (take 2)

After https://github.com/rust-lang/rust/pull/72314#discussion_r449689675 and https://github.com/rust-lang/rust/pull/72314#discussion_r449764210, I'll review the tests, and then I think we're close to done!

Avi-D-coder

comment created time in a month

Pull request review commentrust-lang/rust

Stability annotations on generic parameters (take 2)

 impl<'a, 'tcx> Annotator<'a, 'tcx> {         attrs: &[Attribute],         item_sp: Span,         kind: AnnotationKind,+        inherit_deprecation: bool,

I suppose we don't usually have nested items that individually support stability attributes, so this problem usually doesn't occur. Okay, I'm happy passing this around as a flag, though perhaps an enum would be better:

enum InheritDeprecation {
	Yes,
	No,
}

Then you can add a comment to InheritDeprecation explaining why this is necessary.

Avi-D-coder

comment created time in a month

issue commentrust-lang/rust

non-exhaustive patterns false positive

I think the relevant concerns arose in the RFC thread (from this comment up). The overview is that we ought not to make assumptions about pointer sizes on the target platform, because they're not guaranteed to be fixed, so this could cause compatibility issues.

leonardo-m

comment created time in a month

issue commentrust-lang/rust

non-exhaustive patterns false positive

I'm not sure the feature is ever going to be stabilised, because there are concerns that this isn't a desirable feature. But hopefully the diagnostics will at least be improved in https://github.com/rust-lang/rust/pull/73937.

leonardo-m

comment created time in a month

Pull request review commentrust-lang/rust

Stability annotations on generic parameters (take 2)

 impl<'tcx> TyCtxt<'tcx> {     /// Additionally, this function will also check if the item is deprecated. If so, and `id` is     /// not `None`, a deprecated lint attached to `id` will be emitted.     pub fn check_stability(self, def_id: DefId, id: Option<HirId>, span: Span) {+        self.check_stability_internal(def_id, id, span, true, |span, def_id| {

Hmm, so the issue is that generic parameters are the only language feature that has optional stability: everything else is either not a staged_api item, or is either explicitly marked stable or unstable. Maybe we could call this function check_optional_stability or something like that, and give the reason why we want it (i.e. specifically mention the case of generic parameters).

Avi-D-coder

comment created time in a month

Pull request review commentrust-lang/rust

Stability annotations on generic parameters (take 2)

 impl<'a, 'tcx> Annotator<'a, 'tcx> {         attrs: &[Attribute],         item_sp: Span,         kind: AnnotationKind,+        inherit_deprecation: bool,

Remind me what happens if we inherit deprecation for generic parameters?

Avi-D-coder

comment created time in a month

pull request commentrust-lang/rust

Add `format_args_capture` feature

Thanks. @bors r+

I couldn't find such a cfg flag - do you think it would be worth me opening a PR to implement it?

I'm not sure what use-cases this would have other than for tests. Maybe you could open up an issue if you can think of others, though?

davidhewitt

comment created time in a month

pull request commentrust-lang/rust

add `lazy_normalization_consts` feature gate

r=me with comment fixed.

lcnr

comment created time in a month

Pull request review commentrust-lang/rust

add `lazy_normalization_consts` feature gate

 declare_features! (     /// Be more precise when looking for live drops in a const context.     (active, const_precise_live_drops, "1.46.0", Some(73255), None), +    /// Lazily evaluate constants. Which allows constants to depend on type parameters.
    /// Lazily evaluate constants. This allows constants to depend on type parameters.
lcnr

comment created time in a month

Pull request review commentrust-lang/rust

Explain exhaustive matching on {usize,isize} maximum values

 fn check_exhaustive<'p, 'tcx>(          possibly by adding wildcards or more match arms",     );     err.note(&format!("the matched value is of type `{}`", scrut_ty));+    if (scrut_ty == cx.tcx.types.usize || scrut_ty == cx.tcx.types.isize)+        && joined_patterns == "`_`"+    {+        err.note("for `usize` and `isize`, no assumptions about the maximum value are permitted");

How about only having a single note, with something like:

`usize` does not have a fixed maximum value, so a wildcard `_` is necessary  to match exhaustively
JohnTitor

comment created time in a month

Pull request review commentrust-lang/rust

Explain exhaustive matching on {usize,isize} maximum values

 fn check_exhaustive<'p, 'tcx>(          possibly by adding wildcards or more match arms",     );     err.note(&format!("the matched value is of type `{}`", scrut_ty));+    if (scrut_ty == cx.tcx.types.usize || scrut_ty == cx.tcx.types.isize)+        && joined_patterns == "`_`"+    {+        err.note("for `usize` and `isize`, no assumptions about the maximum value are permitted");

It'd be even better to only trigger these warnings if the entire range was covered, but that's probably unnecessary.

JohnTitor

comment created time in a month

Pull request review commentrust-lang/rust

Explain exhaustive matching on {usize,isize} maximum values

 fn check_exhaustive<'p, 'tcx>(          possibly by adding wildcards or more match arms",     );     err.note(&format!("the matched value is of type `{}`", scrut_ty));+    if (scrut_ty == cx.tcx.types.usize || scrut_ty == cx.tcx.types.isize)+        && joined_patterns == "`_`"+    {+        err.note("for `usize` and `isize`, no assumptions about the maximum value are permitted");

Maybe it would also be good to add:

if nightly_options::is_nightly_build() {
    err.help(&format!("add `#![feature(precise_pointer_size_matching)]` to the crate attributes to enable precise `usize` matching", feature));
}
JohnTitor

comment created time in a month

Pull request review commentrust-lang/rust

Explain exhaustive matching on {usize,isize} maximum values

 fn check_exhaustive<'p, 'tcx>(          possibly by adding wildcards or more match arms",     );     err.note(&format!("the matched value is of type `{}`", scrut_ty));+    if (scrut_ty == cx.tcx.types.usize || scrut_ty == cx.tcx.types.isize)+        && joined_patterns == "`_`"

It'd be better to match on witnesses instead of joined_patterns.

JohnTitor

comment created time in a month

issue commentrust-lang/rust

non-exhaustive patterns false positive

I hope to see that precise_pointer_size_matching implemented.

It already exists.

leonardo-m

comment created time in a month

issue commentzulip/zulip

Allow two streams to be merged

In this case, two users created a stream for an event, without realising they were duplicated. Various topics were then created in each one, before it was noticed. The subscribers were also different. In this case, the ideal behaviour would have been to make the two streams the same, merging the topics, and taking the union of the different users. I think this would make sense in general, though it could always be left as an option for the administrator when merging.

varkor

comment created time in a month

pull request commentrust-lang/rust

Add `format_args_capture` feature

You can add a comment to the relevant tests like this: https://github.com/rust-lang/rust/blob/f8b796b10b3282b02a6bb6f5b5be9dc8dc0dbf94/src/test/codegen/global_asm_include.rs#L37-L39

davidhewitt

comment created time in a month

issue commentzulip/zulip

Make it easier to mass-subscribe users to existing streams

:+1: (I saw #15186, but thought it covered a slightly different use case, because it doesn't allow users to be unselected before subscribing them.)

varkor

comment created time in a month

pull request commentrust-lang/rust

WF-check all ty::Const's, not just array lengths.

Const generics would be unsound without this check. However, there should be a way to modify the code slightly to make these now-failing examples work: it's just that we haven't worked out the right way to do it yet. See this issue for more details: https://github.com/rust-lang/rust/issues/68436.

lcnr

comment created time in a month

pull request commentrust-lang/rust

Add `format_args_capture` feature

This looks good to me; thanks for the pull request!

@bors r+

davidhewitt

comment created time in a month

issue openedzulip/zulip

Make it easier to mass-subscribe users to existing streams

When creating a new stream, it is easy to add everyone, with a list of all users and Check/Uncheck buttons. However, the UI for editing membership of existing streams is different, and there seems to be no easy way to subscribe many users to existing streams. This could be mitigated by stream merging (https://github.com/zulip/zulip/issues/15634), but both features seem useful.

(I expect this to already have been reported somewhere, but I couldn't find it: apologies if this is a duplicate.)

created time in a month

issue openedzulip/zulip

Allow two streams to be merged

On occasion, two people have created separate streams regarding the same topic, and we wish to merge them. However, there doesn't seem to be any function for doing so. Perhaps if a stream name is changed to an existing stream name, the user can be asked if the two streams should really be merged?

created time in a month

issue commentrust-lang/rust

Split up files with `// ignore-tidy-filelength`

@alex-griffiths: that's an interesting observation. I think in these cases, it's not so important to split up the files, because the length doesn't pose an issue for comprehension. Anyone editing the file is going to be interested in one or two particular functions, which are well-isolated within the file, and wouldn't benefit from being in their own file. In some sense, files like these are "false positives", though I don't think we could automatically exclude them. The lint is really more for files with large functions, and interdependency that we want to make easier to navigate. Thanks for pointing this out!

varkor

comment created time in a month

Pull request review commentrust-lang/rust

Add `format_args_capture` feature

 impl<'a, 'b> Context<'a, 'b> {                         self.verify_arg_type(Exact(idx), ty)                     }                     None => {-                        let msg = format!("there is no argument named `{}`", name);-                        let sp = *self.arg_spans.get(self.curpiece).unwrap_or(&self.fmtsp);-                        let mut err = self.ecx.struct_span_err(sp, &msg[..]);-                        err.emit();+                        let capture_feature_enabled = self+                            .ecx+                            .ecfg+                            .features+                            .map_or(false, |features| features.format_args_capture);++                        // For the moment capturing variables from format strings expanded from macros is+                        // disabled (see RFC #2795)+                        let can_capture = capture_feature_enabled && self.is_literal;++                        if can_capture {+                            // Treat this name as a variable to capture from the surrounding scope+                            let idx = self.args.len();+                            self.arg_types.push(Vec::new());+                            self.arg_unique_types.push(Vec::new());+                            self.args.push(+                                self.ecx.expr_ident(self.fmtsp, Ident::new(name, self.fmtsp)),+                            );+                            self.names.insert(name, idx);+                            self.verify_arg_type(Exact(idx), ty)+                        } else {+                            let msg = format!("there is no argument named `{}`", name);+                            let sp = if self.is_literal {+                                *self.arg_spans.get(self.curpiece).unwrap_or(&self.fmtsp)+                            } else {+                                self.fmtsp+                            };+                            let mut err = self.ecx.struct_span_err(sp, &msg[..]);++                            if capture_feature_enabled && !self.is_literal {+                                err.note(&format!(+                                    "did you intend to capture a variable `{}` from \+                                     the surrounding scope?",+                                    name+                                ));+                                err.note(+                                    "to avoid ambiguity format_args! cannot capture variables \
                                    "to avoid ambiguity, `format_args!` cannot capture variables \
davidhewitt

comment created time in a month

Pull request review commentrust-lang/rust

Stability annotations on generic parameters (take 2)

 impl<'tcx> TyCtxt<'tcx> {     /// If `id` is `Some(_)`, this function will also check if the item at `def_id` has been     /// deprecated. If the item is indeed deprecated, we will emit a deprecation lint attached to     /// `id`.-    pub fn eval_stability(self, def_id: DefId, id: Option<HirId>, span: Span) -> EvalResult {+    pub fn eval_stability(+        self,+        def_id: DefId,+        id: Option<HirId>,+        span: Span,+        check_deprecation: bool,

Okay, let's remove this special casing for now, and we can revisit it if it occurs again. Unless we have a concrete test case demonstrating it, I'd prefer simpler behaviour.

Avi-D-coder

comment created time in a month

Pull request review commentrust-lang/rust

Stability annotations on generic parameters (take 2)

 impl<'tcx> TyCtxt<'tcx> {     /// If `id` is `Some(_)`, this function will also check if the item at `def_id` has been     /// deprecated. If the item is indeed deprecated, we will emit a deprecation lint attached to     /// `id`.-    pub fn eval_stability(self, def_id: DefId, id: Option<HirId>, span: Span) -> EvalResult {+    pub fn eval_stability(+        self,+        def_id: DefId,+        id: Option<HirId>,+        span: Span,+        check_deprecation: bool,

Why do we not always want to check deprecation?

Avi-D-coder

comment created time in a month

more