profile
viewpoint
Vadim Petrochenkov petrochenkov Moscow, Russia

petrochenkov/cargo 0

The Rust package manager

petrochenkov/ccache 0

ccache – a fast compiler cache

petrochenkov/cmake-rs 0

Rust build dependency for running cmake

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)

petrochenkov/rust 0

a safe, concurrent, practical language

petrochenkov/rust-central-station 0

Rust building infrastructure

petrochenkov/rustc-guide 0

A guide to how rustc works and how to contribute to it.

petrochenkov/rustfmt 0

Format Rust code

pull request commentrust-lang/rust

O(log n) lookup of associated items by name

The second part of https://github.com/rust-lang/rust/pull/69072#issuecomment-586700971 still holds, we have a single canonical iteration order now, so in_(definition,arbitrary)_order could be removed thus simplifying the interface.

ecstatic-morse

comment created time in 30 minutes

Pull request review commentrust-lang/rust

O(log n) lookup of associated items by name

 impl AssocItem {     } } +#[repr(transparent)]+#[derive(Debug, Clone, Copy, HashStable)]+struct AssocItemByNameUnhygienic(ty::AssocItem);

It's somewhat weird to use a set with a comparator as a map, if we can use an actual map instead. This should be an implementation detail of OrderedIndexMultiMap, IMO. (Which can reuse all of the implementation of OrderedIndexMultiSet because they are pretty much equivalent Map<Key, T> ~ Set<(Key, T)>). The extra space for the Symbol key shouldn't be a big deal.

ecstatic-morse

comment created time in 32 minutes

Pull request review commentrust-lang/rust

O(log n) lookup of associated items by name

 impl AssocItem {     } } +/// A list of `ty::AssocItem`s in definition order that allows for efficient lookup by name.+///+/// When doing lookup by name, we try to postpone hygienic comparison for as long as possible since+/// it is relatively expensive. Instead, items are indexed by `Symbol` and hygienic comparison is+/// done only on items with the same name.+#[derive(Debug, Clone, PartialEq, HashStable)]+pub struct AssociatedItems {+    items_in_def_order: Vec<ty::AssocItem>,+    item_idx_in_name_order: Vec<usize>,

This commit contains a chunk of other removed commit.

ecstatic-morse

comment created time in 40 minutes

pull request commentrust-lang/rust

Fix race condition when allocating source files in SourceMap

cc @matklad

Zoxc

comment created time in 3 hours

pull request commentrust-lang/rust

Add lint when no doc is present at the crate-level

I still don't understand why you can't report existing missing_docs from rustdoc instead, https://github.com/rust-lang/rust/pull/66938#issuecomment-584684822 didn't answer any of my questions.

GuillaumeGomez

comment created time in 3 hours

pull request commentrust-lang/rust

[WIP] Cleanup `rmeta::MacroDef`

Remaining unresolved comments: https://github.com/rust-lang/rust/pull/66364#discussion_r357677628 https://github.com/rust-lang/rust/pull/66364#discussion_r377254283 https://github.com/rust-lang/rust/pull/66364#issuecomment-584317587

Centril

comment created time in a day

Pull request review commentrust-lang/rust

[WIP] Cleanup `rmeta::MacroDef`

 reemit_legacy! {     assert_source_file! { "Hello, world!" } } -say_hello_extern! { assert_fake_source_file }+say_hello_extern! { assert_source_file }

It's quite possible that proc macros are no longer "fake source files" either, since they keep their spans in metadata. I agree that we need to attempt making say_hello_extern a proc macro, and if assert_fake_source_file still fails, then remove the test case.

Centril

comment created time in a day

Pull request review commentrust-lang/rust

[WIP] Cleanup `rmeta::MacroDef`

  #[macro_export] macro_rules! produces_async {-    () => (pub fn async() {})+    () => {+        pub fn async() {}+    };

I didn't immediately figure out what eddyb meant in this commit, but it appears to be this diff:

-LL | () => (pub fn r#async () { })
+LL | r#async

Error reporting machinery no longer fetches the whole r#async's line for displaying, only the r#async itself.

Centril

comment created time in a day

pull request commentrust-lang/rust

[WIP] Cleanup `rmeta::MacroDef`

I indeed missed https://github.com/rust-lang/rust/pull/66364#issuecomment-584317587.

Looks like significant part of this PR can be landed without the primary change (if it's moved to a separate PR) - #[allow]s, is_macros -> is_imported, comments, get_macro, tests.

I'll get to the primary part this weekend, most probably.

Centril

comment created time in a day

pull request commentrust-lang/rust

parser: Simplify treatment of macro variables in `Parser::bump`

Updated.

petrochenkov

comment created time in a day

push eventpetrochenkov/rust

Steven Degutis

commit sha ac19dffd1eaea34c3861324c2588f9cb1f1489f5

Updating str.chars docs to mention crates.io. This might spare someone else a little time searching the stdlib for unicode/grapheme support.

view details

Mazdak Farrokhzad

commit sha cec2a9fad057f71fc640392ba3fa47602aea12f6

macro_legacy_warnings -> error

view details

Dylan MacKenzie

commit sha 5c473a059e26614b65414cfb8cf75c283cda5a87

Don't print block exit state if unchanged

view details

Vadim Petrochenkov

commit sha dcad07af8aa831344fd3be353c71379854637c21

parser: `macro_rules` is a weak keyword

view details

Amos Onn

commit sha 302b9e4b540cc352e75d3de6f803a99147107a50

Improve #Safety in various methods in core::ptr s/for reads and writes/for both ...

view details

Amos Onn

commit sha 351782d30aaa6e15204e17ecdd51ac1e712685cf

Improve #Safety of core::ptr::replace Added missing condition: `dst` must be readable

view details

Amos Onn

commit sha 40ca16794456e9b1520bba6d887a176395f127f0

Improve #Safety in various methods in core::ptr For all methods which read a value of type T, `read`, `read_unaligned`, `read_volatile` and `replace`, added missing constraint: The value they point to must be properly initialized

view details

Guillaume Gomez

commit sha cadf9efad123a62472cad45f22569747cc599256

Clean up E0309 explanation

view details

Camille GILLOT

commit sha d5691209b6d5fe5e47560b1db7b822dbeb0880fd

Move librustc/{traits,infer} to librustc_infer.

view details

Camille GILLOT

commit sha 187a9741d3cd63dd78571e2a0e08344aef05f51b

Make librustc compile.

view details

Camille GILLOT

commit sha f07e8891458259bb4373bb6aa59d158304f637b1

Make librustc_infer compile.

view details

Camille GILLOT

commit sha 4b57cb3cbed8674aa480bff450affa62ac6b75bf

Make librustc_typeck compile.

view details

Camille GILLOT

commit sha 1637aab15e175b5e0dc14947ffa946804420d414

Make librustc_mir compile.

view details

Camille GILLOT

commit sha 2519f4a0a336993fc2e494a194807c56060256b3

Make librustc_traits compile.

view details

Camille GILLOT

commit sha bee6a5ac1274201e7da2081a5aff6b3b1f407185

Other crates.

view details

Camille GILLOT

commit sha 795673ae2060198cdb09c6ded8d303c244dac6fd

Remove librustc_infer crate re-exports.

view details

Camille GILLOT

commit sha 0b93cfc1ee3d61987e9f3229370d79acd51544a1

Prune features.

view details

Camille GILLOT

commit sha 5d5720835329230c60cb7b4f56e2a9b234dae6cf

Gate macro use.

view details

Camille GILLOT

commit sha e88500b5e18bbbad2323944d3c23f8a4465eb147

Prune rustc dependencies.

view details

Amos Onn

commit sha 943e65396d7bc7b91bcc30407d323d06f4b20a22

Improve #Safety of core::ptr::drop_in_place Added missing conditions: - Valid for writes - Valid for destructing

view details

push time in a day

pull request commentrust-lang/rust

parse: fuse associated and extern items up to defaultness

@bors r+

Centril

comment created time in a day

Pull request review commentrust-lang/rust

parse: fuse associated and extern items up to defaultness

 pub type ForeignItem = Item<ForeignItemKind>; /// An item within an `extern` block. #[derive(Clone, RustcEncodable, RustcDecodable, Debug)] pub enum ForeignItemKind {-    /// A foreign function.-    Fn(FnSig, Generics, Option<P<Block>>),-    /// A foreign static item (`static ext: u8`).+    /// A static item (`static FOO: u8`).     Static(P<Ty>, Mutability),-    /// A foreign type.+    /// A function.

Ok, let's land this then.

Centril

comment created time in a day

Pull request review commentrust-lang/rust

parser: Simplify treatment of macro variables in `Parser::bump`

 impl<'a> Parser<'a> {         }     } -    pub fn process_potential_macro_variable(&mut self) {-        let normalized_token = match self.token.kind {-            token::Dollar-                if self.token.span.from_expansion() && self.look_ahead(1, |t| t.is_ident()) =>

I think I'll just remove the special diagnostic support for $ IDENT from this PR. I've filed https://github.com/rust-lang/rust/issues/69229 for a better fix.

petrochenkov

comment created time in a day

issue openedrust-lang/rust

parser: Implement recovery for potential unknown macro variables `$ IDENT`

https://github.com/rust-lang/rust/pull/69211 simplified parsing and fixed treatment of $ tokens coming from proc macros, but slightly regressed diagnostics.

If a declarative macro body contains something that looks like an unknown macro variable $ var, then it's preserved and outputted like two-token sequence punctuation $ and identifier var.

We previously tried to detect such sequences in Parser::bump, but the detection wasn't correct and wasn't done in the best way for recovery.

Instead, we need to support parsing the $ IDENT sequences in context dependent fashion, as an error expression in expression position, as an error type in type position etc.

Currently supported positions for macro variables (roughly in the order of importance):

  • [ ] expr
  • [ ] ty
  • [ ] pat
  • [ ] item
  • [ ] ident
  • [ ] lifetime
  • [ ] vis
  • [ ] path
  • [ ] block
  • [ ] literal
  • [ ] meta
  • [ ] stmt

It's quite possible that implementing this recovery for ident can successfully make implementing it for expr, ty, pat, path and meta unnecessary.

created time in a day

pull request commentrust-lang/rust

Transition macro_legacy_warnings into a hard error

@bors r+

Centril

comment created time in 2 days

pull request commentrust-lang/rust

Do not ICE when encountering `yield` inside `async` block

@bors r+ rollup

estebank

comment created time in 2 days

pull request commentrust-lang/rust

O(log n) lookup of associated items by name

@ecstatic-morse To clarify, it's not necessary to implement the whole multimap interface for this, only the basic parts needed for this PR (other parts can be added later on demand), but I'd still prefer it to live as a separate data structure in rustc_data_structures instead of rustc.

ecstatic-morse

comment created time in 2 days

pull request commentrust-lang/rust

parser: Simplify treatment of macro variables in `Parser::bump`

Added a couple more commits.

petrochenkov

comment created time in 2 days

push eventpetrochenkov/rust

Tobias Thiel

commit sha 51021b1d421a7d055ff44f9b6afe11377b825c5c

rustc_session: allow overriding lint level of individual lints from a group

view details

Tobias Thiel

commit sha 34417792deed6f0e570e9c7b01a24f1d05b70519

tools/compiletest: fix argument ordering for allowing unused in ui & compile-fail tests

view details

Tobias Thiel

commit sha 21edd2ae2cc4c06d8ea98051c47d24dc3c4e2238

convert match statement to if let

view details

Tobias Thiel

commit sha 3fc9253a5a27771c72429a738d5379c34e1cd924

rustc: add lint level cli ordering into the documentation

view details

John Kåre Alsaker

commit sha a7db5051d14994474c641328333884aeba70ca25

Treat NodeIs as pure values for incremental compilation

view details

John Kåre Alsaker

commit sha 8a37811e2c3b89beb135cf96dcb5d887a6262751

Panic when hashing node IDs

view details

bors

commit sha 116dff95a37214e86f067715374a18a4de1621f0

Auto merge of #68997 - Zoxc:pure-node-id, r=petrochenkov Panic if NodeIds are used for incremental compilation r? @michaelwoerister

view details

bors

commit sha 5e7af4669f80e5f682141f050193ab679afdb4b1

Auto merge of #67885 - tobithiel:fix_group_lint_allow_override, r=Mark-Simulacrum rustc_session: allow overriding lint level of individual lints from a group Fixes #58211 and fixes rust-lang/rust-clippy#4778 and fixes rust-lang/rust-clippy#4091 Instead of hard-coding the lint level preferences (from lowest to highest precedence: `lint::Allow -> lint::Warn -> lint::Deny -> lint::Forbid`), the position of the argument in the command line gets taken into account. Examples: 1. Passing `-D unused -A unused-variables` denies everything in the lint group `unused` **except** `unused-variables` which is explicitly allowed. 1. Passing `-A unused-variables -D unused` denies everything in the lint group `unused` **including** `unused-variables` since the allow is specified before the deny (and therefore overridden by the deny). This matches the behavior that is already being used when specifying `allow`/`deny` in the source code.

view details

Vadim Petrochenkov

commit sha a91cc79def804ec2a8bf297c94cf7c0c79166999

parser: Do not call `bump` recursively Token normalization is merged directly into `bump`. "Unknown macro variable" diagnostic for unexpected `$`s is moved to expected-found infra.

view details

Vadim Petrochenkov

commit sha ca778462a84e1036bdc79f69037612bbb9b936e8

parser: Set previous and unnormalized tokens in couple more places

view details

Vadim Petrochenkov

commit sha 777d218a35cab7bfa981119aef7c574f9131aa47

parser: Remove `Option`s from unnormalized tokens They are always set synchronously with normalized tokens now

view details

push time in 2 days

Pull request review commentrust-lang/rust

parser: Simplify treatment of macro variables in `Parser::bump`

 impl<'a> Parser<'a> {         }     } -    pub fn process_potential_macro_variable(&mut self) {-        let normalized_token = match self.token.kind {-            token::Dollar-                if self.token.span.from_expansion() && self.look_ahead(1, |t| t.is_ident()) =>

We certainly do not want to check expansion kinds (was this token produced by macro_rules or not) from parser, so the only choice is to not check for $ IDENT ahead of time and delay it until the time when it's actually unexpected (i.e. no https://github.com/rust-lang/rust/pull/69211#discussion_r379913103).

petrochenkov

comment created time in 2 days

pull request commentrust-lang/rust

O(log n) lookup of associated items by name

Damn. Do we have IndexMultiMap by chance? Perhaps we can get one if you move your implementation into rustc_data_structures and make it slightly more generic?

ecstatic-morse

comment created time in 2 days

Pull request review commentrust-lang/rust

parser: Simplify treatment of macro variables in `Parser::bump`

 impl<'a> Parser<'a> {         }     } -    pub fn process_potential_macro_variable(&mut self) {-        let normalized_token = match self.token.kind {-            token::Dollar-                if self.token.span.from_expansion() && self.look_ahead(1, |t| t.is_ident()) =>

Oh man, this from_expansion-based check is totally incorrect.

If we take passing test https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-40847.rs and imagine that gen!(m($var) $var); is produced by a proc macro, it will incorrectly fail with an "unknown macro variable" error.

petrochenkov

comment created time in 2 days

Pull request review commentrust-lang/rust

Implement unused crate lint for 2018 edition

 extern crate libc; #[macro_use] extern crate cfg_if; +// Suppress unused crate lints:+// when #[cfg(parallel_compiler)], there will be no uses+// of these crates+use rayon as _;+use crossbeam_utils as _;+use rayon_core as _;

Ok, parallel_compiler is not even a Cargo feature, it's passed directly to rustc by rustbuild.

Aaron1011

comment created time in 2 days

Pull request review commentrust-lang/rust

parser: Simplify treatment of macro variables in `Parser::bump`

 macro_rules! e {     ($inp:ident) => (         $nonexistent-        //~^ ERROR unknown macro variable `nonexistent`+        //~^ ERROR expected expression, found `$`

Or the old "unknown macro variable" can be put at the end of bump. Now when it separated from normalization it shouldn't mess up anything.

Ideally, unknown $var should be a "fatal" error propagated upwards, but bump doesn't currently return Result and changing that would be pretty invasive.

petrochenkov

comment created time in 2 days

Pull request review commentrust-lang/rust

parser: Simplify treatment of macro variables in `Parser::bump`

 macro_rules! e {     ($inp:ident) => (         $nonexistent-        //~^ ERROR unknown macro variable `nonexistent`+        //~^ ERROR expected expression, found `$`

Not all these diagnostics go through the generic expected-found infra, unfortunately, so those who do not will report something like this. These cases need to be migrated to expect_one_of or something similar, but I didn't do that.

petrochenkov

comment created time in 2 days

Pull request review commentrust-lang/rust

parser: Simplify treatment of macro variables in `Parser::bump`

 fn parse_nt(p: &mut Parser<'_>, sp: Span, name: Symbol) -> Nonterminal {     if name == sym::tt {         return token::NtTT(p.parse_token_tree());     }-    // check at the beginning and the parser checks after each bump-    p.process_potential_macro_variable();

These calls in MBE were unnecessary because process_potential_macro_variable was already performed in Parser::new.

petrochenkov

comment created time in 2 days

PR opened rust-lang/rust

parser: Simplify treatment of macro variables in `Parser::bump`

Follow-up to https://github.com/rust-lang/rust/pull/69006.

Token normalization for $ident and $lifetime is merged directly into bump. "Unknown macro variable" diagnostic for unexpected $s is moved to expected-found infra (as a result bump doesn't call itself recursively anymore and can't make prev_token inconsistent).

r? @Centril

+47 -53

0 comment

8 changed files

pr created time in 2 days

create barnchpetrochenkov/rust

branch : prevtok

created branch time in 2 days

pull request commentrust-lang/rust

Make macro metavars respect (non-)hygiene

This will has to wait for one more week, unfortunately. (The change is nontrivial, but not super urgent, so it ends up in in the end of my review queue for the second weekend in a row.)

matthewjasper

comment created time in 2 days

pull request commentrust-lang/rust

parse: fuse associated and extern items up to defaultness

To progress further, we must make a decision: should we parse e.g. default use foo::bar; and whatnot?

I think we can do the same thing as with visibilities in pub call::my_macro!();, always parse the default, but immediately report an error in the parser unless it's a fn, const or type.

Centril

comment created time in 2 days

Pull request review commentrust-lang/rust

parse: fuse associated and extern items up to defaultness

 impl ItemKind {     } } -pub type ForeignItem = Item<ForeignItemKind>;+pub type ForeignItem = Item<AssocItemKind>;+pub type ForeignItemKind = AssocItemKind;

Could you add a FIXME comment telling that these definitions will be "unmerged"?

Centril

comment created time in 2 days

Pull request review commentrust-lang/rust

parse: fuse associated and extern items up to defaultness

 pub type ForeignItem = Item<ForeignItemKind>; /// An item within an `extern` block. #[derive(Clone, RustcEncodable, RustcDecodable, Debug)] pub enum ForeignItemKind {-    /// A foreign function.-    Fn(FnSig, Generics, Option<P<Block>>),-    /// A foreign static item (`static ext: u8`).+    /// A static item (`static FOO: u8`).     Static(P<Ty>, Mutability),-    /// A foreign type.+    /// A function.

Can we deal with this once we have a single ItemKind and unified parsing and do the "fan-out" to #69194 (comment) at that point?

Do you plan to work on that in the near future?

Centril

comment created time in 2 days

pull request commentrust-lang/rust

O(log n) lookup of associated items by name

Using the IndexMap, providing a single iterator and getting rid of in_(definition,arbitrary)_order looks preferable. (The size of SmallVec should indeed be 1 in 99.9% of cases.)

ecstatic-morse

comment created time in 2 days

pull request commentrust-lang/rust

O(log n) lookup of associated items by name

it also defines the layout of vtables

Hmm, this is interesting. Predictable ABI is a good reason to keep the original order.

I actually had some doubts about the original order being preserved during AST -> HIR lowering (if not, then it wouldn't make much sense to preserve it later), it it turned out it's indeed preserved (see https://github.com/rust-lang/rust/pull/68814#issuecomment-586698849).

ecstatic-morse

comment created time in 2 days

pull request commentrust-lang/rust

Record proc macro harness order for use during metadata deserialization

I won't revert this PR since it had already landed, but the error was actually in the encoder.

tcx.hir().krate().items

=>

tcx.hir().krate().module.item_ids

Item order in HIR does repeat the item order in AST, Crate::items was just a wrong list to walk (it accumulates all items from all modules in the crate in semi-arbitrary order).

Aaron1011

comment created time in 2 days

pull request commentrust-lang/rust

Panic if NodeIds are used for incremental compilation

@bors r+ (If it passes through CI.)

Zoxc

comment created time in 2 days

Pull request review commentrust-lang/rust

WIP: Suggest similar type or module on resolve failure

 impl<'a> Resolver<'a> {          err.emit();     }++    crate fn make_undeclared_type_suggestion(+        &mut self,+        ident: Ident,+    ) -> (String, Option<Suggestion>) {+        let parent_scope = &ParentScope::module(self.graph_root);+        let typo_suggestion = self.early_lookup_typo_candidate(

You can make a single boolean

let use_early_resolution = ribs.is_none() || opt_ns.is_none() || opt_ns == Some(MacroNS);

in fn resolve_path_with_ribs and pass it as a whole to make_undeclared_type_suggestion.

It doesn't matter much, early_resolve_ident_in_lexical_scope and resolve_ident_in_lexical_scope need to be merged into a single function anyway.

phansch

comment created time in 2 days

pull request commentrust-lang/rust

Implement unused crate lint for 2018 edition

r? @petrochenkov

Aaron1011

comment created time in 2 days

pull request commentrust-lang/rust

Implement unused crate lint for 2018 edition

This seems significantly more complicated than it can be.

All crate resolutions go through a single point (CrateLoader::maybe_resolve_crate), so CrateLoader can keep a list of crate names requested by source code. If some name x is not in the list, then the corresponding option --extern x is unused.

The list is finalized after the self.crate_loader.postprocess(krate) call in fn resolve_crate, so all the reporting for unused --extern options can be done at that point without ever going to typeck.

Aaron1011

comment created time in 2 days

Pull request review commentrust-lang/rust

Implement unused crate lint for 2018 edition

 extern crate libc; #[macro_use] extern crate cfg_if; +// Suppress unused crate lints:+// when #[cfg(parallel_compiler)], there will be no uses+// of these crates+use rayon as _;+use crossbeam_utils as _;+use rayon_core as _;

Does cargo support making these conditional in Cargo.toml? Like

[target.'cfg(windows)'.dependencies]
winapi = { version = "0.3" }

, but for cfg(parallel_compiler).

Aaron1011

comment created time in 2 days

pull request commentrust-lang/rust

Stabilize fn-like proc macros in expression, pattern and statement positions

This is still waiting on me writing the stabilization report, but it's also blocked on https://github.com/rust-lang/rust/pull/68716.

petrochenkov

comment created time in 2 days

pull request commentrust-lang/rust

Stabilize `Span::mixed_site`

@dtolnay Would it be practically possible to make a new major quote release with the new hygiene default? Most proc macro crates will be able to migrate trivially. Macros with hygiene mismatches like those found in https://github.com/rust-lang/rust/pull/68716#issuecomment-583761512 will be able to migrate at their own pace and use the old version in the meantime without any breakage.

petrochenkov

comment created time in 3 days

pull request commentrust-lang/rust

Stabilize `Span::mixed_site`

@dtolnay

This would require some kind of function in proc_macro that returns an enum revealing whether the proc macro currently being expanded is in item position, statement, expression, pattern, type, etc (nonexhaustive?).

I would prefer not to block stabilization on this, too many unresolved questions. Imaging the macro call context like this:

#[non_exhaustive] // !
enum MacroCallContext {
    Expression, // Statement?
    Pattern,
    Type,
    Statement, // Item? Expression?
    Item, // Statement?
    TraitItem, // Item?
    ImplItem, // Item?
    ForeignItem, // Item?
    Unknown, // !
}

First, an explicitly Unknown context should be supported, because macros should be expandable in situations like eager expansion where we just paste tokens into tokens without any AST-like context.

Second, the AST-like context itself is pretty vague.

fn main() {
    // Item statement - item context or statement context?
    #[attr]
    struct S;

    // Trailing position in a block - statement or expression?
    mac!()
}

Should we report trait/impl/foreign items as just items, given the ongoing syntax unification effort?

The TokenStream model was chosen to avoid answering AST-related questions like this, and with the macro call context support they will kinda creep in again.

petrochenkov

comment created time in 3 days

pull request commentrust-lang/rust

proc_macro: Stabilize `Span::resolved_at` and `Span::located_at`

There are a few alternatives in terms of naming and the function signatures here. I think the status quo hits a sweet spot between them.

The primary alternative is some API looking like,

impl Span {
	fn set_location(&mut self, location: ???);
	fn set_hygiene_context(&mut self, hygiene_context: ???);
}

, which has some issues.

  • We don't have stable types representing the location alone and the hygienic context alone. All our API is in terms of spans and it seems reasonable to keep the API surface minimal as it is now for both simplicity (less types less issues) and faster stabilization. This means the API will combine locations and hygiene from spans.

    impl Span {
    	fn set_location_from(&mut self, location: Span);
    	fn set_hygiene_context_from(&mut self, hygiene_context: Span);
    }
    
  • The setter interface is just inconvenient in practice. Built-in macros in the compiler use similar location and hygiene combining a lot, and they eventually evolved to a functional-style API returning a new span rather than modifying the old one for ergonomics.

    impl Span {
    	fn with_location_from(&self, location: Span) -> Span;
    	fn with_hygiene_context_from(&mut self, hygiene_context: Span) -> Span;
    }
    

This kind of promises that Span is cheaply copyable, but we already kind of promise it because Span is already Copy.

  • "Hygiene context" is too abstract, nobody knows what it means, the name should preferably tell what the user-visible consequences the choice of context has, and the primary consequence is where the identifier with that context is resolved from.

So, fn located_at and fn resolved_at are basically better worded alternatives of the previous variant.

let span = input_subspan.resolved_at(Span::def_site()); // Nice
petrochenkov

comment created time in 3 days

Pull request review commentrust-lang/rust

parse: fuse associated and extern items up to defaultness

 pub enum ItemKind {     /// A static item (`static`).     ///     /// E.g., `static FOO: i32 = 42;` or `static FOO: &'static str = "bar";`.-    Static(P<Ty>, Mutability, P<Expr>),+    Static(P<Ty>, Mutability, Option<P<Expr>>),

Ah, sorry, ignore this, I assumed statics in both contexts require an initializer, but foreign statics actually do not.

Centril

comment created time in 3 days

pull request commentrust-lang/rust

parse: fuse associated and extern items up to defaultness

@Centril

I think that will lead to more code sharing in terms of pretty printing, visitors, and whatnot

Not significantly, it's basically an extra match function in printing, visitors, parsing and lowering, but instead we do not keep syntactically impossible state in AST. Yes, it doesn't allow to reduce code to absolute minimum, but on the other hand it would be nice to keep AST in check a bit in terms of its closeness to the language.

Centril

comment created time in 3 days

Pull request review commentrust-lang/rust

parse: fuse associated and extern items up to defaultness

 pub type ForeignItem = Item<ForeignItemKind>; /// An item within an `extern` block. #[derive(Clone, RustcEncodable, RustcDecodable, Debug)] pub enum ForeignItemKind {-    /// A foreign function.-    Fn(FnSig, Generics, Option<P<Block>>),-    /// A foreign static item (`static ext: u8`).+    /// A static item (`static FOO: u8`).     Static(P<Ty>, Mutability),-    /// A foreign type.+    /// A function.+    Fn(FnSig, Generics, Option<P<Block>>),+    /// A type.     Ty,-    /// A macro invocation.+    /// A macro expanding to an item.
    /// A macro expanding to items.

0 or more of them. (This is applicable to other macro items.)

Centril

comment created time in 3 days

Pull request review commentrust-lang/rust

parse: fuse associated and extern items up to defaultness

 pub type ForeignItem = Item<ForeignItemKind>; /// An item within an `extern` block. #[derive(Clone, RustcEncodable, RustcDecodable, Debug)] pub enum ForeignItemKind {-    /// A foreign function.-    Fn(FnSig, Generics, Option<P<Block>>),-    /// A foreign static item (`static ext: u8`).+    /// A static item (`static FOO: u8`).     Static(P<Ty>, Mutability),-    /// A foreign type.+    /// A function.

I disagree with comment changes from this commit from https://github.com/rust-lang/rust/pull/69194#issuecomment-586639669 point of view.

Centril

comment created time in 3 days

Pull request review commentrust-lang/rust

parse: fuse associated and extern items up to defaultness

 pub type ForeignItem = Item<ForeignItemKind>; #[derive(Clone, RustcEncodable, RustcDecodable, Debug)] pub enum ForeignItemKind {     /// A static item (`static FOO: u8`).-    Static(P<Ty>, Mutability),+    Static(P<Ty>, Mutability, Option<P<Expr>>),

This commit is generally in the wrong direction given https://github.com/rust-lang/rust/pull/69194#issuecomment-586637192.

Centril

comment created time in 3 days

Pull request review commentrust-lang/rust

parse: fuse associated and extern items up to defaultness

 pub type ForeignItem = Item<ForeignItemKind>; #[derive(Clone, RustcEncodable, RustcDecodable, Debug)] pub enum ForeignItemKind {     /// A static item (`static FOO: u8`).-    Static(P<Ty>, Mutability),+    Static(P<Ty>, Mutability, Option<P<Expr>>),

And further commits too.

Centril

comment created time in 3 days

Pull request review commentrust-lang/rust

parse: fuse associated and extern items up to defaultness

 pub type ForeignItem = Item<ForeignItemKind>; #[derive(Clone, RustcEncodable, RustcDecodable, Debug)] pub enum ForeignItemKind {     /// A static item (`static FOO: u8`).-    Static(P<Ty>, Mutability),+    Static(P<Ty>, Mutability, Option<P<Expr>>),

Also not necessary.

Centril

comment created time in 3 days

Pull request review commentrust-lang/rust

parse: fuse associated and extern items up to defaultness

 pub enum ItemKind {     /// A static item (`static`).     ///     /// E.g., `static FOO: i32 = 42;` or `static FOO: &'static str = "bar";`.-    Static(P<Ty>, Mutability, P<Expr>),+    Static(P<Ty>, Mutability, Option<P<Expr>>),

The option here is also not necessary given https://github.com/rust-lang/rust/pull/69194#issuecomment-586637192. (But it can be parsed and immediately reported for diagnostics though.)

Centril

comment created time in 3 days

pull request commentrust-lang/rust

parse: fuse associated and extern items up to defaultness

Basically we can use a parse_item routine for free items in all cases, but then filter and re-package its results.

Centril

comment created time in 3 days

pull request commentrust-lang/rust

parse: fuse associated and extern items up to defaultness

Here's how I see the end state here

enum ItemKind {
    Fn(FnCommon),
    Const(ConstCommon),
    TyAlias(TyAliasCommon),
    Mac(MacCommon),
    Static(StaticCommon),
    ... // Others
}

enum AssocItemKind {
    Fn(FnCommon),
    Const(ConstCommon),
    TyAlias(TyAliasCommon),
    Mac(MacCommon),
}

enum ForeignItemKind {
    Fn(FnCommon),
    TyAlias(TyAliasCommon),
    Mac(MacCommon),
    Static(StaticCommon),
}

, modulo the *Common naming.

All *Common things share data structures and parsing code, but ItemKind, AssocItemKind and ForeignItemKind are still different enums because they support different subsets of items inside them at parse time (at least in the near future).

Centril

comment created time in 3 days

pull request commentrust-lang/rust

parse: fuse associated and extern items up to defaultness

The grammar of extern items now recognize const items. The grammar of associated items now recognize static items.

This is excessive, IMO. The goal is unify with free items as well, does that mean we'll syntactically accept e.g. struct inside traits or extern blocks? I don't think so. We can parse them (for better diagnostics) while still issuing immediate errors in the parser.

Centril

comment created time in 3 days

pull request commentrust-lang/rust

Record proc macro harness order for use during metadata deserialization

r=me with comments added to AST as well.

Aaron1011

comment created time in 3 days

Pull request review commentrust-lang/rust

Record proc macro harness order for use during metadata deserialization

 pub struct Crate {     pub module: Mod,     pub attrs: Vec<Attribute>,     pub span: Span,

Could you add a comment here telling that the order of items in HIR is unrelated to order of items in AST, but the AST order is referred to by code generated by proc macro harness, so we have to preserve it in some form. It should be clearly visible that this field only exists to preserve the order.

Aaron1011

comment created time in 3 days

pull request commentrust-lang/rust

Record proc macro harness order for use during metadata deserialization

Ahaha, it turns out the order of items in HIR is not related to the order of items in AST at all, any similarity is purely coincidental.

Me and alexcrichton used some seriously outdated knowledge in https://github.com/rust-lang/rust/pull/64528. This PR is doing the right thing, but needs some more comments.

Aaron1011

comment created time in 3 days

issue commentrust-lang/rust

beta regression: $crate may not be imported

Introduced in https://github.com/rust-lang/rust/pull/67775 ("Make "use $crate" a hard error ").

Mark-Simulacrum

comment created time in 3 days

pull request commentrust-lang/rust

[WIP] Treat NodeIs as pure values for incremental compilation

Nonterminal tokens don't exist in HIR, they are converted into primitive tokens during AST -> HIR lowering, so NodeIds shouldn't exist in HIR either. HIR hashing can insert some kind of runtime panic for them.

Zoxc

comment created time in 3 days

pull request commentrust-lang/rust

[WIP] Treat NodeIs as pure values for incremental compilation

@eddyb, do you remember these PRs - https://github.com/rust-lang/rust/pull/56492 ("syntax: use MetaPath (a simpler version of Path) for Attribute and MetaItem"), https://github.com/rust-lang/rust/pull/56480 (Use hir::Path instead of ast::Path in HIR Attribute's)? The goal was to avoid AST types being embedded into HIR types due to attributes.

Zoxc

comment created time in 3 days

Pull request review commentrust-lang/rust

O(log n) lookup of associated items by name

 impl<'o, 'tcx> dyn AstConv<'tcx> + 'o {         let trait_did = bound.def_id();         let (assoc_ident, def_scope) =             tcx.adjust_ident_and_get_scope(assoc_ident, trait_did, hir_ref_id);++        // FIXME(ecstaticmorse): Can this use `find_by_name_and_namespace` instead?

Same answer as in https://github.com/rust-lang/rust/pull/69072#discussion_r379839906.

ecstatic-morse

comment created time in 3 days

Pull request review commentrust-lang/rust

O(log n) lookup of associated items by name

 impl<'o, 'tcx> dyn AstConv<'tcx> + 'o {          let (assoc_ident, def_scope) =             tcx.adjust_ident_and_get_scope(binding.item_name, candidate.def_id(), hir_ref_id);++        // FIXME(ecstaticmorse): Can this use `find_by_name_and_kind` instead?

Yes, but that will do the adjustments calculations (which we already did in adjust_ident_and_get_scope above) for the second time. If perf run says it's ok, then it can be done (here and next to other uses of adjust_ident_and_get_scope).

ecstatic-morse

comment created time in 3 days

pull request commentrust-lang/rust

O(log n) lookup of associated items by name

This is certainly over-complicated for my taste.

Let me clarify one thing - is in_definition_order required for performance in any way? E.g. due to faster iteration over vector than over some map with faster search.

If the answer is "no", then I'd prefer to keep only that map in AssociatedItems after making sure that it has the necessary iteration reproducibility properties (BTreeMap, IndexMap, whatever). Visiting the items strictly in the definition order should never be necessary (modulo the lang item issue).

Since the perf issue is no longer super critical on the latest nightlies, then I'd prefer to block this PR until the lang item issue is resolved and this PR's design can be simplified.

ecstatic-morse

comment created time in 3 days

Pull request review commentrust-lang/rust

O(log n) lookup of associated items by name

 impl AssocItem {     } } +// Whether an item exists in the type or value namespace.+#[derive(Copy, Clone, PartialEq, Eq, Debug)]+pub enum Namespace {

This can be removed entirely in favor of librustc_hir::def::Namespace.

ecstatic-morse

comment created time in 3 days

PR opened rust-lang/rust

[tiny] parser: `macro_rules` is a weak keyword

r? @Centril

+9 -6

0 comment

4 changed files

pr created time in 3 days

create barnchpetrochenkov/rust

branch : kwrules

created branch time in 3 days

pull request commentrust-lang/rust

Split non macro portion of unused_doc_comment from macro part into two passes/lints

@yaahc

So I'm not sure what change you're proposing at this point

Something like this, but more careful.

I don't understand how you can tell from check_attributes if you're an attribute of an item that still exists or not.

check_attributes in expand.rs is never an item that still exists. (Except for the case in visit_attribute where people writing it had little idea of what they were doing.)

yaahc

comment created time in 3 days

create barnchpetrochenkov/rust

branch : unudoc

created branch time in 3 days

pull request commentrust-lang/rust

Suggest a comma if a struct initializer field fails to parse

@bors r+

Aaron1011

comment created time in 4 days

pull request commentrust-lang/rust

Do not ICE when encountering `yield` inside `async` block

r=me with tidy fixed

estebank

comment created time in 4 days

pull request commentrust-lang/rust

Avoid calling `fn_sig` on closures

@bors r+

JohnTitor

comment created time in 4 days

pull request commentrust-lang/rust

Split non macro portion of unused_doc_comment from macro part into two passes/lints

the checks on stmts and expressions do not catch unused doc comments after expansion.

That's true, but fn check_attributes in librustc_expand/expand.rs happens during expansion, not after expansion. So it allows to check attributes that no longer exist after expansion.

Some other checks like surface attribute well-formedness are also performed in that place:

macro_rules! empty { () => () }

fn main() {
    // The error below is reported despite the inline attribute disappearing during expansion.
    #[inline = "nonsense"] // error: attribute must be of the form `#[inline]` or `#[inline(always|never)]`
    empty!();
}
yaahc

comment created time in 4 days

pull request commentrust-lang/rust

O(log n) lookup of associated items by name

@ecstatic-morse

For example, some places use comparison with ident.modern() and some places use tcx.hygienic_eq which requires the DefId of the containing impl.

That should depend on whether it's path resolution and "adjustment" is performed (asymmetric, bar in foo::bar is adjusted to foo before comparing identifiers, if that makes sense), or just ident comparison (symmetric, e.g. checking for overlap in inherent associated items).

I don't have all the details in cache, but the last time I was trying to make this consistent in https://github.com/rust-lang/rust/pull/44818. Now I'm not even entirely sure the idea of adjustments makes sense for associated (type-relative) names, as opposed to free (module-relative) names.

ecstatic-morse

comment created time in 4 days

Pull request review commentrust-lang/rust

Avoid calling `fn_sig` on closures

+#![feature(track_caller)]

I'd recommend to trust playground less :) Looks like it's actually doing cargo check on "Build". Regular rustc produces an error when building this code.

UI tests also test in check mode by default, you have to add // build-fail to them to catch later codegen-time or link-time failures.

JohnTitor

comment created time in 4 days

pull request commentrust-lang/rust

Split non macro portion of unused_doc_comment from macro part into two passes/lints

I certainly agree that unused_doc_comments shouldn't be a pre-expansion pass. I however don't think unused_macro_doc_comments should exist.

As it was said previously, the only case that's not reported if unused_macro_doc_comments is removed is something like this

/// Doc comment.
macro_call!();

, and all cases like this can caught by reporting the same unused_doc_comments lint from fn check_attributes in librustc_expand/expand.rs which is called for all attributes disappearing in macro expansion. This can be done with fn buffer_lint if I'm not mistaken (the lint infra is pretty volatile and was changed multiple times recently).

yaahc

comment created time in 4 days

Pull request review commentrust-lang/rust

Avoid calling `fn_sig` on closures

+#![feature(track_caller)]

Why?

JohnTitor

comment created time in 4 days

Pull request review commentrust-lang/rust

Avoid calling `fn_sig` on closures

+#![feature(track_caller)]

I don't understand, this particular test requires running or ui tests require running?

JohnTitor

comment created time in 4 days

pull request commentrust-lang/rust

Avoid calling `fn_sig` on closures

r=me after moving the test to ui, if that's possible.

JohnTitor

comment created time in 4 days

Pull request review commentrust-lang/rust

Avoid calling `fn_sig` on closures

+#![feature(track_caller)]

Any specific reason to put this test into compile-fail instead of ui? compile-fail is generally deprecated and only contains tests with not fully reproducible or heavily platform-specific output.

JohnTitor

comment created time in 4 days

Pull request review commentrust-lang/rust

Avoid calling `fn_sig` on closures

 fn codegen_fn_attrs(tcx: TyCtxt<'_>, id: DefId) -> CodegenFnAttrs {         } else if attr.check_name(sym::thread_local) {             codegen_fn_attrs.flags |= CodegenFnAttrFlags::THREAD_LOCAL;         } else if attr.check_name(sym::track_caller) {-            if tcx.fn_sig(id).abi() != abi::Abi::Rust {-                struct_span_err!(tcx.sess, attr.span, E0737, "`#[track_caller]` requires Rust ABI")+            if !tcx.is_closure(id) {+                if tcx.fn_sig(id).abi() != abi::Abi::Rust {

Closures are not Abi::Rust, so the error should likely be reported for them as well.

JohnTitor

comment created time in 4 days

Pull request review commentrust-lang/rust

Avoid calling `fn_sig` on closures

 fn codegen_fn_attrs(tcx: TyCtxt<'_>, id: DefId) -> CodegenFnAttrs {                 codegen_fn_attrs.export_name = Some(s);             }         } else if attr.check_name(sym::target_feature) {-            if tcx.fn_sig(id).unsafety() == Unsafety::Normal {-                let msg = "`#[target_feature(..)]` can only be applied to `unsafe` functions";-                tcx.sess-                    .struct_span_err(attr.span, msg)-                    .span_label(attr.span, "can only be applied to `unsafe` functions")-                    .span_label(tcx.def_span(id), "not an `unsafe` function")-                    .emit();+            if !tcx.is_closure(id) {+                if tcx.fn_sig(id).unsafety() == Unsafety::Normal {

Closures are not unsafe, so the error should be reported for them as well.

JohnTitor

comment created time in 4 days

pull request commentrust-lang/rust

Follow-up to #68848

r? @Mark-Simulacrum

nnethercote

comment created time in 5 days

pull request commentrust-lang/rust

expand: misc cleanups and simplifications

@bors r+

Centril

comment created time in 5 days

pull request commentrust-lang/rust

parse: merge `fn` syntax + cleanup item parsing

@bors r+

Centril

comment created time in 5 days

pull request commentrust-lang/rust

Move resolve_instance to rustc_ty.

@cjgillot Could you squash the commits before this PR is merged, so it doesn't pollute rustc_resolve history?

cjgillot

comment created time in 5 days

pull request commentrust-lang/rust

Fix box_region.rs

r? @Zoxc

lebensterben

comment created time in 6 days

issue commentrust-lang/rust

Incorrect help message for type declared on struct using raw identifier

why we can't format all identifiers according to the edition used by current project?

We can, that would be a very good approximation for the suggestion №2, since we are mostly reporting error for identifiers coming directly from the current crate.

That would be Ident::with_dummy_span(name) from the original version of https://github.com/rust-lang/rust/pull/68963. The only thing is that I'd like to see a method with some other name than Ident::with_dummy_span(name), because it's entirely unclear why you need to create an Ident, if you can just print the name, unless you know about this subtlety about raw identifiers.

olegnn

comment created time in 6 days

pull request commentrust-lang/rust

move unused_doc_comment lint to later pass

@bors rollup- (I'd like to review this.)

yaahc

comment created time in 7 days

pull request commentrust-lang/rust

Suggestion when encountering assoc types from hrtb

Could someone take this over? I have too many assigned PRs. r? @nagisa

estebank

comment created time in 7 days

issue openedrust-lang/rust

LLVM: rustllvm produces unsilenceable warnings on new versions of GCC (9.2.0)

... which are pretty annoying. It probably wouldn't be a problem if Cargo didn't cache the warnings and didn't display them on every build, even if rustllvm isn't actually built.

Example of the warnings:

warning: In file included from ../rustllvm/rustllvm.h:4,
warning:                  from ../rustllvm/PassWrapper.cpp:6:
warning: C:/msys64/home/we/rust/src/llvm-project/llvm/include/llvm/ADT/ArrayRef.h: In instantiation of 'llvm::ArrayRef<T>::ArrayRef(const std::initializer_list<_Tp>&) [with T = long long unsigned int]':
warning: C:/msys64/home/we/rust/src/llvm-project/llvm/include/llvm/IR/DIBuilder.h:644:74:   required from here
warning: C:/msys64/home/we/rust/src/llvm-project/llvm/include/llvm/ADT/ArrayRef.h:101:37: warning: initializing 'llvm::ArrayRef<long long unsigned int>::Data' from 'std::initializer_list<long long unsigned int>::begin' does not extend the lifetime of the underlying array [-Winit-list-lifetime]
warning:   101 |     : Data(Vec.begin() == Vec.end() ? (T*)nullptr : Vec.begin()),

This is fixed in LLVM upstream (https://github.com/llvm/llvm-project/commit/6c2151bf4c829958891e65a4cc396daa6d308eb0), so that commit can be cherry-picked into our LLVM fork.

The commit seems to be included into LLVM 10, but I'm not sure when https://github.com/rust-lang/rust/pull/67759 will be able to land.

created time in 7 days

pull request commentrust-lang/rust

On mismatched argument count point at arguments

r=me after squashing the commits

estebank

comment created time in 7 days

pull request commentrust-lang/rust

parse: unify function front matter parsing

r=me after rebase

Centril

comment created time in 7 days

pull request commentrust-lang/rust

Suggest correct raw identifier in case of typo

@bors r-

Let's discuss treating this as wontfix first - https://github.com/rust-lang/rust/issues/69053#issuecomment-584768407.

olegnn

comment created time in 7 days

issue commentrust-lang/rust

Incorrect help message for type declared on struct using raw identifier

Suggestion №1: Forget about raw identifier after the original tokens are lost (~lexing/parsing/expansion) and never report them.

Suggestion №2: Use an approximate identifier printing routine that may print edition-specific keywords inaccurately, but at least doesn't require keeping precise spans. Note that even https://github.com/rust-lang/rust/pull/68963 doesn't do edition hygiene correctly, because the spans it uses may be stripped from "transparent" macro layers (e.g. ident = ident.modern()) which are not needed for name resolution, but must be preserved for edition hygiene.

olegnn

comment created time in 7 days

issue commentrust-lang/rust

Incorrect help message for type declared on struct using raw identifier

I wonder whether cases like this need to be "fixed" at all. There going to be an endless stream of these issues, basically every diagnostic that reports an arbitrary identifier.

I'm not sure whether https://github.com/rust-lang/rust/pull/68963 alone has the right cost/benefit ratio for merging, let alone changing this everywhere.

olegnn

comment created time in 7 days

pull request commentrust-lang/rust

Add lint when no doc is present at the crate-level

This PR is still missing motivation.

If the lint is not enabled by default, then we already have missing_docs that can be enabled. If the lint is enabled by default in rustdoc runs, then we already have missing_docs that can be reported by rustdoc as well, it should have all the necessary information.

GuillaumeGomez

comment created time in 7 days

more