resolve: Introduce (Local,Extern)Module newtypes for local and external modules respectively#155242
Conversation
|
r? @jackh726 rustbot has assigned @jackh726. Use Why was this reviewer chosen?The reviewer was selected based on:
|
|
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
resolve: Introduce `(Local,Extern)Module` newtypes for local and external modules respectively
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (64fb35f): comparison URL. Overall result: ❌✅ regressions and improvements - no action neededBenchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf. @bors rollup=never Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)This perf run didn't have relevant results for this metric. CyclesResults (primary 5.1%, secondary 9.8%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis perf run didn't have relevant results for this metric. Bootstrap: 491.114s -> 489.595s (-0.31%) |
|
@bors r+ |
resolve: Introduce `(Local,Extern)Module` newtypes for local and external modules respectively Right now both `LocalModule` and `ExternModule` refer to the same `ModuleData`, but the module data for local and extern modules can potentially be made quite different, and we can specialize name lookup for both cases as an optimization. Declaration creation for local and external modules was already specialized as a part of the parallel import resolution work (see `define_local` and `define_extern`, rust-lang#145108 and previous PRs), because they have different properties with regards to ownership and synchronization.
resolve: Introduce `(Local,Extern)Module` newtypes for local and external modules respectively Right now both `LocalModule` and `ExternModule` refer to the same `ModuleData`, but the module data for local and extern modules can potentially be made quite different, and we can specialize name lookup for both cases as an optimization. Declaration creation for local and external modules was already specialized as a part of the parallel import resolution work (see `define_local` and `define_extern`, rust-lang#145108 and previous PRs), because they have different properties with regards to ownership and synchronization.
This comment has been minimized.
This comment has been minimized.
…rnal modules respectively
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
@bors r=mu001999 |
…uwer Rollup of 5 pull requests Successful merges: - #154781 (Fix attribute order implementation) - #155242 (resolve: Introduce `(Local,Extern)Module` newtypes for local and external modules respectively) - #149614 (Use `MaybeDangling` in `std`) - #153178 (Add `TryFromIntError::kind` method and `IntErrorKind::NotAPowerOfTwo` variant) - #155049 (Documenting the case of `Weak::upgrade` returning `None` when the value behind the reference is missing) Failed merges: - #155308 (Make `OnDuplicate::Error` the default for attributes)
…uwer Rollup of 5 pull requests Successful merges: - #154781 (Fix attribute order implementation) - #155242 (resolve: Introduce `(Local,Extern)Module` newtypes for local and external modules respectively) - #149614 (Use `MaybeDangling` in `std`) - #153178 (Add `TryFromIntError::kind` method and `IntErrorKind::NotAPowerOfTwo` variant) - #155049 (Documenting the case of `Weak::upgrade` returning `None` when the value behind the reference is missing) Failed merges: - #155308 (Make `OnDuplicate::Error` the default for attributes)
Rollup merge of #155242 - petrochenkov:modmodmod, r=mu001999 resolve: Introduce `(Local,Extern)Module` newtypes for local and external modules respectively Right now both `LocalModule` and `ExternModule` refer to the same `ModuleData`, but the module data for local and extern modules can potentially be made quite different, and we can specialize name lookup for both cases as an optimization. Declaration creation for local and external modules was already specialized as a part of the parallel import resolution work (see `define_local` and `define_extern`, #145108 and previous PRs), because they have different properties with regards to ownership and synchronization.
Right now both
LocalModuleandExternModulerefer to the sameModuleData, but the module data for local and extern modules can potentially be made quite different, and we can specialize name lookup for both cases as an optimization.Declaration creation for local and external modules was already specialized as a part of the parallel import resolution work (see
define_localanddefine_extern, #145108 and previous PRs), because they have different properties with regards to ownership and synchronization.