See #41444. As a first step towards untangling `ParameterEnvironment`, change
its `caller_bounds` field from a `Vec` into an interned slice of
`ty::Predicate`s.
This change is intentionally well-contained and doesn't pull on any of the
loose ends. In particular, you'll note that `normalize_param_env_or_error`
now interns twice.
Support for disabling ELF-style thread local storage in
the standard library at configure time was removed in
pulls #30417 and #30678, in favour of a member in
the TargetOptions database. The new method respects
MACOSX_DEPLOYMENT_TARGET on macOS, addressing the
original use case for this configure option.
However, those commits left the configure option itself
in place. It's no longer referenced anywhere and can
be removed.
This is a more principled version of the `RefCell` we were using
before. We now allocate a `Steal<Mir<'tcx>>` for each intermediate MIR
pass; when the next pass steals the entry, any later attempts to use it
will panic (there is no way to *test* if MIR is stolen, you're just
supposed to *know*).
The new setup is as follows. There is a pipeline of MIR passes that each
run **per def-id** to optimize a particular function. You are intended
to request MIR at whatever stage you need it. At the moment, there is
only one stage you can request:
- `optimized_mir(def_id)`
This yields the final product. Internally, it pulls the MIR for the
given def-id through a series of steps. Right now, these are still using
an "interned ref-cell" but they are intended to "steal" from one
another:
- `mir_build` -- performs the initial construction for local MIR
- `mir_pass_set` -- performs a suite of optimizations and transformations
- `mir_pass` -- an individual optimization within a suite
So, to construct the optimized MIR, we invoke:
mir_pass_set((MIR_OPTIMIZED, def_id))
which will build up the final MIR.
Overall goal: reduce the amount of context a mir pass needs so that it
resembles a query.
- The hooks are no longer "threaded down" to the pass, but rather run
automatically from the top-level (we also thread down the current pass
number, so that the files are sorted better).
- The hook now receives a *single* callback, rather than a callback per-MIR.
- The traits are no longer lifetime parameters, which moved to the
methods -- given that we required
`for<'tcx>` objecs, there wasn't much point to that.
- Several passes now store a `String` instead of a `&'l str` (again, no
point).
It's possible to build the sanitizers when using an external LLVM, but
we still need cmake for this. Extend the sanity check to look for cmake
whenever sanitizers are enabled too.
Removal pass for anonymous parameters
Removes occurences of anonymous parameters from the
rustc codebase, as they are to be deprecated.
See issue #41686 and RFC 1685.
r? @frewsxcv
Add a lint to disallow anonymous parameters
Adds a (allow by default) lint to disallow anonymous parameters, like it was decided in RFC 1685 (rust-lang/rfcs#1685).
cc tracking issue #41686
On demandify region mapping
This is an adaptation of @cramertj's PR. I am sort of tempted to keep simplifying it, but also tempted to land it so and we can refactor more in follow-up PRs. As is, it does the following things:
- makes the region-maps an on-demand query, per function `tcx.region_maps(def_id)`
- interns code extents instead of of having them be integers
- remove the "root region extent" and (to some extent) item extents; instead we use `Option<CodeExtent<'tcx>>` in a few places (no space inefficiency since `CodeExtent<'tcx>` is now a pointer).
I'm not entirely happy with the way I have it setup though. Here are some of the changes I was considering (I'm not sure if they would work out well):
1. Removing `item_extents` entirely -- they are rarely used now, because most of the relevant places now accept an `Option<Region<'tcx>>` or an `Option<CodeExtent<'tcx>>`, but I think still used in a few places.
2. Merging `RegionMaps` into the typeck tables, instead of having it be its own query.
3. Change `CodeExtent<'tcx>` to store the parent pointer. This would mean that fewer places in the code actually *need* a `RegionMaps` anyhow, since most of them just want to be able to walk "up the tree". On the other hand, you wouldn't be able to intern a `CodeExtent<'tcx>` for some random node-id, you'd need to look it up in the table (since there'd be more information).
Most of this code is semi-temporary -- I expect it to largely go away as we move to NLL -- so I'm also not *that* concerned with making it perfect.
r? @eddyb
Under MinGW, x.py fails to run with UnboundLocalError.
Under MinGW, `x.py` will fail with the following errors:
```bash
$ ./x.py
Traceback (most recent call last):
File "./x.py", line 20, in <module>
bootstrap.main()
File "C:/src/rust/src/bootstrap/bootstrap.py", line 620, in main
bootstrap()
File "C:/src/rust/src/bootstrap/bootstrap.py", line 601, in bootstrap
rb.build = rb.build_triple()
File "C:/src/rust/src/bootstrap/bootstrap.py", line 459, in build_triple
if os.environ.get('MSYSTEM') == 'MINGW64':
UnboundLocalError: local variable 'os' referenced before assignment
```
The reason is due to the `build_triple` function in `src/bootstrap/bootstrap.py` (Line 416):
```python
if ostype == 'Linux':
os = subprocess.check_output(['uname', '-o']).strip().decode(default_encoding)
```
Here, the assignment to `os` is causing the `os` module to be shadowed.
Then, in (Line 459):
```python
if os.environ.get('MSYSTEM') == 'MINGW64':
cputype = 'x86_64'
```
`os` now refers to the uninitialized local variable, not the `os` module.
Easiest fix is to simply rename the `os` variable to something like `os_from_sp`.
Also, there is a small typo fix in `x.py` referencing the wrong file name.
