unisonweb/unison
1
0
Fork 0
mirror of https://github.com/unisonweb/unison.git synced 2024-09-11 10:35:57 +03:00
Code Issues Projects Releases Wiki Activity

remove ls-pretty-print-scope-bug.md, we don't really support subnamespaces for this any more

Browse Source
This commit is contained in:
Chris Penner 2024-06-26 11:22:32 -07:00
parent 6625996039
commit 59aebe93a5
2 changed files with 0 additions and 159 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

44
unison-src/transcripts/ls-pretty-print-scope-bug.md
View File

@ -1,44 +0,0 @@
```unison
unique type Foo = Foo
```
```ucm
scratch/main a.b> add
scratch/main> fork .a.b .c.d.f
.c.g.f>
```
```unison
unique type Foo = Foo
```
```ucm
scratch/main c.g.f> add
.c>
```
```unison
foo = .d.f.Foo.Foo
```
```ucm
scratch/main c> add
```
At this point we have:
`.a.b.Foo`
`.c.d.f.Foo` which is equal to `.a.b.Foo`
`.c.g.f.Foo` which is distinct from the other `Foo` types
```ucm
scratch/main> delete .c.d.f.Foo
```
Once `.c.d.f.Foo` is deleted `.c.foo` should have the type `.a.b.Foo`
when viewed from `scratch/main>`, but an unnamed type when viewed from `.c>`,
since referencing `.a.b.Foo` would reference names outside of the
namespace rooted at `.c`.
```ucm
scratch/main> ls c
scratch/main c> ls
```

115
unison-src/transcripts/ls-pretty-print-scope-bug.output.md
View File

@ -1,115 +0,0 @@
```unison
unique type Foo = Foo
```
```ucm
Loading changes detected in scratch.u.
I found and typechecked these definitions in scratch.u. If you
do an `add` or `update`, here's how your codebase would
change:
⍟ These new definitions are ok to `add`:
type Foo
```
```ucm
☝️ The namespace .a.b is empty.
.a.b> add
⍟ I've added these definitions:
type Foo
scratch/main> fork .a.b .c.d.f
Done.
☝️ The namespace .c.g.f is empty.
```
```unison
unique type Foo = Foo
```
```ucm
Loading changes detected in scratch.u.
I found and typechecked these definitions in scratch.u. If you
do an `add` or `update`, here's how your codebase would
change:
⍟ These new definitions are ok to `add`:
type Foo
```
```ucm
.c.g.f> add
⍟ I've added these definitions:
type Foo
```
```unison
foo = .d.f.Foo.Foo
```
```ucm
Loading changes detected in scratch.u.
I found and typechecked these definitions in scratch.u. If you
do an `add` or `update`, here's how your codebase would
change:
⍟ These new definitions are ok to `add`:
foo : d.f.Foo
```
```ucm
.c> add
⍟ I've added these definitions:
foo : d.f.Foo
```
At this point we have:
`.a.b.Foo`
`.c.d.f.Foo` which is equal to `.a.b.Foo`
`.c.g.f.Foo` which is distinct from the other `Foo` types
```ucm
scratch/main> delete .c.d.f.Foo
Done.
```
Once `.c.d.f.Foo` is deleted `.c.foo` should have the type `.a.b.Foo`
when viewed from `scratch/main>`, but an unnamed type when viewed from `.c>`,
since referencing `.a.b.Foo` would reference names outside of the
namespace rooted at `.c`.
```ucm
scratch/main> ls c
nothing to show
```
🛑
The transcript failed due to an error in the stanza above. The error is:
nothing to show