https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.28.0 2018-06-19T02:17:52+00:00 2018-06-19T02:17:52+00:00 bors bors@rust-lang.org 2018-06-19T02:17:52+00:00 urn:sha1:ed39523406fea9d4c82f87f4ac9ad92388084123 Fix processing mod with multi-level path on Windows Fix error in [rustfmt](https://github.com/rust-lang-nursery/rustfmt/issues/1754) because libsyntax can not handle `mod` with multilevel path on Windows. Alternative is do almost same in https://github.com/rust-lang/rust/blob/master/src/libstd/sys/windows/fs.rs#L717 to allow work on paths with different separators, Ex. "\\\\?\\c:\\windows/temp" 2018-06-17T14:05:43+00:00 bors bors@rust-lang.org 2018-06-17T14:05:43+00:00 urn:sha1:9181741ede48e0f7b8a0cdf838fd09cc4b1aa1c2 Follow up to #51508, make parse_block public instead parse_block_expr This is an follow up to #51508 I mistakenly made parse_block_expr public instead of parse_block. This fixes this. 2018-06-17T09:48:10+00:00 bors bors@rust-lang.org 2018-06-17T09:48:10+00:00 urn:sha1:594b05dd9786c09c916745c1b1c281a3c54cdbd1 refactor: create multiple HIR items for imports When lowering `use` statements into HIR, they get a `Def` of the thing they're pointing at. This is great for things that need to know what was just pulled into scope. However, this is a bit misleading, because a `use` statement can pull things from multiple namespaces if their names collide. This is a problem for rustdoc, because if there are a module and a function with the same name (for example) then it will only document the module import, because that's that the lowered `use` statement points to. The current version of this PR does the following: * Whenever the resolver comes across a `use` statement, it loads the definitions into a new `import_map` instead of the existing `def_map`. This keeps the resolutions per-namespace so that all the target definitions are available. * When lowering `use` statements, it looks up the resolutions in the `import_map` and creates multiple `Item`s if there is more than one resolution. * To ensure the `NodeId`s are properly tracked in the lowered module, they need to be created in the AST, and pulled out as needed if multiple resolutions are available. Fixes https://github.com/rust-lang/rust/issues/34843 2018-06-16T06:00:14+00:00 PSeitz PSeitz@users.noreply.github.com 2018-06-14T08:18:44+00:00 urn:sha1:b1c0857f6246c3359c1e40a2a39d938f267ee2a4 This is an follow up to #51508 I mistakenly made parse_block_expr public instead of parse_block. This fixes this. 2018-06-15T19:05:25+00:00 bors bors@rust-lang.org 2018-06-15T19:05:25+00:00 urn:sha1:967c1f3be1c9ce0469ae9e30659bdf4da5346a9f Add error message for using >= 65535 hashes for raw string literal escapes Fixes #50111. 2018-06-14T22:47:28+00:00 QuietMisdreavus grey@quietmisdreavus.net 2018-06-13T16:44:06+00:00 urn:sha1:122b5b47c2d8387a5095c3cac50fe11c9aaf1369 2018-06-12T17:22:53+00:00 Mark Rousskov mark.simulacrum@gmail.com 2018-06-12T17:22:53+00:00 urn:sha1:1e06b1757c843c4cda538327dbd325378c539bfe Make parse_seq_to_end and parse_path public (see SergioBenitez/Rocket#660, rust-lang/rust#51265) Rocket currently uses `parse_seq_to_end` and `parse_path` in its codegen macros. Assuming I tested correctly, this is the minimal set of methods that are currently necessary to build Rocket again. I would be happy to add documentation of this and Rocket's other usages, if desired. 2018-06-12T11:06:09+00:00 bors bors@rust-lang.org 2018-06-12T11:06:09+00:00 urn:sha1:a1aae290d5560b45353071dc5be7554df5e6f72b Make span_fatal and parse_block public span_fatal and parse_block were made private in #51265. These methods are used in stainless. Related #51498 #51504 2018-06-11T19:19:12+00:00 PSeitz PSeitz@users.noreply.github.com 2018-06-11T19:19:12+00:00 urn:sha1:6fd9ede0cd3a3c73e44a8fdbbb3cabfb622d2a7f span_fatal and parse_block were made private in #51265. These methods are used in stainless. Related #51498 #51504 2018-06-11T16:40:58+00:00 jeb jeb@jebrosen.com 2018-06-11T16:40:58+00:00 urn:sha1:7e56261fcbdaa8d039ee507911f8e5e886de1e41