profile
viewpoint
Vadim Petrochenkov petrochenkov Moscow, Russia

petrochenkov/cargo 0

The Rust package manager

petrochenkov/cbindgen 0

A project for generating C bindings from Rust code

petrochenkov/ccache 0

ccache – a fast compiler cache

petrochenkov/cmake-rs 0

Rust build dependency for running cmake

petrochenkov/dynamorio 0

Dynamic Instrumentation Tool Platform

petrochenkov/highfive 0

Github hooks to provide an encouraging atmosphere for new contributors

petrochenkov/reference 0

The Rust Reference

petrochenkov/rfcs 0

RFCs for changes to Rust

petrochenkov/rls 0

Repository for the Rust Language Server (aka RLS)

PR opened eqrion/cbindgen

Support an annotation for generating bitfield sizes in C code (`: SIZE`)

Closes https://github.com/eqrion/cbindgen/issues/609

The first commit is a relatively large refactoring that turns (String, Type, Documentation) into a proper structure Field.

+314 -155

0 comment

19 changed files

pr created time in 2 hours

create barnchpetrochenkov/cbindgen

branch : bitfield

created branch time in 2 hours

issue openedeqrion/cbindgen

Document all supported `/// cbindgen:` annotations

Right now only few of them are mentioned in the docs, the remaining ones have to be discovered by grepping tests and source code.

created time in 2 hours

pull request commentrust-lang/rust

Add compiler support for LLVM's x86_64 ERMSB feature

@bors r+

josephlr

comment created time in 4 hours

pull request commentrust-lang/rust

Suggest that expressions that look like const generic arguments should be enclosed in brackets

r=me with commits squashed.

varkor

comment created time in 4 hours

push eventpetrochenkov/cbindgen

Vadim Petrochenkov

commit sha c74290ddd9190fa83d1ddae9c6b85ffbddfec8db

[WIP] Support generation of Cython bindings

view details

push time in 12 hours

Pull request review commentrust-lang/rust

Qualify `panic!` as `core::panic!`

 pub fn expand_assert<'cx>(     });     let args = P(MacArgs::Delimited(DelimSpan::from_single(sp), MacDelimiter::Parenthesis, tokens));     let panic_call = MacCall {-        path: Path::from_ident(Ident::new(sym::panic, sp)),+        path: Path {+            span: DUMMY_SP,+            segments: vec![+                PathSegment::from_ident(Ident::with_dummy_span(kw::PathRoot)),+                PathSegment::from_ident(Ident::with_dummy_span(sym::core)),+                PathSegment::from_ident(Ident::new(sym::panic, sp)),+            ],+            tokens: None,+        },

Built-in macros use a function called std_path for paths pointing to the standard library, no need to hand-roll it.

camelid

comment created time in 16 hours

PullRequestReviewEvent

pull request commentrust-lang/rust

WIP: Compile rustc crates with the initial-exec TLS model

@bjorn3

If you tell the linker about the storage model instead of LLVM it should rewrite all TLS accesses to use that storage model I think.

How do you do that? I can't find any options on ld doc page that look relevant, at least by searching for thread/tls/etc.

joshtriplett

comment created time in 17 hours

pull request commenteqrion/cbindgen

[WIP] Support generation of Cython bindings

Status update:

  • The whole test suite passes.

Remaining items:

  • [ ] Figure out why cython is mad when its input file extension is .pxd.
  • [ ] Re-enable doc comments in the generated files.
  • [ ] Add some docs.
  • [ ] Cleanup code.
petrochenkov

comment created time in a day

push eventpetrochenkov/cbindgen

Vadim Petrochenkov

commit sha 30ad4c5ec981d2115b84ffd7161e233ad275d19f

[WIP] Support generation of Cython bindings

view details

push time in a day

push eventpetrochenkov/cbindgen

Vadim Petrochenkov

commit sha 64b0809c46306f7ca6b448369e22ab627d4f0d71

[WIP] Support generation of Cython bindings

view details

push time in a day

issue commentrust-lang/rust

What is a trailing expression in a block exactly?

@Aaron1011 I do not object, we can try making it an error if its use in practice is rare enough.

petrochenkov

comment created time in a day

Pull request review commentrust-lang/rust

Update RELEASES.md for 1.48.0

+Version 1.48.0 (2020-11-19)+==========================++Language+--------++- [The `unsafe` keyword is now syntactically permitted on modules.][75857] This+  is still rejected *semantically*, but can now be parsed by procedural macros.++Compiler+--------+- [Stabilised the `-C link=<yes|no>`][76158] Which tells `rustc` whether to link+  its own libraries or to rely on a external linker. (supported only on
  its own C runtime and libraries or to rely on a external linker to find them. (supported only on
XAMPPRocky

comment created time in a day

PullRequestReviewEvent

Pull request review commentrust-lang/rust

Update RELEASES.md for 1.48.0

+Version 1.48.0 (2020-11-19)+==========================++Language+--------++- [The `unsafe` keyword is now syntactically permitted on modules.][75857] This+  is still rejected *semantically*, but can now be parsed by procedural macros.++Compiler+--------+- [Stabilised the `-C link=<yes|no>`][76158] Which tells `rustc` whether to link
- [Stabilised the `-C link-self-contained=<yes|no>`][76158] Which tells `rustc` whether to link
XAMPPRocky

comment created time in a day

PullRequestReviewEvent

pull request commentrust-lang/rfcs

RFC: Plan to make core and std's panic identical.

Ok, what I want to convey is that keeping compiler simple and minimizing edition differences is more important that preventing a couple of obscure crates from breaking. That's how breaking bug fixes were treated historically and continue being treated now. Anyway, we need some reference breakage numbers from crater.

m-ou-se

comment created time in a day

push eventpetrochenkov/cbindgen

Vadim Petrochenkov

commit sha 910c9a28ed611b043592e8f7f7b20a3c73252e05

[WIP] Support generation of Cython bindings

view details

push time in a day

pull request commentrust-lang/rfcs

RFC: Plan to make core and std's panic identical.

Edit: Here's already a small preview of what crater will find: https://grep.app/search?q=panic%21%5C%28%5Cs%2A%5B%5E%5Cs%22%29%5D&regexp=true&filter[lang][0]=Rust

Nothing in the search looks like an incompatible use of a format string, in particular (panic!("{}") or panic!("{{")). So it's very possible that we can make behavior at least in this case (first argument is a string literal) identical.

m-ou-se

comment created time in a day

pull request commentrust-lang/rfcs

RFC: Plan to make core and std's panic identical.

However, that would break too much existing code.

[Citation needed]

I think the first thing that needs to be here is a crater run. Then we can break cases that are rare enough in practice (that may mean all of them).

m-ou-se

comment created time in a day

push eventpetrochenkov/cbindgen

Vadim Petrochenkov

commit sha 3182cf7e1e5acc8a4f10336d95c4317c9bc0cb97

[WIP] Support generation of Cython bindings

view details

push time in a day

push eventpetrochenkov/cbindgen

Vadim Petrochenkov

commit sha a045f90e83825b6ea254462fa2116fff0ef0ea20

[WIP] Support generation of Cython bindings

view details

push time in a day

issue openedeqrion/cbindgen

Support a cbindgen annotation for generating bitfield sizes in C code (`: SIZE`)

as described in https://github.com/eqrion/cbindgen/issues/608

struct S {
    #[cfg(not(feature = "cbindgen"))]
    foo_and_bar: u64,

    #[cfg(feature = "cbindgen")]
    /// cbindgen:bitfield="8"
    foo: u64,
    #[cfg(feature = "cbindgen")]
    /// cbindgen:bitfield="56"
    bar: u64,
}

will generate

struct S {
    uint64_t foo: 8;
    uint64_t bar: 56;
};

In general, the string passed to the annotation will be copypasted into the generated field code:

/// cbindgen:bitfield="BITFIELD_STRING"
name: Type,

=>

Type name: BITFIELD_STRING;

created time in 2 days

issue closedeqrion/cbindgen

Support splitting a field into multiple fields in a user-defined way

The title is a bit vague, so I'll give two use cases:

Use case 1: bitfields

struct S {
    /// cbindgen:???
    foo_and_bar: u64,
}

that should really turn into

struct S {
    uint8_t foo;
    uint64_t bar: 56;
};

, the Rust side doesn't uses bitfields just because Rust doesn't have them.

Use case 2: slices (#247)

struct S<'a> {
    /// cbindgen:???
    foos: &'a [Foo]
}

that should turn into

struct S {
    const Foo* foos;
    size_t foos_size;
};

@emilio I'm not sure at which abstraction level is this better solved.

  • In the first case we should replace the Rust field at the generated text level, because Rust doesn't have bitfields to provide a conversion source (but perhaps we can come up with a syntax extension for bitfields usable inside cbindgen doc comments?).
  • In the second case we'd want to perform the replacement at Rust level to keep the dependency on Foo because if "const Foo* foos;\nsize_t foos_size;" is substituted simply as a text, then the dependency on Foo will be lost.

(In this example the annotation is applied to fields, but the same idea of generic replacement is probably applicable to other entities as well.)

closed time in 2 days

petrochenkov

issue commenteqrion/cbindgen

Support splitting a field into multiple fields in a user-defined way

I'm going to close this issue since a solution for "splitting a field into multiple fields" was found, and open a new one for bitfield annotations.

petrochenkov

comment created time in 2 days

issue commenteqrion/cbindgen

Support splitting a field into multiple fields in a user-defined way

@emilio

Is their layout well-defined now?

With the cfg-based solution above it's not cbindgen who converts slices, so this is left under responsibility of the person who writes cfgs or annotations replacing slices with pointers and sizes. (I'm personally sure enough in their stability to use them in my project, others may think different.)

petrochenkov

comment created time in 2 days

issue commenteqrion/cbindgen

Support splitting a field into multiple fields in a user-defined way

Some update: supporting /// cbindgen:ignore on fields is not necessary, cfging things in and out with feature = "cbindgen" works good enough! cbindgen doesn't run compilation far enough to reach the missing field errors.

struct S {
    #[cfg(not(feature = "cbindgen"))]
    foo_and_bar: u64,
    #[cfg(feature = "cbindgen")]
    foo: u8,
    #[cfg(feature = "cbindgen")]
    /// cbindgen:bitfield=56
    bar: u64,
}

struct S<'a> {
    #[cfg(not(feature = "cbindgen"))]
    foos: &'a [Foo]
    #[cfg(feature = "cbindgen")]
    foos: *const Foo,
    #[cfg(feature = "cbindgen")]
    foos_size: usize,
}
petrochenkov

comment created time in 2 days

issue commenteqrion/cbindgen

Support splitting a field into multiple fields in a user-defined way

One alternative solution to this that I can think of is supporting /// cbindgen:ignore on fields (https://github.com/eqrion/cbindgen/pull/579) AND supporting annotations like /// cbindgen:bitfield=56 for generating bitfields.

Then the problems above would be solved by writing something like

struct S {
    /// cbindgen:ignore
    foo_and_bar: u64,
    #[cfg(feature = "cbindgen")]
    foo: u8,
    #[cfg(feature = "cbindgen")]
    /// cbindgen:bitfield=56
    bar: u64,
}

struct S<'a> {
    /// cbindgen:ignore
    foos: &'a [Foo]
    #[cfg(feature = "cbindgen")]
    foos: *const Foo,
    #[cfg(feature = "cbindgen")]
    foos_size: usize,
}
petrochenkov

comment created time in 2 days

issue openedeqrion/cbindgen

Support splitting a field into multiple fields in a user-defined way

The title is a bit vague, so I'll give two use cases:

Use case 1: bitfields

struct S {
    /// cbindgen:???
    foo_and_bar: u64,
}

that should really turn into

struct S {
    uint8_t foo;
    uint64_t bar: 56;
};

, the Rust side doesn't uses bitfields just because Rust doesn't have them.

Use case 2: slices

struct S<'a> {
    /// cbindgen:???
    foos: &'a [Foo]
}

that should turn into

struct S {
    const Foo* foos;
    size_t foos_size;
};

@emilio I'm not sure at which abstraction level is this better solved.

  • In the first case we should replace the Rust field at the generated text level, because Rust doesn't have bitfields to provide a conversion source (but perhaps we can come up with a syntax extension for bitfields usable inside cbindgen doc comments?).
  • In the second case we'd want to perform the replacement at Rust level to keep the dependency on Foo because if "const Foo* foos;\nsize_t foos_size;" is substituted simply as a text, then the dependency on Foo will be lost.

(In this example the annotation is applied to fields, but the same idea of generic replacement is probably applicable to other entities as well.)

created time in 2 days

pull request commentrust-lang/rust

Qualify `panic!` with `$crate::` in `core` macros

This PR reroutes majority of code that previously called std::panic to core::panic. We can only do this if core::panic and std::panic have identical interface and behavior in all case affected by the PR. cc @RalfJung @m-ou-se

camelid

comment created time in 2 days

push eventpetrochenkov/cbindgen

Vadim Petrochenkov

commit sha b4bc542cdc397cbe58a04d72fa02c129a2f38ac8

[WIP] Support generation of Cython bindings

view details

push time in 2 days

pull request commentrust-lang/rust

Suggest adding missing braces in `const` block pattern

@camelid parse_stmt_without_recovery or parse_item_kind probably, the goal is to get to the expression-parsing part in parse_stmt_without_recovery by returning None from parse_item_common, or never entering it.

camelid

comment created time in 2 days

pull request commentrust-lang/rust

Suggest adding missing braces in `const` block pattern

Something like self.look_ahead(1, |t| t.is_ident()) would work.

(Or self.look_ahead(1, |t| t.is_ident() && !t.is_reserved_ident() || t.is_keyword(kw::Underscore)) if less conservative.)

camelid

comment created time in 2 days

pull request commentrust-lang/rust

Compute proper module parent during resolution

@bors r+

Aaron1011

comment created time in 2 days

pull request commentrust-lang/rust

Suggest adding missing braces in `const` block pattern

@camelid I have a suggestion for a different approach for const in expressions. In expressions we have a well established precedent for general-purpose unary operators, including keyword-based ones like box.

So I suggest to parse const expr in expressions exactly like a unary operator box expr, but then report a non-fatal error if expr is not actually a block. The only difference would be an extra check at statement start to avoid interpreting const IDENT: ... or const _: ... items as const expressions.

In patterns we have the unary box operator too, so const recovery can potentially work in the same way as in expressions (parse const PAT, error if PAT is not a block), but I'm not sure about interactions with range patterns, they may require special cases.

camelid

comment created time in 2 days

pull request commentrust-lang/rust

resolve: Relax macro resolution consistency check to account for any errors

r? @eddyb

Ha-ha, no. r? @Aaron1011

petrochenkov

comment created time in 2 days

issue commentrust-lang/rust

ICE: panicked at 'compiler/rustc_resolve/src/macros.rs:892:21: inconsistent resolution for a macro'

Fixed in https://github.com/rust-lang/rust/pull/78327.

chengniansun

comment created time in 2 days

push eventpetrochenkov/rust

Vadim Petrochenkov

commit sha ef09ed200227207872b8e201d091681be3240c5b

resolve: Relax macro resolution consistency check to account for any errors

view details

push time in 2 days

PR opened rust-lang/rust

resolve: Relax macro resolution consistency check to account for any errors

The check was previously omitted only when ambiguity errors or Res::Err were encountered, but the "macro-expanded extern crate items cannot shadow..." error (at least) can cause same inconsistencies as well.

Fixes https://github.com/rust-lang/rust/issues/78325

+29 -4

0 comment

3 changed files

pr created time in 2 days

create barnchpetrochenkov/rust

branch : inconsist

created branch time in 2 days

pull request commentrust-lang/rust

Compute proper module parent during resolution

r=me with the test changes https://github.com/rust-lang/rust/pull/77984#discussion_r511489491

Aaron1011

comment created time in 2 days

Pull request review commentrust-lang/rust

Suggest that expressions that look like const generic arguments should be enclosed in brackets

 impl<'a> Parser<'a> {             }         }     }++    /// Handle encountering a symbol in a generic argument list that is not a `,` or `>`. In this+    /// case, we emit an error and try to suggest enclosing a const argument in braces if it looks+    /// like the user has forgotten them.+    pub fn handle_ambiguous_unbraced_const_arg(+        &mut self,+        args: &mut Vec<AngleBracketedArg>,+    ) -> PResult<'a, bool> {+        // If we haven't encountered a closing `>`, then the argument is malformed.+        // It's likely that the user has written a const expression without enclosing it+        // in braces, so we try to recover here.+        let arg = args.pop().unwrap();+        // FIXME: for some reason using `unexpected` or `expected_one_of_not_found` has+        // adverse side-effects to subsequent errors and seems to advance the parser.+        // We are causing this error here exclusively in case that a `const` expression+        // could be recovered from the current parser state, even if followed by more+        // arguments after a comma.+        let mut err = self.struct_span_err(+            self.token.span,+            &format!("expected one of `,` or `>`, found {}", super::token_descr(&self.token)),+        );+        err.span_label(self.token.span, "expected one of `,` or `>`");+        match self.recover_const_arg(arg.span(), err) {+            Ok(arg) => {+                args.push(AngleBracketedArg::Arg(arg));+                if self.eat(&token::Comma) {+                    return Ok(true); // Continue+                }+            }+            Err(mut err) => {+                args.push(arg);+                // We will emit a more generic error later.+                err.delay_as_bug();+            }+        }+        return Ok(false); // Don't continue.+    }++    /// Handle a generic const argument that had not been enclosed in braces, and suggest enclosing+    /// it braces. In this situation, unlike in `handle_ambiguous_unbraced_const_arg`, this is+    /// almost certainly a const argument, so we always offer a suggestion.+    pub fn handle_unambiguous_unbraced_const_arg(&mut self) -> PResult<'a, P<Expr>> {+        // FIXME(const_generics): to distinguish between idents for types and consts,+        // we should introduce a GenericArg::Ident in the AST and distinguish when+        // lowering to the HIR. For now, idents for const args are not permitted.+        let start = self.token.span;+        let expr = self.parse_expr_res(Restrictions::CONST_EXPR, None).map_err(|mut err| {+            err.span_label(+                start.shrink_to_lo(),+                "while parsing a `const` generic argument starting here",+            );+            err+        })?;+        let valid_const = match &expr.kind {+            ast::ExprKind::Block(_, _) | ast::ExprKind::Lit(_) => true,+            ast::ExprKind::Unary(ast::UnOp::Neg, expr) => match &expr.kind {+                ast::ExprKind::Lit(_) => true,

Ok, looks like this is a part of the reference parser logic, so it needs to be moved back from diagnostics.rs.

varkor

comment created time in 2 days

Pull request review commentrust-lang/rust

Suggest that expressions that look like const generic arguments should be enclosed in brackets

 use super::ty::AllowPlus;-use super::{BlockMode, Parser, PathStyle, SemiColonMode, SeqSep, TokenExpectType, TokenType};+use super::{+    BlockMode, Parser, PathStyle, Restrictions, SemiColonMode, SeqSep, TokenExpectType, TokenType,+};

Nit: could you avoid multi-line imports here and below?

varkor

comment created time in 2 days

Pull request review commentrust-lang/rust

Suggest that expressions that look like const generic arguments should be enclosed in brackets

 impl<'a> Parser<'a> {             }         }     }++    /// Handle encountering a symbol in a generic argument list that is not a `,` or `>`. In this+    /// case, we emit an error and try to suggest enclosing a const argument in braces if it looks+    /// like the user has forgotten them.+    pub fn handle_ambiguous_unbraced_const_arg(+        &mut self,+        args: &mut Vec<AngleBracketedArg>,+    ) -> PResult<'a, bool> {+        // If we haven't encountered a closing `>`, then the argument is malformed.+        // It's likely that the user has written a const expression without enclosing it+        // in braces, so we try to recover here.+        let arg = args.pop().unwrap();+        // FIXME: for some reason using `unexpected` or `expected_one_of_not_found` has+        // adverse side-effects to subsequent errors and seems to advance the parser.+        // We are causing this error here exclusively in case that a `const` expression+        // could be recovered from the current parser state, even if followed by more+        // arguments after a comma.+        let mut err = self.struct_span_err(+            self.token.span,+            &format!("expected one of `,` or `>`, found {}", super::token_descr(&self.token)),+        );+        err.span_label(self.token.span, "expected one of `,` or `>`");+        match self.recover_const_arg(arg.span(), err) {+            Ok(arg) => {+                args.push(AngleBracketedArg::Arg(arg));+                if self.eat(&token::Comma) {+                    return Ok(true); // Continue+                }+            }+            Err(mut err) => {+                args.push(arg);+                // We will emit a more generic error later.+                err.delay_as_bug();+            }+        }+        return Ok(false); // Don't continue.+    }++    /// Handle a generic const argument that had not been enclosed in braces, and suggest enclosing+    /// it braces. In this situation, unlike in `handle_ambiguous_unbraced_const_arg`, this is+    /// almost certainly a const argument, so we always offer a suggestion.+    pub fn handle_unambiguous_unbraced_const_arg(&mut self) -> PResult<'a, P<Expr>> {+        // FIXME(const_generics): to distinguish between idents for types and consts,+        // we should introduce a GenericArg::Ident in the AST and distinguish when+        // lowering to the HIR. For now, idents for const args are not permitted.

This FIXME is outdated.

varkor

comment created time in 2 days

Pull request review commentrust-lang/rust

Suggest that expressions that look like const generic arguments should be enclosed in brackets

 impl<'a> Parser<'a> {     /// Also performs recovery for `and` / `or` which are mistaken for `&&` and `||` respectively.     fn check_assoc_op(&self) -> Option<Spanned<AssocOp>> {         let (op, span) = match (AssocOp::from_token(&self.token), self.token.ident()) {+            // When parsing const expressions, stop parsing when encountering `>`.+            (+                Some(+                    AssocOp::ShiftRight+                    | AssocOp::Greater+                    | AssocOp::GreaterEqual+                    | AssocOp::AssignOp(token::BinOpToken::Shr),

Could you add a test in which these tokens are encountered in a const arg expression?

varkor

comment created time in 2 days

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentrust-lang/rust

Compute proper module parent during resolution

+const _: () = {+    #[path = "issue-75982-foo.rs"]+    mod foo;

I'd remove the path attribute and the file issue-75982-foo.rs at least. Also, it would be nice to have two macros - one directly in the const block, and one inside mod foo to test both cases.

Aaron1011

comment created time in 2 days

PullRequestReviewEvent

pull request commentrust-lang/rust

Split out statement attributes changes from #78306

@bors r+

Aaron1011

comment created time in 2 days

pull request commentrust-lang/rust

Suggest adding missing braces in `const` block pattern

@camelid Could you rebase this over https://github.com/rust-lang/rust/pull/78116? There were some significant changes in the same area in that PR.

camelid

comment created time in 2 days

pull request commentrust-lang/rust

Fix inconsistencies in handling of inert attributes on statements

r=me on the implementation.

Aaron1011

comment created time in 2 days

issue commentrust-lang/rust

Tracking issue for stmt_expr_attributes: Add attributes to expressions, etc.

@Aaron1011

There's an issue with how this applies to item statements.

Yes, that's

Expansion needs a rewrite (especially treatment of trailing expressions, #61733).

from https://github.com/rust-lang/rust/issues/15701#issuecomment-627818180. The treatment of semicolons is a big mess in particular.

Attributes on item statements should be treated as attributed on statements, and produce statements. (Basically, ast::Stmt should has an attrs field and those attrs need to be processed as any other attrs, with zero additional hackery.)

Right now such attributes are kind of passed through from statements to items and expanded as item attributes. I suspect this, like many other hacks, has something to deal with #[derive] and stabilization of macros 1.1 (derive only works on items, but it had to work on item statements).

brson

comment created time in 2 days

pull request commentrust-lang/rust

Unconditionally capture tokens for attributes.

@bors r+

Aaron1011

comment created time in 2 days

pull request commentrust-lang/rust

rustc_metadata: Deduplicate code between `encode_info_for_item`, `encode_info_for_foreign_item`, `encode_info_for_trait_item`, and `encode_info_for_impl_item`

I'm going to reassign this to r? @oli-obk who requested this change in https://github.com/rust-lang/rust/pull/77375#discussion_r498013190. With so few things shared and so many boolean flags passed, I'm not sure this is an improvement.

pitaj

comment created time in 2 days

pull request commentrust-lang/rust

TyCtxt: generate single impl block with `slice_interners` macro

@bors r+ rollup

bugadani

comment created time in 2 days

pull request commentrust-lang/rust

Add regression test for issue-77475

@bors r+ rollup

JohnTitor

comment created time in 4 days

issue commentrust-lang/rust

dynlib stopped building on nightly

@mati865 https://github.com/rust-lang/rust/pull/69519 introduced different defaults for crt-static for executables (yes) and proc-macros (no) (should apply to all dylibs really). If -C target-feature=+crt-static is specified explicitly, then the compiler respects it and overrides the defaults, that's the compiler's job.

Then cargo comes into play. AFAIK, it applies RUSTFLAGS only to target if --target specified explicitly, and to both target and host otherwise. (I remember people complaining about this inconsistency.) So it doesn't pass -C target-feature=+crt-static when compiling proc macro dependencies (which is correct in this case). I think this is a problem that should be solved at the cargo's abstraction level, in general. Cargo should provide a way to set compiler options per-crate-type and per-build-target (per-crate).

otavio

comment created time in 4 days

issue commentrust-lang/rust

`use dep1::foo as dep1` is considered ambiguous

@nikomatsakis Very simple, it only requires reverting https://github.com/rust-lang/rust/pull/77421.

I'd say that for the current implementation of resolve it's more natural to support it than to not support.

jmesmon

comment created time in 4 days

pull request commentrust-lang/rust

Rewrite `collect_tokens` implementations to use a flattened buffer

@Aaron1011 I'm still interested in trying splicing with the old token collection scheme.

Record a list of positions to allow us to traverse the topmost PreexpTokenStream to the proper position.

I don't think we need a list here, only a single number - index of the position in DFS traversal, or something similar to the number of next calls that you are counting here. Or a pointer to the group (in some sense, perhaps Lrc or something) + offset in the group.

Right now, we're collecting tokens in more cases than is strictly necessary (builtin attributes other than cfg, cfg_attr, and derive don't need tokens).

fn maybe_needs_tokens here is really a layering violation, we shouldn't look at attribute names during parsing, it's a name resolution's job. I wouldn't want to go further in this direction.

Aaron1011

comment created time in 5 days

pull request commentrust-lang/rust

Unconditionally capture tokens for attributes.

https://github.com/rust-lang/rust/pull/77250 has landed.

Aaron1011

comment created time in 5 days

pull request commentrust-lang/rust

Add `Item::from_inner` to reduce duplication in rustdoc

https://github.com/rust-lang/rust/pull/78077 has landed.

jyn514

comment created time in 5 days

push eventpetrochenkov/cbindgen

Vadim Petrochenkov

commit sha c434dbec25eec35fced0d9db1427186fe0ec4460

Add an option for converting usize/isize into size_t/ptrdiff_t

view details

push time in 5 days

PR opened eqrion/cbindgen

Add an option for converting usize/isize into size_t/ptrdiff_t

This PR adds a new global option usize_is_size_t that mirrors size_t_is_usize in bindgen and allows to map usize/isize into the more traditional pair size_t/ptrdiff_t instead of uintptr_t/intptr_t into which they are converted currently.

(I'd personally want to see this as the default, similarly to https://github.com/rust-lang/rust-bindgen/pull/1902, but I didn't change any defaults in this PR.)

cc https://github.com/eqrion/cbindgen/issues/239

+151 -40

0 comment

12 changed files

pr created time in 5 days

push eventpetrochenkov/cbindgen

Vadim Petrochenkov

commit sha 34f69ebf9579fadc8350fd8cb199f007d06ed1a0

Add an option for converting usize/isize into size_t/ptrdiff_t

view details

push time in 5 days

create barnchpetrochenkov/cbindgen

branch : size

created branch time in 5 days

pull request commentrust-lang/rust

Make inline const work in range patterns

r=me after squashing commits.

spastorino

comment created time in 5 days

push eventpetrochenkov/cbindgen

Vadim Petrochenkov

commit sha 9f00f6fdc579fa01783d4963480c9244a06231de

Remove artificial restriction on lifetime parameters on enums

view details

Vadim Petrochenkov

commit sha 3a7e24d2d784d447ed6fd9f7168eeafe19d0a98f

test suite: Do not generate identical expectation files

view details

Vadim Petrochenkov

commit sha 050863a249f765f56b70683b0f76b2361e388405

test suite: Remove existing duplicate expectation files

view details

Vadim Petrochenkov

commit sha 9b7cdfddb10dc4e7712dc752d77e9be73c362dc4

[WIP] Support generation of Cython bindings

view details

push time in 6 days

PR opened rust-lang/rust

[experiment] Implement `pub macro_rules`

This PR shows the amount of effort required to implement

    pub macro_rules! foo {
        ...
    }

which turns out to be... negative?

pub (or pub(...)) here makes the macro use regular module scoping (with specified visibility) instead of the traditional macro_rules scoping.

(This PR still needs a feature gate and more tests though.)

+18 -37

0 comment

4 changed files

pr created time in 6 days

create barnchpetrochenkov/rust

branch : pubrules

created branch time in 6 days

Pull request review commentrust-lang/rust

Make inline const work in range patterns

 impl<'a> Parser<'a> {     }      /// Is the token `dist` away from the current suitable as the start of a range patterns end?-    fn is_pat_range_end_start(&self, dist: usize) -> bool {+    fn is_pat_range_end_start(&mut self, dist: usize) -> bool {         self.look_ahead(dist, |t| {-            t.is_path_start() // e.g. `MY_CONST`;-                || t.kind == token::Dot // e.g. `.5` for recovery;-                || t.can_begin_literal_maybe_minus() // e.g. `42`.+            t.is_inline_const_start()+            || t.is_path_start() // e.g. `MY_CONST`;+            || t.kind == token::Dot // e.g. `.5` for recovery;+            || t.can_begin_literal_maybe_minus() // e.g. `42`.                 || t.is_whole_expr()         })     }      fn parse_pat_range_end(&mut self) -> PResult<'a, P<Expr>> {-        if self.check_path() {+        if self.check_inline_const() {+            self.parse_const_expr(self.token.span)

Semi-related: could you rename parse_const_expr into parse_const_block, this is a missing part of my old comment - https://github.com/rust-lang/rust/pull/77124#discussion_r494532128.

spastorino

comment created time in 6 days

Pull request review commentrust-lang/rust

Make inline const work in range patterns

+// build-pass++#![allow(incomplete_features)]+#![feature(inline_const)]+fn main() {+    const N: u32 = 10;+    let x: u32 = 3;++    match x {+        const { N - 1 } ..= 10 => {},+        _ => {},+    }++    match x {+        const { N - 1 } ..= const { N + 1 } => {},+        _ => {},+    }++    match x {+        1 ..= const { N - 1 } => {},+        _ => {},+    }

Could you add ..= const { .. } to test cases as well, so all range code paths are covered?

spastorino

comment created time in 6 days

Pull request review commentrust-lang/rust

Make inline const work in range patterns

 impl Token {         self == &Lt || self == &BinOp(Shl)     } +    pub fn is_inline_const_start(&self) -> bool {+        self.is_keyword(kw::Const)+    }

Could you always use check_inline_const instead of introducing new functions? You could add a dist: usize to it for the lookahead case (see fn is_keyword_ahead as an example.)

spastorino

comment created time in 6 days

Pull request review commentrust-lang/rust

Make inline const work in range patterns

 impl<'a> Parser<'a> {     }      /// Is the token `dist` away from the current suitable as the start of a range patterns end?-    fn is_pat_range_end_start(&self, dist: usize) -> bool {+    fn is_pat_range_end_start(&mut self, dist: usize) -> bool {
    fn is_pat_range_end_start(&self, dist: usize) -> bool {
spastorino

comment created time in 6 days

Pull request review commentrust-lang/rust

Make inline const work in range patterns

 impl<'a> Parser<'a> {             PatKind::Box(pat)         } else if self.check_inline_const() {             // Parse `const pat`-            PatKind::Lit(self.parse_const_expr(lo.to(self.token.span))?)+            let const_expr = self.parse_const_expr(lo.to(self.token.span))?;++            if let Some(re) = self.parse_range_end() {+                if !self.check(&token::FatArrow) {

I think parse_pat_range_begin_with is supposed to be used here. See how range end is treated in other cases (CONST .. <END> and 10 .. <END>).

spastorino

comment created time in 6 days

PullRequestReviewEvent
PullRequestReviewEvent

issue commenteqrion/cbindgen

References in enum fields not supported?

Fixed in https://github.com/eqrion/cbindgen/pull/604.

drlagos

comment created time in 6 days

PR opened eqrion/cbindgen

Remove artificial restriction on lifetime parameters on enums

Fixes https://github.com/eqrion/cbindgen/issues/485

+126 -16

0 comment

9 changed files

pr created time in 6 days

create barnchpetrochenkov/cbindgen

branch : enumlife

created branch time in 6 days

pull request commenteqrion/cbindgen

feat(ir) Add ability to ignore specific struct fields

I wanted to use this for a union like this:

union U {
    a: [u64; 2],
    b: u128,
}

cbindgen cannot produce anything useful for u128, so it's ok to make this field unavailable from the C side while keeping all the other fields available. I guess I'll have use the "typical cbindgen workaround" instead.

/// cbindgen:ignore
union U {
    a: [u64; 2],
    b: u128,
}

union U_FFI {
    a: [u64; 2],
}
[export]
include = ["U_FFI"]
[export.rename]
U = "U_FFI"
Hywan

comment created time in 6 days

pull request commentrust-lang/rust

Inline const followups

@bors r+

spastorino

comment created time in 7 days

pull request commentrust-lang/rust

Compute proper module parent during resolution

So, the sad part here is that the Module in question is not actually a mod item, but any "module in resolve sense" aka "a container for named items", that includes blocks.

If

const _: () = {
    #[macro_export]
    macro_rules! my_macro {
        () => {};
    }
};

was written in the current crate, then get_module would indeed returned the constant's block (it would have ModuleKind::Block).

We don't track blocks for other crates, so we simply cannot produce a correct answer here. This situation is specific to #[macro_export] macros which have unique ability to be visible to other crates while being written in very internal locations.

So, returning the closest mod item is not really correct, but at least it doesn't ICEs. Thankfully, returning an incorrect parent module in this case shouldn't have any observable effect in theory (but it would be a different story if my_macro could use def-site hygiene).

Aaron1011

comment created time in 7 days

Pull request review commentrust-lang/rust

Compute proper module parent during resolution

 impl<'a> Resolver<'a> {                 .data                 .get_opt_name()                 .expect("given a DefId that wasn't a module");-            // This unwrap is safe since we know this isn't the root-            let parent = Some(self.get_module(DefId {++            let mut parent_id = DefId {+                krate: def_id.krate,                 index: def_key.parent.expect("failed to get parent for module"),-                ..def_id-            }));+            };+            // A module's immediate parent may not be a module+            // (e.g. `const _: () =  { #[path = "foo.rs"] mod foo; };`)+            // Walk up the tree until we hit a module or the crate root.+            while parent_id.index != CRATE_DEF_INDEX {
            while parent_id.index != CRATE_DEF_INDEX && self.cstore().def_kind(parent_id) != DefKind::Mod {
Aaron1011

comment created time in 7 days

Pull request review commentrust-lang/rust

Compute proper module parent during resolution

+const _: () = {+    #[path = "issue-75982-foo.rs"]+    mod foo;

mod here is a distraction, you could put the macro directly into the const block and it would ICE in the same way.

Aaron1011

comment created time in 7 days

PullRequestReviewEvent
PullRequestReviewEvent

push eventpetrochenkov/cbindgen

Vadim Petrochenkov

commit sha 4a9e13c10c2ec9ec9ca5a7a227dc2aa2887ea798

[WIP] Support generation of Cython bindings

view details

push time in 7 days

push eventpetrochenkov/cbindgen

Yury Mikhaylov

commit sha 4be2fb4598f73855193104e4d4b7f2b2ec9c5b27

Add missing function `with_style` to the Builder It's impossible to select desired style when cbindgen is configured from the build script.

view details

Emilio Cobos Álvarez

commit sha fbdad17dc630bd2e0cf7975c879a6738e3949074

ci: Remove clippy check. While useful sometimes, it doesn't have stability guarantees (so CI can break when new rust stable versions are released), and it can do suggestions that make us require newer rustc versions than needed, which is not ideal.

view details

Vadim Petrochenkov

commit sha c943a99194626c8247ae6f8d9c3143292b472087

CI: Add a minimum version check

view details

Vadim Petrochenkov

commit sha d09fe6b75380ac295c553ef05791f27eacf898a6

test suite: Use suffixes instead of directories for test variants

view details

Vadim Petrochenkov

commit sha 924170b89cb7f0ca538c3fa75f5bc9f58518f259

[WIP] Support generation of Cython bindings

view details

push time in 7 days

pull request commentrust-lang/rust

Tweak ui-tests structure

Thanks! Many of these similar directories appeared when run-pass tests were moved to the ui directory. @bors r+

JohnTitor

comment created time in 7 days

Pull request review commentrust-lang/rust

Inline const followups

 impl<'a> Parser<'a> {      fn check_inline_const(&mut self) -> bool {         self.check_keyword(kw::Const)-            && self.look_ahead(1, |t| t == &token::OpenDelim(DelimToken::Brace))+            && self.look_ahead(1, |t| match t.kind {+                token::Interpolated(ref nt) => match **nt {+                    token::NtBlock(..) => true,

const $block needs a test. Also matches! can be used here.

spastorino

comment created time in 7 days

PullRequestReviewEvent
PullRequestReviewEvent

push eventpetrochenkov/cbindgen

Vadim Petrochenkov

commit sha d09fe6b75380ac295c553ef05791f27eacf898a6

test suite: Use suffixes instead of directories for test variants

view details

Vadim Petrochenkov

commit sha f65fbfc3e9b2a45710629ed872191f553d53d97c

test suite: Do not generate identical expectation files

view details

Vadim Petrochenkov

commit sha 30090f927c9edb2865ad287bafca95848bf15c81

test suite: Remove existing duplicate expectation files

view details

push time in 7 days

pull request commentrust-lang/rust

Fix false positive for `unused_parens` lint

Thanks! @bors r+

aticu

comment created time in 7 days

pull request commentrust-lang/rust

Make inline const work in range patterns

r=me with additional test cases.

spastorino

comment created time in 7 days

Pull request review commentrust-lang/rust

Make inline const work in range patterns

+// build-pass++#![allow(incomplete_features)]+#![feature(inline_const)]+fn main() {+    const N: u32 = 10;+    let x: u32 = 3;++    match x {+        const { N - 1 } ..= 10 => {},+        _ => {},+    }++    match x {+        const { N - 1 } ..= const { N + 1 } => {},+        _ => {},+    }++    match x {+        1 ..= const { N - 1 } => {},+        _ => {},+    }

Could you add test cases for half-open ranges as well - const { N } .. and .. const { N }?

spastorino

comment created time in 7 days

more