David Lukes [Sat, 10 Mar 2018 08:57:01 +0000 (09:57 +0100)]
Enable doctests
Doctests were disabled globally because up until #2456, they were just
formatting examples which were not supposed to compile. Now that there
is one runnable doctest, I disabled the other ones individually (by
adding the ignore directive).
I also added some empty lines around the code blocks to avoid the
following warning and instead ignore the code blocks cleanly:
WARNING: ... Code block is not currently run as a test, but will in
future versions of rustdoc. Please ensure this code block is a runnable
test, or use the `ignore` directive.
Rob Tsuk [Tue, 6 Mar 2018 14:28:08 +0000 (07:28 -0700)]
Restore cargo fmt behavior in workspaces
Previously, cargo fmt invoked without parameters would
only format the crate in the current directory, even if
the crate was part of a workspace. This patch restores
that behavior.
topecongiro [Fri, 9 Mar 2018 08:10:20 +0000 (17:10 +0900)]
Avoid unindenting code block in comment with unformattable macro
`format_code_block` formats the given `code_snippet` by enclosing it inside
`fn main` block. Previously we did not add indentation to the `code_snippet`
before formatting it. This works fine as long as we can format the given
`code_snippet`, but when the code block has unformattable macro, they gets
unindented. This commit fixes it by adding proper indentation before formatting
the `code_snippet`.
For example, when formatting the following code block,
Seiichi Uchida [Wed, 7 Mar 2018 06:40:52 +0000 (15:40 +0900)]
Add overflow module
This commit adds `overflow` module. This module provides two APIs.
`rewrite_with_parens` is basically the same as `rewrite_call_inner`.
`rewrite_with_angle_brackets` is used for rewriting generics and types.
Seiichi Uchida [Tue, 6 Mar 2018 10:56:49 +0000 (19:56 +0900)]
Work around removal of beginning_vert field from ast::Arm
`ast::Arm` used to have `beginning_vert` field whose type is `Option<Span>`
and holds a span of the beginning `|` if available. This field is now removed.
This commit works around that.
Since we only need a `BytePos` of the `|`, the type of `beginning_vert` in
`ArmWrapper` is `Option<BytePos>`.
David Lukes [Mon, 19 Feb 2018 10:00:07 +0000 (11:00 +0100)]
Parse template with state machine instead of regex
This allows occurrences of `{` and `}` within `{}` placeholders in the
template, and also for having literal `{` and `}` in the template by
means of escaping (`\{`).
Unbalanced, unescaped `}` at the toplevel is a syntax error which
currently triggers a panic; I'll add proper error handling as I move the
license template parsing code into the config parsing phase.
David Lukes [Fri, 16 Feb 2018 22:21:57 +0000 (23:21 +0100)]
Attempt at checking for license (#209)
I'm not quite sure how best to handle loading the license template from
a path -- I mean obviously I know *how* to do it, but I'm not sure where
to fit it in the codebase :) So this first attempt puts the license
template directly into the config file.
These are my misgivings about the license template config option as a
path to a file (I'd love feedback if some of these are wrong or can be
easily circumvented!):
1. I thought the obvious choice for the type of `license_template` in
`create_config!` should be `PathBuf`, but `PathBuf` doesn't implement
`FromStr` (yet? see https://github.com/rust-lang/rust/issues/44431), so
it would have to be wrapped in a tuple struct, and I went down that road
for a little while but then it seemed like too much ceremony for too
little gain.
2. So a plain `String` then (which, mind you, also means the same
`doc_hint()`, i.e. `<string>`, not `<path>` or something like that). The
fact that it's a valid path will be checked once we try to read the
file.
3. But where in the code should the license template be read? The
obvious choice for me would be somewhere in `Config::from_toml()`, but
since `Config` is defined via the `create_config!` macro, that would
mean tight coupling between the macro invocation (which defines the
configuration option `license_template`) and its definition (which would
rely on the existence of that option to run the template loading code).
4. `license_template` could also be made a special option which is
hardwired into the macro. This gets rid of the tight coupling, but
special-casing one of the config options would make the code harder to
navigate.
5. Instead, the macro could maybe be rewritten to allow for config
options that load additional resources from files when the config is
being parsed, but that's beyond my skill level I'm afraid (and probably
overengineering the problem if it's only ever going to be used for this
one option).
6. Finally, the file can be loaded at some later point in time, e.g. in
`format_lines()`, right before `check_license()` is called. But to
face a potential *IO* error at so late a stage, when the source files
have already been parsed... I don't know, it doesn't feel right.
BTW I don't like that I'm actually parsing the license template as late
as inside `check_license()` either, but for much the same reasons, I
don't know where else to put it. If the `Config` were hand-rolled
instead of a macro, I'd just define a custom `license_template` option
and load and parse the template in the `Config`'s init. But the way
things are, I'm a bit at a loss.
However, if someone more familiar with the project would kindly provide
a few hints as to how the path approach can be done in a way that is as
clean as possible in the context of the codebase, I'll be more than
happy to implement it! :)