Summary

Extra modules leak into environment when using -j

Metadata

Attachments

Description

Found by dieggsy on IRC.

When defining multiple modules in a single file and generating an import file for only one of those the namespace from the other modules leaks into the importing code.

In this case it's the srfi-13 leaking into the importing code. Just saying `(import m)` should only bring module `m`'s imports into the environment.

This seems to be a regression from C4.

 (module helper *
         (import scheme)
         (import srfi-13)
         ;; (import chicken) (use srfi-13) ; for C4
 
         (define-syntax complex-foreign-lambda
           (ir-macro-transformer
            (lambda (e i c)
              `(begin)))))
 
 (module m *)
; 4.13.0
; $ csc -s m.scm -j m && csi -qbn -e '(import m) (print (string-null? "") (string-null? "1"))'
;
; Error
unbound variable: string-null?
; chicken-5.0.0rc2
; $ csc -s m.scm -j m && csi -qbn -e '(import m) (print (string-null? "") (string-null? "1"))'
; #t#f
; $ csc -debug 2 -s m.scm -j m
; [[canonicalized]|]
; (##core#callunit library)
;
; (##core#callunit eval)
;
; (##core#callunit expand)
;
; (##core#undefined)
;
; (##core#undefined)
;
; (##core#undefined)
;
; (let ((t43 (##core#provide helper#)))
; (let ((t44 (scheme#eval '(import-syntax scheme srfi-13)))) ; <---- offending import
; (let ((t45 (##sys#register-compiled-module
; 'helper
; 'helper
; (scheme#list)
; '()
; (scheme#list
; (scheme#cons
; 'complex-foreign-lambda
; (chicken.syntax#ir-macro-transformer
; (##core#lambda (e37 i38 c39) (##sys#list 'begin)))))
; (scheme#list))))
; (let ((t46 (chicken.load#load-extension 'srfi-13 '(srfi-13#) 'require)))
; (##core#undefined)))))
;
; (##core#provide m#)
;
; (##core#undefined)

Changes and comments

[2018-10-10 07:42:50 UTC] megane wrote:

I forgot to mention that using `-J` fixes the problem. This moves the offending import to `helper.import.scm`.

[2018-10-10 16:24:54 UTC] sjamaan changed milestone from 5.0 to 5.1

[2018-10-10 16:24:54 UTC] sjamaan wrote:

I'm not sure this is an entirely correct comparison, given that `(import)` is now equivalent to `(use)` in CHICKEN 4. If you do `csc -s m.scm -j m && csi -qbn -e '(use m) (print (string-null? "") (string-null? "1"))'`, you'll notice that it prints the same as C5. So, IMO it's not a true regression and we should probably postpone this to 5.1, especially given that fixing this would probably involve changing the import machinery, which might lead to new bugs and cause other unexpected changes this late in the process.

[2018-10-10 17:00:54 UTC] megane wrote:

Replying to sjamaan: > I'm not sure this is an entirely correct comparison, given that `(import)` is now equivalent to `(use)` in CHICKEN 4. If you do `csc -s m.scm -j m && csi -qbn -e '(use m) (print (string-null? "") (string-null? "1"))'`, you'll notice that it prints the same as C5. So, IMO it's not a true regression and we should probably postpone this to 5.1, especially given that fixing this would probably involve changing the import machinery, which might lead to new bugs and cause other unexpected changes this late in the process.

On CHICKEN 4 `csc -s m.scm -j m && csi -qbn -e '(use m) (print (string-null? "") (string-null? "1"))` gives me `Error: unbound variable: string-null?`. That is the expected behavior.

[2018-10-10 17:14:45 UTC] megane wrote:

Replying to megane: > Replying to sjamaan: ...

There was a PEBKAC issue here. I was compiling the `(import srfi-13)` version, when I should have used the `(use srfi-13)` version. No wonder `string-null?` wasn't found. So my regression judgement is wrong.

[2018-10-10 17:14:45 UTC] megane wrote:

1539184957016477

[2018-10-10 17:14:45 UTC] megane wrote:

1539185021066378

[2019-04-07 12:23:24 UTC] sjamaan changed milestone from 5.1 to 5.2

[2019-04-07 12:23:24 UTC] sjamaan wrote:

Getting ready for 5.1, moving tickets which won't make it in to 5.2.

[2019-08-25 15:15:42 UTC] felix wrote:

Attached is a patch that seems to fix the problem. The module registration code pollutes the global namespace, which doesn't cause problems in import libraries, because the loading is wrapped in a `parameterize` form that preserves the environment. The patch factors out the preservation into a spearate form (`##sys#with-environment`) and wraps the module-registration in such a form.

[2019-08-25 15:16:14 UTC] felix attached 0001-Preserve-global-environment-when-executing-module-re.patch (description=with-environment)

[2019-08-25 15:45:43 UTC] sjamaan changed status from new to closed

[2019-08-25 15:45:43 UTC] sjamaan set resolution to fixed

[2019-08-25 15:45:43 UTC] sjamaan wrote:

Fixed by f43fb51e