- 11 8月, 2019 4 次提交
-
-
由 bors 提交于
diagnostics: Describe crate root modules in `DefKind::Mod` as "crate" Or we can use "extern crate" like resolve previously did sometimes, not sure. r? @davidtwco
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
-
由 bors 提交于
rustdoc: general cleanups This is purely a refactoring, mostly just simplifying some of the code. Commits are best reviewed individually.
-
- 10 8月, 2019 36 次提交
-
-
由 Mazdak Farrokhzad 提交于
Cleanup & Simplify stuff in lowering Closes https://github.com/rust-lang/rust/issues/60253 as a byproduct. It turns out that it is in fact necessary to have a `DropTemps(...)` around the `match_expr` and there is a test (https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-13304.rs) which fails without that. r? @EddyB
-
由 Mazdak Farrokhzad 提交于
.gitignore: Readd `/tmp/` Specifically, `/tmp/partitioning-tests/` it is generated by the incremental tests, https://github.com/rust-lang/rust/search?p=2&q=partitioning-tests&unscoped_q=partitioning-tests. These are cleaned up by compiletest but not if you kill testing prematurely (which I just did to test out a rollup, and it is annoying to `rm -rf tmp/`). r? @Mark-Simulacrum cc @RalfJung
-
由 Mazdak Farrokhzad 提交于
Cleanup historical stability comments These weren't removed by ccbcc720 most likely by accident, let's clean them up now.
-
由 Mazdak Farrokhzad 提交于
Try to break resolve into more isolated parts Some small step towards resolve librarification. "Late resolution" is the pass that resolves most of names in a crate beside imports and macros. It runs when the crate is fully expanded and its module structure is fully built. So we just walk through the crate and resolve all the expressions, types, etc. This pass is pretty self-contained, but it was previously done by implementing `Visitor` on the whole `Resolver` (which is used for many other tasks), and fields specific to this pass were indiscernible from the global `Resolver` state. This PR moves the late resolution pass into a separate visitor and a separate file, fields specific to this visitor are moved from `Resolver` as well. I'm especially happy about `current_module` being removed from `Resolver`. It was used even for operations not related to visiting and changing the `current_module` position in process. It was also used as an implicit argument for some functions used in this style ```rust let orig_current_module = mem::replace(&mut self.current_module, module); self.resolve_ident_somewhere(); self.current_module = orig_current_module; ``` and having effects on e.g. privacy checking somewhere deeply inside `resolve_ident_somewhere`. Now we explicitly pass a `ParentScope` to those functions instead, which includes the module and some other data describing our position in the crate relatively to which we resolve names. Rustdoc was one of the users of `current_module`, it set it for resolving intra-doc links. Now it passes it explicitly as an argument as well (I also supported resolving paths from rustdoc in unnamed blocks as a drive-by fix). Visibility resolution is also changed to use early resolution (which is correct because it's used during the work of `BuildReducedGraphVisitor`, i.e. integration of a new AST fragment into the existing partially built module structures.) instead of untimely late resolution (which worked only due to restrictions on paths in visibilities like inability to refer to anything except ancestor modules). This slightly regresses its diagnostics because late resolution has a more systematic error detection and recovery currently. Due to changes in `current_module` and visibilities `BuildReducedGraphVisitor` ended up almost as heavily affected by this refactoring as late resolution. Fixes https://github.com/rust-lang/rust/issues/63223 (due to visibility resolution changes).
-
由 Mark Rousskov 提交于
-
由 Mark Rousskov 提交于
-
由 Mark Rousskov 提交于
-
由 Mark Rousskov 提交于
-
由 Mark Rousskov 提交于
-
由 Mark Rousskov 提交于
Also privatizes needlessly public methods to enforce which methods callers are intended to call, i.e., only `new` and `visit`.
-
由 Mark Rousskov 提交于
Previously visit could be called multiple times, but this is inaccurate, as it deconstructs Visitor state.
-
由 Mark Rousskov 提交于
-
由 Mark Rousskov 提交于
-
由 Vadim Petrochenkov 提交于
Make the `is_import` flag in `ScopeSet` independent from namespace Fix rebase
-
由 Mazdak Farrokhzad 提交于
-
由 Vadim Petrochenkov 提交于
Cleanup some surrounding code. Support resolution of intra doc links in unnamed block scopes. (Paths from rustdoc now use early resolution and no longer need results of late resolution like all the built ribs.) Fix one test hitting file path limits on Windows.
-
由 Vadim Petrochenkov 提交于
Move methods logically belonging to build-reduced-graph into `impl BuildReducedGraphVisitor` and `build_reduced_graph.rs` Move types mostly specific to late resolution closer to the late resolution visitor
-
由 Vadim Petrochenkov 提交于
Rename it to `report_error` and move into `diagnostics.rs` Also turn `check_unused` into a method on `Resolver`
-
由 Vadim Petrochenkov 提交于
It's now immediately clear what fields belong to the global resolver state and what are specific to passes/visitors.
-
由 Vadim Petrochenkov 提交于
Instead of tracking current module and other components separately. (`ParentScope` includes the module as a component.)
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
Move `Resolver` fields specific to late resolution to the new visitor. The `current_module` field from `Resolver` is replaced with two `current_module`s in `LateResolutionVisitor` and `BuildReducedGraphVisitor`. Outside of those visitors `current_module` is replaced by passing `parent_scope` to more functions and using the parent module from it. Visibility resolution no longer have access to later resolution methods and has to use early resolution, so its diagnostics in case of errors regress slightly.
-
由 bors 提交于
Sort the fat LTO modules to produce deterministic output. Some projects that use LTO for their release builds are not reproducible. We can fix this by sorting the fat LTO modules before using them. It might also be useful to do this for thin LTO, but I couldn't get that to work to test it so I didn't do it.
-
由 Mazdak Farrokhzad 提交于
-
由 Mazdak Farrokhzad 提交于
-
由 Mazdak Farrokhzad 提交于
It is produced during `./x.py test`
-
由 bors 提交于
Rollup of 7 pull requests Successful merges: - #63056 (Give built-in macros stable addresses in the standard library) - #63337 (Tweak mismatched types error) - #63350 (Use associated_type_bounds where applicable - closes #61738) - #63394 (Add test for issue 36804) - #63399 (More explicit diagnostic when using a `vec![]` in a pattern) - #63419 (check against more collisions for TypeId of fn pointer) - #63423 (Mention that tuple structs are private if any of their fields are) Failed merges: r? @ghost
-
由 Mazdak Farrokhzad 提交于
Mention that tuple structs are private if any of their fields are CC #39703
-
由 Mazdak Farrokhzad 提交于
check against more collisions for TypeId of fn pointer Cc https://github.com/rust-lang/rfcs/pull/2738#issuecomment-519923318
-
由 Mazdak Farrokhzad 提交于
More explicit diagnostic when using a `vec![]` in a pattern ``` error: unexpected `(` after qualified path --> $DIR/vec-macro-in-pattern.rs:3:14 | LL | Some(vec![x]) => (), | ^^^^^^^ | | | unexpected `(` after qualified path | in this macro invocation | use a slice pattern here instead | = help: for more information, see https://doc.rust-lang.org/edition-guide/rust-2018/slice-patterns.html = note: this warning originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info) ``` Fix #61933.
-
由 Mazdak Farrokhzad 提交于
Add test for issue 36804 I slightly reduced the repro that ICEs on nightly-2017-01-20. Closes #36804
-
由 Mazdak Farrokhzad 提交于
Use associated_type_bounds where applicable - closes #61738
-
由 Mazdak Farrokhzad 提交于
Tweak mismatched types error - Change expected/found for type mismatches in `break` - Be more accurate when talking about diverging match arms - Tweak wording of function without a return value - Suggest calling bare functions when their return value can be coerced to the expected type - Give more parsing errors when encountering `foo(_, _, _)` Fix #51767, fix #62677, fix #63136, cc #37384, cc #35241, cc #51669.
-
由 Mazdak Farrokhzad 提交于
Give built-in macros stable addresses in the standard library Continuation of https://github.com/rust-lang/rust/pull/62086. Derive macros corresponding to traits from libcore are now available through the same paths as those traits: - `Clone` - `{core,std}::clone::Clone` - `PartialEq` - `{core,std}::cmp::PartialEq` - `Eq` - `{core,std}::cmp::Eq` - `PartialOrd` - `{core,std}::cmp::PartialOrd` - `Ord` - `{core,std}::cmp::Ord` - `Default` - `{core,std}::default::Default` - `Debug` - `{core,std}::fmt::Debug` - `Hash` - `{core,std}::hash::Hash` - `Copy` - `{core,std}::marker::Copy` Fn-like built-in macros are now available through libcore and libstd's root module, by analogy with non-builtin macros defined by libcore and libstd: ```rust {core,std}::{ __rust_unstable_column, asm, assert, cfg, column, compile_error, concat, concat_idents, env, file, format_args, format_args_nl, global_asm, include, include_bytes, include_str, line, log_syntax, module_path, option_env, stringify, trace_macros, } ``` Derive macros without a corresponding trait in libcore or libstd are still available only through prelude (also see https://github.com/rust-lang/rust/pull/62507). Attribute macros also keep being available only through prelude, mostly because they don't have an existing practice to follow. An advice from the library team on their eventual placement would be appreciated. ```rust RustcDecodable, RustcEncodable, bench, global_allocator, test, test_case, ``` r? @alexcrichton
-
由 bors 提交于
Stabilize duration_float Closes: #54361