-
Notifications
You must be signed in to change notification settings - Fork 424
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Improved robustness of internal modules including standard ones
This checkin fixes the two userInsteadOfStandard futures as well as the case-insensitive filename issue that cropped up on the Mac after my commits yesterday. In particular, it permits a user module to take the same name as a standard module without affecting the ability of an internal module to use that standard module to implement itself. It does this without duplicating the storage for the standard module in the event that both the user code and the internal modules require it. It does this by changing the build code for the module use statements to keep a list of the PRIM_USE expressions for all internal modules using a vector modReqdByInt ("module required by internal module"). After parsing the ChapelBase and ChapelStandard modules, the compiler attempts to resolve all of their modules using the internal module path, as before. As a result, any standard modules required by the internal modules will not be parsed at this time. We then clear the list of all modules that need to be resolved since we have the full list of modules required by the internal modules in the new modReqdByInt vector. We then parse the Chapel files listed on the command line and then parse any files they depend on as before, which may include some of the standard modules required by the internal modules and/or may involve defining some modules with the same name as those modules. Next, we iterate over all the modules required by the internal modules and see whether we've read in such a module as a standard and/or user module. If we haven't read in the standard module, we do so now. If we did not read a user module with the same name we're done. If we have, we rename the standard module to a unique filename (currently chpl_ followed by the module's original name) and update the use statements in the internal module to refer to this new name. This is reasonable and legal because as far as the user's code is concerned, this module was never read in by the program. Note that the dual approach could be taken (read in the standard modules for the internal modules first and in the event that the user modules end up using modules by the same name, rename the user's use statements and modules. I took the approach here under the assumption that (a) in large programs there would be more user modules than standard modules required by internal modules, and (b) Chapel users would have an easier time reasoning about their code if their names were preserved rather than munged. Removed the .future files for the tests that now work, updated the printModStuff test to reflect the current parse order (though in retrospect, perhaps I shouldn't have had the pass print out the standard modules required by the internal modules with --no-devel since they aren't part of the user's view of the world). This change also makes it so that if the --print-module-files flag is on and we're in developer mode, the internal modules are printed out in addition to the user and standard ones. git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@15935 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
- Loading branch information
Showing
9 changed files
with
78 additions
and
26 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file was deleted.
Oops, something went wrong.
This file was deleted.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,2 +1,3 @@ | ||
warning: Ambiguous module source file -- using ./Math.chpl over /Users/bradc/chapel/modules/standard/Math.chpl | ||
In my math! | ||
In my foo2 |