Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 6 pull requests #62449

Closed
wants to merge 24 commits into from
Closed

Conversation

Centril
Copy link
Contributor

@Centril Centril commented Jul 6, 2019

Successful merges:

Failed merges:

r? @ghost

pawroman and others added 24 commits April 18, 2019 15:30
Co-Authored-By: varkor <github@varkor.com>
Because Weak doesn't Deref, so there's no reason for them to be only
associated methods.
…varkor

Refactor unicode.py script

Hi, I noticed that the `unicode.py` script used some deprecated escapes in regular expressions. E.g. `\d`, `\w`, `\.` will be illegal in the future without "raw strings". This is now fixed. I have also cleaned up the script quite a bit.

## Escape deprecation

OK (note the `r`):
`re.compile(r"\d")`

Deprecated (from Python 3.6 onwards, see [here][link1] and [here][link2]):
`re.compile("\d")`.

[link1]: https://docs.python.org/3.6/whatsnew/3.6.html#deprecated-python-behavior
[link2]: https://bugs.python.org/issue27364

This was evident running the script using Python 3.7 like so:

```
$ python3 -Wall unicode.py
unicode.py:227: DeprecationWarning: invalid escape sequence \w
  re1 = re.compile("^ *([0-9A-F]+) *; *(\w+)")
unicode.py:228: DeprecationWarning: invalid escape sequence \.
  re2 = re.compile("^ *([0-9A-F]+)\.\.([0-9A-F]+) *; *(\w+)")
unicode.py:453: DeprecationWarning: invalid escape sequence \d
  pattern = "for Version (\d+)\.(\d+)\.(\d+) of the Unicode"
```

The documentation states that
> A backslash-character pair that is not a valid escape sequence now generates a DeprecationWarning. Although this will eventually become a SyntaxError, that will not be for several Python releases.

## Testing

To test my changes, I had to add support for choosing the Unicode version to use. The script will default to latest release (which is 12.0.0 at the moment, repo has 11.0.0 checked in).

The script generates the exact same output for version 11.0.0 with Python 2.7 and 3.7 and no longer generates any deprecation warnings:

```
$ python3 -Wall unicode.py -v 11.0.0
Using Unicode version: 11.0.0
Regenerated tables.rs.
$ git diff tables.rs
$ python2 -Wall unicode.py -v 11.0.0
Using Unicode version: 11.0.0
Regenerated tables.rs.
$ git diff tables.rs
$ python2 --version
Python 2.7.16
$ python3 --version
Python 3.7.3
```

## Extra functionality

Furthermore, the script will check and download the latest Unicode version by default (without the `-v` argument). The `--help` is below:

```
$ ./unicode.py --help
usage: unicode.py [-h] [-v VERSION]

Regenerate Unicode tables (tables.rs).

optional arguments:
  -h, --help            show this help message and exit
  -v VERSION, --version VERSION
                        Unicode version to use (if not specified, defaults to
                        latest available final release).
```

## Cleanups

I have cleaned up the code quite a bit, with Python best practices and code style in mind. I'm happy to provide more details and rationale for all my changes if the reviewers so desire.

One externally visible change is that the Unicode data will now be downloaded into `src/libcore/unicode/downloaded` directory suffixed by Unicode version:

```
$ pwd
.../rust/src/libcore/unicode
$ exa -T downloaded/
downloaded
├── 11.0.0
│  ├── DerivedCoreProperties.txt
│  ├── DerivedNormalizationProps.txt
│  ├── PropList.txt
│  ├── ReadMe.txt
│  ├── Scripts.txt
│  ├── SpecialCasing.txt
│  └── UnicodeData.txt
└── 12.0.0
   ├── DerivedCoreProperties.txt
   ├── DerivedNormalizationProps.txt
   ├── PropList.txt
   ├── ReadMe.txt
   ├── Scripts.txt
   ├── SpecialCasing.txt
   └── UnicodeData.txt
```
…ckler

Make the Weak::{into,as}_raw methods

Because Weak doesn't Deref, so there's no reason for them to be only
associated methods.

As kindly pointed out here rust-lang#60766 (comment) by @chpio.
Improve documentation for built-in macros

This is the `libcore` part of rust-lang#62086.
Right now the only effect is improved documentation.

The changes in the last few commits are required to make the `libcore` change compile successfully.
…xcrichton

Remove some uses of mem::uninitialized

cc rust-lang#62397
r? @RalfJung
…_compiler_messages_1, r=Centril

normalize use of backticks/lowercase in compiler messages for librustc_mir

normalize use of backticks/lowercase in compiler messages for librustc_mir

rust-lang#60532

r? @alexreg
@Centril
Copy link
Contributor Author

Centril commented Jul 6, 2019

@bors r+ p=6 rollup=never

@bors
Copy link
Contributor

bors commented Jul 6, 2019

📌 Commit a63886c has been approved by Centril

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Jul 6, 2019
@bors
Copy link
Contributor

bors commented Jul 6, 2019

⌛ Testing commit a63886c with merge 240ee60...

bors added a commit that referenced this pull request Jul 6, 2019
Rollup of 6 pull requests

Successful merges:

 - #60081 (Refactor unicode.py script)
 - #61862 (Make the Weak::{into,as}_raw methods)
 - #62243 (Improve documentation for built-in macros)
 - #62422 (Remove some uses of mem::uninitialized)
 - #62432 (Update rustfmt to 1.3.2)
 - #62436 (normalize use of backticks/lowercase in compiler messages for librustc_mir)

Failed merges:

r? @ghost
@bors
Copy link
Contributor

bors commented Jul 6, 2019

💔 Test failed - checks-azure

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 6, 2019
@Centril Centril closed this Jul 6, 2019
@Centril Centril deleted the rollup-fbqhf11 branch July 6, 2019 18:20
@Centril Centril added the rollup A PR which is a rollup label Oct 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants