profile
viewpoint
Martin Carton mcarton Eindhoven, Netherland

arthaud/moc 5

Micro Objective-C compiler

mcarton/CRAPS-Kernel 4

A simple operating system, processor and compiler for Nexys2

arthaud/egg 2

Extended Generator Generator

arthaud/GRO 1

Dépôt pour les cours et TP de « Graphes et Recherche Opérationnelle » en seconde année à l'ENSEEIHT.

arthaud/raytracer 1

A simple raytracer made in Java.

mcarton/interwiki 1

A script to change URL in your browser

mcarton/apply_attr 0

A syntax extension providing higher-order attributes to Rust.

issue commentrust-lang/rust

Regression from 1.44 to 1.45

With beta or nightly this again prints 13 as expected.

mcarton

comment created time in 10 days

issue openedrust-lang/rust

Regression from 1.44 to 1.45

The following MVE prints 42 with rustc 1.45.0 but 13 with rustc 1.44.0

struct Foo {
    x: i32,
}

fn main() {
    let mut foo = Foo { x: 42 };
    let x = &mut foo.x;
    *x = 13;
    let y = foo;
    println!("{}", y.x); // -> 42; expected result: 13
}

Initially reported on Stack Overflow.

created time in 10 days

startedrust-lang/rfcs

started time in 19 days

issue openedrust-analyzer/rust-analyzer

Bad hints and pop-up for `for` loops

It looks like the for loop could get some love:

Here is an example with VS Code:

  1. First, a useless hint appears: image

  2. When I type space, my cursor is teleported: image

  3. After I type i, it's teleported back, and the hint is replaced by an equally useless pop-up: image

  4. After I type n, the hint is back teleporting the cursor again, and the pop-up is slightly different: image

  5. Another space and the pop-up disappears: image

The constant back and forth of the cursor and the dialogs is rather annoying. Neither the hint nor the dialog seem very useful in this case.

(I couldn't find a similar issue, GitHub's search isn't really good with common keywords such as "for" and "hint". Sorry if this was already reported.)

created time in a month

issue openedtokio-rs/tracing

Unknown arguments to `#[instrument]` are ignored

Bug Report

Version

└── tracing v0.1.15
    ├── tracing-attributes v0.1.8
    └── tracing-core v0.1.10

Crates

  • tracing-attributes

Description

I made the mistake to use

#[instrument(foo="bar", id=1, show=true)]
fn foo() {}
#[instrument(fields(foo="bar", id=1, show=true))]
//           ^^^^^^^                          ^
fn foo() {}

This is silently accepted by the attribute, but does nothing. I'd expect an error that foo, id and show don't exist, with a possible suggestion to use fields.

created time in a month

Pull request review commentrust-lang/rust-clippy

Remove `bar` from blacklisted names

 macro_rules! define_Conf { pub use self::helpers::Conf; define_Conf! {

I would explain in the documentation why "bar" isn't in that list, as it's a well-known list and I wouldn't be surprised if someone raised the issue or opened a PR to readd it "because we forgot about it".

ijijn

comment created time in 2 months

issue openedunicode-rs/unicode-security

404 for documentation

The documentation link gives a 404: https://unicode-rs.github.io/unicode-security

created time in 2 months

Pull request review commentrust-lang/rfcs

Inline `const` expressions and patterns

+- Feature Name: `inline_const`+- Start Date: 2020-04-30+- RFC PR: [rust-lang/rfcs#2920](https://github.com/rust-lang/rfcs/pull/2920)+- Rust Issue: TBD++# Summary+[summary]: #summary++Adds a new syntactical element called an "inline `const`", written as+`const { ... }`, which instructs the compiler to execute the contents of the+block at compile-time. An inline `const` can be used as an expression or+anywhere in a pattern where a named `const` would be allowed.++```rust+use std::net::Ipv6Addr;++fn mock_ip(use_localhost: bool) -> &'static Ipv6Addr {+    if use_localhost {+        &Ipv6Addr::LOCALHOST+    } else {+        const { &Ipv6Addr::new(0x2001, 0xdb8, 0, 0, 0, 0, 0, 0) }+    }+}++fn main() {+    match *x {+        0 ..= const { u32::MAX / 2 } => println!("low"),+        const { u32::MAX / 2 + 1 } ..= u32::MAX => println!("high"),+    }+}+```++# Motivation+[motivation]: #motivation++Rust has `const` items, which are guaranteed to be initialized at compile-time.+Because of this, they can do things that normal variables cannot.  For example,+a reference in a `const` initializer has the `'static` lifetime, and a `const`+can be used as an array initializer even if the type of the array is not+`Copy` (with [RFC 2203]).++[RFC 2203]: https://github.com/rust-lang/rfcs/pull/2203++```rust+fn foo(x: &i32) -> &i32 {+    const ZERO: &'static i32 = &0;+    if *x < 0 { ZERO } else { x }+}+++fn foo() -> &u32 {+    const RANGE: Range<i32> = 0..5; // `Range` is not `Copy`+    let three_ranges = [RANGE; 3];+}+```++Writing out a `const` declaration everytime we need a long-lived reference or+a non-`Copy` array initializer can be annoying. To improve the situation,+[RFC 1414] introduced rvalue static promotion to extend lifetimes, and+[RFC 2203] extended the concept of promotion to array initializers.+As a result, the previous example can be written more concisely.++[RFC 1414]: https://github.com/rust-lang/rfcs/pull/2203++```rust+fn foo(x: &i32) -> &i32 {+    if *x < 0 { &0 } else { x }+}++fn foo() -> &u32 {+    let three_ranges = [0..5; 3];+}+```++However, the fact that we are executing the array initializer or expression+after the `&` at compile-time is not obvious to the user. To avoid violating+their assumptions, we are very careful to promote only in cases where the user+cannot possibly tell that their code is not executing at runtime. This means a+[long list of rules][prom-rules] for determining the promotability of expressions, and it+means expressions that call a `const fn` or that result in a type with a `Drop`+impl need to use a named `const` declaration.++[prom-rules]: https://github.com/rust-lang/const-eval/blob/master/promotion.md#promotability++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++This proposal is a middle ground, which is less verbose than named constants but+more obvious and expressive than promotion.++```rust+fn foo(x: &i32) -> &i32 {+  if *x < 0 { const { &4i32.pow(4) } } else { x }+}++fn foo() -> &u32 {0..5+    let three_ranges = [const { (0..=5).into_inner() }; 3];+}+```++With this extension to the language, users can ensure that their code executes+at compile-time without needing to declare a separate `const` item that is only+used once.++## Patterns++Patterns are another context that require a named `const` when using complex+expressions.  Unlike in the expression context, where promotion is sometimes+applicable, there is no other choice here.++```rust+fn foo(x: i32) {+    const CUBE: i32 = 3.pow(3);+    match x {+        CUBE => println!("three cubed"),+        _ => {}+    }+}+```++If that `const` is only used inside a single pattern, writing the code using an+inline `const` block makes it easier to scan.++```rust+fn foo(x: i32) {+    match x {+        const { 3.pow(3) } => println!("three cubed"),+        _ => {}+    }+}+```++# Reference-level explanation+[reference-level-explanation]: #reference-level-explanation++This RFC extends the [grammar for expressions] to be,++[grammar for expressions]: https://doc.rust-lang.org/stable/reference/expressions.html#expressions++> ```+> ExpressionWithBlock :+>    OuterAttribute*†+>    (+>         BlockExpression+>       | AsyncBlockExpression+>       | UnsafeBlockExpression+>       | ConstBlockExpression // new+>       | LoopExpression+>       | IfExpression+>       | IfLetExpression+>       | MatchExpression+>    )+>+> ConstBlockExpression: `const` BlockExpression // new+> ```++This RFC extends the [grammar for patterns] to be,++[grammar for patterns]: https://doc.rust-lang.org/stable/reference/patterns.html++> ```+> Pattern :+>      LiteralPattern+>    | IdentifierPattern+>    | WildcardPattern+>    | RangePattern+>    | ReferencePattern+>    | StructPattern+>    | TupleStructPattern+>    | TuplePattern+>    | GroupedPattern+>    | SlicePattern+>    | PathPattern+>    | MacroInvocation+>    | ConstBlockExpression // new+>+> RangePatternBound :+>      CHAR_LITERAL+>    | BYTE_LITERAL+>    | -? INTEGER_LITERAL+>    | -? FLOAT_LITERAL+>    | PathInExpression+>    | QualifiedPathInExpression+>    | ConstBlockExpression // new+> ```++In both the expression and pattern context, an inline `const` behaves exactly+as if the user had declared a uniquely identified `const` with the block's+contents as its initializer. For example, in expression context, writing+`const { ... }` is equivalent to writing:++```rust+{ const UNIQUE_IDENT: Ty = ...; UNIQUE_IDENT }+```++where `Ty` is inferred from the expression inside the braces.++An inline `const` is eligible for promotion in an implicit context (just like a+named `const`), so the following are all guaranteed to work:++```rust+let x: &'static i32 = &const { 4i32.pow(4) }; // NOT IDIOMATIC+let x: &'static i32 = const { &4i32.pow(4) }; // IDIOMATIC++// If RFC 2203 is stabilized+let v = [const { Vec::new() }; 3];  // IDIOMATIC+let v = const { [ Vec::new(); 3] }; // NOT IDIOMATIC+```++Whether to lint against the non idiomatic versions is an open question.+Personally, I would like to lint against `&const {...}` but not `const { [expr;+3] }`.++Inline `const`s are allowed within `const` and `static` initializers, just as we+currently allow nested `const` declarations. Whether to lint against inline+`const` expressions inside a `const` or `static` is also an open question.++# Drawbacks+[drawbacks]: #drawbacks++This excludes other uses of the `const` keyword in expressions and patterns.+I'm not aware of any other proposals that would take advantage of this.++This would also be the first use of type inference for const initializers. I'm+not aware of any technical issues that would arise from this, but perhaps I'm+overlooking something?++# Rationale and alternatives+[rationale-and-alternatives]: #rationale-and-alternatives++The main alternative is the status quo. Maintaining it will likely result in+promotion being used for more contexts. The lang-team decided to [explore this+approach](https://github.com/rust-lang/rust/pull/70042#issuecomment-612221597)+instead.++It would also possible to separate out the parts of this RFC relating to patterns+so that they can be decided upon seperately. I think they are similar enough+that they are best considered as a unit, however.++# Prior art+[prior-art]: #prior-art++I'm not aware of equivalents in other languages.++AFAIK, this was [first proposed] by @scottmcm.++[first proposed]: https://internals.rust-lang.org/t/quick-thought-const-blocks/7803/9++# Unresolved questions+[unresolved-questions]: #unresolved-questions++## Naming++I prefer the name inline `const`, since it signals that there is no difference+between a named `const` and an inline one. @scottmcm prefers "`const` block",+which is closer to the syntax and parallels the current terminology of `async`+block and `unsafe` block. It also avoids any accidental conflation with the+`#[inline]` attribute, which is unrelated.++## Lints++As mentioned in the reference-level specification, we need to decide whether we+want to lint against certain types of inline `const` expressions.++# Future possibilities+[future-possibilities]: #future-possibilities++It would be possible to allow the syntax `const expr` for an inline `const` that+consists of a single expression. This is analagous to the single expression+variant of closures: `|| 42`. This is backwards compatible with the current proposal.++This could allow us to deprecate the more esoteric classes of promotable+expressions (e.g., `&(u32::MAX + u32::MAX)`) in favor of inline `const`

This does not result in a const_err lint currently

Yes it does: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6ef001057822f9a1f070e973e5c3ff0f

But that still doesn't answer my first question: What makes this esoteric? What's "the more esoteric classes of promotable expressions" this sentence talks about?

ecstatic-morse

comment created time in 3 months

Pull request review commentrust-lang/rfcs

Inline `const` expressions and patterns

+- Feature Name: `inline_const`+- Start Date: 2020-04-30+- RFC PR: [rust-lang/rfcs#2920](https://github.com/rust-lang/rfcs/pull/2920)+- Rust Issue: TBD++# Summary+[summary]: #summary++Adds a new syntactical element called an "inline `const`", written as+`const { ... }`, which instructs the compiler to execute the contents of the+block at compile-time. An inline `const` can be used as an expression or+anywhere in a pattern where a named `const` would be allowed.++```rust+use std::net::Ipv6Addr;++fn mock_ip(use_localhost: bool) -> &'static Ipv6Addr {+    if use_localhost {+        &Ipv6Addr::LOCALHOST+    } else {+        const { &Ipv6Addr::new(0x2001, 0xdb8, 0, 0, 0, 0, 0, 0) }+    }+}++fn main() {+    match *x {+        0 ..= const { u32::MAX / 2 } => println!("low"),+        const { u32::MAX / 2 + 1 } ..= u32::MAX => println!("high"),+    }+}+```++# Motivation+[motivation]: #motivation++Rust has `const` items, which are guaranteed to be initialized at compile-time.+Because of this, they can do things that normal variables cannot.  For example,+a reference in a `const` initializer has the `'static` lifetime, and a `const`+can be used as an array initializer even if the type of the array is not+`Copy` (with [RFC 2203]).++[RFC 2203]: https://github.com/rust-lang/rfcs/pull/2203++```rust+fn foo(x: &i32) -> &i32 {+    const ZERO: &'static i32 = &0;+    if *x < 0 { ZERO } else { x }+}+++fn foo() -> &u32 {+    const RANGE: Range<i32> = 0..5; // `Range` is not `Copy`+    let three_ranges = [RANGE; 3];+}+```++Writing out a `const` declaration everytime we need a long-lived reference or+a non-`Copy` array initializer can be annoying. To improve the situation,+[RFC 1414] introduced rvalue static promotion to extend lifetimes, and+[RFC 2203] extended the concept of promotion to array initializers.+As a result, the previous example can be written more concisely.++[RFC 1414]: https://github.com/rust-lang/rfcs/pull/2203++```rust+fn foo(x: &i32) -> &i32 {+    if *x < 0 { &0 } else { x }+}++fn foo() -> &u32 {+    let three_ranges = [0..5; 3];+}+```++However, the fact that we are executing the array initializer or expression+after the `&` at compile-time is not obvious to the user. To avoid violating+their assumptions, we are very careful to promote only in cases where the user+cannot possibly tell that their code is not executing at runtime. This means a+[long list of rules][prom-rules] for determining the promotability of expressions, and it+means expressions that call a `const fn` or that result in a type with a `Drop`+impl need to use a named `const` declaration.++[prom-rules]: https://github.com/rust-lang/const-eval/blob/master/promotion.md#promotability++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++This proposal is a middle ground, which is less verbose than named constants but+more obvious and expressive than promotion.++```rust+fn foo(x: &i32) -> &i32 {+  if *x < 0 { const { &4i32.pow(4) } } else { x }+}++fn foo() -> &u32 {0..5
fn foo() -> &u32 {
ecstatic-morse

comment created time in 3 months

Pull request review commentrust-lang/rfcs

Inline `const` expressions and patterns

+- Feature Name: `inline_const`+- Start Date: 2020-04-30+- RFC PR: [rust-lang/rfcs#2920](https://github.com/rust-lang/rfcs/pull/2920)+- Rust Issue: TBD++# Summary+[summary]: #summary++Adds a new syntactical element called an "inline `const`", written as+`const { ... }`, which instructs the compiler to execute the contents of the+block at compile-time. An inline `const` can be used as an expression or+anywhere in a pattern where a named `const` would be allowed.++```rust+use std::net::Ipv6Addr;++fn mock_ip(use_localhost: bool) -> &'static Ipv6Addr {+    if use_localhost {+        &Ipv6Addr::LOCALHOST+    } else {+        const { &Ipv6Addr::new(0x2001, 0xdb8, 0, 0, 0, 0, 0, 0) }+    }+}++fn main() {+    match *x {+        0 ..= const { u32::MAX / 2 } => println!("low"),+        const { u32::MAX / 2 + 1 } ..= u32::MAX => println!("high"),+    }+}+```++# Motivation+[motivation]: #motivation++Rust has `const` items, which are guaranteed to be initialized at compile-time.+Because of this, they can do things that normal variables cannot.  For example,+a reference in a `const` initializer has the `'static` lifetime, and a `const`+can be used as an array initializer even if the type of the array is not+`Copy` (with [RFC 2203]).++[RFC 2203]: https://github.com/rust-lang/rfcs/pull/2203++```rust+fn foo(x: &i32) -> &i32 {+    const ZERO: &'static i32 = &0;+    if *x < 0 { ZERO } else { x }+}+++fn foo() -> &u32 {+    const RANGE: Range<i32> = 0..5; // `Range` is not `Copy`+    let three_ranges = [RANGE; 3];+}+```++Writing out a `const` declaration everytime we need a long-lived reference or+a non-`Copy` array initializer can be annoying. To improve the situation,+[RFC 1414] introduced rvalue static promotion to extend lifetimes, and+[RFC 2203] extended the concept of promotion to array initializers.+As a result, the previous example can be written more concisely.++[RFC 1414]: https://github.com/rust-lang/rfcs/pull/2203++```rust+fn foo(x: &i32) -> &i32 {+    if *x < 0 { &0 } else { x }+}++fn foo() -> &u32 {+    let three_ranges = [0..5; 3];+}+```++However, the fact that we are executing the array initializer or expression+after the `&` at compile-time is not obvious to the user. To avoid violating+their assumptions, we are very careful to promote only in cases where the user+cannot possibly tell that their code is not executing at runtime. This means a+[long list of rules][prom-rules] for determining the promotability of expressions, and it+means expressions that call a `const fn` or that result in a type with a `Drop`+impl need to use a named `const` declaration.++[prom-rules]: https://github.com/rust-lang/const-eval/blob/master/promotion.md#promotability++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++This proposal is a middle ground, which is less verbose than named constants but+more obvious and expressive than promotion.++```rust+fn foo(x: &i32) -> &i32 {+  if *x < 0 { const { &4i32.pow(4) } } else { x }+}++fn foo() -> &u32 {0..5+    let three_ranges = [const { (0..=5).into_inner() }; 3];+}+```++With this extension to the language, users can ensure that their code executes+at compile-time without needing to declare a separate `const` item that is only+used once.++## Patterns++Patterns are another context that require a named `const` when using complex+expressions.  Unlike in the expression context, where promotion is sometimes+applicable, there is no other choice here.++```rust+fn foo(x: i32) {+    const CUBE: i32 = 3.pow(3);+    match x {+        CUBE => println!("three cubed"),+        _ => {}+    }+}+```++If that `const` is only used inside a single pattern, writing the code using an+inline `const` block makes it easier to scan.++```rust+fn foo(x: i32) {+    match x {+        const { 3.pow(3) } => println!("three cubed"),+        _ => {}+    }+}+```++# Reference-level explanation+[reference-level-explanation]: #reference-level-explanation++This RFC extends the [grammar for expressions] to be,++[grammar for expressions]: https://doc.rust-lang.org/stable/reference/expressions.html#expressions++> ```+> ExpressionWithBlock :+>    OuterAttribute*†+>    (+>         BlockExpression+>       | AsyncBlockExpression+>       | UnsafeBlockExpression+>       | ConstBlockExpression // new+>       | LoopExpression+>       | IfExpression+>       | IfLetExpression+>       | MatchExpression+>    )+>+> ConstBlockExpression: `const` BlockExpression // new+> ```++This RFC extends the [grammar for patterns] to be,++[grammar for patterns]: https://doc.rust-lang.org/stable/reference/patterns.html++> ```+> Pattern :+>      LiteralPattern+>    | IdentifierPattern+>    | WildcardPattern+>    | RangePattern+>    | ReferencePattern+>    | StructPattern+>    | TupleStructPattern+>    | TuplePattern+>    | GroupedPattern+>    | SlicePattern+>    | PathPattern+>    | MacroInvocation+>    | ConstBlockExpression // new+>+> RangePatternBound :+>      CHAR_LITERAL+>    | BYTE_LITERAL+>    | -? INTEGER_LITERAL+>    | -? FLOAT_LITERAL+>    | PathInExpression+>    | QualifiedPathInExpression+>    | ConstBlockExpression // new+> ```++In both the expression and pattern context, an inline `const` behaves exactly+as if the user had declared a uniquely identified `const` with the block's+contents as its initializer. For example, in expression context, writing+`const { ... }` is equivalent to writing:++```rust+{ const UNIQUE_IDENT: Ty = ...; UNIQUE_IDENT }+```++where `Ty` is inferred from the expression inside the braces.++An inline `const` is eligible for promotion in an implicit context (just like a+named `const`), so the following are all guaranteed to work:++```rust+let x: &'static i32 = &const { 4i32.pow(4) }; // NOT IDIOMATIC+let x: &'static i32 = const { &4i32.pow(4) }; // IDIOMATIC++// If RFC 2203 is stabilized+let v = [const { Vec::new() }; 3];  // IDIOMATIC+let v = const { [ Vec::new(); 3] }; // NOT IDIOMATIC+```++Whether to lint against the non idiomatic versions is an open question.+Personally, I would like to lint against `&const {...}` but not `const { [expr;+3] }`.++Inline `const`s are allowed within `const` and `static` initializers, just as we+currently allow nested `const` declarations. Whether to lint against inline+`const` expressions inside a `const` or `static` is also an open question.++# Drawbacks+[drawbacks]: #drawbacks++This excludes other uses of the `const` keyword in expressions and patterns.+I'm not aware of any other proposals that would take advantage of this.++This would also be the first use of type inference for const initializers. I'm+not aware of any technical issues that would arise from this, but perhaps I'm+overlooking something?++# Rationale and alternatives+[rationale-and-alternatives]: #rationale-and-alternatives++The main alternative is the status quo. Maintaining it will likely result in+promotion being used for more contexts. The lang-team decided to [explore this+approach](https://github.com/rust-lang/rust/pull/70042#issuecomment-612221597)+instead.++It would also possible to separate out the parts of this RFC relating to patterns+so that they can be decided upon seperately. I think they are similar enough+that they are best considered as a unit, however.++# Prior art+[prior-art]: #prior-art++I'm not aware of equivalents in other languages.++AFAIK, this was [first proposed] by @scottmcm.++[first proposed]: https://internals.rust-lang.org/t/quick-thought-const-blocks/7803/9++# Unresolved questions+[unresolved-questions]: #unresolved-questions++## Naming++I prefer the name inline `const`, since it signals that there is no difference+between a named `const` and an inline one. @scottmcm prefers "`const` block",+which is closer to the syntax and parallels the current terminology of `async`+block and `unsafe` block. It also avoids any accidental conflation with the+`#[inline]` attribute, which is unrelated.++## Lints++As mentioned in the reference-level specification, we need to decide whether we+want to lint against certain types of inline `const` expressions.++# Future possibilities+[future-possibilities]: #future-possibilities++It would be possible to allow the syntax `const expr` for an inline `const` that+consists of a single expression. This is analagous to the single expression+variant of closures: `|| 42`. This is backwards compatible with the current proposal.++This could allow us to deprecate the more esoteric classes of promotable+expressions (e.g., `&(u32::MAX + u32::MAX)`) in favor of inline `const`

Is this esoteric only because it gives a const_err message? What does this proposal do in this case?

ecstatic-morse

comment created time in 3 months

more